[Thaxll]

I'm testing Istio at the moment and I feel those comments to be very inaccurate:

"Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."

Istio is like k8 it's very modular and you setup what you need.

"Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."

Not sure what it means, Istio is all about observability ect...

[williamallthing]

Those quotes aren't from the article. I'll address them anyways since they're from a different article which I wrote:

>> "Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."

> Istio is like k8 it's very modular and you setup what you need.

Istio is a very different beast from Linkerd. But out of curiosity, I just tried the latest Istio release on my laptop (1.0.2 on Docker for Mac K8s). The simplest configuration I found installs 50 (!) CRDs, 13 deployments, and is currently sitting at ~600mb of memory without any traffic. Perhaps by "modular" you mean you can add more modules on top of that?

(By contrast, Linkerd 2.0 installs 0 CRDs, 4 services, and is sitting at 250mb including 50mb full Grafana UI. It also does a lot less... but that's the point.)

That's the control plane. Let's not get started on the data plane.

>> "Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."

> Not sure what it means, Istio is all about observability ect...

This is all in the article. You can install Linkerd as a service owner on a single service. You'll get metrics, debugging, and more. It's lightweight and small enough for this installation make sense.

Try it. You might just like it :)

[brazzledazzle]

Are they talking about Istio? It seems way too new to call it “traditional”.

[presspot]

Buoyant invented the service mesh concept and added that term to our vernacular as a way to describe Linkerd 1.x and similar systems. Istio was built using the same pattern as Linkerd 1.0. Those are "traditional", albeit in internet years not real years.

Linkerd 2.0 takes a fundamentally different approach. It's tiny, fast, lightweight and designed to add value as a service sidecar (installed on a single service) without any "mesh". If multiple service owners install Linkerd 2.0, it self-morphs into a mesh configuration and provides all of the value of a service mesh. This creates an installation and deployment pattern that is very practical and bottoms-up, delivering value to the individual service (and service owner) but also supporting a higher-level abstraction of a mesh at the platform level. This is a fundamental innovation and, hence, a new model for service mesh patterns versus the original, er, traditional model.

[williamallthing]

The article this quote is pulled from [1] is primarily referring to Linkerd 1.x, but Istio follows the same patterns.

[1] https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

[barbecue_sauce]

What would be an example of a "traditional" service mesh then?

[presspot]

Linkerd 1.0 and Istio are traditional service meshes; you install them in their totality across an entire platform. They are rich in features and bulky, completely overkill for a single service.

Linkerd 2.0 follows a new bottoms-up model that is, frankly, non-traditional. An individual service owner can install a lightweight package on a single service and derive immediate value. When multiple service owners on a project adopt Linkerd 2.0, their services will properly "mesh" without any platform-level installs. This makes adoption organic and immediately valuable for a single dev but also for an entire project as it gets installed into more services. Game changing IMHO.

[nemothekid]

I would assume hand rolling it yourself with either nginx or ELB. Pretty much what was “popular@“ before envoy and friends