Microservices

We continue to belief in the microservices concept and its related patterns and best practices. However, it's worth mentioning that we had to learn some lessons when it came to resilient thinking and deployment-related dependencies between microservices.

We feel that our microservice-based applications are more robust than monolithic ones have been. Thanks to the split of the overall complexity into multiple services, new employees or team members are becoming productive within days or a few weeks.

In order to get microservices right and to benefit from the advantages, there is a lot more required. The following "pyramid of need" for microservices shows this:

Microservices as an architecture style is getting very popular recently. At AOE, more and more teams are adding microservices to their existing application architecture or designing applications with microservices.

We also like the term "self-contained systems" instead of microservices.

The benefits we see are:

• better handling of complexity compared to adding features in a monolithic approach
• being able to use the languages and framework that best fit the purpose of the service
• enabling better parallel work in big teams or multi-team projects
• flexibility in deploying changes to production - by just deploying the changed service

Related patterns are Strategic Domain Driven Design as an approach to wisely cut your architecture according to useful bounded contexts and decide on the relevant communication and "translation" between the services. In case you are looking for a small visualisation tool for your microservice architecture you might find vistecture useful.

Also Resilience thinking is especially important when designing an application as a suite of microservices.