The service mesh era: Using Istio and Stackdriver to build an SRE service
1–10 of 33 posts
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#2Zero 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
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#3What the utter shit is an SRE service?
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#4I 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.
They also seriously need to give CloudWatch a UI/UX overhaul.
1. https://opencensus.io/introduction/#partners-contributors
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#5I 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. They also seriously need to give CloudWatch a UI/UX overhaul. 1. https://opencensus.io/introduction/#partners-contributors
Never happen. That might further reveal how absurd their pricing is.
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#6Zero 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
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...
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#7I 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. They also seriously need to give CloudWatch a UI/UX overhaul. 1. https://opencensus.io/introduction/#partners-contributors
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.
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#8I would interested in anyones feedback of embracing and rolling out a service mesh/Istio in a non-GCP environment.
I apologize if this is a naive question but how come this wasn't included as part of the Kubernetes project given that it has the same Google origins?
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#9Zero 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
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…
That sounds horrific for whoever is going to be supporting that system...
The last thing I would want in a production environment is to have some 3rd party software monkey-patching the code at runtime.
What happens when: - a bug only occurs (due to timing or some other extremely subtle issue) when this monkey-patching is applied. - there's a bug in the monkey-patching itself (sounds like a fun debugging session!) - a library is accidentally monkey-patched with a slightly different version, or falsely detected as a known library (maybe it is a fork)
Give me statically compiled, reproducible, dependency free, bit-for-bit identical with what has been thoroughly tested in CI, musl binaries any day. That's how you avoid getting woken up at 4am.
This kind of magic should happen at compile time, if at all.
Re: The service mesh era: Using Istio and Stackdriver to build an SRE service
#10n00b question, I always see service meshes used in the context of containers and mostly with kube. Would they work with more monolithic/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't exist in containerized architectures?