The service mesh era: Using Istio and Stackdriver to build an SRE service

I am still praying that some day soon AWS will announce that they are joining Opencensus (along with Google, MS, Datadog, Prometheus)[1] in the hopes that we can move towards standard tooling for observability.<p>They also seriously need to give CloudWatch a UI&#x2F;UX overhaul.<p>1. <a href="https:&#x2F;&#x2F;opencensus.io&#x2F;introduction&#x2F;#partners-contributors" rel="nofollow">https:&#x2F;&#x2F;opencensus.io&#x2F;introduction&#x2F;#partners-contributors</a>

Zero instrumentation visibility with the service mesh, but the demo app is instrumented. I’ve seen this point being sold everywhere for service mesh, but the vanilla tracing data given by Istio or others is not that useful by itself. There is no magic, you need to instrument your code

SRE service. Not any kind of service - an SRE service!<p>Can we please stop the buzzword train?

I would interested in anyones feedback of embracing and rolling out a service mesh&#x2F;Istio in a non-GCP environment.<p>I apologize if this is a naive question but how come this wasn&#x27;t included as part of the Kubernetes project given that it has the same Google origins?

n00b question, I always see service meshes used in the context of containers and mostly with kube. Would they work with more monolithic&#x2F;traditional n-tier architecture deployed directly on host OS as well? Or maybe put another way, are there likely to be pain points that don&#x27;t exist in containerized architectures?