We’ve just wrapped up Adobe Summit 2022, and there were some seriously interesting new developments that Adobe announced for its AEM as a Cloud Service digital experience platform.
Last year’s Summit had a mild lack of shock value, due to our getting a steady diet of amazing new features all year as they were released. But this year, the Adobe crew was prepared with some heavy-duty features that they’ve been working hard on this year, with a real focus on bettering the developer and operations experience.
New Relic APM comes to AEM as a Cloud Service! Finally!
If you’ve read anything I’ve written in the last two years, it’s been one of the most major points that has made it tough to recommend AEM as a Cloud Service in the past, in that there was no way for developers to get a feedback loop for how their AEM environments are performing. Additionally, as AEM as a Cloud Service automatically scales up your environment to meet load, it could be that your infrastructure would automatically scale up due to poorly-performing pages and API calls, ridiculously large repository traversals, or poor caching strategies – and you’d NEVER KNOW.
New Relic is already being used by Adobe engineers on the backend, so there’s nothing to do on the infrastructure side to enable it for you. However, setting up your own access to access New Relic One for AEM as a Cloud Service requires some manual ticketing & work on your end, which is described here in the Adobe docs.
Again, tough to overstate how excited I am about this feature, given that it’s come up in every interview I’ve had with anyone on the AEMaaCS product side, as well as in virtually every blog post I’ve written on the subject. It’ll be fun to put this into use!
And now, with APM on the application server, plus ingesting Splunk logs from the Dispatcher, Publisher and Author, plus being able to also get logging from AEM Assets Worker Microservices (another amazing new feature that I saw demo’d at Summit that deserves its whole own blog post) plus adding in Synthetics monitoring on the front end, it’s entirely possible to have a full suite of pro-grade application, browser, performance and stability monitoring for your web presence.
There are a number of other features which are in the “coming soon” category, and are meant for delivery in Q2-Q4 2022.
This is a long-requested feature, both on AEM as a Cloud Service, but also on AMS as well (AEM Managed Services for AEM 6.4/6.5). Actually, it’s been a pretty regular ask of any devops team for any CQ/AEM site I’ve ever worked on.
The problem is: in order to test adequately on lower environments, lower envs have to match prod. The longer production operates, with authors publishing out content, versions getting created, indexes being updated, etc, etc, the further your Stage and Dev environments get from actually looking and acting anything like the production environment. So, the requests inevitably come to get a full copy of the Prod environment brought down to Stage or Dev so that testing can be done against the full corpus of content in the repository. But that’s always been harder than it sounds, and is more so with a completely new architecture like the Cloud Service is.
Details are still forthcoming, but what we know at this point is that the copy-down functionality will allow you to copy all of the content from your production environment down to any of your dev or stage environments (Cloud Service only, not local or local-hosted). It’s possible that they may allow you to copy to other Programs as well – which would be intensely useful if one was going to need to make a complete copy of a site to turn over to another business unit for, say, a EU-only website or the like. We’ll learn more about this when the feature is released.
CDN Logs & Tuning
If you look at the overall architecture of the AEM as a Cloud Service product, all inbound requests to the system go through the Fastly content delivery network (CDN). Normally, the CDN slaves off of the cache-control headers that you set in the dispatcher, so any cache lifetimes or cachability of objects is generally controlled there. However, let’s say you want different cache behaviour, or are trying to troubleshoot why it was that – maybe – an image didn’t show up right, or a cached copy was being served when it shouldn’t, or maybe you thought a purge happened but it didn’t, etc. Or perhaps you want different cache behavior in your CDN than your dispatcher.
Tooling is going to be coming out for more CDN tunability later in 2022, which is very exciting -especially for sites that leverage the CDN heavily for performance. This is especially important where you want different rules for areas that are further away from the origin – like if you’re running AEM in China and are serving out of Singapore. You may want your /content/zh/cn to be cached in the CDN WAY more than /content/ja/jp or something like that.
Additionally – LOGGING. Currently, the only logs that you get in Splunk when you set up Splunk log forwarding is the access, error, request and dispatcher logs – but not any logs for the CDN. This is evidently set to change, with logs from the CDN made available to you for troubleshooting and analytics. Again, this is HUGE.
This feature – which we got very little detail of and which should be available around Q4 of this year, is allowing the creation of temporary AEM environments in the Cloud Service on which live changes can be made without a pipeline.
If you’ve followed any of the deployment chatter on AEM as a Cloud Service deployments, the mechanics and safety features built into the AEM as a Cloud Service deployment mechanism makes for some sometimes very slow deployments. Dev deployments generally take around 45 minutes, production deployments can take two hours. There are a NUMBER of things that Adobe is currently doing to speed that up, with a near-term goal of having all dev deployments take under 30 minutes and prod deployments taking under an hour.
But still, for quick dev changes where you want to tweak one thing and watch it go, it’s important to be able to iterate fast. In such a case, the ability to spin up a temp environment on which hot changes can be made is a big deal, and gets bigger the more you think about your last deployment. 🙂
One thing that has changed with the Cloud Service is that the old CRXDE node-browsing environment previously available on self-hosted versions of AEM (or on the local SDK) is not available in the cloud service. So, sometimes when you need to browse the repository for specific debugging (why did this meta tag get applied, what configuration is REALLY running on my system, etc) it makes it hard if you can’t crack open the repository and look directly at the repo. Fortunately for us, it was Bertrand-to-the-rescue once again!
Oooh, these are all fantastic new features! Great write-up, thanks!