If there’s one thing folks working in internet services love saying, it’s: "Yeah, sure, but that won’t scale." It’s an easy complaint to make, but in this post, we’ll walk through building a service using an approach that doesn’t scale in order to learn more about the problem. (And in the process, discovering that it actually did scale much longer than one would expect.)
Rich Anakor, chief solutions architect at Vanguard, is on a small team with a big goal: Give Vanguard customers a better experience by enabling internal engineering teams to better understand their massively complex production environment—and to do that quickly across the entire organization, in the notoriously slow-moving financial services industry. They also had a big problem: The production environment itself.
This is the second post in our series about Lattice, Honeycomb’s new design system and how we’re applying a user-centric design philosophy to our product. Lattice begin! At Honeycomb, we understand that our users are often under a great deal of pressure when troubleshooting complicated issues in their applications.
Slack experienced meteoric growth between 2017 and 2020—but that level of growth came with growing pains. In his talk at the 2021 o11ycon+hnycon, Frank Chen (LinkedIn), a Slack Senior Staff Engineer, detailed one of Slack’s biggest pain points in that period: flaky tests. A flaky test returns both a passing and failing result despite no changes in the code. At one point, between 2017 and 2020, Slack’s flaky test rate reached as high as 50%.
Modern software services are expected to be highly available, and running a service with minimal interruptions requires a certain amount of reliability-focused engineering work. At the same time, teams also need to build new features and improve existing ones, so that users are delighted and don’t churn.
You might have noticed some visual changes happening in Honeycomb lately. Colors, typography, icons, and some features have started to look a bit different. While these changes are just beginning to make their way into the product, we’ve been working on them for some time. Let’s look at what has been going on behind the scenes to make them happen.
But it’s better than nothing… Most of the industry is racing to adopt better observability practices, and they’re discovering lots of power in being able to see and measure what their systems are doing. High data availability is better than none, so for the time being, what we get is often impressive. There’s a qualitative difference between observability and data availability, and this post aims to highlight it and orient how we structure our telemetry.
Today, we released our second annual Observability Maturity Community Research Findings report. This year-over-year report identifies trends occurring in the observability community that we use to further develop our Observability Maturity Model. Our goal in running this annual report is to understand community perceptions and awareness of observability, how engineering teams are approaching observability, and mapping an observability maturity model that reflects current research findings.
Today at o11ycon+hnycon—right now, actually, if you’re reading this blog when it was posted—we’re announcing several new Honeycomb features during the keynote. Our industry and community have come a long way since we burst onto the scene, and I’m delighted to give you another version of Honeycomb that continues to demonstrate what’s possible with observability. And it includes metrics.
With the Honeycomb extension for AWS Lambda, you no longer need to make your Lambda functions Honeycomb-aware. Today, AWS announced the general availability of AWS Lambda Extensions, which make it easy for us to send logs from your Lambda functions directly to Honeycomb. In October, we announced Honeycomb’s extension for AWS Lambda as part of a preview launch. Today, we’re pleased to announce everyone can now use this extension to easily debug their AWS Lambda functions with Honeycomb.
