[ajessup]

One reason for the explosive interest in service mesh over the last 24 months that this article glosses over is that it's deeply threatening to a range of existing industries, that are now responding.

Most immediately to API gateways (eg. Apigee, Kong, Mulesoft), which provide similar value to SM (in providing centralized control and auditing of an organization's East-West service traffic) but implemented differently. This is why Kong, Apigee, nginx etc. are all shipping service mesh implementations now before their market gets snatched away from them.

Secondly to cloud providers, who hate seeing their customers deploy vendor-agnostic middleware rather than use their proprietary APIs. None of them want to get "Kubernetted" again. Hence Amazon's investment in the very Istio-like "AppMesh" and Microsoft (who already had "Service Fabric") attempt to do an end run around Istio with the "Service Mesh Interface" spec. Both are part of a strategy to ensure if you are running a service mesh the cloud provider doesn't cede control.

Then there's a slew of monitoring vendors who aren't sure if SM is a threat (by providing a bunch of metrics "for free" out of the box) or an opportunity to expand the footprint of their own tools by hooking into SM rather than require folks to deploy their agents everywhere.

Finally there's the multi-billion dollar Software Defined Networking market - who are seeing a lot of their long term growth and value being threatened by these open source projects that are solving at Layer 7 (and with much more application context) what they had been solving for at Layer 3-4. VMWare NSX already have a SM implementation (NSX-SM) that is built on Istio and while I have no idea what Nutanix et al are doing I wouldn't be surprised if they launched something soon.

It will be interesting to see where it all nets out. If Google pulls off the same trick that they did with Kubernetes and creates a genuinely independent project with clean integration points for a wide range of vendors then it could become the open-source Switzerland we need. On the other hand it could just as easily become a vendor-driven tire fire. In a year or so we'll know.

[streetcat1]

This is a good overview. However, I think that the reason that we see a lot of service variations is because the core tech - namely - Envoy, contains all the "hard" tech (the data plane) while creating a "service mesh", basically comes down to creating a management layer on top of it.

Another intresting note is that Google did NOT recede control over Istio to CNCF.

[jacques_chester]

> Envoy, contains all the "hard" tech (the data plane) while creating a "service mesh", basically comes down to creating a management layer on top of it.

I'd argue this is backwards. Envoy has a fairly tightly defined boundary with relatively strong guarantees of consistency given by hardware -- each instance is running on a single machine, or in a single pod, with a focus on that machine or pod.

The control plane is dealing with the nightmare of good ol' fashioned distributed consistency, with a dollop of "update the kernel's routing tables quickly but not too quickly" to go with it. It's "simple" insofar as you don't need to be good at lower-level memory efficiency and knowing shortcuts that particular CPUs give you. But that's detail complexity. The control plane faces dynamic complexity.

[vidar]

And it will hopefully cost them dearly, to have a single provider control such a core piece is deeply wrong.

[phlakaton]

I was going to say re: "How is this different from an API Gateway?" – this was a lot harder a question for me to get my head around than William suggests, _because_ API Gateway vendors, I'm sure quite intentionally, have been positioning their stuff as service mesh solutions or alternatives, not as service mesh complements.

[Bombthecat]

Yeah... And they still do. I work in the api management field (vendors / software)

And I think it is more akin to have an aircraft carrier and the protection fleet of smaller ships..

You have your big api gateway with management, billing, governance (for B2b, b2c, b2b2c) and your service mesh.

[jensneuse]

I don't get the part on API gateways. Gateways are north south most of the time while a sm is east west. They can work together perfectly fine and don't even have to be integrated.

[ajessup]

Supporting North/South is how they have traditionally been marketed, but not how they are actually used much of the time. Inside enterprise they are often used as an internal "service catalog" and are effectively a shim providing discovery and consistency over a bunch of fairly scoped internal services.

[graphememes]

This is blatantly false. Service catalogs are the worst functions of gateways.

[graphememes]

This is so far from the truth. It’s simply another deployment method. One of many that an enterprise will try. That’s why. As simple as that.

[jacques_chester]

> If Google pulls off the same trick that they did with Kubernetes and creates a genuinely independent project with clean integration points for a wide range of vendors then it could become the open-source Switzerland we need.

Istio is that project, but they'd rather it was Luxembourg than Switzerland.

[scarface74]

The cloud vendors haven’t gotten “Kuberneted”. The whole concept of “lock in” is exaggerated. At a certain scale, you’re always locked in to your infrastructure. The rewards are too low in doing a wholesale switch of vendors, and when you try to stay “cloud agnostics” you spend more maintaining layers of abstraction and you don’t get many of the benefits of cloud services.

Kubernetes hasn’t changed the landscape as far as cloud providers market share. AWS is still the leader, Azure is still big in MS shops and GCP is an also ran.