Adobe Experience Manager As a Cloud Service - Features and Benefits

AEM as a cloud service is a new and redesigned offering from Adobe to manage sites in the cloud-native environment. It helps you deliver content quickly and efficiently using a built-in Content Delivery Network (CDN), and other best practices.

What’s new

• Always on: AEM as a Cloud service is a cloud-native AEM implementation with service-oriented architecture. You will not experience any downtime.
• Always current: AEM in the cloud is always up to date with new features that are updated regularly without any downtime.
• Always at scale: AEM is redesigned to keep code and content separate. Every instance contains only code packages. This new architecture paradigm helps to create and recycle instances on the cloud at scale easily.
• With AEM as a cloud service, AEM asset handling is done through a different microservice, which is more efficient than earlier.
• It offers CDN out of the box for images, files, and assets.

In its new avatar, AEM as a Cloud service brings exciting new features for different roles. To help you make a well-informed decision on behalf of your team/role, we have curated a list of changes and features by role.

Business user/Author

• AEM Assets sharing with Marketing Cloud and Creative Cloud is not available. Customers would need to use Adobe Asset Link for integration with Creative Cloud.

• There is a significant change in the way assets are managed in AEM as a cloud service. It comes with a dedicated microservice for asset processing, which has brought in the following changes compared to traditional On-premise installation:

  • All assets are directly uploaded to binary cloud storage, which is a separate entity from AEM instances. Because of this, asset import does not impact the performance of the AEM Author.
  • Asset upload is now faster.
  • DAM Asset upload workflow in the previous version is no longer required. The Author triggered this workflow for every asset upload for asset processing ( create renditions, text extraction for indexing), etc. This was consuming a lot of author resources. In the new implementation, this is handled by the Asset microservice in a more scalable way without impacting the performance of author instances.

• Following features are not yet supported:

  • AEM Forms
  • AEM screens
  • AEM Community
  • User-Generated Content (UGC) such as profile or form submissions.
• Only Adobe IMS (Adobe SSO) Identity Management is supported for authentication. IMS can be configured with Organization SSO using Federated ID.

• In AEM Cloud service, operations that traditionally have blocked the UI have been broken down into smaller tasks in the background.

  • Roll-out pages
  • Move pages

Developer

There are many changes from the development standpoint in the way you structure your project and push code to staging or production. Here are some of the main changes.

Structural changes

• Until now, code and content were packaged together into a single file. With this version, AEM requires a separation of code and content. This means a single content package cannot deploy to both /apps and runtime-writable areas (e.g.,/content, /conf, /home, or anything not /apps ) of the repository.
• This version has introduced a concept called mutable and immutable areas of the repository. /apps and /libs are considered immutable areas of AEM as they cannot be changed (create, update, delete) after AEM starts. Any attempt to change an immutable area at runtime will fail.
• Everything else in repositories: /content , /conf , /var , /etc , /oak:index , /system , /tmp , etc. are all mutable areas. This means they you can change them at runtime.

Local setup

For development, you need the following artifacts.

• Quickstart Jar - The AEM runtime used for development
• Java API Jar - This contains all dependencies required for local dependencies.
• Dispatcher Tools - The set of tools used to develop against Dispatcher locally.

Since improvements are made to AEM on a continuous basis, it is recommended to download the latest SDK frequently, and then rebuild and test the custom application. The monthly maintenance release will typically include more impactful changes and thus developers should immediately refresh, rebuild, and test.

Code repository

The cloud manager provides a Git repository account to manage code. This git repo is tied to CI/DD pipeline to deploy code to staging or production. The cloud manager also provides a way to sync your own git repository with the Cloud manager’s git repository.

Development guidelines

• We might often cache data in Service to avoid fetching of data from nodes with each request. The state must not be kept in memory but persisted in the repository.
• Publish tier should ensure that any data that needs to be persisted is shipped off to an external service for longer-term storage.

• AEM as a cloud service instance is frequently recycled - can be brought down at any time without intimation. Keeping this behavior in mind, developers need to avoid the following implementations:

  • Events such as JCR events or Sling resource events can not be guaranteed to be executed locally. You should avoid using this event handler for critical logic in the code.
  • Executing long-running jobs should be avoided if possible. Or it should be resumable, i.e when code gets re-executed it should not start from the beginning but rather it should start from the point where it left off.
  • AEM instances running on AEM as a Cloud Service will enforce a global timeout. These timeout values are 10 seconds for connect calls and 60 seconds for read calls for connections used by the following popular Java libraries:
• Reverse replication from Publish to Author is not supported in AEM as a Cloud Service. If such a strategy is needed, you can use an external persistence store that is shared amongst the farm of Published instances and potentially the Author cluster.

DevOps

AEM as a cloud service has alleviated a lot of operational pain to manage AEM.

• With AEM as a cloud, your application is always running on the latest version of AEM and hence organizations do not need to worry about upgrading to newer versions anymore.
• Autoscaling was another big challenge in the past. Especially auto-scaling of author instance which was not possible earlier.

Changes

• All environments are managed through the Cloud Manager.
• The /apps and /libs paths, as well as the OSGi console, are not modifiable at runtime.
• No access to Felix OSGI console.
• No access to CRXDe lite in staging and production environments. The cloud manager provides a developer console to access.
• You don’t have console access to the boxes.

Debugging in Cloud service

• In both staging and production, users will not have access to the OSGi web console. To change any configuration, update the OSGi configuration in code and redeploy the application. However, in a local system, developers can access this console.
• AEM as a cloud service provides a Developer console to view various details like running status, list of bundles, components, OSGi configurations, services, OAK indexes, Queries, and Java packages. So developer console is kind of alternative to OSGi console in cloud instances
• On cloud instances, you can download logs only from the Cloud Manager. In order to debug issues, you need to download logs locally and then use the command line too to tail the logs. Logs can also be downloaded through cloud manage API and Adobe IO command line API. Even dispatcher can be downloaded using this method.
• Log levels can be modified directly on the instance. Changing log levels will require you to check-in Sling logging OSGi configuration and redeploy your application.
• To get thread dumps, you should submit a request to AEM support.

Code Deployment

Code deployment can happen only through CI/CD process. On release, changes will be deployed to all Author and Publisher instances. If you see any issues due to a release, you can rollback all changes. There is no argument that CI/CD is a recommended approach for any kind of application. However, this diminishes some of the flexibility in deployment in the on-prem AEM setup. We had the flexibility to deploy the code to just one of the instances and validate the changes before deploying it on the rest of the instances.

End of the day, we may see surprises on production in spite of a lot of testing on staging due to different datasets. This model really helps to minimize the impact of the wrong release.

We are not saying this is the best way to deal with wrong releases. However, these are very handy to deal with simple issues easily rather than rollback the whole release.

Maintenance tasks

Adobe will manage maintenance tasks that do not require customer decisions. For example:

• Garbage collection
• Version Purge
• Audit Log Purge

Backup and restore

In the event of content or data corruption, AEM as a Cloud Service can restore a customer's full application (code and content) to specific, predetermined times from the last seven days.

Customers should file a support ticket, describing the issue being experienced. This will lead to an investigation by Adobe support who will determine if a restore is necessary.

Hope these points help you make a well-informed decision on your AEM Cloud journey. If you have any questions, do reach out to us for a free workshop. We can help you understand fit, feasibility, and cost estimates for your organization.