Adobe Experience Manager (AEM) Cloud Service vs. AEM Managed Services

This is Part One of a four-part series on Adobe Experience Manager as a Cloud Service. This first part provides an overview of AEM Cloud Service as compared with AEM 6.5. Part Two will focus on the unique operations and deployment features of AEM Cloud Service. Part Three will describe how AEM development changes under AEM Cloud Service, along with migration options and lessons learned using AEM Cloud Service to date. Part Four completes the series with an overview of the tools that Adobe provides to facilitate migrating to AEM Cloud Service.

Adobe Experience Manager (AEM) is the market leading web content management system, used to power websites for top brands across multiple industries around the world. We have been using AEM to help our customers achieve their website goals for over eight years now. Until recently, customers had two choices when it came to AEM: take out an “on-premise” license and install AEM on their own infrastructure (whether that was within their own data center or in the cloud) or take out a contract with Adobe Managed Services to host AEM on the customer’s behalf (which I will refer to as “AEM Managed Services” or “AMS”). Regardless of the option chosen, it was the same software – AEM 6.5 (although AEM Managed Services would typically come as part of a “Foundation” package that included entry-level editions of Adobe Analytics and Adobe Target for analytics and site optimization).

Features of AEM Cloud Service compared to AEM Managed Services

Two years ago, the game changed as Adobe announced the launch of AEM as a Cloud Service (which I will shorten to “AEM Cloud Service”). AEM Cloud Service features a completely new container-based architecture along with changes to the way in which content is replicated, assets are processed, and deployments are made.  Some of the many new features of AEM Cloud Service include:

1. Always current – Adobe releases updates to AEM Cloud Service several times a month. These consist of bug fixes, security patches and monthly feature releases. These largely eliminate the need for regular (and expensive) upgrade projects such as were typically required for AEM on-premise and AMS installations.
2. Modular – the AEM architecture has been decomposed from one monolithic application into a core application augmented by several external services. This is explained further below.
3. Scalable – both the Author and Publish tiers auto-scale i.e. new instances are dynamically spun up and torn down as needed based on usage. This will be of significant interest to customers who have major spikes in usage at specific points of the year.
4. Global – AEM Cloud Service comes with a CDN (Fastly) by default.
5. Performance resiliency – geographical redundancy is built into the architecture, which is self-healing (instances can be easily replaced if needed). An environment can be restored to any point in the preceding 24 hours and daily snapshots are kept for the preceding week.
6. Secure by default – AEM Cloud Service features enterprise-level isolation, environments are pre-configured with security rules, and the Author tier is automatically integrated with the Adobe Identity Management System (IMS) by default.
7. Page view licensing – AEM Cloud Service is licensed based on the number of page views for the Publish tier, bringing it in line with other Adobe Experience Cloud products such as Adobe Target and Adobe Analytics.

The architectural changes make AEM Cloud Service cheaper for Adobe (and its customers) to set up and maintain.  The flexible licensing model means that it is easier to support small-mid size customers and allows AEM to better compete with Sitecore, Drupal and WordPress for such customers.

Deeper Dive on AEM Cloud Service Architecture

The architecture of AEM Cloud Service is so different from AEM 6.5 that it is worth taking a deeper dive.  The diagram below illustrates the extent to which the traditional monolithic AEM architecture has been decomposed.

Here is a quick summary of the external services with which AEM Cloud Service integrates:

• CDN Service – a CDN (Fastly) comes OOTB – previously customers had to provide their own CDN.  The CDN is discussed in more detail in Part Two of this series.  
• Replication Service – legacy replication has been replaced with content distribution; this is described further below.
• CI/CD Service – this is essentially Cloud Manager, which is not new but has several enhancements that are specific to AEM Cloud Service.  These are discussed in more detail in Part Two of this series.
• Identity Management Service – this is the integration with Adobe IMS.  This is described further below.
• Content Repository Service – this is how the instances access the content.  This is described further below.
• Assets Compute Service – we’ll talk about that in more detail shortly.
• Testing Service – this is leveraged by Cloud Manager to run a suite of different tests during deployment.  These are discussed further in Part Two of this series.
• Orchestration Service – this is what monitors the load on each tier and auto-scales the instances.  It can scale horizontally (by adding instances) or vertically (by adding memory and/or CPU capacity).

Content access and distribution deserve more discussion.  Traditionally AEM storage has consisted of a node store that stores the non-binary data (e.g. component source code, page configurations, asset metadata) and a blob store that stores binary data (e.g. digital asset files).  The Content Repository Service for AEM Cloud Service consists of separate node stores for the Author tier (leveraging MongoDB to share storage across all the Author instances) and each Publish instance.  Blob storage is shared across all instances in both tiers – which means there is no need to copy binary files when they are published (this was possible for traditional AEM deployments but is the mandatory default for AEM Cloud Service).

Content distribution replaces legacy replication and employs a publish-subscribe model using Adobe I/O and Apache Kafka.  Distributed content is written to a persistent, append-only log that is subscribed to by Publish instances and can be leveraged by new AEM Publish instances to “roll forward” to the latest publish content when needed (new instances are based on a “Golden Publish” instance that represents a recent copy of the content).  This makes content distribution faster and less error-prone than traditional replication.

Asset Microservices

One of the fundamental changes has been the way that assets are processed.  In traditional AEM installations, assets are uploaded directly to AEM, which then triggers the DAM Update Asset workflow to process each asset uploaded.  This can significantly bog down the Author instance when a large batch of assets is uploaded at once.

Under AEM Cloud Service, the processing model has completely changed, as shown in the diagram above:

1. Clients send an upload request to AEM and start uploading the binary directly to the binary cloud storage platform.
2. When the direct binary upload completes, the client notifies AEM.
3. AEM sends a processing request to the Assets Compute Service. The contents of the request depend on the configuration of the processing profiles in AEM (including the renditions to generate).
4. The Assets Compute Service receives the request and dispatches it to one or more microservices depending on the content of the request.  Each microservice accesses the original binary directly from the storage platform.
5. The results of the processing by the microservices, such as renditions, are stored in the storage platform.
6. The Assets Compute Service notifies AEM that the asset processing is complete and provides it with direct links to the generated binaries, which are then made available within the AEM user interface for the uploaded asset.

By writing the binary directly to binary storage and delegating processing of the asset to the Assets Compute Service, asset uploads become significantly faster and more scalable, and it is now feasible to import significantly larger batches of assets than before because the microservices can auto-scale and the impact on the Author instance is negligible.

Enhancements deployed to AEM Cloud Service

Adobe is constantly rolling out enhancements to AEM Cloud Service. Some of the more notable features that have been released since it launched include:

• Preview server – each AEM Cloud Service environment includes a Preview instance – essentially a specialized Publish instance that content authors can publish content to before they publish the content to the Publish instances that serve the live site. This enables business users who do not have AEM logins (e.g. legal or compliance team members) to easily review changes prior to them being made to the live site. Previously customers would need to preview such changes in the Stage environment and then transfer the changes to Production (a tedious and error prone process) or alternatively use AEM’s Multi Site Manager feature to set up an authorable site alongside the live site and roll out changes from the former to the latter.
• Integration with Adobe IMS – essentially this means that users and groups can be managed via the Adobe Admin Console rather than directly in AEM.  Adobe IMS can also be integrated from an authentication and single sign-on perspective with external Identity Management Systems such as Azure AD via OpenID Connect or SAML.  Azure Sync can also be used to sync users and groups from Azure AD to Adobe IMS (and hence to AEM as well).
• Better support for SPAs – Adobe’s support for Single Page Applications (SPAs) now includes the ability for SPA’s with authorable content to be edited within the AEM authoring user interface.
• Smart tags for documents – this feature leverages the AI capabilities of Adobe Sensei to analyze text documents such as PDFs as they are uploaded into AEM and extract useful keywords that are applied as tags to the document, building on what was possible before for images and videos.
• Content automation – this feature enables Adobe Creative Cloud APIs to be called as part of asset processing in order to augment or enhance a digital asset such as an image.
• GraphQL endpoints – content fragments were introduced several years ago in AEM 6.3 and provide the foundation for AEM’s support for headless content. AEM Cloud Service now extends content fragments to support GraphQL endpoints as the basis for querying and retrieving content fragments.
• Text transcripts – a brand new feature, this enables text transcripts in VTT format to be generated for the video and audio formats supported by AEM Assets.

Who should use AEM Cloud Service?

Adobe is now rightly positioning AEM Cloud Service as the default choice for new AEM customers and encouraging existing customers to migrate to it. However, there are some scenarios where we recommend choosing AEM Managed Services over AEM Cloud Service:

• Where the customer needs to host their site in a region that is not supported by AEM Cloud Service.  In particular, China is yet to be supported as a hosting option and the great Chinese firewall makes it impractical to serve a site to Chinese users from outside of China – so AEM Managed Services or on-premise AEM is a better option for Chinese websites.
• Where the site needs to comply with specific regulations for which AEM Cloud Service is yet to be certified.  For example, AEM Cloud Service is not yet HIPAA-certified, although this is expected to occur by the end of Q1 2022.
• Where the limitations that the AEM Cloud Service architecture places upon development are a significant obstacle to achieving a key functional or non-functional requirement.  This will be discussed further in Part 3 of this series.

These scenarios tend to be edge cases however, and the vast majority of customers will be best served by selecting AEM Cloud Service as their web CMS platform.