The service mesh era: Using Istio and Stackdriver to build an SRE service (opens in new tab)

OpenCensus seems like it's really a Google-only project. OpenTracing and OpenMetrics appear to have more community and vendor engagement.

E.G. Datadog is basing their newer tracing libraries on OpenTracing, and Prometheus devs are behind OpenMetrics.

Never happen. That might further reveal how absurd their pricing is.

Distributed tracing requires instrumentation / app modification (for header forwarding if nothing else), but metrics don't.

E.g. Linkerd gives you service "golden metrics" (success rate, latency distribution, request volumes) without any app changes. It can draw the service topology too, since it's observing everything in realtime. https://linkerd.io/2/features/telemetry/

There is magic, (caveat: I work here), but Instana (https://instana.com) will instrument most major languages and frameworks auto-magically. As in, I don't have to declare a dependency, change a configuration, or anything - our agent finds processes running on the system and bootstraps the libraries while running and monkey patches a huge number of standard libraries and frameworks with no restarts. (don't believe me, give the trial a shot)

There is literally nothing else quite like it in the market, and it gives you distributed tracing, automatic metric collection, and pre-defined alerts for a reasonable price.

https://docs.instana.io/core_concepts/tracing/#supported-tec...

The Istio project is not supposed to be tied to Kubernetes. It is supposed to be a general-purpose service mesh.

That being said, I have been looking for a while and I can't find anyone who uses it in production on a platform other than Kubernetes.

So kubernetes seems to be one of Googles biggest efforts at really building a healthy open source project for Borg v2. Perhaps they wanted it to be mostly community driven? It’s for this reason that they collaborated with others to introduce ISTIO so the community doesn’t feel like Google is taking over or whatever fears a lot of OSS folks have of the company.

Google's a big place.

The main pain point at the moment is that meshes were written for containerized environments first, and attempts to extend full functionality to other environments are pretty immature at the moment.

Meshes are a lot more than just sidecar proxying -- they are what make sidecar proxying manageable, and they add a lot of other features like authentication, network policies, various other traffic control policies, service discovery, etc. They are an attempt to do for service-to-service communication what Kubernetes has done for container deployment -- make it abstract and declarative, with configurations that are independent from the underlying implementation.

The underlying implementation that works right now is the Kubernetes API and etcd, and alternate implementations need to be provided for those features to work well outside of Kubernetes. I think it will happen sometime in the next few years.

Meshes are there to abstract away stuff that is much more manageable in a monolith. If you have 100 microservices implemented using 5 different platforms you need libraries and programming discipline to implement retries with backoffs, circuit breakers, health checks, tracing, service discovery and other similar stuff in every single one of them.

In a monolith you need to implement some of this stuff only once and you don't need a lot of it at all because you are not making remote procedure calls.

If your monolith interacts with many other monoliths, service meshes might be useful. If not, maybe not so much.