Getting a quick win is hard because it needs multiple ideologies and practices to come together. It would ideally be a combination of least time to support the customer and to help the customer at the right point of their journey. By helping our customers to do the above, we help our products to grow steadily. Microservices can be likened to fast acting customer support, where we are building things in a faster and leaner way. Let’s talk about why an organization would need microservices in the first place.
As a first hand believer of picking the right tools for the right jobs, I would caution the reader that Microservices might not be a good fit for all organizations. You will have to take a stock of the needs, the pros and cons of an architecture style and then take a decision to either migrate or start building through the specific architecture. Microservices do help in a few things as the organization grows and it helps the product to be modularized so that it can developed independent of others.
Microservices is a style of architecture where instead of building a product as a single service, it is split into multiple sub modules and are developed as individual services. These smaller services are developed individually by different teams in different repositories without any need for a single big team to be present. Each service has a well-defined role and it doesn’t creep into other services. Each service can communicate with each other through APIs or any messaging channel.
The advantage is that the each microservice can be scaled, deployed, updated independently. The teams work fairly independent on their services and this helps them to move faster wherever possible.
What does Microservices Help Us to Achieve?
Microservices helps us to solve many problems that come with maintaining a huge monolith. When individual teams focus on a single problem to be solved, it becomes easier for them to build into their own service. It helps them focus on important features or bugs and develop them quickly. This leads to a quicker deployment as well since the deployment belongs to the smaller team and they release as quickly as possible. When multiple teams work simultaneously on different services, the development gets parallelized without entanglements. Also, if there is a need, a single service which has huge volume of requests, it can be scaled to solve the problem instead of the scaling the entire service as a whole. There is another intangible benefit that help us in building distributed systems — a contract based development where the other teams need not worry about what goes inside the system and can blindly believe on the contract specified by the team for their APIs. In a nutshell we can list them down as:
- Focussed Development
- Faster releases
- Parallelized development
- Black box APIs
- Technology Diversity
While building microservices, if care is not taken it could lead to a few problems of its own as listed down below.
- Too much fragmentation could ariseIncreased complexity of maintaining and integrating different services
- Distributed monolith
Areas of Deep Dive Needed
There are some potential areas like Authentication & Authorization where the services can know who was calling and to check whether the request was authorized that needs to be baked into each service. Also backward compatibility might become an area where each service has to be compatible in their APIs with microservices that are still using the old endpoints. Service Discovery is also another topic which needs to be discussed in detail where how services establish themselves for others to be discovered. API Gateway is one another topic that can talk about how each call goes through to the services from the public consumers.
Since I have talked about the fundamentals of microservices architecture, I will be diving deep into these topics and how I have solved some of these problems at my work in another post.
Please subscribe to my email newsletter to receive the next post on microservices.
Originally published at work.jeygeethan.com.