Let’s talk about Microservices and Macroservices in this series. Rest is history now(Monolithic).
I will first walk you through Microservice application design complexities and how to make a decision on architecture design, whether to go with Microservice or not.
More Microservices is equal to more complexity?
- Complexity in management
If you look around there are multiple people working in the same organization under different groups. For example, there can be an HR section, Accounts sections etc. These departments run independently to not to fail the organization. For materializing the same there are more people working in each section and at the top will be an exclusive board of directors team to manage and maintain all sections. Each of the functional sections can be compared to a microservice. And the director’s board can be compared to a group of System Engineers, SRE’s, DevOps etc. The infrastructure of the organization can be compared to your cloud environment.
So if you want to reduce the complexity you should have a big Director board.
- Does the size of your team really matters??
Of course, it matters; Microservices are only meant for larger teams working on bigger applications. If you have a big team of engineers and developers, you can probably divide them to a number of teams, and this could probably be as same as the number of Microservices you are planning to build. Thus they can work independently, with their comfortable tech-stack and finally containerize the app and deploy it on Kubernetes, without breaking any dependencies on each other.
Thus, you eventually decrease the time for the overall development of the application.
From where the complexity starts in Microservice environment?
From where does it not? From code? From K8's? From automation tools? Or from your cloud environment? This is a pretty big topic to discuss. For now, we will only discuss about a Microservice app which has already been deployed to production. Below are some pain points.
- It is going to be difficult to troubleshoot an application failure if there is no proper logging implemented at the code level
- Storing logs are also equally important as the first point
- Management of that logging infra is the next pain
- If your services talk to each other, you need to monitor the requests and responses made by each Microservice. This helps you in identifying bottlenecks for each Microservice. To counter this, you have to introduce more tools.
- Increase in east-west traffic or service to service communication will increase the complexity
- Logs from your K8s nodes are to be collected and monitored with another set of tools
- K8s cluster should be secured with proper RBAC, network controls, pod security policies and a pod disruption budget. You may have to bring in tools for conformance checks.
- Next is your cloud environment. Make a separate subscription/account for your production environment. And access to that environment should be limited and restricted.
- You have to implement WAF and necessary security measures to protect your north-south application traffic.
Out of these pain points, point number 5–7 are the only additional pains introduced by Microservice design. For solving all these pains we had to bring in additional tools with Kubernetes.
How to reduce these complexities?
- There’s a need for more highly skilled Engineers to manage a Microservice environment on Kubernetes in order to make it less complex
- Also, usage of multiple tools to achieve the same purpose as log monitoring of cluster nodes and application pods increases the complexity, rather use the same tools to do both, so the skills required in your engineering team can be minimized.
- Environment optimization is another exercise which has to be done while architecting your application.
- Consider writing server-less microservices, which can be deployed on any cloud environment of your choice. This can minimize cost and management complexities.
According to me, Microservices are meant to be developed and deployed on server-less platforms, and thus you can reduce a lot of costs.
How to decide your application design has to be Microservice or not?
We do know that the Microservice application design pattern has lot of advantages. Think it to be as similar to a car, a costly model with some advanced features, like Tesla. Purpose of a car is to commute, however, with Tesla you get good comfort and some advanced features. Nevertheless, it is highly costly compared to a regular model car. And the cost of maintenance is pretty high for this type of cars. The only significant difference is that of travel comfort which certainly varies with price.
Now let’s say your application is the traveller who wants to commute. If it is Tesla, the passenger will be more comfortable, if it is a regular model, the passenger will be less comfortable. Similarly, if the application is shipped on K8s in Microservices, it will be more comfortable while running. And if it’s going to be a regular 3 tier deployment, it will still run. The purpose will be achieved in both cases.
So what I meant is, your decision should purely depend on the application you’re going to ship. If we take the example of Netflix, it serves millions of customers every second. For them, scalability is a concern. Breaking monolithic to Microservices will surely increase their customer experience. If they want to release a new feature they can do it without even telling that to customers. They even test out new features to customers by using the well-known Canary deployment model.
So for an application like Netflix which serves millions of customer requests in seconds, there might be a need to follow the Microservice design pattern. It helps them to manage scalability, improve customer experience and ship new features faster and safer without even notifying the customers.
However, if you have a small team and still wants to go with the Microservice design, you should consider server-less rather than containers. In case you don’t want to get locked with a vendor by going server-less, consider Macro-service design patterns.
Wait for part 2 of this series on Macro-services. Catch you soon!
