Microservices, like many other terms in systems development, doesn't have an exact definition, but I found a good working description at an article by Martin Fowler and James Lewis:
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.Looking at the description, there is nothing that doesn't reasonable, and reading the article linked above, it becomes clear that Microservice Architecture is a valid way of building systems, and one that should be taken into consideration when designing a system.
Unfortunately, it seems like people don't really consider it, but rather just choose it by default.
A decade ago Service Oriented Architecture was all the rage, and all systems had to be based on SOA. Unfortunately a lot of people didn't understand SOA and thought it was all about having a servicebus as the central component through which all communication went through. This was so widespread that I and many others started to say that SOA stood for Servicebus Oriented Architecture.
It seems like Microservice Architecture is moving down a similar path.
Many systems supposedly based on Microservice Architecture are not really based upon it, but rather on a misunderstanding of what Microservices are all about, creating systems which mimics the properties of Microservice Architecture, but don't implement the actual characteristics of Microservices.
Some symptoms of this misunderstanding of Microservices, could be:
- Code dependencies between services. If code changes to one services means that you also have to change the code of other services, then the architecture doesn't fulfill the concept of independently deployable services.
- Functionality dependencies between services. If the system always have to call service A before service B, and only call service A when service B needs to be called, then it seems like the lines of the system hasn't been drawn the right place.
- The need for a service portal (or even a servicebus).
There could be good reasons for each of these symptoms (though I am hard pressed to think of one for the first one), but they are definitely something that should make you consider whether you have really created a Microservice Architecture, or if you have just peppered your system with services.
ReplyDeleteI think the much worse (and much more common) symptom of "misapplied microservice-ification" is
* Doing stuff "because microservices!!" instead of evaluating costs and benefits of alternative approaches.
Maybe the problem domain you work with doesn't lend itself to microservice architecture. Maybe the project scale or structure isn't aligned with a microservice approach. If you haven't analyzed these things you simply haven't done your work!
perhaps in 5 years nanoservices will be all the rage.
ReplyDeleteGood writeup mate... Yeah, and maybe "MicroService Architecture" is also equal to the new "agile"..
ReplyDeleteMany jump into it without adequate training, understanding and more importantly, without serious assessment of the context in which they are.
Furthermore, many are ready to switch "architecture" but not "technology". Mature technologies are built with the basis that you have control over clients, which is not intended for microservices architecture.
In my head, the concept of "service" has two very different meanings respectively SOA and MicroServices Architecture.