Microservices with Mo - Part Two: The architecture
This post is part of the series ‘Microservices with Mo’:
Part 0: Intro
Part 1: Setting up docker
In the last part we created our git repository including a Dockerfile and Docker-Compose File. We are now able to run multiple microservice pretty easy in different containers. But what will we do with it?
The goal
During the last day I was thinking about what a useful use-case would be or especially what I want to build. Honestly — I didn’t come to a real conclusion. Since this is a proof-of-concept project I think it is ok to just think about the components. After finishing the surrounding we still can build a few ‘useful’ demo microservices. Because of that I will build a simple ‘Counter Microservice’ which will just very intelligently increase a number for each GET it receives. In this part we will deal with the whole architecture which we are going to build.
So what are typical components of a successful microservice architecture?
I think the main components/functions of a microservice architecure are the following. The short description may not be 100% accurate but you may forgive that since each component will be discussed more deeply once it gets implemented:
- Service Discovery: Service Discoveries allow other components to register themselves and let them discover each other.
- Configuration: A Configuration provide a way for externalized configurations. That means that a service can fetch its configuration from another source than having it locally.
- Edge-Service: Your services may be scattered across the globe, still there can be a benefit to have an shared entry point. This entry point can deal with cross-cutting concerns like authentication or routing.
- Load balancing: Can be achieved via different means. I will show a way how load balancing can be done dynamically depending on the available instances of our services.
- Admin Dashboard: With an increasing number of services in our architecture it is easy to loose track. With an admin dashboard we have the opportunity to manage and monitor them all in one place.
- Health Checks: Similar to the dashboards it is also difficult to keep track of the healthiness of our services. Health Checks are an indispensable tool to find out about crashes or errors.
— Advanced Topics: The next two topics may get covered but don’t pin me down on that.
- Tracing: In a microservice architecture interaction happens between the service borders. In contrast to a monolith were all of that happens inside the service bounds of that one service. For debugging purposes it will be necessary to gain insight into those intra-microservice interactions. With the introduction of tracing we should be able to follow a call which hits the edge service across our whole architecture.
- Circuit-Breaker: Sometimes a service relies on external APIs or other services. What happens when the external dependency is not available or performing poorly. When our service is doing an REST call to an slow external API it will also have slow response times. With the introduction of circuit-breakers we can react on that. A circuit-breaker allows in this cases to response with a degraded fallback without stressing the dependency even more. When the dependency recovers it will switch back to normal functionality. Our service is then available (with probably some limitations) despite missing dependencies.
Just writing all these points I realized this is quite a lot. But anyways we need to start somewhere. In order to cover a lot of this functionality we need to define a few services and a simple architecture.
The architecture
Thinking about how to compose everything here I came up with following diagram:
Here we have some clients which are out of scope of this series.
The Edge Service will be our gateway to our architecture, every request to the services behind it will have to pass through. In order to do something useful the Edge Service will provide basic auth protection.
Then there is the Admin Service which will provide a Dashboard with a lot of information about our services. The Config and Discovery Services are there to provide configuration and discovery possibilities to the services. The Counter MS is the only service which is a providing a real business logic. In a real microservice architecture there would be a lot of more services like that. But once we finish this architecture we always can create more microservice using the existing ones.
Getting started
Now that we have the architecture I think it would be a good moment to decide in which order we want to build it. I personally love to do everything incrementally if possible. Because of that reason I would start with the following plan:
- Implementing the counter microservice
- After that extend it to use the configuration service
- On top of that build the discovery and extend the microservice to discover the config server via discovery
- Provide an admin service for the already implemented services
- Create an edge service for the existing architecture
At that point we will already have covered a lot of the topics of a successful microservice architecture. The few bulletpoints cover only the components but there are a lot of functions which we mentioned before and not yet have discussed.
What I am talking about here is the earlier mentioned Health Checks, Load Balancing, Tracing and Circuit Breaker functionalities.
Recap and Outlook
Phew … I hope I didn’t bore you to death :)
In this story we learned what typical ingredients and functions of a microservice architecture are. On top of that we have seen how our architecture will look after finishing this series.
I hope you are similar tuned for the next part as I am since it will (finally) involve some coding. Hope you don’t mind myself rebranding the series to ‘Microservices with Mo’ since that is my nick across my friends and colleagues.
Thank you guys for following along. I would love to get some feedback from you, so feel free to leave a comment below.
