4 ms·

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

by brazzledazzle 8y ago

barbecue_sauce 8y ago
What would be an example of a "traditional" service mesh then?
- nemothekid 8y ago
  I would assume hand rolling it yourself with either nginx or ELB. Pretty much what was “popular@“ before envoy and friends
- presspot 8y ago
  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.
williamallthing 8y ago
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/ https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/
presspot 8y ago
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.

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

barbecue_sauce 8y ago

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

nemothekid 8y ago
I would assume hand rolling it yourself with either nginx or ELB. Pretty much what was “popular@“ before envoy and friends
presspot 8y ago
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.

williamallthing 8y ago

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/ https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

presspot 8y ago

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.