The Current Ecosystem of Microservices
A few days ago I stumbled upon this article by TechCrunch and among other things it depicts the current ecosystem of microservices in a concise and elegant way. I highly recommend reading the whole article, but I especially liked this cited observation by Martin Fowler and Ryan Murray about the “microservice premium”:
Not every application is complicated enough to warrant being broken into microservices. […] in many use cases the complexity of microservices hampers the productivity of your team. There comes a point when your application becomes very complex or your team begins to grow past 50–75 engineers that the benefits of this architecture begin to take off.
Here are some other interesting observations and recommendations from the article:
- Start every new product as a monolith.
- Don’t throw away the monolith. This can have disastrous results. Take one piece at a time and break it off.
One question that still does not have a definitive answer is “What is a microservice?”. I think the definition given in the article is sensible albeit a bit too generic:
Microservices is an approach to building software that shifts away from large monolithic applications toward small, loosely coupled and composable autonomous pieces. The benefit of this abstraction is specialization, which drives down costs to develop and drives up agility and quality — while operating much more resilient systems.
The Open Group’s definition for service-orientation and SOA is very similar in my humble opinion:
A service:
* Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
* Is self-contained
* May be composed of other services
* Is a “black box” to consumers of the service
I think in a microservices-based architecture, there’s a higher emphasis on resiliency compared to SOA (disclaimer: I only have basic general knowledge about SOA. I haven’t worked on SOA projects in the past).
I think now it’s the time to read a bit more about this statement by Conway as this is the first time I have stumbled upon it:
Teams should have bounded context and systems should follow the ordinary flow of business. Melvin Conway first came up with this principle in 1967, and it holds true today. When your services are not directly mapped, it makes troubleshooting or re-architecting in the future far more difficult.


Happy coding!

