What are microservices made of?
In one of my favorite texts on the subject, Should That Be a Microservice? Keep These Six Factors in Mind, the author cites one of the factors for using this architecture:
The Freedom to Choose the Right Tech for the Job
This freedom to choose the best technology to solve each problem attracts technology teams a lot. But as Uncle Ben would say, with great power comes great responsibility. If each team chooses a technology and makes a decision thinking only about its local problem, it is likely to generate several headaches in the future. Services with different requirements, levels of quality, and maturity can create difficulties in maintenance, evolution, and availability.
To mitigate these and other problems, we turn to some literature that can be considered classics about microservices architecture.
Templates and Chassis
The first important source was the book Microservices Patterns: With Examples in Java by Chris Richardson, who also maintains https://microservices.io/. He defines several essential patterns a team can use in the book, but I will highlight the Service Template and the Microservice Chassis.
When we start developing an application, we often spend a significant amount of time implementing the mechanisms to deal with cross-cutting issues such as:
- External configuration — includes credentials and network addresses of external services, such as databases and message brokers;
- Logs — configuration of a centralized log recording structure;
- Health checks — a URL that some monitoring service can “ping” to determine the health of the application;
- Metrics — measures that provide insights into what the application is doing and how it is performing;
- Distributed tracing — instrumentation services that assign each external request a unique identifier passed between services.
It is not uncommon to spend several hours configuring these mechanisms. If you’re going to spend months or years developing a monolithic application, the initial investment to deal with cross-cutting issues is negligible. The situation is very different, however, if you are developing an application that follows microservice architecture. There may be dozens or hundreds of services, and you will often create new ones, each of which will only take days or weeks to develop. You don’t have the luxury of spending a few days setting up mechanisms to deal with cross-cutting issues.
To solve this problem, we can use the Service Template, creating a project template that teams can easily replicate. There are several ways to make these templates, from something simple like a project that can be copied and pasted by teams, a model repository on Github, or something more complex. Here at PicPay, we use Backstage’s template functionality, the basis for building our IDP.
However, using just the Service Template ends up causing another problem: code duplication between projects.
When duplicating the template, the process will replicate code between projects, which makes maintenance difficult.
To solve the duplication problem, we use the Service Template pattern in conjunction with the Microservice Chassis. According to the author:
“Create services in a framework or collection of frameworks that address cross-cutting issues such as exception tracking, logging, health checks, externalized configuration, and distributed tracing.”
Now, the template depends on a series of libraries and frameworks that form the microservices chassis. With this, we remove duplication, as the templates now use the libs that are part of the Chassis. This way, we update all projects created from the template when updating a library.
But in addition to code, the Chassis defines the components that a microservice must have. To do this, we created an RFC, an internal standardization document that describes all the mandatory and recommended requirements of a microservice. This document contains topics such as Authentication, Authorization, Circuit Break, Rate Limit, Graceful Shutdown, etc. I won’t go through all the items here as it would make the text too long, and which items are essential depends on the company’s context.
With this documentation, libraries, and templates that implement the Chassis, we have a healthy and scalable way to standardize and disseminate good practices in building microservices.
Ready for production
The second source we’re using is the excellent book Production-Ready Microservices: Building Standardized Systems in a Software Engineering Organization by Susan J. Fowler.
The author goes through several essential topics that a team must consider so that a microservice can be put into production and be ready to receive traffic. Among the items I can mention:
- Stability and reliability;
- Scalability and performance;
- Fault tolerance and disaster recovery;
- Monitoring;
- Documentation.
For each of these significant topics, she details important concepts and recommendations on how teams should pay due attention to them.
At the end of the book, you can find a checklist with questions for each topic above in the appendices. We use this checklist for teams to discuss and review each item and prepare their services to meet these critical requirements.
Other important literature, such as Sam Newman’s Building Microservices, is strongly recommended.
In conclusion, the most critical message here is that there are sources that can help us make microservices architecture a healthy environment instead of a chaotic one, which is the natural tendency if it is not something well thought out.
