Service mesh looks like an evolution of Enterprise Service Bus and has similar focus. An ESB is a single point of failure. Since it’s a combination of many concerns, it can be hard to get right. A service mesh tries to mitigate this by focus mainly on HTTP, HTTP2 style communication and being distributed as a deployment (each service has it’s own copy of the mesh software).
A service mesh starts to look really attractive once you start get into something like hundreds of services written by several teams. For fewer services it might introduce unnecessary operations overhead. This should be similar to recommendations around ESB. This should also be depending on if your service provider makes it easy to enable such a service. Using a service mesh also looks more attractive than using ESB since some of the issues are mitigated.
If you have mostly things hosted on one type of web server/service host, then collection of web server logging might be enough to satisfy the observability requirement. For instance when your hosting provider makes it easy to enable HTTP log collection. Going towards more dockerized services shifts your needs (as you do not have as homogeneous environment).
The security requirement could also be satisfied by decent middleware. Many HTTP frameworks have JWT support. Your hosting provider could let you enable let’s encrypt for sites.
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.
Comments