Nowadays microservice is very popular among companies with the increasing complexity of systems. The goal is to make each microservice to handle one specific job and handle it well. This normally would provide the benefit of maintaining the service easily and isolating errors and making the service more reliable and scalable.
The benefits of adopting microservice are obvious.
- Maintainability. Decouple functions so that each function can be maintained separately which reduces the risk of issue caused by bug in other code which is not related to this function at all. It can be easily maintained by the application team with dedicated scope.
- Easy to deploy. If a project is very large and there are lots of developers contributing code to the same service, it would be problematic to deploy and rollback the service as the chance of having bug is higher and sometimes some developer's change must get in but they have to rollback due to some bug in other developer's code. microservice model would reduce such trouble in some extent.
- Flexibility in tech stack choice. Since each microservice is an independent function and is hosted separately. The tech stack can be different for each service. This means each service team can choose the one which is most suitable for the service and the team is comfortable with. It can be GoLang, Java or Python etc.
- Easy to scale. If the service traffic spikes suddenly, the service instance can be launched quickly as it would not be that heavy and not too many processes need to be started.
- Easy to migrate. In case some function can be replaced with other service, it means only the upstream or downstream system need to connect to the new service and have the old service removed after the migration is done.
However, every thing has two sides, with these benefits, microservice also brings issues to companies if not handled properly in real projects.
Below are some of the problems it would cause if microservice is not adopted properly.
- Maintainability. With every new microservice introduced, there is a new set of infrastructure(server instance, network connection, security group etc) needing to be set up and maintained. These configurations need to be maintained well especially in a cloud environment. This increases challenges to SREs.
- Scalability. When there is any upgrade or patch to be done, there would be extra work for the SRE to work on all the instances of each service. When it becomes large, this would be overkilling.
- Availability. Each service is communicating through either HTTP or RPC, hence it has high requirement on network connection and it would cause trouble if the network connection is not stable and hence latency would increase
- Dependency. If designed improperly, it would cause dependency issue where one service must be deployed after another service deployment because there would be something new added and shared between two services.
- Consistency. In a distributed environment, each service handles its own responsibility. There would be a coordinator needed if some function needs to be completed as a whole. In such case, the difficulty of maintaining state consistency would increase and if one service fails to fulfill some request, all other services need to be notified and rollback accordingly.
- Tech complexity. As mentioned in the benefits part, each service can have its own tech stack. The drawback for this is that it is not good for people to move between services. Some people may not know about the language being used by other service and when he moves to other team or takes over other service, it would increase the learning curve and slow down the transition.
Be cautious about whether you want to have a new microservice whenever a new function is to be introduced. Some general advice are documented below.
- Try to have standard template about creating new microservice. This should include why a new service is needed, tech stack being used, how the service interacts with other service and so on. And it needs to be reviewed by a group of people from different team to determine whether the new service should be created
- A tool or flow needs to be provided so that a new service can be set up easily without service team manually set up everything(server instance, database, cache, api-gateway etc).
- Common tech stack used across microservices so that it's easy to manage and move around within the company.
