Microservice Mastery: 3 Crucial Factors to Consider Before You Start Building
Are you building microservices? There are several factors you have to weigh in. But no fear. We are going to cover some of the must-consider ones here!
Service Boundaries
When defining microservices, it’s crucial to define clear boundaries that separate services. Each microservice should have a specific responsibility and not be too tightly coupled with other services. This ensures that each microservice can be managed independently and scaled as needed.
A microservice that is too broad in scope can become challenging to manage and scale. Here are some tips for defining clear service boundaries:
- Identify the specific responsibilities of each microservice: Each microservice should have a specific responsibility or task that it performs. For example, a microservice that handles user authentication should not be responsible for processing payments or managing user profiles.
- Ensure that each microservice is not too tightly coupled with other services: Each microservice should have clear boundaries that separate it from other services. Avoid creating dependencies between microservices that make it difficult to modify or replace one service without impacting others.
- Define clear communication protocols and data formats: Standardizing communication protocols, and data formats between microservices can improve interoperability and reduce the potential for errors and integration issues. Tools like schema registries and data serialization systems, such as Avro and Protobuf, can be used to help with this. They offer a large set of benefits, including allowing a smooth change of the data being exchanged between microservices, different versions of the data, backwards and forward compatibility and more.
- Monitor and maintain service boundaries over time: As your microservices evolve, it’s essential to regularly review and update the boundaries between services to ensure they remain clear and well-defined. Monitoring tools and processes can help identify areas where service boundaries may have become blurred, or dependencies have been introduced.
Defining clear service boundaries requires a balance between specificity and flexibility. It’s important to ensure that each microservice has a specific responsibility but also that the boundaries between services are not too rigid, allowing for flexibility as your system evolves.
Statelessness
I have recently reviewed a piece of code intended to be delivered as a microservice.
The service used a collection, which kept user information.
Based on some incoming requests, it was saving some specific user information in a collection.
For some other incoming requests, it was checking information against that collection.
What’s the problem, you might wonder? 🤔
We develop microservices so that we can scale up or down as we wish.
Assume we have two instances of this specific microservice up and running.
In this case, some information will be saved on the corresponding collection of Microservice1 and some on the corresponding collection of Microservice2!
So when a new request comes in, and Microservice1 checks its corresponding collection for information, it might not find the information it wants. Why? Because the information is looking for is on the corresponding collection on Microservice 2.
If you must maintain a state, there are ways to achieve this in a scalable and distributed manner. One way to do this is using a distributed cache like Redis, where you can store and retrieve data across multiple instances.
I also want to note that maintaining the state in microservices is not always bad. There are some scenarios where stateful microservices can be helpful—for example, caching frequently accessed data. So, you should consider whether maintaining a state in a microservice is necessary or not.
Conclusion: Aim to have stateless microservices unless you really need a state.
Health Endpoints
There are a couple of endpoints you need before deploying the microservice in a Kubernetes cluster that are essential for monitoring and managing microservices, namely the liveness and the readiness endpoint. These health endpoints can be used for zero-downtime deployments.
- The readiness endpoint allows Kubernetes to determine when a pod is ready to receive traffic. Kubernetes will not send traffic to a pod until it receives a successful response from the readiness endpoint. This helps avoid situations where a pod may receive traffic before it is fully configured or initialized, leading to errors or poor performance.
- The liveness endpoint allows Kubernetes to determine whether a pod is still running or has become unresponsive. Kubernetes regularly sends requests to the liveness endpoint, and if the endpoint does not respond with a successful status code, Kubernetes will assume that the pod has failed and will take corrective action. This helps ensure that pods that are no longer functional are automatically restarted or replaced by Kubernetes.
Readiness and liveness endpoints are essential for microservices running in a Kubernetes environment because they provide a way for Kubernetes to monitor and manage the health of your microservices.
Note: If you are using Java, and Spring Boot, adding these endpoints can be done using the Spring Boot Actuator.
Start creating your microservices
Well done, friend💪! You are great. You’ve just finished learning about some of the 3 essential points you should consider when creating microservices.
Part 2 of this series is coming, which covers more of how we can monitor our services. So, stay tuned for more blog posts, courses and videos!
I invite you to share your experiences and best practices in the comments section.
Don’t forget to follow me on Twitter, where I share more information regarding best practices when you design, develop, deliver and maintain software!
