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 of 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 of multiple complex bundles that individually connect to cumbersome APIs and whatnot. 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 the AEM Server? Well, it’s still there, acting as another service.
Argil DX has developed F-AI-shion Police with the above approach.
F-AI-shion Police
Fig: High-level architecture of F-AI-shion Police
Here, we’re invoking “Object Detection Service” from UI (JavaScript) of our page component.
The Object Detection Service in this tool resides on a server of their own. You scale according to your needs making cost-effective decisions. These architectural decisions are of great business value.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.