Prologue
I'll be frank — I've spent most my career building reliability into products and businesses. I've never considered it a feature that's for sale. As I've seen businesses struggle with addressing the reliability that customers expect to have, largely because businesses do not start out with the intention or capability to scale to millions of users, I've started to think outside of the box. At some point a business hits a critical mass whereby one user can disrupt the experience for thousands -- in traditional hosting we call this "noisy neighbors" and is largely the reason we have the system level isolation technologies we have today. This series of pieces dives into blueprints for what that could be.
Reliability engineering has a striking resemblance to cybersecurity. You’ve got your blue teams — folks on the front lines, defending against emergent threats with structured triage and response. Then there are R&D-adjacent teams, often called “platform engineering,” building the underlying systems that make that defense possible.
Both disciplines are typically labeled as cost centers. Why? Because their core function is to save the business from potential loss. And that’s a tough sell — proving a negative is hard, especially when the economy’s wobbling. When the belt tightens, chances are it’s coming for your britches.
But here’s the key difference: reliability is for sale in a way that security isn’t. Customers can — and do — pay for higher SLAs, for prioritized uptime, for white-glove reliability. That opens up an opportunity to reframe parts of reliability engineering not as a cost sink, but as a profit-aligned function.
Multi-modal performance
The idea of selling availability and performance as a value-added service isn’t all that foreign when you really sit with it. Take shipping, for example: when I drop off a package at the local courier, they’re happy to offer a menu of prices based on performance — same-day, next-day, two-day — and those tiers aren’t universally available. What you get in the mountains of Tennessee isn’t what you get in Manhattan.
But here’s the kicker: if the courier fails to meet that promised level of service, there are consequences. I, as the customer, get reimbursed. That SLA is contractual, and violations have tangible outcomes.
Behind the scenes, that system runs on a layered foundation of insurance policies, real-time monitoring infrastructure, and scheduling algorithms that calculate capacity on the fly. Strip it down to brass tacks, and it’s not all that different from what we do in software — figuring out how many boxes (by size and weight) can fit in a cargo plane isn’t so different from managing server capacity and demand.
Sound familiar? I’d bet more than a few of you have pulled out the container ship analogy at some point. That’s multi-modal transportation at its core — and it’s exactly what underpins the varied “performance as a service” model. Different modes, different costs, different guarantees — but ultimately, it’s all just reliability delivered in tiers.
SLAs as SKUs
Let’s think about what offering reliability as a product actually entails. I see two primary ways to get there:
-
Privileged access through isolation. Run dedicated infrastructure for a customer. This requires that platform engineering deliver two flavors of service: a shared platform and a dedicated managed platform. Same software, different architectural tricks. At its core, this is an availability play — but if you throw in preferential ingress, it starts to touch on performance, too.
-
Preferential rate limits. Cloud providers do this all the time. They’re just a little more generous about handing out those privileges. More often than not, you can simply pay for the limits you want, even if they’re not on the menu. Today, many businesses rate-limit out of safety, adjusting thresholds manually based on usage patterns. But that’s ripe for productization.
Now, if you're going to sell SLAs as SKUs, you need real infrastructure behind the curtain. I think it's generally accepted that there are orders of magnitude differences in spend when you move from 99.99% to 99.999% uptime. You can only get away with data warehouses and Excel sheets for so long before your customers catch on and start ignoring the MSA clause that says “don’t externally monitor us.” Sooner or later, you’ll need to provide your own trustworthy data — hard numbers that prove you delivered what you promised. The kind of stuff that stands its ground in court.
The good news? That same SLA-backed SKU can fund the very systems that make it work. When you can calculate availability and performance accurately at scale, report on it per customer, and identify threats to that service level in a timely manner — that's the golden goose.
That’s not just ops. That’s product.