Not all cloud customers are the same, but there seems to be a lack of awareness of this in the industry. Let me sketch out two customer personas for you.
Customer A is a SaaS company. They run their environment on the cloud in some way: Perhaps it’s all-in-on one provider, perhaps it’s multi-cloud (which given that they have to serve customers where they are, may well make sense for them). They might even have a physical data center or two.
Customer B is from the very same SaaS company, but someone else’s cost center entirely. They’re the corporate IT function for the business, and they’re tasked with running the phone systems, the corporate network, the payroll systems — basically everything internal to the business that’s employee-facing and not the SaaS application that the company sells to its customers.
Customer A has historically been a primary driver of cloud adoption. Customer B is the future of cloud.
Customer A
We’ve seen Customer A on stage at cloud conferences a fair bit. They talk about what they’re building, their engineers make obnoxious amounts of money, and their KPIs are aligned around accelerating feature velocity. They care about cost to a point, but only insofar as they feel the obligation to be reasonable stewards of the money entrusted to them, invariably by venture capitalists. Getting new features to market is always going to take precedence over saving money.
Customer B
Customer B is the historical IT department. They are a cost center, and they’re painfully aware of it. “Do more with less” may as well be their mission statement. Even as cloud starts to shift IT from “pure cost center” to “value driver,” it’s not perceived that way by the business — at least, not particularly seriously. This is the truest sense of “utility computing”: It’s expected to approach the reliability of a municipal utility. You don’t wonder if water is going to come out of the faucet when you turn on the tap; it’s noteworthy when it doesn’t.
This isn’t an exaggeration: If payroll doesn’t run, there isn’t a company anymore. The IT department’s constraints may seem ridiculous to an outside observer. “This requires Windows Server 2012. No, 2016 won’t work. Nor will any other edition that follows.” Those vendor constraints are immovable. Even Amazon couldn’t overcome that inertia.
My recurring “joke” about Customer A’s cloud bill being a function of how many engineers they hire is absolutely not a joke for Customer B; staff headcount drives their costs.
Where These Customers Diverge
You can mostly get by with similar messaging to both of these customer personas to a point. Unfortunately, you will reach a point where you’re alienating at least one of them if the conversation goes on long enough.
I’m going to talk about Customer B; if you want to learn more about Customer A, go watch any cloud keynote over the past decade.
Customer B is unlikely to ever implement “Infrastructure as Code.” Their jobs have generally been built around “infrastructure as clicking buttons in a GUI.” There’s nothing wrong with that, to be very clear! The failure is instead on the part of a number of cloud providers to acknowledge that this customer exists. “Oh, you built something in our console? Great, throw it away and start over using code” is a terrible experience for this customer. If they were capable of effectively defining infrastructure as code using the modern toolsets, they likely could make more money working over in Customer A’s world — and then they’d get backfilled by someone who wasn’t so adept. Customer B’s problem would remain.
Customer B absolutely does not want to build a solution out of a bunch of Popsicle sticks and serverless functions. They want what distills down to a turnkey solution. In the AWS universe, offerings like Amazon Workspaces and Amazon Connect nail what the customer wants. In an ideal world, Honeycode would become another standout offering in this space instead of a sad afterthought. Nimble Studio is another prime example of delivering solutions to specific customer pain.
Over on the Google Cloud front, they’re nailing this market with whatever they’re calling G-Suite this month, because it’s an entire product ecosystem in its own right. You don’t need to be an engineer to set up a custom email domain and scale it out to even hundreds of users. You simply need some time and a web browser.
The trouble is that the success stories are islands within their respective cloud providers. The rest of the service offerings trend heavily toward “build it yourself with the help of fourteen other services,” so why would Customer B not just buy something off the shelf that’s built by someone who knows how to speak Customer B’s language?
We’re all becoming Customer B
When I needed to host the Last Week in AWS website, I chose to go with WordPress. It’s easy to find developers who know the platform, I spent a year running it at very large scale at a web hosting company a decade ago, and the ecosystem is thriving. My next step was to hurl money at WPEngine to run all of it for me because I have the good sense not to try to run web servers myself when I can pay professionals a reasonable amount to do it for me. This leaves me to focus on things that have a larger strategic impact on my business, such as shitposting. Running the website on AWS is certainly doable, but it looks a lot like a sick joke instead of a viable solution.
Ignoring Customer B represents an existential threat for a cloud vendor
A few years ago, I built a URL shortener from serverless parts. Today I’d use Bitly or similar. When I launched my newsletter, I built a custom system that aggregates my link collection each week; today, I’d use something like Curated or Substack. Increasingly, there are turnkey solutions that solve the kinds of business problems that real customers have. Unless the problem you solve is directly core to my business, I’m invariably going to be better served buying whatever it is you’re selling than by building and maintaining it myself. That’s the way the world is going.
The large cloud vendors largely have failed to internalize this message. They continue to come out with better components that can be built into ever-more-impressive systems with extensive amounts of work. If they continue down this path, they’re going to find themselves inhabiting a world where the bulk of their business comes from SaaS companies who package their services into something that’s customer coherent, that speaks to problems end users want to pay to make go away, and that drives significant margin to those SaaS customers. The cloud provider in question becomes a vague abstraction to the end user, the same way that AWS is an abstraction to Netflix’s viewers. At that point, they’ve effectively become the utility computing they’ve always tried to be — and along with it, they’ve taken on the completely commoditized aspect of modern utilities as well.
I don’t think that this is what the cloud providers want — but unless they start taking steps to move up the stack and offer more inclusive solutions for customers who don’t want to build them themselves, they’re going to find that their presence in the cloud market is increasingly relegated to behind-the-scenes roles instead of the current front-and-center positioning which they so clearly enjoy.
