AEM Architecture: The Stack, AEM 6.5 Topology and AEM as a Cloud Service

Adobe Experience Manager comes in three architectures today: AEM 6.5 (with its successor AEM 6.5 LTS) installed on your own servers, AEM as a Cloud Service run by Adobe, and Edge Delivery Services, which renders pages at the edge. All three share the idea of separate authoring and delivery, but they are built very differently. This page goes through the stack first, then each architecture, with a diagram for each.

The technology stack

Under every AEM 6.5 and AEM as a Cloud Service instance sits the same stack, from the bottom up:

Storage in AEM 6.5 is covered in more depth in storage concepts in AEM 6.5.

AEM 6.5: author, publish and Dispatcher

• Author (port 4502 by default) is where content is created and approved.
• Replication agents on author push published content to each publish instance (port 4503).
• A Dispatcher in front of each publish caches the rendered pages as files. When content changes, a flush agent tells it to invalidate the cache. Requests with a query string, without an extension or with authentication headers skip the cache by default.
• Reverse replication brings content created on publish, such as form submissions, back to author.
• A load balancer or CDN sits in front of the Dispatchers.

Which storage for which instance

Adobe's recommended deployments for 6.5 are:

• TarMK for author by default, with optional Cold Standby for manual failover;
• a TarMK farm for publish, where each publish has its own repository and capacity grows by adding instances;
• a MongoMK cluster for author only when one author server cannot cope, which Adobe puts at thousands of named users a day or hundreds working at the same time. Adobe advises against MongoMK on publish.

Binaries belong in a shared file data store or S3, not in MongoDB.

AEM as a Cloud Service

Tap or click a diagram to open it full size. Adobe calls the cloud architecture a complete redesign of AEM 6.x. The main pieces:

• Author runs as a cluster of at least two pods sharing one repository.
• Publish is a farm of at least two pods. Each pod has its own repository with the published content and its own Apache and Dispatcher, and serves as an origin for the CDN. Pods are added automatically when traffic grows.
• Preview is a single node for checking content before it goes live.
• The replication service replaces replication agents. Author hands content to Sling Content Distribution, which feeds a pipeline service outside AEM. Publish pods subscribe to its content queues, so author does not need to know how many publish pods exist. That is what makes autoscaling possible. The Replication Java API still works, with two targets, publish and preview.
• The CDN is included and managed by Adobe. The architecture page does not name the vendor; Adobe's domain and log-forwarding documentation shows it is Fastly.
• Binaries live in a cloud data store. They are uploaded to it and served from it directly, never streamed through the AEM pods, which keeps the pods small and quick to start. Asset microservices read the files from there to create renditions.
• Everything runs as containers managed by an orchestration service. Cloud Manager's pipeline turns your code into the images, and it is the only way code reaches an environment.

How Cloud Service updates without downtime

The repository is split in two. Each AEM version has its own read-only part that holds /libs and /apps, and all versions share one writable part with /content, /conf, /var and the rest. Oak combines the two with a composite node store. During an update or a deployment, pods running the new version start next to the old ones, pass health checks and take over traffic, and the old pods are removed. This is also why /apps and /libs cannot be changed at runtime in the cloud.

The practical differences for teams moving from 6.5 are summed up in AEM as a Cloud Service and the FAQ.

Edge Delivery Services

Edge Delivery Services has no AEM publish instance at all. Its architecture works like this:

• Content comes from AEM author with the Universal Editor, or from documents: Word and Excel in SharePoint, Google Docs and Sheets, or Adobe's Document Authoring.
• Publishing goes through an API in two steps. Preview pulls the content from its source; publish pushes it to delivery and purges the CDN.
• Content, media, code and configuration are kept in separate stores. Media files are addressed by a hash of their content, so they can be cached forever.
• Serverless functions render the content into plain HTML, which a CDN serves. The CDN can be Adobe's, or your own Akamai, Cloudflare, Fastly or CloudFront.
• Code lives in GitHub. Every branch gets its own URL on aem.page (preview) and aem.live (live).

Adobe now recommends Edge Delivery Services as the starting point for new projects. It can share one domain with AEM Sites pages and with Assets.

Which architecture you are on

Common questions

What is AEM built on?

Java, OSGi through Apache Felix, the Apache Sling web framework, and a JCR repository implemented by Apache Jackrabbit Oak, with Apache httpd and the Dispatcher in front.

What is the Dispatcher?

Adobe's caching and load-balancing module for Apache httpd. It stores rendered pages as files and serves them without asking AEM, until a flush invalidates them.

TarMK or MongoMK?

TarMK, unless an author installation is too busy for one server. MongoMK is meant for large author clusters, never for publish.

How does publishing work without replication agents in the cloud?

Through Sling Content Distribution and Adobe's pipeline service. Publish pods subscribe to content queues and pick up new content themselves.

Related: AEM headless tutorial, AEM Core Components and hiding /content in publish URLs.