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

21–30 of 50 posts

Re: Service mesh use cases (2020)

#21

Post by dasil003 »

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?

It’s 100% a question of scale. And I don’t mean throughput, I mean domain and business logic complexity that requires an army of engineers.

Just as it’s foolish to create dozens of services if you have a 10-person team, you don’t really get much out of a service mesh if you only have a handful of services and not feeling the pain with your traditional tooling.

But once you get to large scale with convoluted business logic that is hard to reason about because so many teams are involved, the search for scalable abstractions begin. Service mesh then becomes useful because it is completely orthogonal to biz logic and you can now add engineers 100% focused on tooling and operations, and product engineers can think a lot less about certain classes of reliability and security concerns.

Of course in todays era of resume driven development, and the huge comp paid by FAANGs, you are going to get a ton of young devs pushing for service mesh way before it makes sense. I can’t say I blame them, but keep your wits about you!

Re: Service mesh use cases (2020)

#22

Post by peteradio »

dasil003 wrote: post #21
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?

It’s 100% a question of scale. And I don’t mean throughput, I mean domain and business logic complexity that requires an army of engineers. Just as it’s foolish to create dozens of services if you have a 10-person team, you don’t really get much out of a service mesh if you only have a handful of services and not feeling the pain with your traditional tooling. But once you get to large scale with convoluted business…

If you can convince your business folks to run shit on the command-line then there is basically no need for services ever. I know it sounds insane but its how it was done in the old days and there really is only a false barrier to doing it again.

Re: Service mesh use cases (2020)

#25

Post by remram »

MoOmer wrote: post #8
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?

Many of the use cases described in the post are solved by service meshes. So, in my opinion, the questions are introspective: - “Do I have enough context to know what problem those solutions are solving, and to at least appreciate the problem space to understand why someone may solve it like this?” - “Do I have or perceive those problem to impact my infrastructure/applications?” - “Does the solution offered by the us…

It is true that a lot of those use cases are covered by "basic" Kubernetes (or Nomad) without the addition of Istio or similar, e.g. service discovery, load-balancing, circuit-breaking, autoscaling, blue-green, isolation, health checking...

Adding a service mesh onto Kubernetes seems to bring a lot of complexity for a few benefits (80% of the effort for the last 20% sort of deal).

Re: Service mesh use cases (2020)

#26

Post by steviesands »

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

Earlier quoted context omitted.

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?

API gateways are primarily used for HTTP traffic coming from clients external to your backend services eg. an iOS device (hence the term 'gateway' vs. 'mesh'). I don't think they support thrift or grpc (at least aws doesn't, not sure about other providers). https://aws.amazon.com/api-gateway/

Re: Service mesh use cases (2020)

#27

Post by emptysea »

peteradio wrote: post #22
dasil003 wrote: post #21

Earlier quoted context omitted.

It’s 100% a question of scale. And I don’t mean throughput, I mean domain and business logic complexity that requires an army of engineers. Just as it’s foolish to create dozens of services if you have a 10-person team, you don’t really get much out of a service mesh if you only have a handful of services and not feeling the pain with your traditional tooling. But once you get to large scale with convoluted business…

If you can convince your business folks to run shit on the command-line then there is basically no need for services ever. I know it sounds insane but its how it was done in the old days and there really is only a false barrier to doing it again.

Place I worked had support staff copy-pasting mongo queries from google docs -- worked in the early days but eventually you have to start building an admin interface for more complicated processes

When it was just mongo installs are easy since they only needed a mongo desktop client

Re: Service mesh use cases (2020)

#28

Post by campbel »

remram wrote: post #25
MoOmer wrote: post #8

Earlier quoted context omitted.

Many of the use cases described in the post are solved by service meshes. So, in my opinion, the questions are introspective: - “Do I have enough context to know what problem those solutions are solving, and to at least appreciate the problem space to understand why someone may solve it like this?” - “Do I have or perceive those problem to impact my infrastructure/applications?” - “Does the solution offered by the us…

It is true that a lot of those use cases are covered by "basic" Kubernetes (or Nomad) without the addition of Istio or similar, e.g. service discovery, load-balancing, circuit-breaking, autoscaling, blue-green, isolation, health checking... Adding a service mesh onto Kubernetes seems to bring a lot of complexity for a few benefits (80% of the effort for the last 20% sort of deal).

> Adding a service mesh onto Kubernetes seems to bring a lot of complexity for a few benefits

I think the benefits are magnified in larger organizations or where operators and devs are not the same people. And the complexity is relative to which solution you pick. If you're already on Kubernetes, linkerd2 is relatively easy to install and manage; is that worth it? To me it has been in the past.

Re: Service mesh use cases (2020)

#29

Post by samsquire »

gnur wrote: post #14
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.

I keep hearing about NATS but I am yet to use it leisurely or for work.

Thanks for the recommendation :-)

Re: Service mesh use cases (2020)

#30

Post by pbalau »

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

Earlier quoted context omitted.

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?

That can work, but it means you simply outsourced the problem to AWS. It's not a bad idea per se, but it means your service needs to talk, in some way, http.

You could use the service mesh thing from AWS, along with cognito jwts, for authenticatetion and authorization

Post reply on HN