and the Deployment Age of the Cloud
The news of
Zeit Vercel raising $21m (slide deck here) is great occasion for taking stock of what is going on with cloud startups. As Brian Leroux (who runs Begin.com) observes, with reference to Netlify’s $55m Series C last month:
Between just Netlify and Vercel the VC community has put over 70MM in cloud focused on frontend dev in 2020.
Haven’t AWS/GCP/Azure owned the cloud space? What is the full potential of this new generation of startups basically reselling their services with some value add?
I am reminded, again, of Fred Wilson’s beloved Carlota Perez framework that I wrote about in React Distros. First you have an Installation Age, with a lot of creative destruction. Then, with the base primitives sorted out, we then build atop the installed layer, in a Deployment Age:
I think the same dynamics I outlined with frontend frameworks is happening here with cloud services. I’m obviously a LOT less well versed with the history of cloud, so please please take this with a grain of salt.
The argument is that the Big 3 Cloud Providers are mostly providing the new commoditized primitives on which the next generation of cloud services will be built. AWS is AWS, Azure maybe caters to the dotNet/Microsoft crowd better, whereas GCP maybe differentiates on Kubernetes and Machine Learning. Basically everyone has a container thing, a data thing, a file storage thing, a serverless thing, and so on.
A nice way to think about it, which I attribute to Guillermo (but I’m not sure about), is that these basic services are the new “Hardware”. Instead of going to Fry’s and picking up a motherboard, we now go to the AWS Console and pick up a
t2.micro or to Azure for a Durable Function. Instead of debating Sandisk vs Western Digital we match up AWS Aurora vs Azure DocumentDB. The benefits are clear - we don’t get our hands dirty, we can easily (too easily?) scale with a single API call, and thanks to Infra-as-Code we can truly treat our infra like cattle, not pets.
When the Big N clouds launched, the expectation was that Platform as a Service (PaaS) would win out over Infrastructure as a Service (IaaS). I mean - look at this chart! - if you were running a Software business, would you want to run it atop an IaaS or a PaaS? It made intuitive sense, and both Google App Engine and Azure originally launched with this vision, while Salesforce bought Heroku within 3 years of founding.
But this thesis was wrong. As Patrick McKenzie recently noted:
I’m surprised that Heroku’s model didn’t win over AWS’ model and that DevOps is accordingly a core competence at most SaaS companies. This seems obviously terrible to me every time I’m doing DevOps, which probably took ~20% of all engineering cycles at my last company for surfacing very little customer value.
This rings true. As moderately successful as Heroku, Parse, and Firebase were, they are dwarfed by the size of the big clouds’ IaaS businesses. It turns out that most people just wanted to lift and shift their workloads, rather than start new apps from scratch on underpowered platforms. Assisted by Docker, this acquired the rather unfortunate name of “cloud native”. (Unfortunate, because there are now “more native” versions of building cloud-powered apps than “containerize everything and somehow mention agile”)
But I don’t think the PaaSes were wrong.
They were just early.
The thing about hardware providers is that they don’t cater well to specific audiences. By nature, they build for general use. The best they can do is offer up a default “Operating System” to run them - the AWS Console, Google Cloud Console, Microsoft Azure Portal (Dave Cutler literally called Azure a Cloud OS when it began).
Meanwhile, the “undifferentiated heavy lifting” (aka Muck) of wrangling datacenters turned into “undifferentiated heavy lifting” of messing with 5 different AWS services just to set up a best practices workflow.
So increasingly, intermediate providers are rising up to provide a better developer experience and enforce opinionated architectures (like JAMstack):
- AWS Amplify
- Railway (new addition)
Nobody loves these names. It doesn’t tell you the value add of having a second layer. Also the name implies that more layers atop these layers will happen, and that is doubtful.
I think the right name for this phenomenon is Cloud Distros (kinda gave this away in the title, huh). The idea is both that the default experience is not good enough, and that there are too many knobs and bells and whistles to tweak for the average developer to setup a basic best practices workflow.
Ok, I lied - there is no average developer. There are a ton of developers - ~40m, going by GitHub numbers. They don’t all have the same skillset. The argument here is that cloud is going from horizontal, general purpose, off the shelf, to verticalized, opinionated, custom distributions. There are ~300,000 AWS Cloud Practitioners - yet, going by Vercel’s numbers, there are 11 million frontend developers.
In order to cross this “chasm”, the cloud must change shape. We need to develop custom “Distros” for each audience. For the Jamstack audience, we now have Netlify, Amplify, Begin and Vercel. For the Managed Containers crew, we have Render and KintoHub. For the Hack and Learn in the Cloud folks, we have Glitch and Repl.it. What the business nerds call verticalization or bundling, developers call “developer experience” - and it is different things to different people.
What’s funny is these startups all basically run AWS or GCP under the hood anyway. They select the good parts, abstract over multiple services and give us better defaults. This is a little reminiscent of Linux Distros - you can like Ubuntu, and I can like Parrot OS, but it’s all Linux under the hood anyway. We pick our distro based on what we enjoy, and our distros are made with specific developer profiles in mind too.
What we have now isn’t the end state of things. It is still too damn hard to create and deploy full stack apps, especially with a serverless architecture. Serverless cannot proclaim total victory until we can recreate DHH’s demo from 15 years ago in 15 minutes. I have yet to see a realistic demo replicating this. Our users and their frameworks want us to get there, but the platforms need to grow their capabilities dramatically. In our haste to go serverless, we broke apart the monolith - and suffered the consequences - now we must rebuild it atop our new foundations.
Begin and Amplify have made some great steps in this direction - offering integrated database solutions. GitHub Codespaces, Codesandbox, Replit, and Coder.com are putting the IDE in the browser. Darklang takes the integration aaaalll the way down past the IDE and even to the language and cloud infrastructure (!). Render and KintoHub buck the serverless trend, offering a great developer experience for those who need a running server.
There’s probably no winner-takes-all effect in this market - but of course, there can be an Ubuntu. This generation of Cloud Distros is fighting hard to be the one-stop platform for the next wave (even the next generation) of developers, and we all win as a result.
Why IaaS Beat PaaS: From People Who Were There featuring quotes from Werner Vogels, Ben Horowitz, and Jason Warner
Bringing AWS to App Developers, my take on AWS and AWS Amplify
“Heroku’s execution suffered after the acquisition. There was always an annoying “missing 10%” that you couldn’t conveniently do on the Heroku model; that 10% covers ~100% of the enterprise, so AWS gave them exactly what they wanted, which is a horrifically complex 1:1 mapping.” - patio11. “PaaS v1.0 lacked private networking & disk storage”, per Anurag Goel.
DigitalOcean’s App Platform launch in Oct 2020 is a notable departure from the Cloud Distros trend - it isn’t built atop an IaaS:
“A common complaint about pure-play PaaS products is that they are inexpensive, to begin with, but become incredibly pricey as you scale apps. One of the reasons behind this is that these PaaS products run on someone else’s infrastructure, and they often need to pass those costs on to you. App Platform runs on DigitalOcean’s infrastructure, and since we own the infrastructure, we can keep the costs low to optimize costs and resources as you scale.”
Disclosures: I formerly worked at Netlify and have interviewed with some companies mentioned here.