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.