This article aims to describe what defines a microservice and what micro in microservice means.
Microservices as a concept has been around for a many years and there are numerous articles, books and videos on the subject.
Despite all the content produced on the topic there are no standardised guidelines for creating microservices.
In this article I will not try to introduce any new standard for creating microservices but instead contribute to the vast collection of already existing articles on the topic.
What is a Microservice
A microservice is a small independent application, often designed to solve one particular business problem. Combining multiple microservices gives you a microservice architecture (MSA).
Now there are two questions that come to mind from this definition, what do I mean with small and independent?
How small is a Microservice?
So, how small should a microservice be? To answer this we must first know how to measure the size of a microservice. Is it the number of classes? or the number of lines of code? or the number of API endpoints?
None of the above would make for a good definition of the size of a microservice. However a service with thousands of classes, millions of lines and hundreds of API endpoints can't be small? ...right?
The problem is that micro isn't referring to size but responsibility. A microservice should be small enough that it only has one responsibility, one reason to change. The experienced reader might recognise this as the SRP SOLID principle. One reason to change is a bit vague, but what it means is that if someone request a change in the behaviour of our system, the change should not cascade and affect other system behaviours. Please read more about SRP here.
A similar idea of single responsibility is found in the Unix philosophy: Do one thing and do it well.
Borrowing from these two concepts gives us a definition of a microservice that should only do one thing and it should have only one reason to change. It limits the responsibility of a microservice but says nothing about its actual size.
As an example, a microservice handling users should not handle blog posts, and a microservice handling blog posts should not handle users. However, the concept of a user may be necessary for a blog-post-microservice, but it should not be responsible for creating, updating or deleting users.
The Independent Microservice
What to I mean with microservice being an independent application?
A microservice should be independently developed, tested and deployed. Developers should be able to produce a fully working microservice without being dependent on the work of other developers.
However, independent does not mean isolation. The microservice might not work properly in isolation and thus have dependencies to other microservices. However this should not stop the development cycle from being executed independently.
This is beneficial since it (hopefully) increases productivity by allowing different teams to develop, test and deploy microservices for different parts of the system. It will also gives you the opportunity to update or replace a microservice without effecting the overall system.
In conclusion I can say that the power of microservices is that there are no standardised guidelines. Instead microservices can be customised for each specific use case. And that is where the power of microservices really comes to show!