I see this more as a "smart" client, where you can push routing, load balancing, retry policy, etc. out to the clients instead of enforcing those at your infrastructure edge… which seems great for controlled clients, but not-feasible for public facing use-cases:
* routing rules potentially sensitive architectural
information and expose many different nodes to the
public internet
* a mobile client doesn't generate enough "load" that the
typical use case for load balancing would be used for
* retry & timeout policies seem useful
However, I'm a curmudgeon that doesn't see a huge benefit to a service mesh over a traditional load balancer in the vast majority of applications. Load balancers can offer a lot of the same functionality at scale (thousands of requests per second) and abstract these ideas away from the client, which has more benefit, in my opinion.
I have used smart clients in the past to interface with, what is now being called, a service mesh. For low latency operations that could possibly hit one of thousands of hosts, it worked well… until network fabric changed and hosts were no longer directly accessible. Then operations became increasingly difficult since you had to be on the appropriate network to communicate.
I have used smart clients in the past to interface with, what is now being called, a service mesh. For low latency operations that could possibly hit one of thousands of hosts, it worked well… until network fabric changed and hosts were no longer directly accessible. Then operations became increasingly difficult since you had to be on the appropriate network to communicate.