This week Corey Quinn wrote about what the “next million cloud customers” will need from Amazon. In the post, he warns Amazon that if they don’t provide a higher level abstraction of all of their cloud services, essentially pre-architecting industry vertical appropriate cloud architectures that will help get the many yet-to-covert companies onto the cloud, then someone will eventually show up and meet this market opportunity, eventually relegating AWS to the domain of NTT and CenturyLink; vital, yet unknown. It’s a compelling argument. But what if AWS doesn’t build this abstraction, and what if nobody else does either?
In 2003, while helping my CTO decide between buy vs build for a CRM to service our VOIP-startup, I experienced my first real appreciation for just how difficult it is to create a service you can sell broadly to many enterprises to fit their needs. Nothing among the ocean of CRMs we could find matched our VOIP-startup needs in a way that wouldn’t create so many new headaches for us as to be worth the cost or implementation. We ended up building a solution ourselves. The CRM we needed had to fit our particular way of doing business. And our particular way of doing business was our secret sauce – our differentiator.
In 2006, I helped rescue a massive project to modernize a major insurance company’s quoting software from COBOL and mainframes to Java and the Web. Many of the problems they’d run into during the move were the result of one assumption: That the way this massive insurance company did business was somehow separate from the encoding of their processes and policies within that old COBOL code. The result: 100s if not 1000s of bugs where the web-based Java software ran exactly as designed, but not in a way that the company needed it to run. And it’s not like the architects were idiots. Things just got lost in translation. Ultimately, that company had to change the code and itself in order to make it all work together.
In the 2010s, Marc Andreesen pointed out that “software is eating the world.” SaaS finally had an acronym people recognized and understood. And ever since, 100s of disruptive new companies have sprung forth, eating the worlds of many older enterprises who can’t just start anew. There are at least 534 billion dollar “technology” companies. In today’s parlance, a “technology company” is often any company that realized you could do something established companies had done for a long time, but with a lot of software to do it, and find margins the established companies could not. You either are a SaaS, or you’ll be eaten by one.
Corey suggests that AWS could possibly understand verticals in which they do not operate at all well enough to pre-architect these cloud implementations. I’m skeptical, even if it is Amazon. No non-trivial business software today is able to execute at a generalized enough level to be applicable to a broad enough market that it would move the needle for a trillion dollar business. And no software that was so broadly attractive to a large enough market would function specifically well enough to meet any one customer’s real needs. Adoption of cloud abstractions overly generalized by industry non-experts would be corporate suicide.
I actually like Corey’s idea. It’s a multi-trillion dollar idea if you can do it right. Which means that there’s an opportunity to become one of many, many multi-billion dollar companies if you can do some piece of it right. And that’s what I think will happen. Hell, that may actually be what Corey meant all along. If nobody shows up to build the uber-abstraction-layer for all things cloud for all industries, then we’ll get dozens if not 100s of industry-specific, cloud-category specializing players.
A market may well demand a singular uber-abstraction, but there’s such a thing as unmet demand. One of my favorite econ profs in college would jokingly call that an “unyet supply.” (Always love a dad-joke.) And in that vacuum of unmet demand we can build an ecosystem of integrable abstractions. But the enterprises still waiting on the sidelines will need to identify and utilize these abstractions quickly, because the domain of benefits will not only belong to them. 100s of other startups will be able to benefit too.
So… a funny thing happened:
I started writing this post on Wednesday of this week, and as I usually do, slept on it to see if I still agreed with myself the next day. And wouldn’t you know it, something did happen: Smart minds, including Cory’s, got their heads around Cloudflare’s new R2 product.
Here’s smart-minded Ben Thompson to explain part of what this means:
That is one way this could play out: R2 is a compelling choice for a certain class of applications that could be built to serve a lot of data without much compute. Moreover, by virtue of using the S3 API, R2 can also be dropped into existing projects; developers can place R2 in front of S3, pulling out data as needed, once, and getting free egress forever-after.
So R2 proves Cory right, but in a funny way. Someone is showing up to take advantage of AWS’s margins, and provide a kind of modular replacement of S3 by supplying a compatible front-end that enables developers to build much lower cost interop between cloud service providers. Do you have any idea how many times in the last several years I wished I could affordably move a ton of data across CSPs without incurring huge costs so I could take advantage of the relative strengths of each? Anyone want to write a quick ETL that takes advantage of Route 53, Lambda, S3, and Google BigQuery? Now you might be able to without upsetting your CFO.
But this is still not quite what Cory had in mind, at least in his stated thesis. This is no abstraction. Indeed, R2’s API is a copy of S3’s API. You still have to have a good bit of actual knowledge – now about 2 cloud providers! – to get lower cost multi-cloud interop working together in a way that suits you. But it’s still a major step forward for those of us with the know-how. And maybe it’s a small step forward to a future of companies that can provide industry-specific abstractions that cross clouds.