AEM as a cloud service introduces major changes in the architecture by using containers. Which key architectural change was necessary to allow this to occur?

The fundamental architectural change that enabled AEM to be containerized for AEM as a Cloud Service was the separation of immutable and mutable content. In this new architecture, code (under /apps and /libs) is part of an immutable base image used to build containers. All mutable content, such as user-generated content (/content), configurations (/conf), and application state, is externalized into a persistent data store (like a cloud database and blob storage). This separation allows AEM application containers to be stateless, enabling them to be quickly created, destroyed, and scaled horizontally, which is a core principle of container-based, cloud-native applications.

A. The use of asset ingestion microservices is a feature built upon the new architecture, not the foundational change that enabled it.
B. Sling Content Distribution is the new replication mechanism, a consequence of the architectural shift, not the cause of it.
C. The specific database technology used is an implementation detail. The key change is the principle of separating the repository, not the choice of database.

1. Adobe Experience League. (2024). Architectural Changes to AEM as a Cloud Service. "A key principle observed in AEM as a Cloud Service is the separation of mutable and immutable areas of the repository... Immutable areas are /libs and /apps... Mutable areas are areas such as /content, /conf, /var, /etc, /oak:index, /system."

2. Adobe Experience League. (2024). AEM as a Cloud Service Architecture. "The AEM version used in AEM as a Cloud Service has been refactored to create a set of modular AEM applications... The content repository is split into a content repository for authoring and one for publishing." This highlights the separation principle.