I understand what the author is saying, but vendor lock-in with closed-source observability platforms is a significant challenge, especially for large organizations. When you instrument hundreds or thousands of applications with a specific tool, like the Datadog Agent, disentangling from that tool becomes nearly impossible without a massive investment of engineering time. In the Platform Engineering professional services space, we see this problem frequently. Enterprises are growing tired of big observability platform lock-in, especially when it comes to Datadog's opaque nature of your spend on their products, for example.
One of the promises of OTEL is that it allows organizations to replace vendor-specific agents with OTEL collectors, allowing the flexibility of the end observability platform. When used with an observability pipeline (such as EdgeDelta or Cribl), you can re-process collected telemetry data and send it to another platform, like Splunk, if needed. Consequently, switching from one observability platform to another becomes a bit less of a headache. Ironically, even Splunk recognizes this and has put substantial support behind the OTEL standard.
OTEL is far from perfect, and maybe some of these goals are a bit lofty, but I can say that many large organizations are adopting OTEL for these reasons.
Well said. We lack as a society in holding some degree of empathy for people who are affected differently by situations, experiences, historical context than us.
My employer was a customer of theirs for a few years. Horrible service, our support pushed down in favor of their government contracts, etc. Grapevine says that they do some pretty shady stuff for the gov as well.
That's not necessarily true. Helm is a way to install things, it is not a replacement for an artifact store. Binaries are still required. Besides, not everything can be containerized. In the finance industry that I work in, we do push k8s a lot, but regardless, there are still many things that simply cannot just be pushed to containers without serious re-writes. Artifactory is a lifesaver for us, especially when it comes to handling proxy servers for library repos (npm, nuget, rubygems, etc).
True, however they are worth the price. I used various brands of LED bulbs for a long time (such as Cree), basically whatever Home Depot was selling. The failure rate was extremely high. In 2017 I switched to Philips LED bulbs, and just last night the first one failed. Overall they are worth the extra up front cost, they'll save you money in the long run.
Hadolint will tell about things like adding --no-cache to apk add. My point being that comments were made about not following best practices, and hadolint will help with that.
Speaking of best practices for Dockerfiles and CI/CD, a lot of these issues can be highlighted at build time with a Docker linter like https://github.com/hadolint/hadolint.
I never knew this. I've known several developer who worked for Getty and had a positive experience. Of course that experience has nothing to do with their legal tactics.
This reminds me of a similar case between SparkFun and Fluke from 2014 where Fluke demanded that SparkFun stop selling their own multimeters which had the same colors as the Fluke brand multimeters.
Seattle replaced all streetlights with LEDs a few years back. It too bad that they are the blue lighting that the article mentions, which absolutely makes viewing anything in the sky a lot harder than it already was. I'd love to go back to Flagstaff some day to see the lighting in person.