codereflection

Well, telemetry is defined as logs, metrics, traces... So it kinda makes sense that OTEL supports the major aspects of telemetry.

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.

... and they'll call it "The cost of doing business". Disgusting.

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.

I love pen and paper. My arthritis and carpal tunnel syndrome, however, do not. I miss writing by hand.

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.

Yep

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.

https://www.sparkfun.com/news/1428

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.

I think that's their point, Teams is the 18 button baby outfit.

Related: Jon Skeet blogged about the concept of programming "in" a language vs programming "into" a language back in 2008.

https://codeblog.jonskeet.uk/2008/04/23/programming-quot-in-...

This reminds be a bit of The Morning Brew by Chris Alcock, which has been around since 2007. It's heavily .NET focused though. http://blog.cwa.me.uk/

Similar to Chris Alcock's The Morning Brew, which has been around since 2007. http://blog.cwa.me.uk/

Perhaps a helpful sidebar: This website loads painfully slow.

This reminds me that I should go back and re-read "Don't Make Me Think". So many of these things seem obvious, but only when pointed out.

That's awesome. We have so much customization around TeamCity that moving away from it doesn't make sense, but we're starting to look at the CI runners for other things, along with the k8s integration, all great stuff in GitLab. Yeah, the DevOps name though, it's unfortunate. DevOps is a culture, not a thing, product, tool, or process. Seems more like calling it Auto CI/CD is more appropriate, maybe? Anyways, thanks for the response!

Tangential: Reading this _really_ makes me appreciate the extremely stable system my team has build internally with GitLab and TeamCity. Azure DevOps sounds extremely frustrating (besides the point that I cannot stand the name they gave this product, and GitLab made that same mistake with the Auto DevOps feature name).

On-premise runs pretty much maintenance free. I've be running GitLab for ~5 years on-premise with ~200 developers. The issues have all been minimal, and few, over those years.

Upgrading is super easy these days when you go with their omnibus installer. That handles all of the upgrade tasks for you, even skipping over versions which was not really possible with the source install days of old.

Or be lucky enough to work for a company that provides them for free.

Seattle does this for kids in middle school and high school. Each kid gets an Orca card for free (transit card that we use in the Seattle area). Lots of kids use them, even the kids who travel ~10 miles to get to their school. I know it's saved me a lot of money in gas and bus fare over the years with my kids getting this benefit. The only down side is that the cards are only good for during the school year.

This. We use Rancher within our data center, because configuring and managing k8s is not trivial. Rancher eases a lot of that pain for our small team.

I can relate to that. I spoke with 3 different support agents and got 3 different answers to my problem.

In some alternate universe, we're all using Sears Web Services and no one has heard of Amazon.

Perhaps because David J. Wheeler said "We can solve any problem by introducing an extra level of indirection."