Microservices Mesh – Part I
If you’ve been following the trends in distributed and cloud architectures over the past few years, you’ve likely heard a lot about microservices. Since their introduction a few years ago, they’ve slowly started taking over the conversation around enterprise cloud deployments. More and more companies are announcing their move to microservices, and making blog posts and press releases to celebrate it.
But while the move to microservices is justly celebrated, many companies neglect to let you know what’s going on behind the scenes. Properly done, microservices solve many of the headaches from the monolith architecture: they’re easy to iterate, cleanly separate into teams, and break code down into manageable components. However, many of the celebratory posts leave out the follow up work and components required to reap the benefits of microservices.
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.
Because the networking between components is very fundamental in microservices, manipulating that networking via a microservices mesh allows you to accomplish some very useful things. For example, when you deploy new versions of a component, you can instantly point network devices away from the old instances and onto the new ones without any configuration. Or if you’re having difficulties scaling, you can use the mesh to point to different load balancers for different services, and beef up the number of containers for different components of your application.
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.
That means if you want to deploy a new version, you can just point to new containers using DNS if you’d like. Or point to a new load balancer. Or change the containers that the existing load balancer points to.
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?
Over the next couple of weeks, we’ll be doing a deeper dive into how microservices mesh operates and what it’s used for in practice for some microservices deployments. We’ll focus on the real benefits that mesh brings to microservices: control, manageability, and insight into what’s going on in a larger application.
Service Mesh Istio
Service in Kubernetes
87836823cookie-checkKubernetes Microservices Mesh – Part Ino