The software industry is moving toward teams that own the services they build. This concept encloses principles and possibilities from movements toward microservices, DevOps, Agile, and Project to Product. In these paradigms, a team of people delivers software that provides valued capabilities. These capabilities help customers get their work done, support business operations, or enable other software to do these.
At its core, observability is understanding the internal state of your systems based on the telemetry they output so you can effectively troubleshoot, debug, and tune performance. However, there’s a tendency to reduce observability to a collection of logs, metrics, and traces, which strips away much of the visibility you need to understand what’s going on.
I've never been on call before, and I'm not sure what to expect, or how I can best prepare for it. Will I need to upend my life just in case the pager goes off? And how should I best cope with getting paged? I've read Charity's piece on the opposite problem of wanting to stop being on call, but it didn't quite answer my question.
I’m Phillip, a product manager here at Honeycomb. After eleven-ish months of working on our product, I totally understand observability, right? ...Kinda? Sorta? Maybe? I'm not sure—but, I have been sitting in this space long enough to be a little better than clueless. Here's my guide on the topic. I hope it helps, especially if you’re passionate about exploring alternative ways you or your team can manage today’s cloud-native applications.
Honeycomb ruffled the first of many feathers nearly seven years ago when we coined the term “observability” in talking about production code. Today, we get to celebrate a major victory in our push for the term to break free from its unsuitable parent category, Application Performance Monitoring (APM).
I use .NET and I keep seeing something called `Activity` but in OpenTelemetry there is only talk about “Span” and “Trace,” why? And what should I be using? This is understandable, and has caused confusion since that decision was made by Microsoft back in 2018/19 (I believe). I’ll do my best to provide some guidance on what the distinction is, and also when each is useful.
What's the first small thing to do in o11y that would teach me something, bring something valuable, and open the way for something else? Observability doesn’t have to be a big, company-wide project. It can be useful locally and individually. A little playing around can get you some crucial insight into how your software works. Try it as a team, or in a pair, or by yourself. It takes 3 steps: Step 1 is easy. The other two might take ten minutes, or maybe more like a day.
In March, we announced official support for a Honeycomb Terraform Provider. Today, we’re announcing additional support for managing Honeycomb Service Level Objectives (SLOs) with Terraform. This furthers Honeycomb’s support for configuration as code and it gives you programmatic control for an immensely popular Honeycomb feature.
It has been seven years since Rent the Runway posted their engineering ladder, kicking off a veritable trend of engineering teams open sourcing their ladders. Interestingly, nearly all of them seem to have coalesced around “area of scope” as a useful proxy for level. At first glance, “area of scope” does seem to make sense. Senior engineers should be able to work across larger areas of the organization. In addition, your area of influence should expand as you gain experience.
If you have an on-call rotation, you want it to be a healthy one. But this is sort of hard to measure because it has very abstract qualities to it. For example, are you feeling burnt out? Does it feel like you’re supported properly? Is there a sense of impending doom? Do you think everything is under control? Is it clashing with your own private life? Do you feel adequately equipped to deal with the challenges you may be asked to meet? Is there enough room given to recover after incidents?
