AEM as a Cloud Service – High Level Deployment Architecture

It’s been a while since I wrote an article and what better way than starting again with AEM as a Cloud Service.

This article will give you a high level understanding of the architecture and how AEM is deployed on cloud. The references of this article are Adobe Documentation and AdaptTo.

There are huge underlying architectural changes in AEM as a Cloud Service. AEM is finally dockerized or containerized officially and icing on the cake is with Kubernetes.

The value add of AEM as a Cloud Service :

• Always On
• Auto Scaling
• Always current

The above values adds are possible due to Kubernetes and containerization of AEM.

Kubernetes Introduction

• Kubernetes is a Container Management Tool which automates the deployment, auto scaling, and managing the container application.

Few of the key features of Kubernetes is:

• Horizontal Scaling
• Self-Healing
• Service Discovery and Load balancing
• Service Topology

Kubernetes Dictionary

Pod – is a group of containers that are deployed together on the same host

Service – Internal Load Balancer, exposing a large number of Pod replicas

Ingress – exposes a service under a public IP address

There are many other advantages of Kubernetes but these are few are directly utilized into AEM as a Cloud Service.

AEM as a Cloud Service deploys AEM in a Docker Images. This basically means the state of AEM is outside of the Docker image.

• /apps and /libs lives in the container
• The content and persistent nodes are outside of the container

High Level Architecture AEM deployment using Kubernetes:

Ref: AdaptTo

AEM Author Deployment

• Author instances are deployed as Docker AEM image container inside the pods.
• Kubernetes support auto scaling – meaning as the load on the server increases or reaches a threshold, Kubernetes deploys more pods of Docker AEM image containers to support the load.
• The author environment inside the nodes of pods are clustered and share a cloud MongoDB storage. The non-binary state of the authoring application is maintained in MongoDB.
• Author and publishing pods share the common cloud blob data store. (same as current versions where we use common s3 data store)
• The asset binaries that you upload in authoring system directly gets upload to the Cloud blob store.

AEM Publish Deployment

• Publish instances are also deployed as Docker AEM image containers inside the pods
• Since publish servers utilizes a common cloud segment store to support the non-binary state of the applications.
• If the load increases on the publishing servers, Kubernetes auto scales by deploying more pods under the service.
• To support deploying new publish instances at run time, Adobe uses a golden publish to replicate and create news pods at run time.
• If some publish pods stops performing due to some reason, Kubernetes uses the golden publish pod to replicate the new publish pod.
• The golden publish pod is not connected to the load balancer service and is the single source of truth for publish farm.
• Publish pods also utilizes the common cloud blog data store.

AEM Author – Publish Replication

• There are no replication agents present in AEM as a Cloud Service
• All the replications are binary less.
• The replication happens utilizing the Adobe Pipeline message queues. Sling content distribution is used to replicate the changes from author and publish. When some content is published in author, the content is added to the pipeline queue and each of the publisher pod reads the queue and updates its content.
• The entries in the queue is persisted  (7 days I guess default)

The Cloud Blobstore allows direct upload and download features

This feature enables a remote client of AEM to upload or download binaries directly to/from a supported Blobstore without streaming the binaries through the AEM.

Using this feature frees AEM from the network, memory and disk I/O involved in transferring binary files, and provides clients of the AEM with scalable, redundant and high-bandwidth access directly to the cloud storage. This eliminates the web application server and its deployment environment as a potential bottleneck of network capacity. Furthermore, it allows leveraging CDN or transfer acceleration options of the cloud storage providers.

The API is designed to be independent of the particular cloud provider, and relies on standard HTTP binary upload & download, as well as cryptographically signed URLs. Currently Azure BlobStore is supported.

AEM as a Cloud service has been recently made GA and looks very promising in terms of performance, scale and standardization. Especially in terms of AEM Assets as a Cloud Service, it solves few of the major problems like Asset Upload, download limit as well as performance and Asset Processing (Asset Microservices).

 

In the next articles, I will cover how

• AEM Assets as a Cloud Service will solve the problems that exists in AEM 6.5
• Asset Microservices and how it uses Adobe Runtime for processing.
• How pre and post processing can be done on the Assets.
• Best practices in deploying applications using Adobe Cloud Manager

#StaySafe #StayTuned.