AEM as a Cloud Service a Year Later – Update on Features & LimitationsFebruary 13, 2021
Approximately a year ago, I made an ill-timed blog post when, in browsing Adobe documentation, I discovered that AEM as a Cloud Service had been released. Only slight problem was that I’d preempted the official Adobe release, and had to retract my blog post for a week or two until the official unveil. (oops) I didn’t make a lot of friends in Adobe PR that day.
But fast forward through the last year and the big question has always remained is not “is AEM as a Cloud Service an amazing technical achievement?” because it is. But instead the question is whether or not it will support the workload that you’re looking to put on it with the requirements of your organization. So now, a year later, I wanted to quickly take stock of what’s changed in AEM as a Cloud Service, and which feature-gap showstoppers have been addressed by Adobe and which may no longer be showstoppers for your projects.
Table of Contents
AEM as a Cloud Service – New Features in 2020/2021
With major releases coming out once every month (see release notes here), there have been countless new minor & major features added and bugfixes addressed over the last year. I wanted to focus in on a handful of the big ones though, as they have addresses a number of the major gaps that (as noted here) existed in the initial rollout of the AEM Cloud Service offering.
AEM Screens as a Cloud Service
Just announced at the Adobe Developers Live event this past week, Adobe is rolling out now with a beta of a new AEM Screens Cloud Service. AEM Screens is an extension of AEM’s capabilities as an all-powerful hub for all of your multichannel experiences you’re looking to drive. AEM Screens allows one to take digital assets and experiences that you house in AEM, and radiate them out to digital displays like the ones you see in metro stations, hotels, restaurants and city squares.
Up until now, Screens was supported only in self-hosted AEM or in AEM hosted by Adobe Managed Services. However, the Screens product has now been fully re-engineered as a true cloud service that doesn’t actually reside (mostly) in an AEM container at all. I’ll be doing a separate blog post on this product once I’ve gotten my hands on it (I only first heard of it a few days ago) but it opens exciting new doors for scalability of a solution one could use to power anything from a single hotel’s displays, to the digital displays at tens of thousands of retail stores.
AEM Forms as a Cloud Service
AEM Forms is a ye olde product that was earlier the “Adobe LiveCycle server” product which then later was a server-within-a-server product that shoehorned massive amounts of adaptive forms, PDF generation and document-of-record functions, as well as a whole host of supporting open source OS packages onto a very capable, very complicated product that was NOT “cloud-ready” by any stretch of the imagination. Whether running as an OSGI service inside of AEM or inside of JBoss, AEM Forms has always created its own unique brand of fun for DevOps folks.
It’s been entirely re-thought as a Cloud Service, and cloud-native functionality is being rolled-out piece-by-piece as it’s ready for primetime. Right now the main features are AEM Adaptive Forms, Adobe Sign integration and Forms Data model, with other key features (PDF Generation, Output Service, etc) coming at a later time.
AEM Commerce as a Cloud Service
AEM Commerce wasn’t a part of the initial AEM as a Cloud Service rollout, but it followed a few months after. Commerce has very quickly moved from being a “nifty beta integration” into a first-class citizen in AEM world, making integrating in compelling commerce capabilities into your AEM site a reality. The AEM CIF (Commerce Integration Framework) supports connecting to both cloud-hosted as well as self-hosted Magento infrastructure, making AEM Cloud Service a versatile option for “owning the glass” on a content-heavy site with commerce capabilities.
Integration with InDesign Server
AEM Assets as a Cloud Service now works with InDesign Server, so long as that InDesign Server is hosted at Adobe Managed Services (AMS). This is another gap that had existed between the self-managed AEM and the Cloud Service, as this now allows brands that have specialized Asset workflows with InDesign file uploads (translations, PDF Output, etc) to be accomodated on the Cloud Service.
Huge Investments in Migration Tooling
Adobe has put tons of engineering muscle behind creating tooling to make it straightforward as possible for brands to move their workloads to the Cloud Service. Some rather notable examples are:
Content Transfer Tool: This tool can run in your self-hosted or AMS-hosted AEM environment and can be set to clone and migrate any or all content from your existing AEM environment to the Cloud Service. It supports delta transfers as well, so as to support content moves and go-lives without having to create iterations of massive multi-gigabyte content packages, or to set up brittle VLT-RCP content transfers yourself.
User Mapping Tool: A major change to AEM as a Cloud Service is the fully integrated use of Adobe IDs for accessing the author tier. So, this user mapping tool allows one to migrate users from your existing AEM setup to ones with valid Adobe IDs.
Bulk Uploader: This Asset Bulk Ingestion Tool allows one to upload assets directly from an S3 bucket or Azure blob store location directly into AEM Assets, along with a separate metadata track which allows for exponentially-faster Asset migrations, especially when you’re talking about a many-TB Asset store that you’re migrating.
Self-Service IP Whitelisting, SSL Certs & Custom Domain Names: Adobe has rolled-out functionality to allow you to self-service manage your IP whitelisting to backend AEM resources (i.e. locking down your Author tier to only a specific IP range, but opening up access to necessary 3rd-party hardware like a search cluster), to manage your SSL certificates, and to allow for custom domain names on resources.
Splunk Logging for AEM Cloud Service Environments
This is a feature I’d been asking for since day 0, as running a complicated application server without the ability to do historical searches, look for error trends, create dashboards, etc is frustrating in the extreme. Prior to this past month, the only way to get at your logs was via an Adobe IO integration (blog post here) Adobe now allows you to forward your logs to a bring-your-own Splunk indexer, so that you can do your own slicing and searching of machine data out of your author, publish and dispatcher instances. I’m working on setting this up now, so once I have some of my favorite Splunk dashboard ported over to AEM as a Cloud Service, I’ll make sure to do up another post.
Gaps & Limitations
There are still a number of gaps and growing pains that face adopters of AEM as a Cloud Service, which companies should be aware of when planning whether or not to launch your next project on a self-hosted AEM AEM platform, or take the leap onto the Cloud Service.
At this writing, if you’ve got data residency restrictions, the Cloud Service may be a non-starter. Given that the AEM Cloud Service
is only deployed in 3 Azure regions at the moment (US and UK). Update 16 Feb 2021: When I’d written this, I had just finished talking with two different folks at Adobe about an EU project we were pursuing, and I’d been told AEMaaCS only was available in 3 regions. HOWEVER, I just got an update from two OTHER folks at Adobe that there are actually a number of other regions that are available for the Cloud Service.
Quoth my Adobe source:
The following datacenters are now live and available in Cloud Manager when creating a new environment:
– EMEA-Great Britain
Canada is coming in the next few days. Then we’ll add Singapore in Q2, Germany in Q3 and India in Q4. I know there’s a couple of “old” references in our public documentation to 3 regions only – but we are getting them corrected.
Also I would be great to note that independently from the “region” where the AEM Cloud Service is operating from, all are served globally with more than 70 CDN POPs
As noted above, AEMaaCS comes built-in with a Fast.ly CDN which enables out-of-the-box acceleration of all resources from those 70 CDN POPs. One would just need to take the above into account when considering one’s global footprint, user base, and data residency requirements.
Note that this is such a challenge that Adobe does have a separate product that they’ve been working on with IBM and Redhat to deploy a containerized AEM on OpenShift for regulated environments like financial services.
Only on Azure, AWS on the Way
There are eventual plans to be able to port AEMaaCS to AWS, as well as to bring it to more individual regions,
but at this writing the AEM Cloud Service is only deployed in 3 Azure regions, (UPDATE: SEE ABOVE) which may make it challenging to leverage if you, say, have low-latency connections you need to maintain to resources you have hosted in AWS.
Again, Adobe’s boffins are busy working on opening up more regions, but this is a limitation at this time.
AEM Forms Cloud Service Limitations
As noted above, the new AEM Forms cloud service is only launching with a subset of the full AEM Forms functionality. So, for example, if you use the PDF Generation & Output services in your AEM Forms implementation, you’ll need to continue to soldier on using the self-hosted or AMS-hosted versions of AEM Forms for now.
No AEM Communities support
It is still yet to be publicly announce what form AEM Communities will take when it moves to the Cloud, but right now AEM Communities is not supported on the Cloud Service.
As you can see from this diagram of the AEM Communities infrastructure, getting this right in the cloud service will be significant re-engineering effort to make it cloud-native and scalable.
Lack of Application Performance Monitoring (APM) Support
Adobe internally uses a massive host of various tools to monitor the health and performance of the AEM Cloud Service infrastructure. However, at this time, there is no way to get APM Metrics from New Relic (or any other APM) from the Cloud Service for your own pages. This can make it somewhat trying to be able to debug performance issues within the product.
Should I Move to the AEM Cloud Service?
All told though, it’s impressive how much muscle Adobe has put behind making the Cloud Service a viable platform to move workloads to. On the one hand, the always-on, always-at-scale and always-updated aspects of the cloud service make it very compelling, especially if one’s had to deal with hardware being a limiting factor on previous Experience Manager deployments.
Does it mean that the Cloud Service is right for your planned deployment? Hit me up on LinkedIn, I’d be happy to chat about it!