Service mesh solutions like Istio and Linkerd are gaining a lot of traction in the industry. However, it seems to me like they are predicated on what I always though was a microservices antipattern i.e. a synchronous chain of microservices calling each other (as opposed to the prescribed "right way" i.e. all inter-service communication is asynchronous through some sort of messaging). I am hesitant to outright dismiss them looking at the hype and adoption. What am I missing here, are they just helping people make their mistakes more easily?
Ask HN: Are Service Meshes an Antipattern?
1–6 of 6 posts
Re: Ask HN: Are Service Meshes an Antipattern?
#2Most of the ideas of the service mesh came from Netflix. You should watch the orignal netflix lectures.
You are confusing the enterprise service bus architecture and micro service architecture.
Async architecture is not always the right answer. If you need it, than the recommended architecture is to use a center event log (i.e. kafka) and feed all the services from it.
Re: Ask HN: Are Service Meshes an Antipattern?
#3Because every system that needs to return a response within N ms (which is pretty much every app, service, API call, etc) ends up being implemented with synchronous calls, with messaging only used for truly offline bits. There's a good writeup of why here: https://programmingisterrible.com/post/162346490883/how-do-y... , with this great quote: "In practice, a message broker is a service that transforms network errors and machine failures into filled disks".
(I used to work at Twitter, which went through this same transformation, but if you watch tech talks from pretty much any other modern company that it building a big distributed system, you'll see the same pattern.)
Re: Ask HN: Are Service Meshes an Antipattern?
#4Because every system that needs to return a response within N ms (which is pretty much every app, service, API call, etc) ends up being implemented with synchronous calls, with messaging only used for truly offline bits. There's a good writeup of why here: https://programmingisterrible.com/post/162346490883/how-do-y... , with this great quote: "In practice, a message broker is a service that transforms network errors…
Are we then paying the price in latency and added hops for development agility? I would have guessed a user request would never be subjected to that. With a mesh, don't you get even more latency because of the sidecar? The link you provided looks interesting; will give it a read, thanks!
Re: Ask HN: Are Service Meshes an Antipattern?
#5Because every system that needs to return a response within N ms (which is pretty much every app, service, API call, etc) ends up being implemented with synchronous calls, with messaging only used for truly offline bits. There's a good writeup of why here: https://programmingisterrible.com/post/162346490883/how-do-y... , with this great quote: "In practice, a message broker is a service that transforms network errors…
Are we then paying the price in latency and added hops for development agility? I would have guessed a user request would never be subjected to that. With a mesh, don't you get even more latency because of the sidecar? The link you provided looks interesting; will give it a read, thanks!
Yes, you pay a latency and resource cost to have the service mesh features decoupled from the application code. Same with any abstraction e.g. containers or Kubernetes.
You could alternatively get service mesh features in the application layer with libraries like Finagle, Hysterix, etc, and not pay that cost. But then you're tied to particular languages, and changing platform features requires making code changes.
It's a tradeoff. I talked about this at Kubecon earlier this year: https://www.youtube.com/watch?v=Z3nfLI3z0hc#t=4m58
Re: Ask HN: Are Service Meshes an Antipattern?
#6Earlier quoted context omitted.
Are we then paying the price in latency and added hops for development agility? I would have guessed a user request would never be subjected to that. With a mesh, don't you get even more latency because of the sidecar? The link you provided looks interesting; will give it a read, thanks!
Yes, you pay a latency and resource cost to have the service mesh features decoupled from the application code. Same with any abstraction e.g. containers or Kubernetes. You could alternatively get service mesh features in the application layer with libraries like Finagle, Hysterix, etc, and not pay that cost. But then you're tied to particular languages, and changing platform features requires making code changes. It…
That was a great talk, thanks for sharing. I guess it all makes sense once you have bought into having synchronous dependencies between microservices - which is the part I was struggling with. But I guess if that is what you have to do, that is what you have to do.