Suddenly, servers really need a service mesh to serve as their communications hub, especially when there are a multitude of simultaneous instances (replicas) of a service propagated throughout the system, when a component of code only needs to contact one.

Also: How the Linkerd service mesh can help businesses TechRepublic

From unknown entity to vital necessity

Most modern applications, with fewer and fewer exceptions, are hosted in a data center or on a cloud platform, and communicate with you via the Internet. For decades, some portion of the server-side logic — often large chunks — has been provided by reusable code, through components called libraries. The C programming language pioneered the linking of common libraries; more recently, operating systems such as Microsoft Windows provided dynamic link libraries (DLL) which are patched into applications at run time.

So obviously you’ve seen services at work, and they’re nothing new in themselves. Yet there is something relatively new called microservices, which as we’ve explained here in some depth, are code components designed not only to be patched into multiple applications on-demand, but also scale out. This is how an application supports multiple users simultaneously without replicating itself in its entirety — or, even less efficiently, replicating the virtual server in which it may be installed, which is how load balancing has worked up to now during the first era of virtualization.

A service mesh is an effort to keep microservices in touch with one another, as well as the broader application, as all this scaling up and down is going on. It is the most liberal, spare-no-effort, pull-out-all-the-stops approach to enabling a microservices architecture for a server-side application, with the aim of guaranteeing connectivity, availability, and low latency.

Also: Why it’s time to open source the service mesh TechRepublic

SDN for the very top layer

Think of a service mesh as software-defined networking (SDN) at the level of executable code. In an environment where all microservices are addressable by way of a network, a service mesh redefines the rules of the network. It takes the application’s control plane — its network of contact points, like its nerve center — and reroutes its connections through a kind of dynamic traffic management complex. This hub is made up of several components that monitor the nature of traffic in the network, and adapt the connections in the control plane to best suit it.

SDN separates the control plane from the data plane of a network, in order that it can literally rebuild the control plane as necessary. This brings components that need each other closer together, without impacting the data plane on which the payload is bound. In the case of network servers that address each other using Layers 3 and 4 of the OSI network model, SDN routes packets along simplified paths to increase efficiency and reduce latency.

Borrowing that same idea, a service mesh such as Istio produces a kind of network overlay for Layer 7 of OSI, decoupling the architecture of the service network from that of the infrastructure. This way, the underlying network can be changed with far fewer chances of impacting service operations and microservices connectivity.

Also: What is SDN? How software-defined networking changed everything

“As soon as you install it, the beauty of Istio and all its components,” remarked Bahubali Shetti, director of public cloud solutions for VMware during a recent public demonstration, “is that it automatically loads up components around monitoring and logging for you. So you don’t have to load up Prometheus or Jaeger [respectively]; it comes with them already. And it gives you a couple of additional visibility tools.

“This is a service-to-service intercommunications mechanism,” Shetti continued. “You can have services on GKE

, PKS [Pivotal Kubernetes Service] and VKE [VMware Kubernetes Engine], all interconnected and running. It helps manage all of that.”

Also: What is SDN? How software-defined networking changed everything

Complementing, not overlapping, Kubernetes

Now, if you’re thinking, “Isn’t network management at the application layer the job of the orchestrator (Kubernetes)?” then think of it like this: Kubernetes doesn’t really want to manage the network. It has a very plain, unfettered view of the application space as multiple clusters for hosting pods, and would prefer things stay that way, whether it’s running on-premises, in a hybrid cloud, or on a “cloud-native” service platform such as Azure AKS or Pivotal PKS. When a service mesh is employed, it takes care of all the complexity of connections on the back end, ensuring that the orchestrator can concentrate on the application rather than its infrastructure.

Also: What Kubernetes really is, and how orchestration redefines the data center

Key benefits

The very sudden rise of the service mesh, and particularly of the Istio framework, is important for the following reasons:

• It helps standardize the profile of microservices-based applications. The behavior of a highly distributed application can be very dependent on the network that supports it. When such behaviors are drastically different, it can be a challenge for a configuration management system to maintain availability for an application on one network that has far fewer challenges on another network. A service mesh does all the folding, spindling, and mutilating — it makes a unique data center look plainer and more unencumbered to the orchestrator.
• It opens up greater opportunities for monitoring, and then potentially improving, the behavior of distributed applications. A good service mesh is designed to place highly requested components in a location on the application control plane where they can be most easily accessible — not unlike a very versatile “speed dial.” So it’s already looking for components that fail health checks or that utilize resources less efficiently. This data can be charted and shared, revealing behavioral traits that developers can take note of when they’re improving their builds with each new iteration.
• It creates the potential for a new type of dynamic, policy-based security mechanism. As we explored last December in ZDNet Scale, microservices pose a unique challenge in that each one may have a very brief lifespan, making the issue of an unimpeachable identity to it almost pointless. A service mesh has an awareness of microservice instances that transcends identity — its job is to know what’s running and where. It can enforce policies on microservices based on their type and their behavior, without resorting to the rigamarole of assigning them unique identities.

Previous and related coverage:

Microservices and containers in service meshes mean less chaos, more agility

For enterprises, it’s full speed ahead with microservices. This may speed up the development of chaos-proof service meshes.

To be a microservice: How smaller parts of bigger applications could remake IT

If your organization could deploy its applications in the cloud the way Netflix does, could it reap the same kinds of benefits that Netflix does? Perhaps, but its business model and maybe even its philosophy might have to be completely reformed — not unlike jumping the chasm from movies-by-mail to streaming content.

Micro-fortresses everywhere: The cloud security model and the software-defined perimeter

A months-old security firm has become the braintrust of engineers working to build the Software-Defined Perimeter — a mechanism for enforcing firewall and access rules on a per-user level. How would SDP remake the ancient plan of the software fortress?

More from ZDNet scale: