There is no actual official definition of what a microservice is and is not; however, the following rules generally apply to commonly used microservices:
- A small unit of a backend infrastructure
- Operating as independently as possible (meaning, no or little communication with other microservices)
- Performing a service (such as processing data or offering an API)
- Offering as little functionality as reasonable
- Operates with its own database
The last point is critical as you might be tempted to leave all data in the same database or the same database server. Leaving all data on the same database server might be an okay choice for small projects in the beginning, but you should never use the same database across multiple microservices.
The same applies to common code or libraries; it should always be separate. You might develop a central library that is shared; however, that might become a problem later on. Zalando, for example, implemented a strict policy prohibiting this (https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando).
The same applies to common code or libraries; it should always be separate. You might develop a central library that is shared; however, that might become a problem later on. Zalando, for example, implemented a strict policy prohibiting this (https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando).
To conclude, a microservice is the smallest and most isolated unit possible of the business logic and is needed for the server application. Now, let's look at the cases when microservices are a great choice!