Taking Agility A Step Ahead with Microservices
Traditional IT architecture operates generally on single application databases, and adding new features on to pre-existing, tightly coupled dependencies is hard, since the entire structure is managed as a unique package.
But it doesn’t have to be that way. Within a microservices architecture, each feature is independent of all others, and free from the siloed approach. An API or message bus is utilized to enable asynchronous communication within that ecosystem.
Monolith Vs Microservice
With legacy architecture, you essentially sign up for large monolithic packages that can be challenging to deploy. If that wasn’t enough, this comes with tricky configurations too, leading developers to deploy these packages seldom, just about once every few weeks or months. Microservices, on the other hand are small, isolated and easier to manage, so they can be plugged in as and when required..
Another significant advantage that microservices offers, is reduced dependency, and increased storage capacity. Traditional architecture usually scales out an application by ramping up more hardware, but microservices save resources instead. The best part is that these features are load balanced across multiple servers.
Interdependency also means increased resilience, as each feature is designed to handle times of crisis in the event that other services fail. Time-to-market that was once measured in months, is now measured in days. Way to enhance business agility!
- Better alignment with the organisation
Microservices enable organizations to align their IT architecture better with existing business goals. With large code bases, there might be three or four teams involved, and confusion may ensue over these codebases. Small decisions like who gets to check in, who is in charge for part of this code etc. can often lead to people stepping on each other’s toes. If teams are in different geographical locations, a microservice architecture can also enhance team ownership, making it much easier to collaborate and let go of silos.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. — Melvin Conway
- Ship features faster and safer
Everybody wants to ship software faster. This is unlikely in monolith, where the entire app needs to be restructured even to make single line of change. Microservices are more like blocks of lego, operating on plug-and-play. If we know what to modify, there’s no need to dismantle everything. A high degree of risk can also be avoided, as monoliths bring the entire system down at once. With microservices, more resilient systems are built, and these are systems that don’t allow failure to cascade.
2. Independent scaling and segregation
All businesses want to scale up, but an understanding of how to go about the process is important. It needs to be a step-by-step approach, and if organisations try to do everything all at once, there’s a good chance of failure. With microservices, single services can be scaled independently as per business requirements. No need to scale the whole system. Independent services enable us to utilize different segregation models. Specific perimeters (such as access control list i.e ACL or network segments) can be applied to singular services, which in turn allows developers to chart out a streamlined, modular way to use microservices. This saves the resources’ time, infrastructure costs and reduces delivery time. Truly the best of both worlds!
3. Adopt technology more easily
Multiple deployable units within a plug and play system allow developers to look at distinct technology choices, different deployment platforms, various coding languages and better database choices. Whereas with a monolithic system within a single codebase we’re often looking for consistency that will drive us towards a single programming idiom, with microservices there’s freedom of choice. The focus still remains on ensuring that API/Communication mechanisms still work, but developers have more room to experiment and innovate.
- Service Communication
Maintaining seamless inter-process communication is a huge challenge for developers across the table. While variations across synchronous, asynchronous ( one to one ) and asynchronous (one to many) are available, it’s recommended that the asynchronous communication be utilized across APIs, for event driven MSA as that ensures quicker turnaround times.
2. Data management
The hardest part of working with a microservices architecture is the data management. Whether that data is generated through internal APIs or across external services, it has to be mined in a certain manner for it to be useful. There are multiple approaches to manage data, one of them and recommended way is to operate your own data store. Data, then, will be accessible via only through the service APIs or message bus, thus ensuring customisation.
3. Distributed Transactions in Microservices
To follow the Single Responsibility Principle ( SRP ), as mentioned earlier, each microservice has to maintain its own data and no other service can access the data without knowledge of the responsible microservice. To overcome the challenge of decentralized data management, a 2 step implementation phase is ideal, so that even if one of transaction fails, it can roll back to the last successful one.
4. Configuration management
We may have multiple microservices running at the same time, in different environments. An external configuration server is more appropriate to manage applications, and take care of concerns in real time. The configuration management code (in chef or puppet) can solely be responsible for cluster management.
Imagine that functionality is distributed among ten micro-services and there’s a bug in one. How do you identify where the bug is? You need to have a centralized log where specific requests can be tracked, to figure out which service caused the problem. Monitoring is imperative, and it helps identify which services go down at what time. Automation plays a huge role here, and the more you bring it in, the faster processes will be.
6. Fault tolerance
Microservices depend on other services in order to fulfill their requirements. Since microservices are deployed independently, their instances may go up and down frequently. Avoiding cascading failures and single point failure is a big challenge with MSA implementation. Fault tolerance can be achieved with the help of a circuit breaker, a pattern that wraps requests to external services and detects when they are faulty.
If you’re looking at fast, scalable and flexible architectures, microservices are your best bet. Bring in CI/CD, automation and cloud environments, and your path to agility is all set. Try for yourself, and you will see the difference!
-Krunal Chaudhari, Team Lead, iauro Systems