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.

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).

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.