This article is based on a piece originally published on devops.com, drawing on experience from Liberty Mutual’s serverless adoption journey.
Serverless and DevOps: Two Misunderstood Game-Changers
DevOps has existed for more than a decade, yet it is still misunderstood by many organisations. You cannot purchase “a DevOps”—it is a culture, a set of practices and a mindset. Serverless carries a similar burden: the name markets well but consistently creates confusion in the industry.
Despite the confusion, both concepts are game-changers. Some have argued that serverless makes DevOps obsolete. That claim is false. What serverless does do is dramatically lower the operational overhead that has historically slowed DevOps adoption at scale—enabling teams to focus on delivery rather than infrastructure management.
Fortune 100 insurer Liberty Mutual is a well-documented example. The company began its cloud journey roughly ten years ago, at the same time internal engineering teams were adopting DevOps principles. Two foundational convictions emerged early:
- Cloud strategy: Build on cloud-native principles, not simply “someone else’s data centre.”
- DevOps strategy: Anchor on CALMS (Culture, Automation, Lean, Measurement, Sharing) rather than writing one-off scripts.
These two tracks eventually converged in a serverless-first strategy that allowed Liberty Mutual to scale advanced DevOps practices across a large, globally distributed engineering organisation.
Why Infrastructure as Code Alone Wasn’t Enough
Infrastructure as code (IaC) is a cornerstone of modern cloud strategy. But teaching more than 1,000 software engineers to provision secure, resilient infrastructure via YAML (as was the common approach around 2015) is a steep learning curve. Layering on advanced requirements—secure-by-design, chaos testing, resiliency, observability, performance optimisation—makes it steeper still.
What changed the equation was the move to serverless architectures. When teams began building serverless systems, a notable shift occurred:
- Workloads became self-healing by default.
- Blue-green deployments became straightforward to implement.
- Teams consistently hit high DORA metrics for both throughput and stability.
- Business value was delivered at significantly lower compute costs.
Core Principles for an Enterprise Serverless Journey
Whether you are a startup or a large enterprise, the following principles provide a useful anchor as you begin adopting serverless. They keep teams focused on business outcomes and prevent the common trap of becoming lost in the vast catalogue of cloud services.
1. Measure Team Outcomes in Business Terms
Product thinking, North Star metrics and impact mapping are all practical tools for keeping engineering teams focused on what matters. The guiding question should always be: What is the most valuable feature we can deliver next? Complexity in tooling and process should never obscure that simple priority.
2. Code Is a Liability
The software industry has known for decades that lines of code (LOC) is a poor proxy for engineering success. Yet LOC counts still generate misplaced pride. Serverless encourages a different instinct: favour managed, event-driven infrastructure that is correctly decomposed, and write as little custom code as possible. Less code means less surface area for bugs, less maintenance burden and faster onboarding for new engineers. You cannot code your way out of complexity—pragmatism is the better tool.
3. Serverless Is a Spectrum, Not a Binary Choice
A serverless-first strategy means starting with fully managed, serverless options and only moving toward IaaS (Infrastructure as a Service) when there is a clear, justified reason. It does not mean every workload must be serverless at all costs. Treat it as an operational construct: begin at the highest level of abstraction and work back toward lower-level infrastructure only when required.
Measurement in modern software development should be trend-based rather than absolute. The four key DORA metrics—deployment frequency, lead time for changes, mean time to restore (MTTR) and change failure rate—are excellent indicators of team health. Serverless teams with minimal handoffs routinely perform strongly across all four.
Key Building Blocks for Scaling DevOps with Serverless
Committing to serverless requires more than choosing a cloud provider’s function-as-a-service offering. The following building blocks provide the foundation that allows advanced DevOps practices to scale safely.
Public Cloud Strategy
Absolute clarity is required before making the move to public cloud. This is a genuine transformation. Security, infrastructure, procurement and engineering functions all need to reinvent how they operate. Getting alignment on what “cloud-native” means to your organisation—before you migrate workloads—is critical. For startups, a serverless-first approach is often the only realistic path to the development velocity required to compete.
Deployment Pipelines
In a serverless environment, the pipeline to production becomes a business-critical capability in its own right. Traditional controls—security gates, compliance checks, approval workflows—must be reimagined to provide genuine protection without creating friction that slows teams down. Under-investment in pipelines is one of the fastest ways to frustrate capable engineers and negate the velocity gains that serverless is supposed to deliver.
Reusable Patterns
As teams adopt serverless, they will independently start creating the same boilerplate components. An effective reuse strategy prevents mass duplication without introducing the bureaucratic overhead that kills momentum. Tools such as the AWS Cloud Development Kit (CDK) and open-source pattern libraries like cdkpatterns.com allow teams to assemble production-ready building blocks quickly. Liberty Mutual has reportedly deployed hundreds of applications using CDK-based patterns.
Well-Architected Reviews
Architecture must live inside the delivery teams, not in a centralised ivory tower. The AWS Well-Architected Framework—with its five pillars covering operational excellence, security, reliability, performance efficiency and cost optimisation—provides a structured, team-friendly approach to non-functional requirements. Teams can self-assess against the framework, but architects play an important coaching role for more nuanced areas.
The goal is to embed well-architected constructs directly into code building blocks so that quality controls are baked into the engineering environment from day one—not bolted on during a pre-release review.
The Business Case: Engineering as a Differentiator
When engineers go through this journey—adopting serverless-first principles, working within strong pipelines, leveraging reusable patterns and applying well-architected reviews—they acquire powerful tools. They can build world-class, low-cost systems quickly. The feedback loop tightens. Innovation accelerates.
There is a caveat, however: this is a relentless journey of optimisation and improvement. Organisations that do not view engineering as a core differentiating capability may find the ongoing commitment difficult to sustain.
The single most important factor in a successful serverless journey is ensuring engineering teams deeply understand the business they are serving. Cross-functional teams chasing a clear business KPI—rather than technical metrics in isolation—are the ones that realise the full potential of serverless. When that alignment exists, the traditional business-IT divide dissolves. Technology teams innovate directly in pursuit of the company’s vision, and engineering engagement improves as a result.
Serverless is not a silver bullet, but as a paradigm shift it genuinely enables engineers to innovate and deliver at a pace that was not previously practical in large enterprises. The key is building the right cultural and technical foundation before, not after, you begin.
Original source: devops.com. Liberty Mutual examples and figures referenced in the original article.