AEM as a Cloud Service delivers personalized, content-led experiences for customers, allowing businesses to expand. With rapid time-to-value, cloud-native solutions can be tailored to meet ever expanding business requirements. From on-premises to cloud a lot has changed.

Let’s discuss 10 architectural changes within AEM as a Cloud Service.

1. Asset Processing

In older versions of AEM, asset processing was done at author instance level which consumes a lot of CPU, memory, and impacts performance. Using AEM as a Cloud Service provides an asset microservices (which is external to AEM) to offload asset ingestion and processing of assets which includes creating renditions, metadata extraction etc. This minimizes the load on Experience Manager and provides scalability. The default workflow DAM Asset Update in previous versions of Experience Manager is no longer available. Instead, asset microservices provide a scalable, readily available service that covers most of the default asset processing.

2. Automatic Updates

AEM as a Cloud Service uses continuous integration and delivery to make sure all AEM projects are on the latest version. There are two types of updates:

Maintenance Updates – These can be released daily and are mostly for maintenance updates and security fixes.
New Feature Updates – These are generally released monthly.

These updates are fully automatic and ensure that there is no disruption to the service for any system in production. Rolling updates are possible due to the composite node store feature in the Oak repository. Code Quality Testing, Functional Testing, and Audit Testing are performed to prevent product upgrades and customer code pushes from breaking production systems. If the update to the production environment fails, Cloud Manager will automatically roll back the staging environment. This is done automatically to make sure that after an update is completed, both the staging and production environments are on the same AEM version.

3. Authentication

AEM as a Cloud Service comes pre-configured with Adobe Identity Management System (IMS). There is an admin console which allows administrators to centrally manage all Experience Cloud users. There are product profiles within the admin console that determine which instances a user can access. IMS Authentication works using OAuth protocol between AEM and the Adobe IMS endpoint. Once a user has created an Adobe ID and has been added to your IMS through the admin console of your AEM cloud, they can log in to AEM author service using IMS credentials.

Shiny new AEM system? Here are 3 ways to improve your AEM training.

4. Publication Process

AEM as a Cloud Service uses the Sling Content Distribution capability to move the appropriate content from author to the publish tier. It uses a pipeline service that runs on Adobe I/O and is outside of AEM Runtime. A single publish or unpublish request can include multiple resources but will return a single status applied to all. That means it will succeed for all resources in the AEM Publish Service or fail for all. This ensures that the resources within the AEM Publish Service will never be in an inconsistent state. Published content is pushed to various queues in the pipeline, to which all nodes of the publish service subscribe. As a result, the author tier does not need to be aware of the number of nodes in the publish service. This allows for fast autoscaling of the publish tier, proving to be a much-improved feature.

5. Build Process

AEM as a Cloud Service uses Adobe’s Cloud Manager to manage the CI/CD processes to your instances. Cloud Manager is used to deploy code to all AEM programs and Environment and is a single point of entry for your operations and development teams. Cloud Manager creates environments in data centers across many geographic regions, providing global coverage. CDN Points of Presence (PoPs) ensure low-latency content delivery for customers located all over the world.

6. Operations and Performance

With AEM as a Cloud Service:

Many tasks like indexing, backup, and other maintenance tasks have been automated.
Heavy-load tasks such as queues, jobs, and bulk-processing tasks have been moved out of the core AEM instance to be handled by shared and dedicated micro-services.
The various elements of the architecture are equipped with a variety of health checks. If, for some reason, a particular node of the architecture is deemed unhealthy, then it is removed from the service and silently replaced with a new, healthy one.

7. Scalability

AEM as a Cloud Service has dynamic architecture with a variable number of AEM images. The architecture is scaled based on actual traffic and has individual instances that only run when needed. It also has an author cluster by default which helps avoid downtime for maintenance tasks.

8. Development

The new architecture supporting AEM as a Cloud Service involves some key changes to the overall developer experience.

The application code and configuration must be stored in the Git code repository of the associated Cloud Manager program. This is important as developers no longer have access to CRX/DE and can only view OSGI console in read only mode.
The application code and configuration must be compatible with the latest version of the baseline AEM image.
The customer application must pass all the code quality, security and performance gates enforced in the pipeline. The default test coverage setting for this is set to 80% but can be reduced if approved by Adobe.
The images built for the customer application must be deployed by the Cloud Manager pipeline.

The Web Console where all OSGI bundles and configurations were managed is no longer available in AEM as a Cloud Service. It is being replaced by a new Developer Console that provides a read-only interface for most of the runtime information. Log files are made available to developers in Cloud Manager either in the form of files that can be downloaded or through APIs.

AEM as a Cloud Service Migration Readiness Jumpstart – 4 Week Engagement

9. AEM Sites

All the basic functionality of AEM Sites remains the same, but at the same time there are some new updates and additions:

Asynchronous Page Operations – All the AEM operations like move pages, rollout pages, etc. run asynchronously and in the background. The initiator of such actions can check their status in a new UI at /mnt/overlay/dam/gui/content/asyncjobs.html.
New Reference Site– WKND, a new AEM reference site, has been updated and published to reflect best practices to build a website with AEM. Previously, We.Retail was installed by default with AEM (except in Production mode). Now, a reference site will not be installed by default going forward. Instead, the Git repo and accompanying tutorial with the updated WKND reference site code is provided.
There is a clear separation of AEM Repository in mutable and immutable content. Access to immutable content is prohibited at runtime. As a result, some of the AEM Sites operations are not available at runtime like i18n dictionary translations, OSGI configurations and Developer Mode in AEM Site page editor.

10. Authoring User Interface

The main difference is that the UI is purely touch-enabled. The classic UI is no longer available. Otherwise, the basics remain unchanged with only small changes being apparent.

A Lot Has Changed, But We Can Help

There are a lot of architectural changes within AEM as a Cloud Service, but hopefully you found these insights helpful. If you’re unsure of what to do now, connect with us! We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others).