Microservices – Not a free lunch!
Author: Benjamin Wootton
Microservices are a style of software architecture that involves delivering systems as a set of very small, granular, independent collaborating services.
Though they aren’t a particularly new idea, Microservices seem to have exploded in popularity 2014, with articles, conference tracks, and Twitter streams waxing lyrical about the benefits of building software systems in this style.
This popularity is partly off the back of trends such as Cloud, DevOps and Continuous Delivery coming together as enablers for this kind of approach, and partly off the back of great work at companies such as Netflix who have very visibly applied the pattern to great effect.
Let me say up front that I am a fan of the approach. Microservices architectures have lots of very real and significant benefits:
- The services themselves are very simple, focussing on doing one thing well;
- Each service can be built using the best and most appropriate tool for the job;
- Systems built in this way are inherently loosely coupled;
- Multiple developers and teams can deliver relatively independently of each other under this model;
- They are a great enabler for continuous delivery, allowing frequent releases whilst keeping the rest of the system available and stable.
This said, Microservices are not a free lunch!
I am currently involved in architecting a system based around Microservices, and whilst the individual services are very simple, a lot of complexity exists at a higher level level in terms of managing these services and orchestrating business processes throughout them.
Microservices one of these ideas that are nice in practice, but all manner of complexity comes out when it meets reality. For this reason, I wanted to write this article to capture some of these and redress the balance.