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

21–30 of 66 posts

Re: The Service Mesh: What Engineers Need to Know

#21

Post by omeze »

theamk wrote: post #17

It’s a pity “fat clients” are dismissed so quickly. I think that when your tech stack is uniform enough to use them, they can provide much more that service meshes, and do it faster as well. After all, why does “service is down” and “service is sending nonsense” have to be handled via completely different paths?

The main problem with fat clients is that for polyglot architectures (which most large companies that end up building a service mesh evolve into over time) you have to maintain a fat client library for every language. You can get very far leveraging existing tools like gRPC that codegens fatty clients for you but the quality of tooling is very uneven depending on the language of choice. By pushing all of this into the network layer you skip all of that.

Re: The Service Mesh: What Engineers Need to Know

#22

Post by erik_seaberg »

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…

It's an RPC plugin but doing it out-of-process is weird (I need an RPC client to talk to my RPC client?). If you don't need a trust boundary or separate ulimits, loopback network traffic and context switches and reserialization are a really expensive way to mitigate a language having poor FFI plugin support.

If it were in-kernel and supported scatter-gather and zero-copy, that might be different (though some people even avoid going through the kernel).

Re: The Service Mesh: What Engineers Need to Know

#23

Post by jayd16 »

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…

I think I get it. Its underpinned by the assumption that the application doesn't need robust logic around connecting to a local proxy like it would connecting to a remote one. In this sense its going back to the days when instances had a local HAProxy running. That assumption didn't really pan out and we all decided service LBs were better but ok, sure. We can have both.

I still think describing the concept more plainly would help a lot of the confusion.

Re: The Service Mesh: What Engineers Need to Know

#24

Post by ajessup »

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 why Kong, Apigee, nginx etc. are all shipping service mesh implementations now before their market gets snatched away from them.

Secondly to cloud providers, who hate seeing their customers deploy vendor-agnostic middleware rather than use their proprietary APIs. None of them want to get "Kubernetted" again. Hence Amazon's investment in the very Istio-like "AppMesh" and Microsoft (who already had "Service Fabric") attempt to do an end run around Istio with the "Service Mesh Interface" spec. Both are part of a strategy to ensure if you are running a service mesh the cloud provider doesn't cede control.

Then there's a slew of monitoring vendors who aren't sure if SM is a threat (by providing a bunch of metrics "for free" out of the box) or an opportunity to expand the footprint of their own tools by hooking into SM rather than require folks to deploy their agents everywhere.

Finally there's the multi-billion dollar Software Defined Networking market - who are seeing a lot of their long term growth and value being threatened by these open source projects that are solving at Layer 7 (and with much more application context) what they had been solving for at Layer 3-4. VMWare NSX already have a SM implementation (NSX-SM) that is built on Istio and while I have no idea what Nutanix et al are doing I wouldn't be surprised if they launched something soon.

It will be interesting to see where it all nets out. 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. On the other hand it could just as easily become a vendor-driven tire fire. In a year or so we'll know.

Re: The Service Mesh: What Engineers Need to Know

#25

Post by taneq »

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.

Re: The Service Mesh: What Engineers Need to Know

#26

Post by streetcat1 »

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.

Re: The Service Mesh: What Engineers Need to Know

#27

Post by djohnston »

This is quite interesting. I used to work in more devopsy kind of roles but at the current gig it has been almost entirely removed from my purview. It's impressive to step away for a few years and return to see so many changes, but the article laid out the concepts in an easy to understand manner.

Re: The Service Mesh: What Engineers Need to Know

#28

Post by theamk »

omeze wrote: post #21
theamk wrote: post #17

It’s a pity “fat clients” are dismissed so quickly. I think that when your tech stack is uniform enough to use them, they can provide much more that service meshes, and do it faster as well. After all, why does “service is down” and “service is sending nonsense” have to be handled via completely different paths?

The main problem with fat clients is that for polyglot architectures (which most large companies that end up building a service mesh evolve into over time) you have to maintain a fat client library for every language. You can get very far leveraging existing tools like gRPC that codegens fatty clients for you but the quality of tooling is very uneven depending on the language of choice. By pushing all of this into th…

Right, polyglot architectures have no choice, but this text talks about “5 person startups” as well. Surely they can keep the set of languages limited?

Plus, it’s not either/or situation. A fat clients for Go + Node.js; and a proxy for all others. This way your core logic can enjoy increased introspection / more speed / higher reliability; while special purpose services get a proxy which allow interoperability.

Re: The Service Mesh: What Engineers Need to Know

#29

Post by thom »

tptacek wrote: post #7
Animats wrote: post #2

How many transactions per second before you need all that stuff? If you're not in the top 100 sites, it seems unnecessary.

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?

Re: The Service Mesh: What Engineers Need to Know

#30

Post by tptacek »

jayd16 wrote: post #23
tptacek wrote: post #18

Earlier quoted context omitted.

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…

I think I get it. Its underpinned by the assumption that the application doesn't need robust logic around connecting to a local proxy like it would connecting to a remote one. In this sense its going back to the days when instances had a local HAProxy running. That assumption didn't really pan out and we all decided service LBs were better but ok, sure. We can have both. I still think describing the concept more plai…

I think this is right, yes. We're not worried about the connectivity between the service and the local proxy because they're (always) cotenants of a container and using localhost to communicate.

A more general way to think about service meshes is that the network layer we code to right now is actually really primitive; its service model was fixated in the 1980s, and its programming interface hasn't much evolved from the early 1990s. We'd be happier if we could level up the whole network, so that it had QoS controls, a really expressive security model that didn't rely on magic-number ports and address ranges, and observation capabilities that communicated application-layer details and didn't just try to approximate them the way flow logs do. You can get all that stuff, internally at least, by putting all your services on the same service mesh.

Another thing to look at is Slack's Nebula, which was just released last week:

https://slack.engineering/introducing-nebula-the-open-source...

Nebula is a service mesh that runs at the IP layer (where Istio and Linkerd ride on top of HTTPS proxies, Nebula rides on top of a somewhat Wireguard-ish VPN). Slack has been using it internally for 2 years now. It's solving the same problems Linkerd is, but with a radically different implementation. You can get your laptop connected to a Nebula service mesh in ways that would be clunky to do with a Linkerd mesh.

Post reply on HN