AEM on premise, as Managed Service or as Cloud Service

The AEM Publish environment also provides all services for content delivery based on OSGi. However, a publish cluster is much easier to operate because no content is edited in this environment and therefore no changes have to be synchronized.

The AEM dispatcher is usually located in front of a publish instance, sometimes also in front of an author instance, in order to cache static content and thus relieve the AEM servers and increase performance.

With AEM as a Managed Service with Cloud Manager, there are also the Cloud Manager, Adobe Identity Management Service (IMS), and CI/CD Service components. Cloud Manager is the interface of the system for the customer. It can be used to access log files, trigger deployments with the help of the CI/CD Service, or assign rights. This is because direct access to the consoles is not possible. Authentication is always via IMS, but it also supports SSO via Microsoft Azure Active Directory (AD).

Limitations in cloud operation
The classic AEM architecture takes the monolithic approach with one large application containing all the required modules such as web front-end, database, asset processing, workflow engine and many others. This makes it very easy to deploy, test and operate the application in a non-cloud environment. However, this approach does not allow AEM to be run and orchestrated effectively on a cloud platform like Kubernetes in an automated fashion.


AEM Cloud Native
What does cloud native actually mean? The Cloud Native Computing Foundation (CNCF) defines cloud native as follows:

"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."

Based on this definition, an application is cloud-native if it is scalable and can run in modern, dynamic environments. Following the definition, this is possible if the application can be operated in containers and has a microservice architecture.

For an application to be effectively run and orchestrated in containers in an automated way, it must comply with the seven cloud-native principles.  The classic AEM architecture, however, violates both the single-concern and self-containment principles and therefore cannot be effectively run and orchestrated in containers in an automated fashion.

The single-concern priciple states that a container should only take on one task at a time. However, in AEM, servers always take on all tasks in an environment. For example, in the authoring environment, the server provides the authoring interface among other things, takes care of replicating the data to the different instances, performs maintenance tasks, and stores the data. Thus, a problem in one task area can quickly affect other areas. For example, authors may suffer performance losses if the server has to process simultaneously uploaded images or videos.

The self-containment principle, on the other hand, describes that a container must contain everything it needs during operation at build time. This ensures that new containers can be started at any time. However, this is not possible with the classic AEM architecture, since the container contains content that changes during operation.

• Asset Compute Service
  The Asset Compute Service was introduced to separate the asset processing from the CMS. It takes care of the creation of renditions, integration of the AI features (smart cropping, smart tagging) and integrates own workers. This means that the resource-intensive are separated from the authoring and do not affect the performance of the performance of the authoring environments.
•  
• Content Repository Service
  The Content Repository Service provides a central repository for the content created and published with AEM. The publisher tier only reads from the repository, while the Author tier both reads and writes. Binary files are stored repository to a BLOB store, which is also shared by both tiers.
  
• 
  With the introduction of the Content Repository Service, Adobe is also moving away from the old AEM principle "Everything is content!" and separates the Code Base from the CMS content. This is therefore no longer stored in the central repository, but each author and publisher node stores the code itself.
•  

• Replication Service
  
• The Replication Service manages the publishing of content from the Author instance to the Publisher instance using a middleware pipeline. Individual publisher nodes subscribe to the content that is moved from the authoring nodes to the pipeline.
  
  With the completion of the project last year, the AEM as a Cloud Service product is available and Adobe itself describes this solution as Cloud Ready.

Summary

The new AEM Cloud-Native architecture is significantly more stable and easier to scale than the AEM Classic architecture. By introducing the Content Repository Service and separating content and code base in line with the self-containment principle, publisher and author nodes can be automatically created and destroyed on demand. By outsourcing numerous services from the publisher and author nodes to microservices, there are also significantly fewer disruptions in CMS operation.

Release Management

As with the architecture, there are major differences between AEM Classic and AEM Cloud Native when it comes to release management.

AEM Classic

Licensing
When licensing the different variants, a differentiation must be made not only between the different deployment variants, but also between the individual AEM products Sites, Forms and Assets.


AEM Sites
While AEM Sites is licensed based on instances and authors in the on premise variant, the AEM as a Managed Service solution is licensed based on traffic, number of users and the SLA. AEM Sites as a Cloud Service, on the other hand, is only licensed on the basis of so-called content requests. One content request is equivalent to one page view or 5 API calls.


AEM Forms
With AEM Forms, on the other hand, the licensing metric is very consistent. It is based on transactions for all variants. Only for As a Managed Service, the SLA is also taken into account.


AEM Assets
For AEM Assets, the number of authors and brand portal users is used as the basis for all variants. For AEM as a Managed Service, the required storage and the selected SLA also have an effect. In the case of AEM as a Cloud Service, the license is also based to a small extent on the memory required, in addition to the authors and fire portal users.

Summary
In summary, it can be said that all three variants still have their reasons for being. On Premise is still the first choice for many German companies due to data security and data protection issues. With AEM as a Managed Service, even complicated individual requirements can be mapped in the cloud with a very high SLA. However, AEM as a Cloud Service will steadily increase its footprint as the much more modern architecture solves many known AEM challenges and Adobe is also moving strongly in this direction. Currently, however, there are still one or two blockers to the cloud native solution for some projects. As is often the case in IT, choosing the right deployment variant depends on the exact application scenario. We are happy to support you in defining your application architecture and solution design.

References

1 Adobe (03.08.2020): Adobe Experience Manager Managed Services | Product Description. Retrieved 27 Jan 2021, von https://helpx.adobe.com/legal/product-descriptions/adobe-experience-manager-managed-services.html

2 Adobe (29.06.2020): An Introduction to Adobe Experience Manager as a Cloud Service. Retrieved 27 Jan 2021, von https://experienceleague.adobe.com/docs/experience-manager-cloud-service/overview/introduction.html?lang=en#value-added-as-a-cloud-service

3 Ihor Dvoretskyi (19.07.2019): Cloud Native Computing Foundation (“CNCF”) Charter. Retrieved 29 Jan 2021, von https://github.com/cncf/foundation/blob/master/charter.md

4 Carlos Santana: Cloud-native principles. Retrieved 27 Jan 2021, von https://www.ibm.com/cloud/architecture/architecture/practices/cloud-native-principles

5 Adobe (09.12.2020): An Introduction to the Architecture of Adobe Experience Manager as a Cloud Service. Retrieved 27 Jan 2021, von https://experienceleague.adobe.com/docs/experience-manager-cloud-service/core-concepts/architecture.html?lang=en