Microservice Mini Guide
Important points you should know before move to microservice
Preamble
So many developer around the world talking about microservice, and wants to migrate their monolithic application to microservice style architecture, without think further about the drawbacks of microservice its self, every trends has its owns problem, so you need to think critically, what kind of problems you faced after implement microservice, in this story I would like to share the painless way of microservice implementation based on my experience.
Microservice
The main idea of microservice is separate application processes to small chunks of processes, so maybe there will be the bottleneck between them while communicate each other, maybe the source of bottleneck happen in database, one of service down, message broker, pub/sub, and data inconsistent.
Stateless
Your microservice must be stateless, no important data stored inside microservice, all important data must be stored in database not in the microservice, microservice just knows how to manipulate data and store it to database, why it must be stateless? because when your microservice has several replication for load balancing purpose, there would be a data inconsistent.
Distributed Tracing
Bottleneck becomes hard to find, without distributed tracing, and you need to research about how to use distributed tracing, for handle this problem, and you need to serve the information about your service to distributed tracer by adding event in every repository function and service function, to trace out the bottleneck, you can use whatever you want, the only that I know is OpenTelemetry and Jaeger, and just don’t do it your self to make your own Distributed Tracing.
Logger
Logger helps you to see the event and the result of code execution, and help you to trace error that happened in some process, log result will be stored inside a file and loaded using program that specially designed for log reading, like google stackdriver, log should have information such as service name, function name, request id, type (info, warning, error), data/result, timestamp, execution time (how long the function executed), you should add the log at the beginning and the end inside a function.
Request Id
Every Request to your API, need to be marked with request id and passed to other function that belongs to the request, to trace the logs belongs to the request if there is an error occurred in a request, so you can easily find the error by request id.
Circuit Breaker
What if one of service we have goes down? cannot be access temporary, circuit breaker helps detect latency problem in microservice, and response immediately that the service is not ready, to the caller service, its cover common cases like slow query, database server down, server down, without showing to customer the latency problem that we faced right now, and straight forward tell the customer we will be ready in a moment, we can use circuit breaker response if there is special case for handling when the server has latency problem.
Security
Every API need security, depends on my experience you need to develop one microservice that designed for handling authentication, and your authentication microservice can be used as middleware for checking every request to endpoint, you can also create ACL (Access Control List) inside authentication microservice to limit a role from accessing administrative data, JWT (JSON Web Token) is the most popular for securing your endpoint, if you are too lazy for developing authentication service, learn Kong API Gateway.
Read more about Kong at https://konghq.com/kong/
Communication Style
REST API with JSON still the popular for communication with front-end or between services, it’s not bad at all, but there is new technology called gRPC that founded in 2015 developed by google, its specially designed for communication between service using HTTP/2 for transport, and use Protocol Buffer as interface description language, and use Bytes as the format, it more light if compared to JSON, but if you want to use REST API it still valid.
Domain Driven Design
I think Domain driven design is a good guide for separating your monolith application services into microservice, it guides you to create microservice depends on its expertise, lets say you have application with these capabilities, send email, sms, notification, and FCM, and then you only need define one microservice named sender for those expertise, and I think its bad idea when you define multiple microservice with same capabilities, because your microservice will getting bigger and complex, just wrap it up together in one microservice if a application has same expertise.
Database
There is several ways to manage data between services that I read in microservices.io, the simplest way to implement is Database per service and Shared database, both of them have pros and cons.
Database per Service
The main idea of Database per service is, where you create single database for each service, and its private cannot be accessed by other service, and you should create API for it to be able accessed by other service.
Cons of Database per Service
- Custom query cannot be performed because its only accessible by its API.
- Complexity of managing multiple SQL or NoSQL database.
- It will be take time for developing new API, when other service need specific data from its database.
Pros of Database per Service
- There is no breaking changes to other service, when you update the database schema or structure
- Database agnostics (every service freely choose their desired database without thinking about other service, because its only accessed by its API).
Shared database
The main idea of Shared database, where you only need define one database for all service, and its freely access data owned by other services.
Cons of Shared database
- Development coupling, you need coordinate with other team when there is changes in a table, or column.
- Runtime coupling, deadlock condition when service A doing database transaction, and service B will be blocked because transaction of service A is still on progress.
- Single database might not satisfy the data storage and access requirements of all services.
Pros of Shared database
- Developer can use ACID transactions to make sure data consistency.
- Easy to operate by other service when they need data from other service.
Conclusion for Database segment
Fair enough both of them, have 3 cons and 2 pros, so I came up with idea to create database for each service, and other service freely access data owned by other service without define new API for other service needs, but each service should define an independent interface contract for access data owned by other service, every time a service need to consume other data it need to define new interface contract, to minimalize breaking changes that affects its functions when there is a change in one of database, but still need strong communication between teams, I named this Shared Database per Service.
And obviously it has pros and cons too.
Cons of Shared Database per Service
- Complexity of managing multiple SQL or NoSQL database.
- Development coupling, you need coordinate with other team when there is changes in a table, or column.
- Runtime coupling, deadlock condition when service A doing database transaction, and service B will be blocked because transaction of service A is still on progress.
Pros of Shared Database per Service
- Services has free access to each service database, by define external interface contract.
- Support custom query for specific need, no need to ask developer to create API for accessing data from other database service.
- Developer can use ACID transactions to make sure data consistency.
- Database agnostics (it force developer to mastering all database).
So I decide to use Shared Database per Service.
Deployment
Microservice can be deployed in many ways, I read on microservices.io, there several ways yo deploy your microservice, the cheapest & expensive, when you just begin business, try to use Multiple Service Instance per VM because you just need one VM, it will be different when your company have many customer and your server is getting busy and slow down, you need to move to Service Instance per VM, like Netflix does, or you can discus with infra team, to know which one is better and fit to company, and for example let say I just start my business need to press expense, so I will go with Multiple Service Instance per VM, and I don’t really talk about deployment to much, I will give you the reference.
- Multiple service instances per host
- Service instance per host
- Service instance per VM
- Service instance per Container
- Serverless deployment
- Service deployment platform
My Thanks
Thank you for coming up to my medium, feel free to comment and correct me if I am wrong.
Source
Cheers :D
