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

Service mesh use cases (2020)

lucperkins.dev

Post reply on HN
Print view View original

11–20 of 50 posts

Re: Service mesh use cases (2020)

#11

Post by jagged-chisel »

Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

Most of my programming peers want to focus on solving product-related problems rather than authe, authn, tls config, failover, throttling, discovery…

We want to automate everything not related to the code we want to write. Service meshes sound like a good way to do that.

Re: Service mesh use cases (2020)

#12

Post by jpdb »

I just wrote something extremely similar, but it's only internal right now.

I personally find that the service mesh value-prop is hard to justify for a serverless stack (mostly Cloud Run, but AWS Lambda too probably), and in situations where your services are mostly all in the same language and you can bake the features into libraries that are much easier to import.

Observability is a great example of this. In serverless-land, you're already getting the standard HTTP metrics (ex request count, response codes, latency, etc), tracing, and standard HTTP request logging "for free."

Re: Service mesh use cases (2020)

#14

Post by gnur »

samsquire wrote: post #3

Thanks for this. I have never deployed a service mesh or used one but I am designing something similar at the code layer. It is designed to route between server components. That is, at the architecture between threads in a multithreaded system. The problem I want to solve is that I want architecture to be trivially easy to change with minimal code changes. This is the promise and allure of enterprise service buses an…

I'd say most of these patterns are supported by NATS, it can do pub/sub but actually also has excellent support for RPC and in the latest iteration it also has a KV store baked in. I've been using it for a few pet projects so far and it has never been the weakest link.

Re: Service mesh use cases (2020)

#15

Post by tyingq »

Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core.

To me, it's a fairly big decision to layer something that's complex in it's own right on top of something else that's also complex.

Re: Service mesh use cases (2020)

#16

Post by darkwater »

NovemberWhiskey wrote: post #4

Now imagine you have something that has the complexity and change volume of a distributed control plane bringing together load-balancing, service advertisement, public key infrastructure, and software defined networking, and then try to imagine running it at the same reliability as your DNS. Also: proxies, proxies everywhere, as far as the eye can see.

This is the production ready part that people will usually discover later on their own skin...

Re: Service mesh use cases (2020)

#17

Post by kevan »

Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

>slightly easier

As a company grows sooner or later most of these features become pretty desirable from an operations perspective. Feature developers likely don't and shouldn't need to care. It probably starts with things like Auth and basic load balancing. As the company grows to dozens of teams and services then you'll start feeling pain around service discovery and wish you didn't need to implement yet another custom auth scheme to integrate with another department's service.

After a few retry storm outages people will start paying more attention to load shedding, autoscaling, circuit breakers, rate limiting.

More mature companies or ones with compliance obligations start thinking about zero-trust, TLS everywhere, auditing, and centralized telemetry.

Is there complexity? Absolutely. Is it worth it? That depends where your company is in its lifecycle. Sometimes yes, other times you're probably better off just building things and living with the fact that your load shedding strategy is "just tip over".

Re: Service mesh use cases (2020)

#18

Post by jpdb »

tyingq wrote: post #15
Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core. To me, it's a fairly big decision to layer something that's complex in it's own right on top of something else that's also complex.

> I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core

I'm not so sure. I suspect it'll follow the same roadmap as Gateway API, which it already kind of is with the Service Mesh Interface (https://smi-spec.io/)

Re: Service mesh use cases (2020)

#19

Post by Scubabear68 »

jagged-chisel wrote: post #11
Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

Most of my programming peers want to focus on solving product-related problems rather than authe, authn, tls config, failover, throttling, discovery… We want to automate everything not related to the code we want to write. Service meshes sound like a good way to do that.

Right - by why not use something like an API gateway then?
Post reply on HN