AEM Cloud Service: An Overview of the Top Changes and New Advantages

[#1]

Author: Ankur Ahlawat

Adobe Experience Manager is the recognized leader for digital experience management, and now, it's strengthening this position even further. Adobe is moving Adobe Experience Manager (AEM) to the cloud.

AEM Cloud Service introduces the next generation of the AEM product line, moving away from versioned releases like AEM 6.4, AEM 6.5, etc. to version-less, fully continual releases of "AEM as a Cloud Service." Below, we'll cover:

• The advantages of making AEM a Cloud Service offering
• What changes/challenges this move to AEM as a Cloud Service brings
• Features Not Supported in AEM Cloud Service.

The advantages of AEM as a Cloud Service

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

• High availability: One of the key benefits of moving to AEM Cloud Service is the ability for all services to be always on, so that our customers never experience 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. No longer.
• 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 manually or automatically based on customer requirements.
• The latest code base, always: This might be the most useful and most anticipated feature delivered by AEM Cloud Service to customers. With AEM Cloud Service, Adobe takes care of updating all running instances to the 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 Service equipped with health checks and are self-healing.

The changes and challenges AEM as a Cloud Service brings to table

There are many changes that you will see as part of the AEM cloud jar when you start with your development. Below are a few of the key changes that might impact how you are currently working with AEM:

• The major performance bottleneck that most big enterprise DAM customers will face is, when bulk uploading of assets in an author instance, the DAM Update workflow degrades the performance of the whole author instance. To resolve this, AEM Cloud Service brings in asset microservices for serverless asset processing, powered by Adobe I/O. Now, when an author uploads an asset, it will go directly to cloud binary storage, triggering Adobe I/O, which will take care of further processing by leveraging renditions and other properties that has been configured.
• As AEM Cloud Service is being fully managed by Adobe, you might not be able to access logs directly as a developer/dev ops. As of now, the only way to access these will be via a download link available in Cloud Manager to request access/error/dispatcher logs, etc. https://docs.adobe.com/content/help/en/experience-manager-cloud-service/implementing/developing/deve...
• For AEM Leads, the only way for deployment is through the Cloud Manager and it follows very strong CI/CD pipeline quality checks. This means you should now focus on test driven development with more then 50% test coverage. For more details, check out our full guide to understanding your test results.
• Currently AEM screens and AEM Adaptive Forms are not supported in AEM Cloud Service.
• In order to support a version-less solution, continuous updates will be pushed to AEM base line image, available on the cloud. So, for any customization over the asset UI console or libs granite, internal node (implemented in AEM 6.5) is no longer possible, as it has been replaced with each base line image update.
• Code quality rules, available in Cloud Manager, are not available for application to local sonar before pushing to git, which will increase development time and extra commits to git repo. Once dev code is pushed to a git repository and a build is triggered, sonar checks will run on the Cloud Manager and you be informed as to what is failing. On the safer side, so that you have no sonar issue with the default rules in your local, keep updating rules as 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
• 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 – All features of Web console is not available on dev/stage/prod environment, where as many key features are still supported using developer console. https://docs.adobe.com/content/help/en/experience-manager-cloud-service/implementing/developing/deve...

Questions? Just get in touch

I personally feel that moving to AEM Cloud Service is very beneficial; due to continuous updates, your system will always be up to date with all latest hot fixes. Moving to a cloud-based solution also reduces infrastructure and maintenance costs.

Originally published at http://www.aemcq5tutorials.com on January 28, 2020.

Thanks to Patrick Faller.