The idea of programmers aiming at designing applications that are modular in concept has been around the corner since the inception of application development. The concept of modularization has however evolved over decades only to deliver superior inventions.
When we talk about Adobe Experience Manager (AEM), it is also equipped to serve modular applications (meaning that it is capable of supporting a microservices architecture), thanks to OSGI (Open Source Gateway Initiative). OSGi “provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed. This allows easy management of bundles as they can be stopped, installed, started individually. The interdependencies are handled automatically.” (Read more) All these work well, in fact very well.
AEM based applications are often complex, consisting multiple complex bundles that individually connect to cumbersome APIs and what not. Such architectures seem quite natural and obvious in AEM-based systems — everything is deployed on a single instance and as and when you want to scale horizontally, you add another instance. Simple and it works, at least in theory.
In practice, some parts of an application are used far more extensively than others and hold far more resources. Adding an entire AEM instance to scale a particular module doesn’t make sense when the TCO for one instance is already high. In totality, traditional AEM applications end up being a monolith.
Comes microservices to the rescue. You scale a module stored on a different server. Where is AEM Server? Well, it’s still there, acting as another service.
Argil DX has developed F-AI-shion Police with the above approach.
The Object Detection Service in this tool reside on a server of their own. You scale according to your needs making cost-effective decisions. These architectural decisions are of great business value.
What are your opinions on microservices for AEM? Do let us know.