How observability unifies workloads across hybrid multi-cloud environments

It’s hard to believe that ten years ago, we were just embarking on the move to containers and Kubernetes. Today, cloud native architectures are providing the composability, agility, and scalability needed for modern applications and infrastructure, including AI workloads. While there are still organizations lagging this trend, most enterprises have containerized at least 20% of their workloads, with many sitting at around 50%. And of course, those born in the cloud companies are 100% cloud-native from the start.

While the benefits of a containerized, microservices-based architecture are proven, there are also challenges inherent from this approach. Namely, they can rack up massive public cloud hosting bills or face business continuity issues if our hosted infrastructure has an outage.

To account for both cost and resilience, many organizations are taking a hybrid, multi-cloud approach – with workloads distributed across multiple public clouds as well as maintaining a cloud native private cloud deployment on-prem. 

So now, to achieve our organizational goals and ensure we provide a reliable end-user experience, we have added complexity on top of complexity with a multi-layered distributed system. We need to easily update, secure, and observe these distributed systems – in a way that serves both operators and developers.

We used to dream about a single pane of glass to manage and view it all from a central location, which proved to be a fantasy. In fact, we’ve ended up with tool sprawl along with increased costs and complexity.

In working with organizations around the world, it’s important to find out how we standardize certain layers of our architecture in order to achieve improved security, lower costs, and ease of management.

We want to maintain the flexibility for developers with how they can build applications, but the infrastructure should be an abstraction layer for them – just be there when they need it, how they need it, and where they need it. 

To create a seamless experience and a true abstraction, we need to make some big bets on architectural layers, such as our container management platform, operating systems, automation, and observability – to name a few. 

To innovate at the speed required, we can’t be tied down with the tech burden of managing and updating dozens of different operating systems and versions or trying to figure out where an issue exists when we are working across six different monitoring and observability solutions that aren’t tied together. 

To summarize, our goal with these standardized layers is to:  

1. Allow developers to do what they do best – build innovative apps 
2. Increase security and resiliency
3. Empower engineers to find and fix issues fast (and not 300 of them)
4. Reduce costs and vendor sprawl
5. Simplify overall management and update cycles

Remember that complexity we talked about earlier? Another aspect of a containerized, microservices architecture is the creation of an exponential amount of telemetry data needed to understand performance or issues amid this complex architecture.

While building those cool new applications, developers are creating a ton of logs alongside them. Plus, we are bombarded with metrics, traces and event data that we have to process, analyze, understand, report, and store. This has led to observability costs rising to the levels of our AWS bills, in addition to dragging our MTTR to new heights.

Modern observability solutions are purpose-built to ride Kubernetes across the hybrid cloud. No matter where your containerized workload resides, your observability should follow and provide a correlated view of all telemetry data – not separate dashboards for logs, metrics, and traces.

However, this should not come with a price tag that brings our CFO to tears.

Let’s consider three key ways observability built for containerized, hybrid-cloud environments can help: 

1. Unifying visibility
2. Controlling costs – Focus on (and pay for) the most useful data
3. Simplifying data at scale with a Telemetry Pipeline

Let’s tackle each of these.

In hybrid cloud or multi-cloud environments, containerized workloads can span across public and private clouds as well as on-prem. Without a unified view, observability data is siloed, which can slow down incident response and, ultimately, risk customer and engineer satisfaction alike.

A SaaS observability platform will monitor containerized applications and infrastructure wherever they are hosted across hybrid, multi-cloud architectures. All data will go to the cloud platform, regardless of whether the containers reside on-prem or in a public cloud. 

This gives engineers and operators a unified view of what is happening across their infrastructure and applications, regardless of where workloads live. And by the way, this should be a unified view of all telemetry data in one place, or at least with clear correlation.

In the modern, containerized world, there’s too much observability data to truly know what data is most useful. We waste time wading through all this telemetry data, and we spend too much money to retain all that data.  Worse yet, we end up dropping data with a hope and a prayer we won’t need that data later to remediate.

Ideally, your observability solution tells you which data matters, automatically.

There should be an ability to quickly identify what data is being queried, used in dashboards, or tagged in some way that clearly denotes its utility. In doing so, only that data with high utility or usage stays in the system, reducing the noise when you need to remediate, and vastly reducing the amount of data stored. 

In complex systems, less data, lower costs. For example, we see customers able to reduce their data volume and associated costs by some 84%, while reducing time to remediate by 50% or more.

The amount of data being generated in cloud-native environments is soaring, and has become a burden for teams trying to manage it all. By some counts, organizations are experiencing 250% log data growth on average.

Teams need more control over telemetry data, from collecting, processing, and routing, to storing and querying. This challenge gets even harder in hybrid cloud and multi-cloud environments.

Telemetry pipelines help teams centralize data management into a single, coherent interface. The telemetry pipeline that can help most is one that can be leveraged for bare metal or VM-based on-premises environments or across hybrid, multi-cloud, containerized workloads. 

There’s still so much confusion around common terms related to cloud native, containers, and hybrid cloud. Below are some definitions of these terms to help drive clarity and shared understanding for your teams.

Observability creates a single correlated view of telemetry (logs, metrics, traces) across public cloud and private/on-prem systems.

This unified visibility:

1. Eliminates data silos and fragmented dashboards
2. Enables faster incident response and improved reliability
3. Supports both operator oversight and developer agility

Focus on storing and processing only the most useful telemetry data—based on what’s actually queried or needed for remediation.

Here are a few best practices for controlling observability costs:

1. Avoid costly vendor sprawl by standardizing on effective pipelines
2. Quickly identify what data is being queried, used in dashboards, or tagged in some way that clearly denotes its utility.
3. Use correlated telemetry data across containerized environments to provide a more unified view of what is happening across infrastructure and applications, regardless of whether the containers reside on-prem or in a public cloud.

By some counts, organizations are experiencing 250% log data growth on average. Telemetry pipelines centralize data collection, processing, and routing from diverse sources (bare metal, VMs, containers).  

Some benefits of a telemetry pipeline include:

• Simplified management in complex architectures
• Stronger data governance and end-to-end control

Here are some key advantages:

1. Developers focus on building apps, while infrastructure abstracts complexity
2. Security and resilience improve via consistent monitoring layers
3. Management overhead drops, and update cycles become easier
4. Vendor/tool sprawl is minimized, reducing operational friction