Building Resilient Apps with Service Meshes

Building Resilient Apps with Service Meshes

As enterprises strive to achieve business agility, the need to revamp legacy architecture is becoming apparent. More and more enterprises are thus making the shift from monolithic applications to those built on a microservices framework. This is much more flexible, scalable and easier to deploy, since each service is independent of the others. Microservices also ensures a container backed sophisticated tech stack for developers, while avoiding the bottlenecks of a central database. Containerization has benefited enterprises massively too, because apps can be run as soon as the code, run time and libraries are packaged inside these containers. Sounds simple, right?

Only if it was! Building this framework is no less challenging than dealing with clunky legacy systems. Unless your tech team is well versed with the technicalities, successful app development is impossible. There’s something that can make the dev team’s lives a little simpler, though: service meshes. A fairly new concept that has been making the rounds in IT, a service mesh is a dedicated infrastructure layer that enables service-to-service communication through APIs.

Much like the microservices framework, this was also popularized when developers at Netflix and Google created their own libraries to request traffic as and when required. It essentially acts as a data plane between services, and ensures modularization, cohesion and coupling within the app. A typical services model deals with caching, load balancing, routing and flow control, but this model can also break easily, when there are multiple layers of infrastructure. When there are too many APIs within a microservice for a single functionality and not enough communication, everything falls apart.

With the rise of cloud native apps, Docker and Kubernetes have also become very popular within the developer community, but these containers have resolved issues related to deployment, not run time. Performance lags and increased run-time are still the biggest pain points. That’s where these meshes come in. While their primary role is traffic management, they also take care of service discovery, health checks, load balancing, fault injection and authentication.

One of the major benefits that microservices offers is scalability, but achieving this is not easy. The more the number of services within the app, the more complex it becomes for these apps to communicate. With service meshes in the mix, each service has a separate responsibility, and inter-service bridge building happens at scale. Traffic is routed in an east-west fashion through data centers, which reduces the infrastructural load. Better in-app flexibility and transparency can also be built through these meshes, as they decouple complexity and structure the flow of requests.

Safe to say, then, that teams need to have sufficient knowledge about service meshes to develop sophisticated applications. There are umpteen benefits that come from adopting this development approach as well. Successfully implemented service meshes mean zero latency across a homogenous network of independent APIs, enabling the end app’s reliability, security and visibility. Complex architecture, can thus be deployed more simply, as this makes for faster test-deployment cycles. All of this, in turn, leads to a holistic, seamless user experience for the end consumer.

But it is not only the responsibility of the developer teams to drive the adoption of service meshes in the organization. As long as business leaders are unaware about the value it brings, it makes no sense for teams to adopt this. In the absence of service meshes, performance lags, inconsistency in data, maintenance and upgradation issues and high costs of infrastructure are bound to exist. App quality might also suffer, if developers get too bogged down with execution, leading to a lack of creativity.

With proper direction, service meshes can act as the glue that binds a successful digital transformation together. Enterprises are also slowly moving towards making the most of this offering, as developers can focus more on business goals rather than executional cycles. It is imperative that modern apps follow the service mesh approach to remain future ready and agile. Else, there’s a very good chance of not reaching the end of the line.

Yogesh Dhande is a team lead at iauro Systems.

Taking Agility A Step Ahead with Microservices

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!

Why Microservices?

  1. 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

  1. 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.

Challenges:

  1. 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.

5. Visibility

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.

Conclusion:

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