Untangling the service mesh

service-mesh-metaphor

You may have noticed that, as you run more and more applications in containers it’s not easy to get them to talk and play well with each other. That’s because instead of monolithic applications using APIs to talk to components on one machine, we now have one app here, another there and they use networking to talk to each other. Worst still, with containers spinning up and down, how’s an app to keep track of which services it can call on and when? The answer is to deploy a service mesh.

A service mesh, like Istio, Linkerd or Consul, must deal with: endpoint discovery, where one service can find and connect to another; how to handle connection failures; how to manage new services popping up; and coping with protecting an ever-changing network perimeter that conventional firewalls can’t handle.

Creating a mesh from scratch is hard. There are many pain points as programmers must cope with various network and application particulars.  Fortunately, using and deploying meshes isn’t that difficult because you can bake the service mesh into your app. Within each app, services are called from other apps as needed to deliver the IT goods.

As Zachary Butcher, a founding engineer at Tetrate and an Istio contributor told Data Center Knowledge, a service mesh provides a new layer that sits between your application and the network. “It provides things like service discovery, fine-grained traffic control, and per-request retries.” And, like networking, once your apps are aware of it, programmers and system administrators don’t need to care about the nuts and bolts.

Does that sound familiar? It should. Services-Oriented Architecture (SOA) explored these concepts in the 90s. Much more recently, microservices have taken a similar approach. But, SOA, while popular in its day, has slowly declined into obscurity.

Microservices uses service-to-service communications, which are built separately into each program. A service mesh, by providing a universal communication layer for all applications, lends itself to easier deployments of bigger, more complex end-user facing applications.

You may also be wondering, “What’s really new here?” Isn’t this just networking aware programming? In a way it is.  What’s different, as Red Hat puts it, “is that it takes the logic governing service-to-service communication out of individual services and abstracts it to a layer of infrastructure.”

It does this by essentially providing programs with an array of network proxies. These proxies are also called sidecars. That’s because they run alongside each service, rather than within them. These “sidecar” proxies—decoupled from each service—are what make up a mesh network.

In Istio, the oldest and most popular mesh implementation thanks to it working hand-in-glove with Kubernetes, sidecars run inside containers. It provides features such as routing, load balancing, retries, timeouts, access control, rate limiting, and more. You can use these by calling them in your code via its libraries. But, that’s way too much trouble. The beauty of a service mesh is, by including Istio configuration information in your deployments, your applications will automatically make use of these services.

For instance, by setting your configuration using Istio Route Rules, you can arrange it so that one website, with all its backend services, is seen by users in the United States, while its twin in French is seen only in France. Or, you can have the canary version of the same site appear to the devs team, while the production version continues to hum along to the rest of the world. Same sites, different versions, separated only by how your service mesh is set up.

That’s a trivial example, but the fact remains that service mesh will soon prove to be an essential part of all cloud-container based deployments. It’s time to start digging into meshes deeply. If you’re not using one yet, you will be soon.

Comments

  1. This is about the clearest explanation of a complex topic that I have ever seen. I have sent it off to nontechnical friends who agree.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: