The old way
I am old enough to remember the Hardware Sizing Guidelines – guidelines to help you estimate the size of your infrastructure. At the beginning of each project, after collecting the requirements, we used Adobe formulas to design infrastructure. The formula may suggest something definitive, infallible, but in practice, the calculations required the adoption of certain factors, such as applicationComplexity or cacheRatio. More or less, it was always a form of guesswork.
Finally, at the end of the day, the suggestion was usually made that we just need to launch it and see how the system behaves.
Moreover, every marketer knows there are traffic peaks (how many Black Fridays have we spent in the office monitoring traffic and preventing incidents?), so we either plan with a reserve or we are able to scale AEM on the fly.
On-prem hosting (less and less popular due to Adobe’s Managed Service policy) requires a dedicated team, monitoring and maintenance and is generating significant costs (note the fact that support should work 24/7!).
In return, we get full flexibility and control over our resources, the ability to introduce any processes (or the ability not to introduce them) and, consequently, practically complete independence.
Infrastructure aside, let’s summon the subject of AEM’s upgrade: usually a difficult process, often turning into a project lasting several months. It effectively supports product fragmentation and, on average, reduces the quality of the project. (more in my last article: AEM Upgrade to 6.5)
Cloud
Okay, the title of the article reveals cards – what does the AEM as a Cloud Service approach contribute to the above problems? What new problems does it generate?
Let’s start with the infrastructure, cutting the long story short: we don’t care about it. I could probably end the article on this, but maybe it would be better to go into details:
- The infrastructure is scaled based on the actual traffic and actual activity and it has an Author cluster as default; this avoids downtime for maintenance tasks.
- What does such a change translate to? No more a priori planning – infrastructure will scale depending on current traffic. Also on Black Friday.
- Adobe by default provides a CDN service in its stack, which was not always present, even in medium-complex multi-country solutions.
- The version updates policy is also addressed in the Cloud Service model: instances can be updated several times a day (bug fixes, security updates) in the no-downtime model. In addition to incremental updates, there are “big” changes updates containing new features, with the difference that they are planned ahead and the timing of the update is predictable.
Sounds like a panacea for all ills? In many cases, yes, but it is worth remembering that to some extent we lose full control over the infrastructure by handing it over to Managed Services. Sometimes it’s good, sometimes it can build resistance in larger organizations.
How does it work under the hood?
Thanks for separating mutable and immutable content and the introduction of CompositeNodeStore, it was possible to separate the code from the content. The tight connection of these two elements was a major blocker in AEM’s containerization. After introducing, step by step, changes to the repository structure and changes to the NodeStore, Adobe took care of containerization with the support of the orchestration tool – Kubernetes.
The introduction of Cloud Manager as a deployment standard completed the fact.
By combining everything together, we got a cloud solution that is scalable and always up-to-date.
Cloud Manager
Cloud Manager deserves a separate article, but for the sake of this one, I will try to summarize it in a few sentences.
Cloud Manager is a set of solutions that compose a comprehensive tool for managing AEM in Cloud. It contains some elements that are required in the CI / CD approaches, but in my opinion, it cannot always be called a full solution. In more complicated setups, it is worth considering it as part of our pipeline (thanks to the shared API, it can be used that way).
One of the integral elements of the Cloud Manager is Quality Gates, which impose the fulfilment of specific requirements in terms of code, good practices, tests, performance and broadly understood quality. For more demanding customers, they may not always be sufficient. In more standard designs, they will be more than useful. On average, I consider them a great step that increases quality: maintaining the right standards in many companies was unfortunately just a dream. Now there is no way out – otherwise, the application will not go to Staging and Production. And that’s very good.
Changes, changes, changes
Some of the changes introduced by AEM Cloud Service:
“Heavy-load tasks, such as queues, jobs and bulk-processing tasks have been moved out of the core AEM instance to be handled by shared and dedicated micro-services“ – finally Authors can upload a large amount of content to the DAM and keep the instances available for the others.
OSGi bundles & packages not available to users (or being more specific are available but in a read-only mode).
Access to logs is now available via Cloud Manager only.
Local development is still possible without a need to spin up a new environment at Adobe’s Cloud (a new jar is there).
For old dinosaurs like myself: no classic UI anymore. That’s probably a good step, but I kind of miss it, after so many years 🙂
No support for Adaptive Forms, AEM screens, Commerce add-on, Communities add-on and Developer Mode.
When it comes to the development and deployment itself, if you have used Cloud Manager before, you will not feel many differences.
Summary
AEM as a Cloud Service is a necessary step in the right direction. As is always the case with relatively new solutions, not all features have been transferred, some gaps appear (Adobe fills them in step by step – let’s look at the development of Cloud Manager).
It also seems that Adobe has decided to settle accounts with the past, by, among others: disabling access to Classic UI. Despite some sentiments, that was an important step towards the future.
Of course, we put a large part under the control of Adobe, which has pros and cons, while on the average: we get autoscaling, no-downtime deployments and maintenance tasks, less space for errors and building boilerplate solutions. That’s good, we can focus on development.
