Operations | Monitoring | ITSM | DevOps | Cloud

This is the story of how I used Honeycomb to troubleshoot redis/redis-rb#924 and discovered a surprising workaround.

Dark is a programming language and platform that enables building serverless backends. There’s no infra, framework or deployment nightmares. It’s a new paradigm in software delivery. As a startup, the Dark team is constantly making decisions about where to invest in improvements to support customer needs. With Honeycomb, they can observe user behavior and make business decisions based on meaningful data.

The most successful software development movement of my lifetime is probably test-driven development or TDD. With TDD, requirements are turned into very specific test cases, then the code is improved so the tests pass. You know it, you probably use it; and this practice has helped our entire industry level up at code quality. But it’s time to take a step beyond TDD in order to write better software that actually runs well in production. That step is observability driven development.

Practicing observability isn’t just about tools. It also means improving how you work together and how you share lessons across the team. Learning from each other helps everyone on your team become better engineers that can create amazing experiences with code, or that make code work at incredible scale (or both!). Writing software and operating it in production is—and must be—a team sport.

Pretty much every organization of any size is paying close attention to the adoption of security practices in order to manage and protect their most sensitive data, including personal identifiable information (PII), personal health information (PHI), or other customer and financial data. For any team using SaaS tools, data protection is a table-stakes requirement. For compliance regulated industries — banking, financial services, healthcare.

I’ve tackled this question before: how much should my observability stack cost? While the things in that post are true now as ever, I did end on one somewhat vague conclusion. When it came to figuring out exactly what you need in your stack by drawing a straight line from the business case to the money you spend, my conclusion was that “it depends.” That’s how we approached pricing at Honeycomb: it depends on your needs, so we should give you many different options.

At Honeycomb, we’ve been listening to your feedback. You want easier ways to predict usage and scale your observability spend with your business. What would it look like to meet you where you already are, using similar terms, and give you more control with a simpler experience? We think that means reimagining the customer experience into one that centers around an event-based model. But what exactly is an event? What does that mean for your team’s observability journey?