Adobe Experience Manager (AEM) as a Cloud Service offers a set of composable services for the creation and management of high impact experiences.
This page provides an introduction to the logical architecture, the service architecture, the system architecture, and the development architecture for AEM as a Cloud Service.
AEM as a Cloud Service is made up of high-level solutions such as AEM Sites, AEM Assets, and AEM Forms. These services are licensed individually, but can be used in collaboration. Each solution uses a combination of composable services provided by AEM as a Cloud Service, dependent on their respective use cases.
AEM applications are materialized in the form of a Program that you create in the Cloud Manager application, according to your licensing entitlements. These programs give you full control over how the associated AEM application is named, configured and how permissions are allocated, in the context of a particular project.
As a customer, you are usually identified by Adobe as a tenant, also known as an IMS organization (Identity Management System). A tenant can have as many programs as needed, and licensed. For example, it is quite usual to see a central program for AEM Assets, while AEM Sites might be used in multiple programs corresponding to multiple online experiences.
AEM Edge Delivery Services are exposed as a top-level solution in Cloud Manager, while being part of the other main solutions from a licensing standpoint. For example, AEM Sites with Edge Delivery Services.
A program can be configured with any combination of the high-level solutions, and each solution can support from one-to-many add-ons. For example, Commerce or Screens for AEM Sites, Dynamic Media or Brand Portal for AEM Assets.
Once a program is created with the AEM Sites, AEM Assets or AEM Forms solutions, the associated AEM instances will be represented in the form of AEM environments in this program.
There are four types of environment available with AEM as a Cloud Service:
Rapid development environment (RDE):
An AEM program can be configured with the Edge Delivery Services as well.
Once configured, AEM can reference GitHub code repositories used for building the experiences with Edge Delivery Services. As a result, new configuration options become available for the associated experiences. These include setting up the Adobe-Managed CDN, and accessing licensing metrics or SLA reports.
The list of high-level composable services in AEM as a Cloud Service can be represented with two segments - Content Management and Experience Delivery:
For content management, there are two main sets of services for the authoring of content, both represented as content sources:
For experience delivery, when using AEM Sites or AEM Forms, there are also two main sets of services, non-mutually exclusive and operating under a shared Adobe-Managed CDN (Content Delivery Network) as different origins:
There are also the key adjacent services:
By default Assets-only programs do not have a publish tier, nor a preview tier.
There are other adjacent services:
The Replication Service:
The replication service went through a complete redesign compared to the 6.x versions of AEM, as the replication framework from previous versions of AEM is no longer used to publish content.
The latest architecture is based on a publish and subscribe approach with cloud-based content queues. For the AEM publish tier, it allows a variable number of publishers to subscribe to the publish content and is an essential part of achieving true and rapid autoscaling for AEM as a Cloud Service
The Content Repository service:
The CI/CD service:
The Testing service:
Represents the underlying infrastructure used to execute:
as part of a deployment pipeline to an AEM environment, or as part of a GitHub pull request to an Edge Delivery code repository.
The Data service:
The Real-User Metric (RUM) service:
The Assets Compute service:
The Identity Management Service (IMS):
The AEM Author and Publish tiers are implemented as a set of Docker containers, operated by a standard Container Orchestration Service. The resulting containerized architecture means a fully dynamic system with a variable number of pods, dependent on actual activity (for content management) and actual traffic (for experience delivery). This enables AEM as a Cloud Service to accommodate your traffic patterns as they change.
The AEM Author tier is operated as a cluster of AEM author pods sharing a single content repository. A minimum of two pods allows for business continuity while maintenance tasks are running, or while a deployment process is happening.
The AEM Publish tier is operated as a farm of AEM publish instances, each with their own content repository of published content. Each publisher is coupled to a single Apache instance equipped with the AEM dispatcher module for a materialized view of the content, serving as the origin for the Adobe-managed CDN. A minimum of two pods allows for business continuity as well, but it is not unusual to see this number expanding in periods of high traffic.
The AEM Preview tier is comprised of a single AEM node. This is used for quality assurance of content before publishing to the publish tier. Occasional downtimes, especially during deployments, can happen on the preview tier.
The Edge Delivery Services are operated on top of a CDN and serverless infrastructure for assembling the pages in the most performant way. When a resource is requested, the serverless infrastructure is responsible for converting the published content into semantic HTML and serves as the origin to the CDN.
The conversion to semantic HTML happens from the published content served from the AEM author tier or the document-based authoring environment.
The following diagram illustrates how you can edit Sites content in Microsoft Word (document-based authoring) and publish to Edge Delivery. It also shows the traditional AEM publishing method using the various editors.
As Edge Delivery Services are part of Adobe Experience Manager and as such, Edge Delivery, AEM Sites and AEM Assets can co-exist on the same domain. This is a common use case for larger websites. For instance, a customer might want to migrate a particular page with high traffic to Edge Delivery Services, while all other pages might remain on the AEM Publish Tier.
The code and configuration for AEM projects is stored in a code repository, from which deployment pipelines are issued when changes are made. There are different types of code repositories:
Developers and administrators manage the AEM as a Cloud Service application by using a Continuous Integration/Continuous Delivery (CI/CD) service, made available via the Cloud Manager. Cloud Manager also exposes anything related to monitoring, maintenance, troubleshooting (for example, access to log files) and licensing.
Cloud Manager manages all updates to your instances of the AEM as a Cloud Service. It is mandatory, being the only way to build, test, and deploy the customer application to the author, the preview, and the publish tiers. These updates can be triggered by Adobe, when a new version of the AEM Cloud Service is ready, or by yourself, when a new version of your application is ready.
This is implemented by a deployment pipeline, coupled to each environment within a program. When a Cloud Manager pipeline is running, it creates a new version of the customer application, both for the author and the publish tiers. This is achieved by combining the latest customer packages with the latest baseline Adobe image.
The deployment pipeline is triggered either when customers are making code changes, or when Adobe is deploying a new maintenance release.
In both cases, the same set of automated tests is executed. It is made up of tests:
These automated tests are run on the Stage environment – which is why it is important to keep the Stage environment content as close as possible to the content on the Production instance.
Once all tests pass successfully, the new code is deployed to the Production environment.
The Cloud Manager fully automates the cut-over to the latest version of the AEM application by updating all service nodes using a rolling update pattern. This means there is no downtime for either the author or publish service.
The latest architecture for AEM as a Cloud Service introduces some fundamental changes and innovations compared to the previous generations (AEM 6.x and previous):
All files are directly uploaded and served from a Cloud Data Store. The associated stream of bits never goes through the JVM of the AEM Author and Publish services. As a result, the nodes of the AEM author and publish services can be smaller in size, and therefore more compatible with the expectation of fast autoscaling. For business practitioners, this results in a faster experience when uploading and downloading images, video, and other tasks.
All operations consisting of publishing content now involve a pipeline following a subscription pattern. 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.
The architecture completely separates the application content from the application code and configuration. All code and configuration is practically immutable and baked into the baseline image used to create the various nodes of the author and publish services. As a result, there is an absolute guarantee that each node is identical, and the changes to code and configuration can only be made globally by running a Cloud Manager pipeline.
The architecture includes multiple micro-services built on serverless technology, especially with the Adobe I/O runtime