All of the business of software, but especially the delivery of product capabilities, is inextricably bound up in questions about time. What’s the estimate? If we have N people working on it, how long will it take? When will we ship?
Stand-up meetings. Is anyone happy with them at this point? They were supposed to help teams work in a more agile manner but they were already controversial in the before times and moving to fully distributed teams hasn’t made things any better. The same old habits, the same tired questions. There must be something better, right? We began meandering syncs to replace stand-ups as an experiment at Honeycomb, but loved the results so much that we have adopted it across the engineering org.
Today, we announced that Honeycomb has raised $50M in Series C funding, in a round led by Insight Partners and joined by all existing investors from our Series B. We’re using this investment to support the growth of our customers and community, ensure the benefits of observability can be realized by all engineering teams, and expand the ways we can better serve you.
You might already know that OpenTelemetry is the future of instrumentation. It’s an open-source and vendor-neutral instrumentation framework that frees you from the trap of using proprietary libraries simply to understand how your code is behaving. Best of all, you can instrument your applications just once and then take that instrumentation to any other backend system of your choice. This blog shows you exactly how to use OpenTelemetry to ✨break the vendor lock-in cycle.✨
As product developers, our responsibility continues beyond shipping code. To keep our software running, we need to notice whether it’s working in production. To make our product smoother and more reliable, we need to understand how it’s working in production. We can do this by making the software tell us what we need to know. How can we notice when the software is running smoothly? Make it tell us!
In my previous post, we explored why Honeycomb is implemented as a distributed column store. Just as interesting to consider, though, is why Honeycomb is not implemented in other ways. So in this post, we’re going to dive into the topic of time series databases (TSDBs) and why Honeycomb couldn’t be limited to a TSDB implementation. If you’ve used a traditional metrics dashboard, you’ve used a time series database.
In the recent past, most engineering teams had a vague notion of what Service Level Agreements (SLAs) and Service Level Objectives (SLOs) were—mainly things that their more business-focused colleagues talked about at length during contract negotiations. The success or failure of SLAs were tallied via magic calculations (what is “available” anyway?!) at the end of the month or quarter, and adjustments were made in the form of credits or celebrations in the break room.
The Query Data API is a Honeycomb Enterprise feature. With a Honeycomb Enterprise account, you can use this API today. Head over to our API docs to learn how to get access to your data. If you aren’t yet a Honeycomb Enterprise user, try it out by requesting an Enterprise Trial. Starting today, Honeycomb Enterprise customers can use the Honeycomb Query Data API to programmatically run queries and retrieve their results, and pull query results into any data visualization tool of their choice.
Ever since the very beginning, Honeycomb has poured a lot of heart and soul into our blog. We take pride in knowing it isn’t just your typical stream of feature updates and marketing promotions, but rather real, meaty pieces of technical depth, practical how-to guides, highly detailed retrospectives, and techno-philosophical pieces. One of my favorite things is when people who aren’t customers tell me how much they love our blog.
