Cloud-Native Hard Truths: Lessons from PagerDuty’s Head of DevOps

This article is based on a guest post written by Eric Sigler in his capacity as Head of DevOps at PagerDuty, originally published on the Computer Weekly Developer Network. PagerDuty offers a Digital Operations Management Platform designed to integrate machine data with human intelligence, supporting optimised response orchestration, continuous development, and delivery.

The Shift to Cloud-Native Is Already Here

It is increasingly rare for engineering teams to build on-premises-only infrastructure. Most organisations are either actively migrating to the cloud, have already completed that migration, or were built cloud-first from day one. This fundamental shift in how companies approach infrastructure means that cloud-native architecture is no longer optional for many teams — it is inevitable.

But cloud-native is not a free upgrade. It comes with a set of hard truths that teams must confront honestly if they want to succeed. Sigler outlines five of the most important.

1. Cloud Native Acts as a Forcing Function

Adopting a cloud-native approach forces a fundamental change in how applications are built on top of infrastructure. By standardising the behaviour of lower-level components — compute, networking, storage — organisations free individual teams from having to reinvent that foundation repeatedly.

“Please stop spending all of your time reinventing the wheel in respect of everything below the application layer.”

Eric Sigler, Head of DevOps, PagerDuty

This is where traditional or virtualised application design tends to break down. Teams spend enormous effort on how to ship software rather than on the software itself. In a cloud-native model, those solved problems stay solved, and teams redirect their energy toward delivering actual business value.

2. Failure Is Not the Exception — It Is the Norm

One of the most common mistakes in cloud-native environments is treating software as a fragile, unique entity that should never encounter failure. In reality, failure occurs at every layer: the network, the application, the underlying platform, and everywhere in between.

If the network breaks, it is tempting to assume the software had nothing to do with that failure. But that assumption is wrong. Failure happens at all parts and in all aspects of operating a cloud-native infrastructure. Ignore this reality at your own peril.

Eric Sigler

Building resilient systems means designing for failure from the start — not retrofitting resilience after the first outage. Practices such as circuit breakers, retries with exponential backoff, graceful degradation, and chaos engineering all stem from this acceptance that failure is a constant, not an anomaly.

3. Own Your Dependencies — Or They Will Own You

Cloud-native applications are rarely self-contained. They depend on external services: DNS providers, SMTP delivery platforms, authentication services, payment gateways, and more. Each of these is a potential point of failure outside your direct control.

The hard truth is that your customers do not care which downstream dependency caused an outage. From their perspective, your service failed. That means every engineering team must have recovery strategies in place for when a dependency degrades or goes offline entirely. This includes:

• Monitoring the health of critical third-party dependencies, not just your own services
• Implementing fallback mechanisms or graceful degradation paths
• Setting and enforcing SLA expectations with external providers
• Running regular failure-scenario tests that include dependency outages

4. Cloud Native Forces a Collaboration Reckoning

Moving to a cloud-native model fundamentally changes how developer and operations teams work together. With cloud native comes a standardised set of primitives — containers, orchestration platforms, managed services — that any team can use. This moves ownership of services closer to the teams building them, which can be deeply uncomfortable for organisations accustomed to clear boundaries between Dev and Ops.

Sigler’s view on how this should play out:

• Operations teams should shift away from simply spinning up infrastructure on request. Their role becomes providing the platforms and primitives that enable developer teams to move faster and own more.
• Developer teams must in turn take responsibility for using those platforms effectively — including monitoring, alerting, and on-call accountability for the services they build.

This model — sometimes described as platform engineering or internal developer platforms — is now widely adopted in mature DevOps organisations, but it requires a genuine cultural shift, not just a tooling change.

5. Composability Enables Agility at Scale

The final foundational principle Sigler highlights is composability: small, focused teams working on smaller, well-scoped services that are then composed together into a larger system. This approach — the foundation of microservices and service-oriented architecture — delivers two significant advantages:

• Greater business agility: Smaller services can be iterated on, deployed, and scaled independently, without requiring large coordinated releases.
• Better fault isolation: When a component fails, the blast radius is smaller and recovery is faster.

Composability is not just an architectural choice — it is an organisational one. It works best when team boundaries align with service boundaries, reducing cross-team coordination overhead and giving each team clear ownership and accountability.

Key Takeaways

Adopting cloud-native architecture is not simply a matter of moving workloads to the cloud. It requires a deliberate shift in mindset across the entire engineering organisation. The five hard truths outlined by Sigler serve as a practical framework:

1. Use cloud native as a forcing function to stop reinventing infrastructure and focus on application value.
2. Accept failure as a constant and engineer for it at every layer.
3. Own your external dependencies — monitor them, plan for their failure, and build recovery paths.
4. Redefine the collaboration model between Dev and Ops around platforms, primitives, and shared ownership.
5. Build for composability — small teams, small services, composed together for resilience and speed.

None of these ideas are new in isolation, but applying them consistently as a unified operating philosophy is what separates organisations that thrive in cloud-native environments from those that merely survive them.