We are all familiar with the "Observability cost crisis". We all know the horror stories of multi-million dollar bill shock and we all know the stats about the cost of observability exceeding the cost of cloud hosting. Vendors have responded to this with a number of solutions offering customers vast scale at low cost or with strategies such as pipelining and sampling. There is, however, a structural alternative that rewrites the rules altogether - BYOC.
Bring Your Own Cloud means retaining telemetry data within your own infrastructure. Rather than piping petabytes of telemetry to a vendor’s cloud, data remains local. The observability system operates as a processing and querying layer, decoupled from data storage. This yields two immediate benefits:
Additionally, BYOC allows organizations to apply consistent observability tooling across all environments. Many businesses can only afford full observability in production, leading to fragmented toolsets and a lack of parity between staging and prod. The cost benefits of BYOC can enable companies to deploy a consistent stack across all environments.
BYOC is not a new concept in IT, and it is not even a new concept in observability - vendors such as Groundcover and Parseable have already blazed a trail in this direction. For this discussion though, we are going to look at how BYOC observability has been re-imagined by Tsuga. In case you’re wondering, Tsuga is the Japanese name for the hemlock tree - which is valued for its medicinal and nutritional properties.
Although Tsuga is a new entrant in the observability space, CEO Gabriel-James Safar and CTO Sébastien Deprez have previously held senior roles at Datadog. The team behind them also boasts other Datadog alumni as well as recruits from big hitters such as Palantir, Cognition and Grafana. So they are a new kid that is no stranger to the observability block.
Tsuga’s architecture comprises two main components:
The in-cloud engine is designed to be lightweight, scalable, and cloud-agnostic. It consists of four core building blocks:
If you work in the Azure cloud, the equivalents would equate to Azure Load Balancer, AKS, Service Bus, and Blob Storage. Other clouds are equally supported, as the architecture is designed to integrate with any CNCF-compliant infrastructure.
This setup is provisioned by Tsuga engineers via infrastructure-as-code (IaC), ensuring consistency, security, and rapid deployment. The Tsuga Control Plane connects securely to your instance using mutual TLS, allowing the centralized UI to monitor and manage observability data without ever ingesting it directly.
The architecture is designed for resilience, with stateless components that can scale independently. Metrics, logs, and traces are collected and processed locally, filtered according to configurable rules, and routed to the appropriate backend for storage and querying.
Tsuga also maintains a dedicated operations control plane to provide remote support, monitor service health, and ensure compliance with SLAs.
A central debate in observability is whether to sample telemetry or store everything. Hyperscale vendors argue for full fidelity - retain every event for compliance and root-cause analysis. Others counter that 80% of telemetry is noise and can be safely discarded.
Tsuga’s position is pragmatic: as telemetry volumes grow exponentially - driven by LLMs, microservices, and automation - even aggressive sampling won't contain the flood. BYOC effectively renders the issue moot by removing vendor-side ingestion costs altogether.
Tsuga’s approach to observability starts with ingestion discipline. Every telemetry stream must be tagged with an ownership key, mapping data to a team. This enforces accountability and enables fine-grained filtering.
Key features of the system include:
The ingestion gateway supports inline transformation using WASM filters, allowing enterprises to shape and validate telemetry before it ever reaches storage. Teams can also define SLIs and SLOs directly in the control plane, helping enforce reliability practices across the organization.
Tsuga doesn’t enforce a single way of working - but it does provide clear guidelines to keep teams aligned.
One of BYOC’s most compelling advantages is composability. Data isn’t locked behind a proprietary API or usage tier. This gives you complete freedom to extract value from your data. You can:
For example, Tsuga includes a built-in integration to spin up a Databricks pipeline, pulling data directly from your S3 backend - enabling deeper analysis without vendor limitations.
BYOC observability, as exemplified by Tsuga, offers a way forward for reining in the juggernaut of runaway telemetry. It decouples data control from vendor dependency, enabling organizations to regain cost control, architectural integrity, and operational coherence.
That said, BYOC is not a universal fit. It requires organisations to feel comfortable with the deployment model. Tsuga takes care of the initial deployment of the cluster in less than two hours, operates the cluster (scale up and down the various services depending on needs) and deploys new versions several times a day, removing the management of the underlying infrastructure
BYOC particularly suits large enterprises, regulated industries, and teams with a strong DevOps culture. It aligns well with zero-trust architectures, privacy-conscious environments, and organizations seeking to eliminate egress costs and avoid vendor lock-in. However, for smaller teams or startups lacking infrastructure resources, traditional SaaS observability may still offer the lowest operational overhead.
As a model for enterprise architecture, BYOC probably still carries with itself an air of the shock of the new. Although it may seem to represent something of a paradigm shift, it is actually more of a relocation of processing and storage than a reinvention of the genre. For organisations that have the necessary in-house expertise, risks are minimal and the benefits can extend far beyond just reducing costs.
Tsuga is now generally available. If you want to see the system in action you can head to the Tsuga web site and sign up for a trial or request a demo.
If the Observability world had a code of secrecy akin to that of the Magic Circle, then Charity Majors might be in danger of being banished to exile and ignominy. In a single slide deck, she has blown the gaff on a whole trove of insider knowledge. It is the “What they don’t teach you at Harvard Business School” of observability knowledge. Not the abstract theory or technical detail but lessons and insights from the o11y frontline.
The deck in question was used in a talk at the LeadDev event in Berlin earlier this month and its 52 slides are an illuminating distillation of observability wisdom. We actually weren’t present at the talk and only came across the deck thanks to a mention in Michael Hausenblas’s excellent olly news newsletter. However, the slides contain sufficient clues (and images of unicorns) to easily re-construct the narrative and win friends and influence people as an observability savant.
If you are an SRE, when an outage happens you will know about it pretty quick. With security breaches the picture is rather less clear as, by their nature, they are designed to go undetected. Intrusion detection therefore is often based on a mixture of tools designed to spot unusual spikes, suspicious patterns or failed logon attempts.
This article by Fatih Koç argues that one of the major difficulties involved in identifying attacks is that of correlating signals across multiple sources such as Falco, Prometheus, Kubernetes Audit Logs etc. In this article, he outlines a strategy for extracting relevant data from each of these sources and pulling it together into a single observability dashboard.
The first line of cyber defence is normally at the perimeter - preventing attackers from entering your network in the first place. The next line of defence is intrusion detection. This can often take the form of anomaly detection using a variety of heuristics.
There are also some more creative possibilities, such as the canary solution adopted by Grafana. Just as the canary in the coalmine sings to alert underground workers to the presence of toxic gases, Grafana’s canary was designed to alert them to the possible presence of intruders in their domain.
Load testing can be simple in theory but in modern distributed architectures, it involves a lot more than throwing requests at an individual service. This article on the Airbnb engineering blog looks at how the company’s engineers use the Impulse load-testing framework to handle a number of more complex requirements such as dependency mockingand managing messaging and asyncronous calls.
Unfortunately, at the moment Impulse is just an internal Airbnb framework, so you won’t be able to get your hands on it at present. At the same time, the article provides a valuable blueprint for tackling advanced, real world load testing scenarios.
It’s an announcement that might have seemed unthinkable not long ago, but the porting of the revolutionary eBPF technology to Windows is now a reality. The ability to bring safe programmability to the kernel has resulted in enormous gains in fields such as security, networking and observability for Linux hosts, so applying the same principle to the Windows ecosystem is obviously an attractive proposition. It is not, though, without its own difficulties. There were a lot of hurdles to overcome and, inevitably, given the differences in OS architecture, this is not a full-fidelity replica of the Linux implementation.
This possibly foundational article by Pavel Yosifovich guides you through the steps involved in boldly going where few have gone before and creating your first eBPF program for Windows. One paragraph in the article begins with the sentence “this is where things get a bit hairy“ - for some that will likely be a challenge rather than a deterrent. This may not be cooking up nuclear fusion in your bedroom, but it does feel pretty radical.
As well as rolling out their Open AI observability solution, Elastic have also been very active within the OpenTelemetry project. C++ has a reputation for being something of a fearsome foe for observability practitioners. In this article on the Elastic blog, Haidar Braimaanie dons his protective gear and attempts to tame the beast with a soothing dose of OpenTelemetry instrumentation.
Unlike languages built in frameworks such as .NET, C++ does not have a standardized runtime environment that supports dynamic instrumentation across all platforms and compilers. C++ also uses a variety of build systems such as Makefiles and CMake, so that implementing instrumentation can be difficult and error-prone. In the article, Haidar looks at adding OpenTelemetry support to a C++ application running on Ubuntu 22.04. He also includes sample code for instrumenting the project with database spans and then observing the application in APM.
After reading this article you may want to give the C++ developer in your life a hug.
Even if you are not familiar with the name of Brendan Gregg, you are almost certainly familiar with the fruits of his labours. Brendan is the creator of the Flame Graph - one of the most important and iconic visualisations in the observability toolkit.
We featured the Flame Graph in our recent tribute to the work of UX designers in the observability arena - but you should also visit Brendans’ web site.
Brendan’s latest innovation is the AI Flame Chart. This is an evolution of the original flame graph and its ambitious aim is to help reduce the vast financial and environmental costs entailed in the use of LLM’s. This means that whereas the original flame graph was focused on CPU cycles, the latest generation sets its sights on reducing GPU load. The article discusses the considerable complexities involved in mapping GPU programs back to their corresponding CPU stacks.
The names of some of the instruction sets look intimidating to the uninitiated but the basic concept of the graph is quite simple - the wider the bar, the more resource it consumes.
If you have ever had to grapple with a 3,000 line Helm chart to deploy your observability infrastructure, you may be forgiven for thinking that there must be a better way to do this. Whilst YAML has a certain formal elegance, its syntax struggles to express the architectures and relationships embedded in highly complex systems.
Whilst Pulumi have tackled this problem by enabling the use of high level programming languages for IaC, System Initiative are taking a fundamentally more radical approach. Their goal is nothing other than completely reinventing IaC from the ground up. The blog article for the launch of the product is an incredibly ambitious statement of intent. The terms ‘game changer’ and ‘paradigm shift’ tend to be thrown around somewhat casually, this might be a case where their usage is appropriate.
So, what are they proposing? Well, System Initiative is IaC without the code. It is a kind of digital canvas where you manipulate digital twins of your systems. Is the future here or is this the Platform Engineering equivalent of science fiction? Read the article and decide for yourself!