Operations | Monitoring | ITSM | DevOps | Cloud

Growing pains can be a natural consequence of meteoric success. We were reminded of that in our recent panel discussion with SumUp’s observability engineering lead, Blake Irvin, and senior software engineer Matouš Dzivjak. They shared how SumUp’s rapid growth spurt compelled them to change their resolution process—both logistically and culturally—to ensure a service level quality that reflects their customer obsession.

In today's digital landscape, organizations rely on software applications to meet the demands of their customers. To ensure the performance and reliability of these applications, observability pipelines play a crucial role. These pipelines gather, process, and analyze real-time data on software system behavior, helping organizations detect and solve issues before they become more significant problems. The result is a data-driven decision-making process that provides a competitive edge.

As an open source company that grew out of a side project in 2008 to an application and performance monitoring platform (APM) used by over 3.5 million developers, Sentry is committed to open source and the community of developers maintaining and building in the open. Similarly, we take a public approach to building our software, which is why it’s a natural extension of our values to announce our support for OpenTelemetry (or OTel), the leading open standard for observability.

When I joined Honeycomb two years ago, we were entering a phase of growth where we could no longer expect to have the time to prevent or fix all issues before things got bad. All the early parts of the system needed to scale, but we would not have the bandwidth to tackle some of them graciously. We’d have to choose some fires to fight, and some to let burn.

For a long time at Honeycomb, we envisioned using the tracing data you send us to generate a service map. If you’re unfamiliar, a service map is a graph-like visualization of your system architecture that shows all of its components and dependencies. We didn’t want it to be a static service map, though—the kind you’d view once before going “huh, neat”—and then never looking at it again.