Thread by @mattklein123

A thread on "service meshes" and distributed system software complexity in general. Buckle up!

Our industry tends to fetishize the technical architectures of companies like Google, Netflix, etc. They have built some impressive tech to solve rare scaling issues, so this is not surprising. However, does your company/system need similar solutions? Probably not...

The backlash against service mesh, K8S, and other ☁️ native tech is based, reasonably IMO, on the view that vendor marketing and big tech thought-leading are causing smaller orgs to not see the forest for the trees and adopt solutions that are too complex for their actual needs.

If you have a new/small distributed system:
✔️ Monolith
✔️ Untyped language/API, go wild
✔️ Monorepo, why not
✔️ ☁️ FaaS, yes please
✔️ MongoDB? Web scale
✖️ Service mesh
✖️ K8S
✖️ Anything else that anyone thought-leads about on here.

Focus on creating customer value and keep things as simple and boring as possible for as long as possible.

BUT, if you are lucky enough to find success, your development team will grow, you will end up moving to SoA, and then the 💩 will hit the fan:

- Untyped languages and APIs won't feel so productive anymore.
- That monorepo? Don't even get me started.
- Today's state of the art FaaS is not going to cut it in terms of reliability, obs, networking, etc.
- You WILL start feeling the SoA networking/obs pain.

At this point, the "service mesh" is coming for you one way or the other because the problems of obs, load balancing, service discovery, consistent timeouts, retries, etc. must be solved or your SoA is DOA.

Are you an all Java shop? Finagle or Hystrix are great choices. Are you an all Go shop? Try something like Micro. Are you polyglot? You can either plow a ⛰️ of resources into custom libraries in every language, or you can embrace the sidecar. Solutions must be found.

But remember, VERY few companies get here. Make damn sure you need the networking complexity you are about to take on, because no matter what the vendors/conferences tell you, there will be pain, and nothing comes for free.

Is it always going to be this way? I don't think so. I actually think we are in a bridge period in which the average engineer has to directly interact with technologies like Envoy and K8S to succeed at SoA.

I am a firm believer that in the 10 year timeframe, FaaS is all anyone will interact with. If I am a developer I want to provide code that:
- R/Ws from the DB
- Calls APIs
- Queues/deques jobs

That's about it. Everything else is noise.

In that vein, I think that in a ☁️ FaaS world that is stable enough to run Google, technologies like K8S, Envoy, "service meshes," etc. will be everywhere, but almost no one will know they are there. It's all plumbing. No one cares about plumbing.

Until that day comes, a large scale SoA *will* require implementing a "service mesh," one way or the other. Don't let anyone tell you otherwise, and don't buy into marketing and tech envy that pushes you to build one before it's required. end/