One Year Working with Microservices
I’ve began working with microsevices, one year ago. And I want to sum up here all advice I wish I had beginning.
- What is a microservice
- Book to read
- Too big microservice
- Anemic microservice
- Code using good practices
- Where is my business Logic ?
What is a Microservice
James Lewis and Martin Fowler describe microservices as :
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
It’s a really good definition that embrace all the scope of microservices architecture. But to embrace less, and be more specific, I consider that :
A microservice is a Product (and not a project) focused on doing only one thing. Is the Single Responsability Principle applied to a product.
Book to read
I highly encourage you to read the book wrote by Sam Newman (Building Microservices: Designing Fine-Grained Systems), it’s the most useful source I’ve found.
Too Big Microservice
When a microservice is too big, it means that he don’t respect the Single Responsability Principle and maybe we should split our microservices.
What is a too big microservice :
- Not single responsability
- take more than 2 weeks to rewrite
For example : in a first step we can create a microservice to manage users and its addresses. After some month we see that it’s a big microservices. it’s because maybe we need to split user and address principles.
It’s very important to avoid anemic microservices. A microservice should manage all the logic of the domain belonging to him. And be more business-centric that just a CRUD in REST (data-centric).
Don’t repeat yourself, it’s a principle, that is very important in developement. But between microservices sometimes it’s allowed to duplicate some code. Because if 2 microservices share a same code, we create a tight coupling, that can be hard to handle.
As Sam Newman wrote :
My general rule of thumb: don’t violate DRY within a microservice, but be relaxed about violating DRY accross all services.
So sometimes it seems a good idea to have a “package” with duplicated code between microservices, but creating a tigh coupling with this “package” can cause some nightmare, when you change something and have to update all services consuming your “package”
Code using good practices
It could be logic for you to code well, but I’ve heard newbies saying “It’s a microservice, so I could code it like pig, if we have an issue, it’s just recode all”
So the answer is NO, even if it’s a microservice, it should be SOLID, and all others principle you learn to be a good developper.
Anyway it’s not completely false, so if you have beginners (leaving college) they will be more productive faster (don’t forget to review their code to introduce good practices)
Where is my Business Logic
The business logic will not be anymore in one monolithic bloc. We should avoid to have a big orchestrator, or a “god” service managing anemic micro CRUD services.
The logic will be splitted between lot of places.
Let’s identify where by looking one example.
On the Registration of a new user (i m sorry, i m not very good to drawings):
First this is just an example, do not reproduce it as it is, in yours project, think about it first.
So we defined 3 places where the logic is :
- 1- WebApp
- 2- Microservice
- 3- The asynchronous flow
The web app needs to check and put some information together, to compose the page, validate the params, auto-complete some fields or combobox. So it’s the first place where the logic of the Registration is.
We don’t have a website, we have a Web App, it means that our pages are intelligent.
On the User microservice We should have all logic related to the customers.
We should avoid to have anemic microservices, that only do CRUD (it can happen but it’s to avoid) All the business logic related to its domain/Responsability, must belong to the microservice.
3- The asynchronous flow
By the events flow, we have an other business workflow. All asynchronous flow should stay asynchronous.