AEM as a Cloud Service (AEMaaCS) – Architecture Overview

AEM as a Cloud Service (AEMaaCS) – Architecture

Adobe Experience Manager (AEM) is one of the leading CMS from Adobe and is part of Adobe Experience Cloud (AEC). The Adobe Experience Manager (AEM) web content management offers a set of capabilities for creating, managing, delivering, and personalizing content across various digital marketing channels, including web, mobile, and email. 

Before we dive into architecture of AEM as a Cloud Service (AEMaaCS) we need to understand why AEMaaCS is needed and how it is different as compared to classic AEM. To understand this, we’ll first look at:

• Evolution/history of AEM
• Challenges with traditional/classic AEM (the AEM that majority of us have used from last 10-12 years)

Evolution/History of AEM

The software was originally launched in early 2000 as Communiqué (CQ) by Day Software of Basel, Switzerland. After CQ 5.3 had been released, Day Software was acquired by Adobe Systems in 2010 then CQ became Adobe Experience Manager.

From technology perspective AEM has evolved (mainly in last 5 years). Year 2020 is when AEM came out as a Cloud Service first time, allowing for additional scalability, faster updates, and consistent accessibility.

Figure 1: Evolution of AEM as a Cloud Service

 

Challenges with classic AEM

Let’s quickly look at the components of classic AEM application to understand the challenges with old AEM.

Figure 2: Traditional AEM Architecture (high-level)

As you can see above, AEM is combination of many frameworks (Felix, OSGi, JCR/Oka repository and many other OSGi modules). Important thing to note is, all these modules are running on single JVM. This is a big limitation in terms of performance and scalability of AEM. Apart JVM, traditional AEM also suffered from issues related to JCR repository, asset ingestion, replication related and other issues.

Here are some key challenges with traditional AEM:

• A typical classic/old AEM instances (author or publish) runs on single JVM instances along with all OSGi modules and supporting components
• Oka/JCR repository related limitation adds to scalability issues (slow I/O operation under load, number of parent/child nodes, performance degrade because concurrent user access)
• Computational limitations (e.g., asset processing and rendition generation)
• Content replication related issues (performance, reliability etc.)

At high level these issues are very common and exists with any traditional monolithic applications. Because of these issues and current architecture AEM was not cloud ready/native and was not capable of scaling dynamically. Where there are challenges there are needs. So, the need was to make AEM cloud-native and hence AEMaaCS came in to picture.

These issues and limitation led to refactoring and architectural changes of traditional AEM to make it cloud-native and scalable. Obviously, there are other benefits as well, but we’ll focus on architectural aspect only in this article.

Please note that, from an end user (mainly developers and authors) perspective nothing has changed significantly, these refactoring changes are very much transparent for developers and authors. Developers and authors will continue to use the same tools and process for development and content creation/publishing. Also, AEMaaCS does not disrupt existing on-premises and AMS deployments.

AEM as a Cloud Service Architecture

If you are following along this article, you must have seen the high-level challenges with traditional AEM (above). Before we deep dive into the architectural discussion, I want to describe in very simple terms what “AEM as a Cloud Service” is so that it is easy for you to follow rest of this article:

 

“In very simple terms consider that traditional AEM was a big monolithic application and had limitations (e.g., scalability, extensibility) like any other legacy applications. AEM was not cloud-native and hence we were missing benefits of cloud in AEM. AEM as a Cloud Service is a result of refactoring of traditional monolithic AEM application into a set of modular components/services that are cloud-native, and these components can be scaled dynamically in cloud.”

Now since we have the context and background about challenges with traditional AEM, let’s look at the various components of the AEMaaCS architecture. Also, we’ll see how it addresses the challenges that are described above in this article. 

Below are key components of AEMaaCS:

 

Figure 3: AEM as a Cloud Service Architecture

• Content Repository Service
• Asset Computer (Microservices) Service
• Container Orchestration Service
• Cloud Manager – as the name “manager” suggests 
• Replication Service

Content Repository Service

AEMaaCS Components	Component Detail	What challenge does it solves?
Content Repository Service	In AEMaaCS, author nodes are designed for high availability with complete separation between the code and content/asset. As illustrated below (in Figure 4), these nodes are connected to the Content Repository Service that stores the structured content and assets in a separate store outside AEM of instances, while all binaries (e.g., based AEM jar, patches etc.) are separately stored in a blob store. This allows for product updates to happen without any downtime or interruption to content creators. While new nodes are getting updated with latest features, existing nodes on previous version keep running in the background. As soon as the new nodes are ready, they get connected to the content repository service (shared between all author nodes) and start receiving serving requests. At this point, old nodes are retired. This redundancy helps ensure that the system is always up to date with no interruption to service.	In a traditional dedicated hosted environment, the resources (e.g., Oka repository throughput, JVM) available to the system are static and limited, requiring infrastructure planning for compute capacity and memory to ensure sufficient capacity. However, predicting traffic is challenging and can put the consumer experience at risk, which leads many brands to overestimate capacity, hence increasing total costs.    Now with this centralized Content Repository Service, we can just define the performance SLAs and let AEMaaCS deal with scaling AEM instances up/down based on traffic load. We don’t need to worry about how content will be replicated to newly created AEM instances because AEMaaCS will take care of it for us.

  

 Figure 4: AEMaaCS Content Repository Service

Asset Computer (Microservice) Service

AEMaaCS Components	Component Detail	What challenge does it solves?
Asset Computer Service	In AEMaaCS, users upload assets/binaries directly to a partition in the cloud storage container. This container is dedicated for storing assets and is separated from Oka repository. As illustrated in below figure, when an authorized user initiates an asset upload request, Experience Manager is notified to trigger optimization of partitioning, followed by allocation of a private location in the binary cloud storage container. This partitioning of high-quality and large-size content into smaller and manageable chunks, instead of handling one big file, is key to significantly speeding up the ingestion process. Once all the parts of the asset have been uploaded to the storage container, Experience Manager is notified of its completion, allowing it to register the new asset in its repository.  Once assets are ingested, they need to be rendered and processed before they can be used widely. Rendering and processing generally entail a series of back-end operations such as extraction of rich XMP metadata, usability of text to power search, creation of thumbnails, Sensei-powered smart tagging, Photoshop imaging engine and web renditions to provide previews of the assets, custom image renditions, and limited video transcoding. This is the job that is done efficient by Asset Microservices.	Depending on the volume and quality of assets, ingestion operation can slow down an author with highly demanding processing requests.  Traditionally, large asset processing has required IT teams to plan for extra compute capacity depending on predictable seasonal demands, such as preparation by marketing teams for product launches or holiday season sales. This not only results in overestimated capacity but also leaves assets vulnerable in unpredictable times.   Asset processing in Cloud Service uses a microservice architecture to carry out this demanding operation outside the Experience Manager environment, saving resources and capacity planning.

  

Figure 5: AEMaaCS Asset Computer and Microservices

 

Container Orchestration Service

AEMaaCS Components	Component Detail	What challenge does it solves?
Container Orchestration Service	In AEMaaCS, author, publish and dispatcher nodes are nothing but containers or images. It is important to note that the container itself is immutable and is combination of binaries (e.g., AEM jar) and custom code/content (code, configuration). This immutable nature of container allows AEMaaCS to scale dynamically. These contains are used to spin up new instances as and when AEMaaCS need to scale up. Container Orchestration Service is an integral part of Cloud Manager which communicate with container manager to create and kill containers as needed. Container Orchestration Service and Cloud Manager works together.	Traditional AEM was not scalable dynamically. IT team had to estimate for capacity upfront or had to add scale the instances manually (by adding new nodes). Note that apart from manual interventions the process of setting up the new instance involved with content replication, dispatcher installation, configuration and much more. In AEMaaCS, every AEM nodes is an immutable container/image (made up of code + configuration + base AEM jar). Container Orchestration Service uses these containers to scale AEM dynamically in cloud (based on events trigged by Cloud Manager).

  

Cloud Manager

AEMaaCS Components	Component Detail	What challenge does it solves?
Cloud Manager	In simple terms consider that Cloud Manager is your liaison to your IT team. Most of the tasks that traditionally DevOps and Development teams used to do are done by Cloud Manager. Cloud Manager’s key capabilities: Continuous Integration/Continuous Delivery (CI/CD) of code API Connectivity to complement existing DevOps Code Inspection, performance testing, and security validation based on best practices before pushing to production to minimize production disruptions Autoscaling feature intelligently detects the need for increased capacity and automatically brings online additional Dispatcher/Publish segment(s). For this task Cloud Manager works with Container Orchestration Service	In a traditional AEM installation IT teams manage the AEM infrastructure, DevOps (CI/CD), release management, configuration. Development team’s responsibility is to ensure that they are following best practices to write secure and scalable code. Many of these tasks were redundant and error prone. Even in some cases organizations do not even have a robust DevOps and Development standards in place. The reason could be budget, lack of skilled resources or anything else.  Cloud Manager takes away the burden of IT teams by offering service implicitly. Following teams can focus on innovation rather than doing trivial tasks: Infrastructure team  DevOps team Development team

 

 

 

 Figure 6:AEM as a Cloud Service - Cloud Manager and CI/CD

Replication Service

AEMaaCS Components	Component Detail	What challenge does it solves?
Replication Service	In AEMaaCS, the author tier, the preview tier, and the publish tier read and persist content from/to a Content Repository Service.  Replication in AEMaaCS is handled differently as compared to traditional AEM implementation. Traditional replication agents are NOT used in AEMaaCS, rather an event-based services mechanism is used to replicate content from author to multiple publish instances. In this even based replication architecture, both author and publish instances are not aware of each other and hence we don’t need to configure replication agents. In AEM Cloud Service, content is published using Sling Content Distribution.  When content is approved from the author tier, this is an indication that it can be activated, therefore pushed to the publish tier persistence layer, or optionally to the preview tier. This happens via the Replication Service, a middleware pipeline. This pipeline receives the new content, with the individual publish service (or preview service) nodes subscribing to the content pushed to the pipeline.	In traditional AEM installation, replication agents are responsible for replicating content from author to one or more publish instances. This replication from author to publish instances is handled via a Sling Jobs. Based on number of publish instances (in publish farm) the author instance gets busy (processing Sling jobs) and overloaded to publish content to every instance in publish farm, this is one challenge.  Another challenge with traditional AEM replication is author should be made aware of publish instance by configuring replication agent. This agent configuration process needs to be repeated every time a new publish node is added in publish farm. To scale AEM dynamically in cloud this manual step must be removed so that Cloud Manager can spin up new containers based.   Since in AEMaaCS architecture replication is handled via an event-based Replication Service we don’t need to configure agents manually. Also, the replication jobs that degrades author instance performance are not executed on author, rather it is handled by an external Replication Service.

 

I hope above explanation provides you with a clear picture of key differences/changes between traditional AEM and AEMaaCS. Why these changes were need and how it helps/addresses challenges that we have with a traditional AEM installation.

In this article I just wanted to provide a very high-level overview of AEMaaCS. I’ll try to cover each of these topics in more details.

Also, I wanted to say this again, from an end user (mainly developers and authors) perspective nothing has changed significantly, these changes are very much transparent for developers and authors. Developers and authors will continue to use the same tools and process for development and content creation/publishing. AEMaaCS provides a secure, always up to date and robust AEM instances infrastructure baked with best practices guardrail so that team can focus more on innovation and digital experience design/delivery.