The presentation covers a microservices architecture used for AEM-based system. If we think of highly-scalable enterprise systems it’s worth considering moving from AEM-based design to microservices architecture. In this approach, some bigger logical parts are deployed separately, outside of AEM – all of these parts are called services. Of course, AEM is still there (it’s another service) and plays one of the most important roles - it delivers the user experience, i.e. websites, pages, their layout and static content. Most of the dynamic content though, is provided by other services deployed e.g. as a stand-alone applications on Tomcat or Node.js servers. The assembly of pages served by AEM and the dynamic content from other services is done with use of… another service. Sounds complicated? Although from deployment point of view it’s more complex than simple AEM-based approach, it brings a couple of significant advantages: * Improved scalability – each service can be scaled separately. If you expect a lot of traffic and the majority of processing is related e.g. to search, then you can add another instance of search service only. You don’t need to replicate the whole system. * Easier deployment – since the services are independent you can upgrade each of them easily whereas other services remain untouched. * Faster development – you are not limited to OSGi technology, so you can develop each service with solutions which best suit the service needs. * Reduced cost and time-to-market – thanks to above, the overall cost of change implementation and time needed to deploy it to production is reduced significantly

1. Microservices Architecture for AEM
Maciej Majchrzak / majchrzak_m

2. System architecture

3. What?

4. What? With what?

5. What? With what? How?

6. What? With what? How?
What next?

7. http://woms.dyndns.org/fashion-designer-clothing.html

8. Scalability

9. Simple AEM system

11. Scalability (1)
Caching layer

12. Scalability (1)
Caching layer

13. Scalability (2)
AEM layer

14. Simple AEM system
Complex system

16. Scalability

17. • Development
• Deployment
• Scalability
• Time to market and cost
Challenges

18. Microservices architecture

19. Architecture

23. {{ /search/adverts }}

28. Architecture Scalability

30. Architecture Scalability
Performance

31. Traditional approach

32. Microservices approach

33. TraditionalMSA

34. Architecture Scalability
Performance Development

35. https://flic.kr/p/4gLRqc
Benefits

36. • Improved scalability – you can scale a part of the system which really needs it. You don’t need additional AEM
licences to scale heavy-processing part of the system, like search, user management, etc.
• Faster development – you can use technology which best suits your needs, you’re no longer limited to AEM/OSGi
stack. You can also separate your teams easily as they may work on separate applications with seperate technology stacks.
• Better performance – the system is performing better and more stable than a pure AEM-based one
• Increased agility – thanks to well seperated services any change introduction is simpler and takes less time
Benefits

37. Benefits Drawbacks

38. • More complicated infrastructure
• More discipline needed during design and services maintenance
Drawbacks

39. Benefits Drawbacks
Success factors

40. • Infrastructure provisioning and deployment automation – tools like Chef and Vagrant are your friends
• Be careful when deciding what should be a separate service
Success factors

41. Benefits Drawbacks
Success factors Take-
aways

42. Q&A
majchrzak_m