Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> 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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: