There are many questions about my inbox about how to deploy a microservice after I share a slide, because this slide I made for presentations is the main one, so it is a bit difficult to understand. I answered a lot, but this is the way I usually advise (for units with large monolithic systems):
1. Separating services : Splitting the application code layer into modules / services is not dependent on what you want, you have to go through the interface (be it http request, streaming, socket, rpc, … usually RPC). Done step 1, the services are independent and still use the common DB.
2. Basic DB layer handling : Remove gradually the store procedures and join commands if any, only retain the ones in the same domain (eg, join from order to user is removed). Remove whichever application code burden that logic. To be safe, you can do the application code first, feel good then switch over, see wrong then correct or rollback version to redo. Because communicate through the interface so long as the return is correct and enough is okay.
3. Split large DB: Large DB used previously into clusters by domain. You can use the way to create db users with domain-restricted rights to test before separating completely. Done this step the official service independent of each other.
4. Microservice (broken down again or not ???): is due to the team’s choice and the system situation. And the procedure is exactly the same as steps 1–3
– – – – – – – – – – Frequently asked Questions – – – – – — – – – – –
1. What about separating the service but not the db?
- It’s okay, but the effect is negligible, at first, only benefit from deployment and minimize the dependence on code layer.
2. Has the DB split finished, but the system is still slow?
- Microservice essentially does not help the system faster, but helps the system be broken down into many parts to ease treatment. For example, a table that is too big makes the service slow is another problem: scaling / sharding db.
3. In the past, a fast-moving lump now became slower than before !!
- That’s right, this time response time appears between the services that were not available in the past. The solution is: reduce encode / decode time and open and close connections between services (using gRPC).
4. Service A call service B, you must know the IP of B, then miss B scale on many nodes?
- That’s why the concept of service proxy and service mesh or service discovery. It helps coordinate requests into nodes as well as IP resolution like DNS. From there A does not call B but calls through a discovery / master node with information of B.
5. The logging, monitoring, tracing in the past used to be a general department, or did it have to do each service separately?
- YES. That’s why logging, monitoring, and tracing in microservices has been upgraded to a new level, with many common concepts: agent, collector, pipeline, streaming, master dashboard, etc. magazine ”Now everyone understands why there is a position of devops already. Deploy correctly and ensure the system runs stably, finding the cause of the problem is in these main skills.
Author: Viet Tran – Founder 200lab
Here is a shared slide from the author.