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

31–40 of 66 posts

Re: The Service Mesh: What Engineers Need to Know

#31

Post by tptacek »

erik_seaberg wrote: post #22
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…

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 e…

The "RPC" that the proxy in Linkerd is doing is radically different and more expressive than the "RPC" that is running between the Linkerd proxy and your application, which is the whole point of the architecture.

Re: The Service Mesh: What Engineers Need to Know

#32

Post by tptacek »

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?

This is more a religious question than a technical one. I tend to build monoliths. Some of our clients build microservices; some of them decompose into just a small number of services, and about half of them have monolithic API servers.

But if you're going to do the fine-grained microservice thing, the service mesh concept makes sense. You might choose not to use it, the same way I choose not to use gRPC, but like, it's clear why people like it.

Re: The Service Mesh: What Engineers Need to Know

#33

Post by scarface74 »

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…

The cloud vendors haven’t gotten “Kuberneted”. The whole concept of “lock in” is exaggerated. At a certain scale, you’re always locked in to your infrastructure. The rewards are too low in doing a wholesale switch of vendors, and when you try to stay “cloud agnostics” you spend more maintaining layers of abstraction and you don’t get many of the benefits of cloud services.

Kubernetes hasn’t changed the landscape as far as cloud providers market share. AWS is still the leader, Azure is still big in MS shops and GCP is an also ran.

Re: The Service Mesh: What Engineers Need to Know

#34

Post by phlakaton »

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 was going to say re: "How is this different from an API Gateway?" – this was a lot harder a question for me to get my head around than William suggests, _because_ API Gateway vendors, I'm sure quite intentionally, have been positioning their stuff as service mesh solutions or alternatives, not as service mesh complements.

Re: The Service Mesh: What Engineers Need to Know

#35

Post by phlakaton »

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 would say it's even a bit more pessimistic than that: it's the assumption that the application _can't be relied on_ to provide robust logic around connecting to a remote service. You can address that problem in a library or in an intermediary service of some sort, but in an organization with a heterogeneous collection of languages, versions, and stacks, the library solution becomes expensive.

I'm not sure what you mean by "instances had a local HAProxy running" but if you're thinking about a bunch of reverse proxies handling incoming requests, be aware that service meshes are handling both inbound _and_ outbound traffic to/from your service. For example, you might use a reverse proxy in front of your instance to terminate TLS, but you cannot implement something like two-way TLS authentication between your services unless you're putting something in at the client side as well.

Re: The Service Mesh: What Engineers Need to Know

#36

Post by lycidas »

At my company, we were migrating all our apps to a kubernetes + istio platform over the past couple of months and my advice is this - don't use a service mesh unless you really, really need to.

We initially choose istio because it seemed to satisfy all our requirements and more - mTLS, sidecar authz, etc - but configuring it turned out to be a huge pain. Things like crafting a non-superadmin pod security policy for it, trying to upgrade versions via helm, and trying to debug authz policies took up a non-trivial amount of time. In the end, we got everything working but I probably wouldn't recommend it again.

It's funny that I was at kubecon last week and there was a start up whose value prop was hassle-free istio and the linkerd people stressed that they were less complex than istio.

Re: The Service Mesh: What Engineers Need to Know

#37

Post by peterwwillis »

Every part of a service mesh could be baked into operating systems so that all this extra technology was just there by default. This would put a fair amount of start-ups out of business, but it would also mean a lot less people having to be hired to set up and maintain all this stuff. Devs could just... develop software, with a clear view into how their apps run at scale. And Ops wouldn't have to custom-integrate 100 different services.

This is really the future of distributed parallel computing, but we're still just bolting it on rather than baking it in.

Re: The Service Mesh: What Engineers Need to Know

#38

Post by jayd16 »

phlakaton wrote: post #35
jayd16 wrote: post #23

Earlier quoted context omitted.

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 would say it's even a bit more pessimistic than that: it's the assumption that the application _can't be relied on_ to provide robust logic around connecting to a remote service. You can address that problem in a library or in an intermediary service of some sort, but in an organization with a heterogeneous collection of languages, versions, and stacks, the library solution becomes expensive. I'm not sure what you…

I'm talking about using HAProxy as a local reverse proxy instead of a remote elastic load balancer. So I guess we're back to it.

Re: The Service Mesh: What Engineers Need to Know

#40

Post by snupples »

lycidas wrote: post #36

At my company, we were migrating all our apps to a kubernetes + istio platform over the past couple of months and my advice is this - don't use a service mesh unless you really, really need to. We initially choose istio because it seemed to satisfy all our requirements and more - mTLS, sidecar authz, etc - but configuring it turned out to be a huge pain. Things like crafting a non-superadmin pod security policy for i…

I would go as far as to say I think the vast majority of people don't need a specialized service mesh. We unfortunately started with Linkerd and it actually is the cause of most reliability/troubleshooting issues. I don't think lack of complexity is actually a good selling point for it, because it's inherently more complex that not using a service mesh.

Istio may appear more complex but that's because it has a superior abstraction model and supports greater flexibility. We're beginning to migrate from Linkerd to Istio at this point. I had the same initial frustrations with podsecuritypolicy (and linkerd suffers from the same), but istio-cni solves the superuser problem, and I believe even the istio control plane is now much more locked down in the latest release.

However if I had my way I would be telling every team they don't need service mesh. We don't have any particular service large and complex enough to really take advantage of its sold features.

Post reply on HN