AEM Cloud Service – Overview

Adobe Experience Manager is the recognized leader for digital experience management, and now, to strengthen this position even further. Adobe is finally moving its last on premise product Adobe Experience Manager (AEM) to cloud.

AEM Cloud Service introduces the next generation of the AEM product line, going away from versioned releases like AEM 6.4, AEM 6.5 etc to version less fully continual release ” AEM as a Cloud Service “. 

In this tutorial we will see:-

  • Advantages of moving on AEM as Cloud Service offering
  • What changes/challenges AEM as Cloud Service brings to table.
  • Features Not Supported in AEM Cloud Service.

Advantages of Aem as a Cloud Service:-

AEM Cloud Service adopts all benefits of modern cloud based services:

  • High Availability:- One of the key benefit of moving to AEM Cloud Service is the ability for all services to be always on, so that our customers do no experience any downtime. In the past, especially on the author side, there was a need to periodically stop the service for different types of maintenance operations: updates, patches, upgrades, and some routine maintenance operation.
  • Real Time Scalability :- All instances of the AEM Cloud Service are created equal with default sizing. AEM Cloud Service is based on an orchestration engine (Kubernetes) that constantly monitors the state of the service and dynamically scales up and down, depending on the needs of our customers without them having to worry about it. Both vertically and horizontally. Scaling can be done manual or automatic based on customer requirement.
  • Always Latest:- This might be the most useful and much awaited feature delivered by AEM Cloud Service to customers. With AEM Cloud Service Adobe will takes care of updating all running instances to latest code base. Updates will be pushed silently without any downtime.
  • Self-Sustaining and Always Learning:- AEM Cloud Service keeps on learning and evolving itself based on the projects implemented by our customers. Content, code and configurations are constantly reviewed and vetted against best practices, which helps in guiding our customers on how to achieve their business goals. Various components in AEM cloud solution are self- healing by equipping them with health checks.

Changes/Challenges AEM as Cloud Service brings to table

There are many changes that you will see part of aem cloud jar, when you start with your development . Below are few key changes that might impact how we are currently working with aem:-

  • The major performance bottleneck that most of big enterprise DAM customers are facing is bulk uploading of asset on author instance and then DAM Update workflow degrade performance of whole author instance. To resolve this AEM Cloud service brings Asset Microservices for serverless asset processing powered by Adobe I/O. Now when author uploads any asset it will go directly to cloud binary storage then adobe I/O is triggered which will take care of further processing by leveraging renditions and other properties that has been configured.
  • As AEM cloud service is going to be fully managed by Adobe, and as a developer/ dev ops you might not be able to access logs directly. The only way that i know as of today will be a download link available in cloud manager to request for access/ error / dispatcher etc logs.
  • For AEM Leads only way for deployment is through cloud manager and it is following very strong CI/CD pipeline quality checks, now you should focus on test driven development with more then 50% test coverage. for more details visit
  • Currently AEM screens and AEM Adaptive forms are not supported in AEM as a cloud service.
  • In order to support version less solution, continuous updates will be pushed to AEM Base line image available on cloud . So any customization over Asset UI console or libs granite:internal node which was still possible as a workaround to meet customer requirement till AEM 6.5 is not possible any more, as it will be replaced with each base line image update.
  • Code quality rules that are available on cloud manager are not available to be applied to local sonar before pushing to git. which i see will increase the development time and extra commits to git repo. Once dev code is pushed to git repository and build is triggered then sonar checks will run on cloud manager and you will come to know what is failing. As a safer side i advise to have no sonar issue with default rules in you local and keep on updating the rules as and when you encounter them while pushing the code to cloud git.

Features Not Supported in AEM Cloud Service

  • Commerce add-on for AEM Sites.
  • Screens add-on
  • Communities add-on
  • AEM Forms
  • Access to Classic UI.
  • Developer Mode in Page Editor.
  • /apps or /libs are ready-only in dev/stage/prod environment – changes need to come in via CI/CD pipeline that builds the code from the GIT repo.
  • OSGI bundles/settings – Web console is not available on dev/stage/prod environment.

Few open threaded question ?

  • Eventually adobe wants everyone to move to their cloud based solution, but what happens for big on premise customers. Do we have two versions of AEM like for Adobe Campaign Classic and Cloud.

Lastly i just want to conclude that, i personally feel moving to aem cloud service is much beneficial, due to continuous updates, your system will always be up to date with all latest hot fixes. Moving to cloud based solution also reduce infrastructure and maintenance cost.

Please comment below if you face any challenge or see any open questions. It will be helpful for AEM community.

Spread the love

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.