[scraegg]

If you see an airplane that flies you might conclude airplanes are a good transportation pattern. But if you see there's a boat, that promises to fly, and you see that people taped a lot of helicopters onto it to make it fly, then probably you would conclude that boats are bad at flying.

Message Brokers are the airplanes. Even if you can't understand how they work you will see that many companies use them who really rely on distributed systems working, eg telephone companies, banks, trading companies.

Service Meshes try to solve a problem that K8s was meant to solve in the first place. So K8s is the boat and Service Mesh is the attached helicopter. By itself it might be a good idea to use it, but the way things are taped together right now it's just an anti-pattern.

If you don't have a pointy-haired boss forcing you to use it, then it's probably better to avoid the whole thing.

I'd rather see how far the development around k8s-less pods with podman will go and take care of the distributed architecture of my systems myself.

[geggam]

These layers of abstraction are nice but they seem to ignore the fact you still have to manage the systems underneath and the networking around it.

At some point folks need to realize they arent google and they really dont need to abstract the development layer because they dont have a team of google SRE to manage what their pods / containers / mesh runs on

[solipsism]

This is a strange answer. A message broker is not in the same category as Istio. Istio is for effecting policy changes (regarding security, traffic routing, monitoring, etc) without updating your code. Which is especially useful if your code is a bunch of diverse microservices.

Message brokers are... not that.

These are apples and elephants you're comparing.

[pm90]

Kubernetes is a platform, it lets you do whatever the f you want to. Service meshes are one thing to build on top of the platform.

[scraegg]

You can do what you want even without k8s.

The reason to use a tool is to make a task simpler or take a task out of your hands in most cases but the rare edge case. For instance grep makes it easier to go to a file to find a certain line.

If you need to know networking, storage, microservice architecture yourself you don't need any tools.

In k8s you need to know all this, and on top you need to know k8s to achieve the same thing. And then you either need to write k8s plugins or also additionally know all the k8s plugins and wether any of them will actually solve the problem you have.

[sigmonsays]

this isn't a good analogy. message brokers by design are asynchronous and dont have a typical request/response flow of http.