Microservices Mesh – Part I
Today, we’re taking a look behind the curtain, so to speak. We’re looking at one particular technology, microservices mesh, that smooths the rough edges of microservices and helps make it easier for developers to get working in a microservices framework. Hopefully, by the end you’ll have a fuller picture of how mesh can fit into your microservices deployment.
What Is Microservices Mesh?
A Microservices Mesh (sometimes also called a service mesh) is an abstract layer that defines the interactions between different microservices in your application. A mesh uses the networking between different containers to control how different components of your application interact. Although that may sound abstract, it’s actually quite a practical concept. Containers interact via the network, so changing the network topology allows you to redefine how containers can interact.
When starting out with microservices, one common piece of advice is to treat different components within your application as APIs from completely different providers. Microservices Mesh gives you the ability to implement this on a network level, by defining exactly what services are available at what network locations. Instead of deploying a configuration change whenever services move or are redefined, you instead make a networking change.
What Does It Get You?
Microservices are praised for their ability to scale, and their ability to break a large app down into digestible components. In contrast, where monolithic apps shine are areas where centralization is important. Logging is easier in monoliths, because they’re running in one place. Version control is easier, because you’re overwriting a single instance. When developers switch from monoliths to microservices, they’re frequently lost. There’s no one central place to log to, or to identify which version of a service they’re targeting.
The key insight of the mesh idea is that there can be, in many cases, a central source of truth for some of that information, namely the networking layer. Consider the case of deploying a new version of a component, which we mentioned above. Rather than destroying all containers hosting the old version and launching new containers with the new version (and repeating this process for components with a dependency on the new service), with a mesh-based application you have control over what containers other containers can see via the network.
By focusing on the network behind the components of your app (the mesh in which they operate) you can retain some of the centralization that made management so much easier in the monolithic world. Want to gain more insight into how traffic flows through your app? Add some monitoring to the network between components. Need to beef up security? Add stricter encryption and enforce HTTPS between components. Mesh makes all this possible.
Want To Learn More?