If you have an app – any app – you should implement microservices. Still, you have many ways to do it and it’s easy to mess things up. With this microservices checklist, you will be sure to do things properly.
If you are new to microservices, you should start with this microservices tutorial. Instead, in this post, we will assume you are in the midst of implementing a microservices application.
Microservices Checklist
This post aims to be a clear map for people implementing microservices. Thus, as a microservices checklist, it is literally a set of things your application should be. Note that the checklist is not about what’s inside the microservice. Instead, it is about all microservices and how they work together.
One service = One team
If you are working alone this may not apply to you. However, if you have many people working on a complex application, you may divide the people into teams. Ideally, one team should work on a single microservice.
One team should work on a single microservice.
This will help you keep things simple, and ease the deployment cycle because you have just one team with full control over the repository. You don’t need to manage complex merges.
API-based
Whatever you are doing, it should have clear interfaces that you can call from other programs. This will help you scale as you add multiple microservices, each calling the other.
It should have clear interfaces that you can call from other programs.
This can take the form of a RESTful application, a SOAP web service, or even an FTP integration.
Container >> Service
Always prefer to have a microservice in a standalone container. Avoid using services on an existing server, like Microsoft services or Linux background applications. In fact, if you go with services you set yourself up to make something that is not scalable.
Always prefer to have a microservice in a standalone container.
Instead, containers are the best way to go. Even if they may sound counterintuitive at first, they allow the best segregation possible. Only with that, you can ensure each microservice is independent.
However, it is also worth noting you have different options, like AWS Lambda functions. Those serverless alternatives are equally viable but more limited in their functionalities.
Persistence for data only
If you go with containers, you will have to bear with the fact that they are transient. Like everything in life, they eventually disappear. This is completely okay, in fact, it is even something we want.
Of course, this comes with a challenge: where the hell should we store data? Fortunately, you can make a container persistent. so that it keeps its data even after a reboot. But do that only with a container that holds data.
If you have a distributed database across containers, then those containers should be persistent. In no other case.
In this case, you can consider cloudless alternatives like a managed MongoDB database (both AWS and Azure offers that).
Hide the middleware
Security is always key, thus be sure to expose to the Internet only the services you want the user to access directly. Instead, hide all other middleware services so that you can’t access them from the Internet.
Most commonly, in Kubernetes terms, you prepare a LoadBalancer for the services you want to expose, and just a ClusterIP exposition for the services you don’t want to expose.
Centralize app logs
All applications have logs. Yet, in a legacy application writing to a file was perfectly fine. However, since containers are transient, any file on the container will disappear. Not to mention the hassle of finding information in many files across multiple containers.
Instead, push logs to a centralized place, like an S3 bucket, or AWS CloudWatch. While you are at it, be sure to include the name of the container that generated the log.
Extra tip: if you plan to store logs in a relational database (e.g. SQL), you are going in the wrong direction.
A container is not a function
This is another important part of this microservices checklist. Remember that a container is not a function and that a microservice is not a function either. So, don’t make microservices with too little code in each. The overhead of using too many containers will kill your application performance.
Use hashed tokens for performance
Most likely, when processing data, your application will engage multiple containers. This is okay, but you should try to reduce the number of containers you engage to the least possible. Only in this way you can keep a great performance with a significant amount of microservices.
So, be sure that a microservice can process the data without calling another microservice all the time.
A good way to do that is wit hashed tokens, most commonly for authentication. You can have just one authentication container than creates a hash to send to the user. Then, whenever any other container receives that hash, it knows it is from the authentication container by verifying the hashing, not by making a call. The saving of time you do by doing this is significant.
The short microservices checklist
Of course, no checklist can cover all the topics about microservices. Ideally, you should understand what you are doing if you are doing something big. However, if you are more in a startup-state-of-mind and you just want to hit the ground running, this template will help you a lot.
In case you are looking for a TL;DR, here you have the microservices checklist.
- A microservice should be managed by a single team of developers.
- Make sure your microservice is an API.
- Prefer containers to implement microservices.
- Use the persistence of containers only where you store data.
- Expose only what needs to be exposed.
- Centralize your application logs.
- Do not make your containers too small, and don’t make too many microservices.
- Reduce calls between containers. A great way to do that is often hashed digests.
In case you have additions to this checklist, just let me know in the comments!
