2 ms·
It’s a pity “fat clients” are dismissed so quickly. I think that when your tech stack is uniform enough to use them, they can provide much more that service mes
by theamk 7y ago
It’s a pity “fat clients” are dismissed so quickly. I think that when your tech stack is uniform enough to use them, they can provide much more that service meshes, and do it faster as well. After all, why does “service is down” and “service is sending nonsense” have to be handled via completely different paths?
- omeze 7y agoThe main problem with fat clients is that for polyglot architectures (which most large companies that end up building a service mesh evolve into over time) you have to maintain a fat client library for every language. You can get very far leveraging existing tools like gRPC that codegens fatty clients for you but the quality of tooling is very uneven depending on the language of choice. By pushing all of this into the network layer you skip all of that.
- theamk 7y agoRight, polyglot architectures have no choice, but this text talks about “5 person startups” as well. Surely they can keep the set of languages limited? Plus, it’s not either/or situation. A fat clients for Go + Node.js; and a proxy for all others. This way your core logic can enjoy increased introspection / more speed / higher reliability; while special purpose services get a proxy which allow interoperability.