General changes from AEM 6.5 to AEMaaCS

AEM as a Cloud Service (AEMaaCS) contains quite some interesting architectural changes. There is an extensive documentation on that, but I'll highlight some things that struck me and became relevant on the project I was working on.

It is hosted by AEM, and you have to adapt your system to the new deployment scheme. The author servers run in a cluster on a MongoDB - if you're doing a deployment, that'll mean that the new author server will be fired up in parallel to the old server, the system will switch over to the new author server and only then the old one is stopped. Likewise, you'll have several publish servers that do the actual delivery of the content, but they are running on separate JCR repositories that will get their content cloned from one special publish instance (the "golden master") when they start, and get updated by content replication. The /apps and /libs content is immutable now. The outgoing content (including both pages and assets) is always delivered through a CDN - in fact, you're not even able to reach the publish servers directly (which can give you sometimes some problems diagnosing things). For the assets this is even more different: these are normally delivered by the publish server and then cached in the dispatcher or CDN anymore, but the publish server just provides a link to, e.g., the Azure cloud, where the actual rendition is stored. (This behaviour is, however, not visible from the browser: the redirect is handled within the CDN.)

Deployment process

The deployment process involves creating Docker images for the new servers, and that process includes firing up an AEM instance during the docker build that deploys all the packages that compose the /apps and /libs resource tree. This explains in part why it takes quite some time to build and deploy a new version of your code, and that limits your ability to test changes on the cloud servers.

There is a local version of the server that you can run on your local machine, but there are many differences to the cloud servers, so it's always wise to test your changes there, too. The deployment in the cloud can be triggered changes in a configurable branch of a Git server in the Adobe cloud. So, for the developer to be able to test our changes quickly (even before the code reviewing process, which of course takes some time), we had established the practice of having a special deployment branch that contains the develop branch, where every developer could merge in the changes he needs to test on the development server in the cloud. That branch would be frequently reset to the develop branch and start from scratch.

The best practices analyzer

AEM recommends using their "best practices analyzer" (BPA) on the application to find out many hot spots in the application that need to be changed. That turned out to be very valuable and a good guide to focus the development efforts. It does, however, generate many many issues of widely varying importance. So we exported those as a CSV, imported that into a Google spreadsheet and added a column with a remark and ticket number that would resolve it. Thus it was easy to categorize the issues into TODOs, change many of them at the same time using filters in the spreadsheet, and even work on that in parallel to get it done quickly.

Identify potential blockers early

While evaluating the BPA results gives you a good indication what to do development wise, there will be other changes that can block your progress if not tackled early. I'd like to suggest to think hard what could become a difficult to solve problem later, and check and tackle these things following things as early as you possibly can. These include:

• Connectivity from the servers to external systems
• User management: creating / migrating users
• Content transfer from the old system. (Is there some migration needed?)
• Assets and content delivery via the CDN
• Automated user interface tests

In many cases you can start to tackle these before you've even done any actual work on the application you want to migrate. You can, for instance, just deploy a random sample application on the cloud system and try running your automated user interface tests against that. If they fail because the sample application has different content - you're fine and have peace of mind. If they fail for some other reason, you can have that fixed by your testers while the developers still are busy making the application deployable in the cloud.

Adobe themselves also have many good hints there what to check.

Using the Composum Browser in AEMaaCS

There are various restrictions in comparison to the on premise AEM versions that are imposed by AEMaaCS. One of them is that the CRX DE Lite browser is available only on the author of the development server, but not on publish servers and not on the stage or production environment anymore. This can make it seriously difficult to find out why something doesn't work. There is one way to work around this: you could deploy the Composum Nodes Browser on your author system(s). You could deploy that on the development author, only, but it's also possible to put it on the stage and production environment if you need it there. If that's a risk to you: it's possible to switch it to read only mode, or you can use it in the early development stages only, and remove it at all later on stage / production when there is too much confidential data on the system, or after going live.

Inspecting the publish server's content

Unfortunately it isn't that easy to deploy it on the publish servers, because many paths are blocked there and you don't have (or nomally need) a login there. But since it's often very helpful to be able to inspect the JCR content on the publish server. With the Composum Remote Resource Provider there is at least a workaround that would enable you to inspect the anonymously readable content there.

Regain some tools from the Sling Console

AEMaaCS makes the Sling Console unavailable in the cloud. To some extent that is replaced by the yet rudimentary Developler Console, but that omits many valuable tools to find problems. While it is possible to move it ( temporarily in a pinch!) to another path by setting the configuration manager.root in org.apache.felix.webconsole.internal.servlet.OsgiManager for config.author.dev some other path like /libs/osgi , you can also use the Composum Browser, that gives you back many of the important tools like recent requests, the bundle list and so forth.

Running Groovy-Scripts

At the time of speaking, the groovy console isn't working with AEMaaCS. But: if you install the groovy bundle(s) on the server, you can use the Script Runner support of the Composum Browser to run Groovy scripts.

Other stuff

Just mentioning: I tend to introduce some debugging utilities from https://github.com/ist-dresden/composum-nodes/tree/develop/xtracts/debugutil if I have to solve a more difficult problem.