Why the Service Mesh Should Fade Out of Sight

Re:Why the Service Mesh Should Fade Out of Sight by tflinton on Sunday January 17, 2021 @07:18PM (#25816751)

Service meshes shouldn’t by-in-large require any sort of dev-specific knowledge to participate in.

My experience is limited to istio but tagging a deployment is more or less all an engineer needs to know. After that a sidecar is attached that rewrites ip traffic and gives you better observability, mutual TLS encrypted transports and obviously http routing / traffic control.

Obviously to take advantage of a lot of policy capabilities an engineer would need to know or declare their dependencies but I hardly think this is something that has a cognitive overhead that the author seems to imply.

[ Parent | on HN ]

Re:Why the Service Mesh Should Fade Out of Sight by jayd16 on Sunday January 17, 2021 @07:44PM (#25816925)

Agreed, maybe I'm not understanding something about how service meshes are run but shouldn't they be transparent to the app?

[ Parent | on HN ]

Re:Why the Service Mesh Should Fade Out of Sight by bincyber on Sunday January 17, 2021 @08:04PM (#25817063)

Transparent to the app while providing all of the features for you so you dont need to reimplement/reinvent the wheel for each service.

[ Parent | on HN ]

Re:Why the Service Mesh Should Fade Out of Sight by LASR on Sunday January 17, 2021 @08:06PM (#25817074)

The service mesh is an abstraction layer. It hides the complexity of interconnecting multiple services. But the mesh itself is not intended to be transparent.

Just like an OS hides the complexity of managing hardware, but software written is very much aware of the OS and depends on it’s specific interfaces to operate.

[ Parent | on HN ]