Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Service Mesh: What Engineers Need to Know

servicemesh.io

Post reply on HN
Print view View original

41–50 of 66 posts

Re: The Service Mesh: What Engineers Need to Know

#41

Post by jayd16 »

cbsmith wrote: post #16

I'm going to sound like an old man but... What amuses me about this is back in the day everyone thought the Mach guys were crazy for thinking things like network routing and IPC services be implemented in user space... and others mocked the OSI model's 7 layers as overly complex (e.g. RFC3439's "layering considered harmful"). Now we've moved all our network services onto a layer 7 protocol (HTTP), and we've discovere…

I think this is a bad take, especially saying HTTP is the reason. Its not. The real reason is we want stateless connections and load balancing and because of TLS we want to keep our handshakes warm too.

We also want our retries to work at the application layer too so lower layers would at least have to understand chunks of a connection larger than a packet can fail even if all the packets were acked successfully... _and_ a completely different machine should receive that chunk instead.

We want all that for free and we don't want to pay for hardware. Http/2 is the only close to this and you still need app layer retries.

Re: The Service Mesh: What Engineers Need to Know

#43

Post by jonahx »

taneq wrote: post #25
cbsmith wrote: post #16

I'm going to sound like an old man but... What amuses me about this is back in the day everyone thought the Mach guys were crazy for thinking things like network routing and IPC services be implemented in user space... and others mocked the OSI model's 7 layers as overly complex (e.g. RFC3439's "layering considered harmful"). Now we've moved all our network services onto a layer 7 protocol (HTTP), and we've discovere…

Network-over-network is just another Inner Platform Effect.

Wonderful term. I've been aware of the phenomenon for a while but not its name.

Link for others:

https://en.wikipedia.org/wiki/Inner-platform_effect

Re: The Service Mesh: What Engineers Need to Know

#44

Post by jacques_chester »

ajessup wrote: post #24

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…

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

Re: The Service Mesh: What Engineers Need to Know

#45

Post by jacques_chester »

tptacek wrote: post #18
jayd16 wrote: post #11

Earlier quoted context omitted.

So a goal of the service mesh is to keep it an api agnostic appliance. I'm not sure that concept requires all this nomenclature. It seems like a very thin API Gateway that forwards calls directly to the microservice API without enforcing much would be much easier to manage and have all the same benefits. Whats the purpose of deploying the reverse proxy alongside the microservice?

Yeah, you haven't grokked the concept yet. The idea behind a service mesh is that no matter how you design and implement a microservice architecture, you still have all these little services talking to each other somehow. By "default", they're communicating using native sockets and HTTP or gRPC. There's lots that can go wrong any time you have a bunch of things talking to each other on a network (see Tanenbaum's "Cri…

> Tanenbaum's "Critique of RPCs"

I had trouble finding this under the given title. For those searching, I believe tptacek is referring to Tanenbaum & Renesse, A Critique of the Remote Procedure Call Paradigm [0], published in 1987 or 1988.

A fun read, especially since "it's just the same as local" is a myth each generation gets to revisit. Compare to Waldo, Wyant, Wollrath & Kendall's A Note on Distributed Computing[1], published in 1994.

[0] https://www.win.tue.nl/~johanl/educ/2II45/2010/Lit/Tanenbaum...

[1] https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...

Re: The Service Mesh: What Engineers Need to Know

#46

Post by jensneuse »

ajessup wrote: post #24

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…

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.

Re: The Service Mesh: What Engineers Need to Know

#47

Post by jacques_chester »

streetcat1 wrote: post #26
ajessup wrote: post #24

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

Re: The Service Mesh: What Engineers Need to Know

#48

Post by solatic »

Re. "fat client" libraries:

> Sure, it only worked for JVM languages, and it had a programming model that you had to build your whole app around, but the operational features it provided were almost exactly those of the service mesh.

The thing is, all of our microservices communicate with each other using Kafka. Envoy has an issue open for Kafka protocol support [1], but it's a fundamentally difficult issue because adopting Kafka forces you to build out "fat client" code and building a network intercept that can work with pre-existing Kafka client code is non-trivial. On observability, Kafka produces its own metrics.

Granted, Kafka doesn't offer the same level of control. But Kafka does offer incredible request durability guarantees. We don't have "outages" - we have increased processing latency, and Istio/Envoy and other service meshes can't offer that because they do not replicate and persist network requests to disk.

[1] https://github.com/envoyproxy/envoy/issues/2852

Re: The Service Mesh: What Engineers Need to Know

#49

Post by dodobirdlord »

adolph wrote: post #39

If one were to implement a service mesh of microservices wouldn’t the services need to be versioned similar to how the packages used by a microservice are version-pinned?

Sort of, but only for major versions, and it's preferable to bake that sort of thing into the API itself. The API exposed by a microservice should only ever be updated in backwards compatible ways unless you can verify that you have no callers, which is hard. New functionality should be introduced using backwards compatible constructs like adding fields to JSON or protobuf. Breaking changes go in a new API. This is easily managed conceptually by having the microservice expose version information as part of the API. A FooService might define "v1/DestroyFoo" and "v2/DestroyFoo" with different calling contracts. Perhaps v1 was eventually consistent and returns a completion token that can be used with a separate "v1/CheckFooDeletionStatus", but now with v2 the behavior has been made strongly consistent and there is no "v2/CheckFooDeletionStatus". The v2 of the API can thus be thought of really as a separate API that happens to be exposed by the same microservice, and pre-existing callers can continue to call the (perhaps now inefficient) v1 API.

Re: The Service Mesh: What Engineers Need to Know

#50

Post by cpitman »

thom wrote: post #29
tptacek wrote: post #7

Earlier quoted context omitted.

It's not as much about load as it is about complexity; it starts to make sense when you hit some threshold number of internal services, regardless of the amount of traffic you're doing. You use a service mesh to factor out network policy and observability from your services into a common layer.

What is the threshold above which a service needs to exist at all, over a module in an existing codebase?

The point at which you have multiple teams working on the same codebase, and their velocity is suffering from communication overhead and missteps.
Post reply on HN