The old, classic Adobe Experience Manager (AEM) was a large monolithic application and had some limitations (e.g., scalability or extensibility). AEM as a Cloud service (AEMaaCS) is the result of refactoring AEM applications into a set of modular components/services that are native to the cloud.

AEMaaCS is the latest addition to the AEM product line that helps you continue to deliver personalized, content-driven experiences to your customers, provides cloud-native flexibility to accelerate time-to-value, and is extensible to meet unique enterprise-level business requirements.

AEMaaCS can be leveraged by building on previous designs and innovations while maintaining and extending all use cases and functionality.

Use of AEMaaCS AEM as a Cloud service enables you to use AEM applications in a cloud-specific way, so you can scale your DevOps efforts with Cloud Manager from Adobe, which offers:

CI/CD structure,
automatic scaling,
API connectivity,
flexible deployment modes,
code quality gates,
transparency of service delivery,
update with guidelines.

Typical AEMaaCS environment When deploying a new project using Adobe Experience Manager as a Cloud Service, an entire system of environments will be created. Within this variant of AEM, three types of environments are classically available as cloud services:

Production environment – hosts the application for business and content authors
Stage environment – this is usually a 1:1 copy of the production environment. It is mainly used by QA, security and stability teams. It is used to perform various performance and quality tests before the changes are transferred to the production environment.
Development environment (so-called Dev environment) – used mainly by development teams. It allows developers to deploy changes to AEM under the same runtime conditions as the aforementioned environments.

avanade-experience-aem-as-a-cloud-service

Each new AEM project is always linked to exactly one specific code repository where both configurations and custom project code can be stored. This information is stored in a code repository that is accessible through regular Git clients when new environments are created.

AEMaaCS also includes two very important components:

AEM Cloud Sites Service
AEM Cloud Assets Service

Both services provide access to many basic functionalities necessary for the functioning of the CMS. The AEM authoring layer will contain all functionalities for both pages and resources (images, documents, audio and video files).

Parameters	AEM on Prem/Managed Service	AEM as Cloud Service
License cost	Depends on infrastructure & users	Depends on usage
Upgrades	Need manual intervention & it’s costly	Automated upgrades are available
Architecture	Built like monolith application, requires custom development & cost to set up the instances & integrate with external services. It has fixed number of AEM images which has to be decided and installed at the beginning of the project.	Built on micro service-based architecture & doesn’t need extra cost for setting up instances etc. like on-prem. It has variable number of AEM images and they are used as per need.
Security	Security fixes need to be deployed manually & it takes time to deploy till prod as proper testing is needed before that.	Security fixes can be deployed automatically on a daily basis.
Code repository	Any code management repository can be used	In the standard process, only Adobe Git repository has to be used.
Code deployment	Any CI tool can be used for this.	Cloud manager has to be used
User management	It has to be controlled through Author Instance User Management page.	It has to be controlled via admin console.
CRX management, Indexing, Runmode & OSGI configurations	CRX can be accessed for any environment and same. Configurations, Indexes can be configured and maintained anytime. Custom Runmodes are possible at any time.	On Prod, CRX is not accessible. OSGI configurations & Indexes has to be managed as a part of code only. There is no alternative to control the configurations directly on any environment. Custom Runmodes are not allowed.
Mutable & immutable content	No constraint for mutable & immutable content.	Mutable & immutable content are strictly managed.
Dispatcher & CDN	Dispatcher configurations can be organized in any folder structure. Any CDN can be used here, mostly Akamai or fastly are used.	Dispatcher configuration follows standard structure as per cloud manager. Adobe managed CDN is used here, if the customer goes for their own CDN, then that CDN has to point to AEM managed CDN.
Key features	• Better support for big repositories • Multiple distributed cluster nodes for high availability • Better performance • Support for many child nodes and Access Control Levels	• Auto-scaling possible, is scaled based on the actual traffic and actual activity. • Has individual instances that only run when needed. • Uses modular applications. • Has an author cluster as default; this avoids downtime for maintenance tasks.
AEM publish changes & replication agent	Changes are possible on AEM publish instance directly. We’ve OOTB replication agents available for publishing, and we can create custom replication agents as well.	On Cloud, changes in the publish instance are not possible. Here, we’ve Sling Content Distribution for publishing content. There is no option to create or use a replication agent.
Identity Management	AEM community, CUG, etc. can be used as identity management. However, the same doesn’t hold applicable in the case of the cloud.	A major change to AEM as a Cloud Service is the fully integrated use of Adobe IDs for accessing the author tier. This requires the use of the Adobe Admin console for managing users and user groups.

Some important problems of its predecessors that are solved:

Zero deployment downtime
Easy scalability
Always up to date with the latest Adobe features/upgrades
Relatively low cost of ownership
High level of security

A few notable things to be aware of:

Cloud Manager:

Adobe Cloud Manager is integral to the continuous upgrade approach of AEM as a Cloud Service, as it controls all updates to your instances.
The Release orchestrator auto-deploys updates to Production Instance (and also deploys code from Master Branch). If there are instances wherein the latest production code is not in master, we will have an unwanted deployment to Production environments.
AEM as a Cloud service pipeline are pre-configured to deploy code from an Adobe GIT repo and not against our company/corporate codebase. For some customers, this is a big flag.
We will need to build/tweak our CI/CD pipelines to sync code between our organization repository to Adobe Git.
Cloud Manager pipelines are preconfigured to run some code quality checks – Junit Coverage, Code Reliability, etc. – however the Code Coverage also includes ACS Commons Code which impacts overall coverage score (there is no way to skip ACS Commons source code from Junit Coverage).
Organizations also need to have some sort of watch mechanism to ensure no unauthorized access/commits are happening on Adobe GIT (although highly unlikely – there is a possibility).
AEM as Cloud Service Environments are publicly accessible over the internet:
- Anyone that knows the programId-environmentId/url will be able to access.
- We will have to work with InfoSecurity team to apply “IP Whitelisting” to each environment and tier (author, publisher, preview).
AEM indexes:
- Developers who are used to re-indexing the Lucene Indexes need to be aware that any index configuration updates and subsequent re-indexing also need a code deployment (although technically indexes sit under “/oak:index” and technically outside of the immutable sections of repository (/apps, /libs)).
- Custom indexes have to follow a certain naming pattern or errors/warnings will be logged.
I18n dictionary updates:
- This requires a code deployment too (unlike AEM on prem/AMS where content authors could go in and update I18N dictionaries).
CDN:
- OOTB Fastly CDN ships with AEM as a Cloud service.
- We will need to have mechanisms for Cache Purge/Cache Invalidation (Fastly as such is a black box and we will have no access whatsoever to internals).
- Fastly does respect dispatcher TTLs. In the event we have an organizational wide CDN, we will need to again work with Adobe and organizational Infra team to configure Fastly as pass through and have caching enabled on our CDN.
- Adobe generates a CHR (Cache Hit Ratio) Report – which sometimes can be an inaccurate representation of how well your caching works.

Here are the steps to migrate to AEMaaCS.

1. Assessment and planning:

Inventory your components: Start by identifying all the custom components in your existing AEM instance. This includes templates, client libraries, dialogs, and any custom Java code.
Review dependencies: Examine the dependencies of your custom components, such as third-party libraries, and make sure they are compatible with AEM as a Cloud Service.
Analyze content structure: Evaluate your existing content structure and determine if it needs any adjustments to fit the cloud service model.
Plan for integration: Consider how your custom components will integrate with other Adobe services and third-party systems in the cloud.

2. Code refactoring:

Update dependencies: Update and refactor your custom code to be compatible with AEM as a Cloud Service. This may involve changes to Java code, HTL (HTML Template Language) code, and client-side JavaScript.
Use core components: Leverage AEM's Core Components, which are pre-built, cloud-ready components provided by Adobe. Replace your custom components with Core Components whenever possible to reduce maintenance efforts.

3. Asset migration:

Plan for migrating assets from your on-premises AEM instance to the cloud service. Adobe provides tools like the Asset Bulk Editor to assist with this.

4. Cloud service configuration:

Configure your AEM as a Cloud Service instance to match your specific requirements, including the deployment environment, author and publish configurations, and scaling needs.

5. Testing and quality assurance:

Thoroughly test your custom components in the AEM as a Cloud Service environment to ensure they function correctly and meet performance requirements.

6. Deployment and monitoring:

Deploy your custom components to your AEM as a Cloud Service instance, following Adobe's recommended deployment practices.
Implement monitoring and logging to ensure the health and performance of your components in the cloud environment.

Post-migration optimization:

Continuously monitor and optimize your custom components for performance and cost-efficiency in the cloud service.

It's important to note that migrating to AEM as a Cloud Service often involves significant changes to the architecture and development practices compared to an on-premises AEM instance. Therefore, thorough planning and testing are critical to a successful migration.

Deliver personalized experiences with AEM as a cloud service