Microservices are individual services that together, make up an application. It’s not unusual for one application to consist of hundreds of microservices, all of which must be continually discovered and tracked, along with their dependencies, performance and status.
Without the ability to see what is happening at all times, it is very difficult for developers to resolve issues as they occur. For example, a failure in one microservice can cause cascading failures in other parts of the application. The longer it takes to identify the source of the failure, the longer a service will be disrupted.
Take the simple example of a payment service performing slower than usual. Getting to the bottom of the situation requires a deep understanding and tracing of all components. For example, if a developer rolls out a new version of the payment system and notices that the end-to-end request now takes 1.5 seconds instead of the previous 700 milliseconds, that might prompt them to ask the payment team to look at the change it made. The payment team might not find anything wrong with the code. The next step would be asking each team that touches the request — the frontend team, the analytics team and all of the others — to check their code.
Microservices also can complicate security. Unlike a traditional application, which has very few entry points, applications built with microservices have dozens or hundreds of entry points. Each exposed application programming interface (API), port and component is a potential attack vector, and every entry point must have the appropriate access controls to protect against denial-of-service attacks, man-in-the-middle attacks and so on.
The Solution: The Service Mesh
Adding a service mesh to microservices can improve visibility, monitoring, management and security.
A service mesh allows developers to make changes without touching the application code itself. It provides the ability to mirror and monitor traffic on multiple versions of the same service, which lets developers test capabilities before deployment and determine the best way to route traffic through the system for specific types of use patterns. Most importantly, it provides automated ways of monitoring what is happening between services at all times, providing important metrics that can help quickly determine the cause of failures or performance issues.
“Microservices tend to get a lot of bloat from all of the things you have to add on to make sure it is secure and can handle different types of failures,” explained Jason Dudash, Principal Solutions Architect at Red Hat. “The service mesh builds that capability into the platform, so it can handle these things without the developer having to import libraries or make source code changes.”
A service mesh also can drastically improve security in microservices-based development through authentication and authorization. When services talk to one another, each must ensure that the others are who they say they are. Without a security layer, your microservices are essentially talking over an unencrypted open channel.
Authorization is equally important. In an application, there are certain services that should talk to one another, and others that should not. For example, although a checkout service talks to a payment service, the front-end service should not talk directly to the payment service. Maintaining secure authorization is difficult if done manually, but when incorporated into a service mesh, the process can be customized and automated.
This article is an excerpt from the GovLoop report, “Getting the Most out of Microservices.” Download the full report here and learn about best practices for using microservices.
