Panel Discussion and Q&A with Adobe on AEM as a Cloud Service

I got to participate in a great panel discussion hosted by Adobe Global Community, discussing AEM as a Cloud Service. I’ve edited up a full replay of the discussion here, as well as some deep links to the discussion, and the Q&A that took place as well.

The guest panelists in the discussion were:

• Philipp Koch – Director of Engineering at Adobe
• Alexander Klimetschek – Principal Scientist at Adobe
• Lokesh Shivalingaiah – AGC Board Member and Principal Architect at TA Digital
• Barnik Maitra – AGC Board Member
• Tad Reeves – AEM Architect at ICF Next (me)

Questions Taken Up in the Discussion:

• What is AEM as a Cloud Service?  (Mechanical discussion of the service itself and what it consists of.)
• What new features of AEM as a Cloud Service are you most excited about? The panel dove into subjects like Assets Microservices, Assets CDN improvements, and the potential to make AEM upgrade projects go much more effortlessly.
• How is AEM as a Cloud Service different for developers working on self-hosted AEM or Adobe Managed Services? (AMS)
• If you have AEM hosted on-premise, and have it integrated with other Adobe applications, what is the impact of moving to AEM as a Cloud Service?
• Who is the ideal customer for AEM Sites or AEM Assets as a Cloud Service, given the current state of the product?
• What is the cost structure for the AEM as a Cloud Service? Philipp from Adobe dives into the costing & rationale how AEM as a Cloud Service is priced.
• MIGRATION: What does the migration process look like presently to AEM as a Cloud Service?
• Challenges: What are the technical challenges that you see a typical AEM customer facing that AEM as a Cloud Service dramatically changes?

Q&A on Moving AEM to the Cloud with the Panel

This is a selection of the Question & Answer provided by the panel during & after the panel presentation.

Q: Is there a way to move customers from on-premise to cloud easily or is this a green field deployment? Can this work in a hybrid arrangement?

A: There are a few answers to this question, and I’m going to take this up in a separate post. But just released the day after the panel discussion was the AEM Content Transfer Tool, which is a package that allows you to directly transfer a complete set of content from an on-premise or self-hosted AEM environment to an AEM as a Cloud Service instance.

In terms of whether or not you can use it in a hybrid environment, that in itself deserves its own post with the valid hybrid architectures you can employ. One such hybrid is using AEM Assets as a Cloud Service with the Remote Assets functionality in AEM 6.5, which is a potentially intriguing concept.

Q: Any recommendation on AEM 6.5 training both developer & administration? Any virtual or on-demand training from Udemy is fine at this point in time.

There are training in the Adobe portal and anyone can register for the same. It has both virtual and class room types .

I would also say that Dan Klco and Mr. Maynard from Hoodoo have done some FABULOUS courses on Pluralsight that I’d highly recommend. Courses like Tyler’s Building Full-Stack Components in AEM or Dan’s Extending Adobe Experience Manager Foundations are excellent places to go for developer training.

Unfortunately for Administrator training, there isn’t a great training line-up aside from Adobe’s own ADLS course on AEM administration, and it’s spendy, and that even won’t get you nearly as far as just working with an AEM environment for a while and reading blog posts.

Q: What about customers haveing AEM Forms? Is there a roadmap for migrating those customers?

AEM Forms, Commerce, Screens and Communities are currently not supported in AEMaaCS. Forms is definitely a roadmap item, though I don’t know it’s public as to WHERE in the roadmap it is.

Q: Will On-premise AEM option still exists? If so how long?

AEM on-premise still exists, and at this point in time there is no EOL for AEM 6.5. There are service packs in the roadmap until the end of the year, but after that Adobe is still evaluating where to take it from there based on customer adoption.

AEM 6.5.7 is the last public roadmap release (i.e. there is no AEM 6.6 presently announced), but there are plenty of customers I am working with that won’t even be finished upgrading to 6.5 by the end of the year, never mind ready (or identified as a candidate) to migrate everything to AEM as a Cloud Service. So, practically speaking, on-premise or self-hosted AEM will continue to exist for some time.

Q: is there an online compaction feature without impacting user experience in authors?

Yes – and as gone over in this part of the panel video, most every maintenance function on AEM will now be taken care of directly by Adobe as a part of the service. This help article talks about what maintenance tasks are done by Adobe and which are done by the user, but basically it’s:

Maintenance Task	Who owns the configuration	How to configure (optional)
Datastore garbage collection	Adobe	N/A – fully Adobe owned
Version Purge	Adobe	Fully owned by Adobe, but in the future, customers will be able to configure certain parameters.
Audit Log Purge	Adobe	Fully owned by Adobe, but in the future, customers will be able to configure certain parameters.
Lucene Binaries Cleanup	Adobe	Unused and therefore disabled by Adobe.
Ad-hoc Task Purge	Customer	Must be done in github.Override the Maintenance window configuration node under /libs and /apps with /conf/global/settings/granite/operations/maintenance/granite_weekly or granite_daily . See the Maintenance Window table below for additional configuration details.Enable the maintenance task by adding another node under the node above (name it granite_TaskPurgeTask ) with the appropriate properties.Configure the OSGI properties see the AEM 6.5 Maintenance Task documentation
Workflow Purge	Customer	Must be done in github.Override the Maintenance window configuration node under /libs and /apps with /conf/global/settings/granite/operations/maintenance/granite_weekly or granite_daily . See the Maintenance Window table below for additional configuration details.Enable the maintenance task by adding another node under the node above (name it granite_WorkflowPurgeTask ) with the appropriate properties.Configure the OSGI properties see AEM 6.5 Maintenance Task documentation
Project Purge	Customer	Must be done in github.Override the Maintenance window configuration node under /libs and /apps with /conf/global/settings/granite/operations/maintenance/granite_weekly or granite_daily . See the Maintenance Window table below for additional configuration details.Enable the maintenance task by adding a node under the node above (name it granite_ProjectPurgeTask ) with the appropriate properties.Configure OSGI properties see AEM 6.5 Maintenance Task documentation

Customers can schedule each of the Workflow Purge, Ad-hoc Task Purge and Project Purge Maintenance tasks to be executed during the daily, weekly, or monthly maintenance windows. These configurations should edited directly in source control.

Q: Is there a possibility for the customer to set up AEM as cloud service in their own Cloud account and manage that themselves?

No. As this is a cloud-native service, there is no encapsulated “docker image” or anything similar which would allow the customer to run this themselves.

Q: For which use cases would you NOT recommend AEM as a Cloud Service for?

We did take this up a bit near the end of the video presentation with some specificity, as there are definitely some use cases that it does not support at this time. This article also goes into some depth on that.

Q: If there is no access to OSGI then if there are features built using flags how do update ?

“System” configuration updates that have been done through the OSGi console before will come through the custom code and go through CI, following the immutability principle needed for horizontal scaling and auto-updates.

It’s a lot more than just “/system/console” isn’t available on running systems, as one has to be aware of mutable vs immutable content in AEM, and what can be modified at runtime vs what will have to be modified through the CI pipeline. This page talks more about that and how it works on AEM as a Cloud Service.

Q: I hope aem as cloud service is using containers. In that case when you scale out I hope you will spin a new container from image in that case all changes to data that I had did in my container how it get carried over to new spinned container

Have a look at this which gives some fabulous detail on how that containerization works:

Q: Have you seen any development efficiencies introduced by the AEM Cloud SDK?

Double-edged sword here. On the one hand, I very much like the fact that there’s finally a dispatcher configuration linter to check your dispatcher configs before they go live. On the other hand, however, there are differences between the SDK and the dev environment, as in the SDK is a standard tarmk setup, does not use assets cloud workers, is not containerized, etc. So, developing locally comes with its own set of challenges presently.

Dan Klco goes into some of those SDK challenges here.

Q: Is this work independent any cloud services provider? like GCP, AWS, Azure etc.,

At launch, AEM as a Cloud Service is only available on 3 Azure regions, with plans to expand it to more regions, as well as to AWS.

Q: How much access control will our DEV teams have if we moved to AEM as cloud service? Like can we ssh to Adobe VM’s ?

Negative – there is presently not SSH access for AEMaaCS. Log access is via Adobe IO, but it’s somewhat limited as you can only get this from a single container, and log messages themselves get truncated if they get too long – so sometimes long stack traces will get cut off by the AIO API. We’re going to take this up likely in our next session as this is a big and sorely needed topic.

Q: Before a implementation is moved to cloud , should all the existing overlays be removed as per the new sustainable upgrade guidelines ?

There is a defined structure in place what parts of the repository can be overlayed or not, and this is one of the quality gates in the Cloud Manager CI and the onboarding. Code that does not adhere to these must be refactored accordingly.

Q: When you say that developers can no longer access the OSGI console, you mean manually, correct? If we use OSGI XML or annotation based configuration for Java service classes, we can still do this, right?

Right – meaning you can’t just hit /system/console/configMgr and start throwing levers and knobs around. 🙂 More specifically, from the AEMaaCS docs:

/apps and /libs are considered immutable areas of AEM as they cannot be changed (create, update, delete) after AEM starts (i.e. at runtime). Any attempt to change an immutable area at runtime will fail.Everything else in the repository, /content , /conf , /var , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.

Ref: Implementing for AEM as a Cloud Service

Your OSGI persistence is generally done in /apps/system, so this is not something you’ll be able to do on a running instance. This doc speaks specifically how to make OSGI config changes on AEMaaCS.

Q: Does AEM as cloud service provide the concept of environments while promoting content . for e.g we run some content review and testing on stage and then move it to prod. How do we achieve this?

There are three environments provided-for in the AEM as a Cloud Service paradigm – DEV, STAGE and PROD. You set up those environments in Cloud Manager, and can promote releases up or content packages as desired.

Q: Tad said commerce is not supported. Does that mean Magento integration will not be supported?

It’s on the roadmap.

Q: How are we going to tail the logs to debug issues ?

Right now it’s somewhat limited. You can download full logs via Cloud Manager, or you can log in and tail the logs of an individual container if you are debugging something specific. Documentation on how to access & tail logs via Adobe IO is here.

However, this doesn’t allow one to look at logs across multiple instances, nor to ingest logs into a log aggregator, so troubleshooting live issues would likely have to be done in conjunction with engineers at Adobe who do have access to log aggregators in the backend.

Q: Does AEM as a Cloud still give you access to the Package Manager and CRX DE Lite?

Yes, but as noted above, uploading packages would have to be limited to mutable areas of the repository.

Q: Are ACS-AEM Commons Tools compatible with AEM as a Cloud Service?

It’s been suggested by Adobe to consider ACS AEM Commons tools to be incompatible with AEM as a Cloud Service unless otherwise noted on the page itself.

A number of the features already are listed as such, like:

Active work is being done, where appropriate, to make a number of the features cloud service compatible, like this.