The cloud got complicated

The first AWS re:Invent was in November 2012. I remember it mostly because that was the year it stopped being a question whether you’d use the cloud and became a question of how much. Amazon had had EC2 and S3 since 2006, so by 2012 both services had been around for six years. Google Compute Engine had just been announced that summer. Azure was around, mostly for Windows shops. Everybody else was buying servers and putting them in a colo, and feeling slightly old-fashioned about it.

What you actually did in 2012, if you used the cloud, was rent virtual machines. You got an Ubuntu box, you SSHed in, you ran a Chef or Puppet script if you were organised and a bash script if you weren’t, and you hoped nobody ever had to rebuild it. Heroku was the exception, and honestly Heroku in 2012 was closer to how I think deployment should feel than most of what came after: git push, done. I liked the convenience less once the bill started growing.

The 2013 and 2014 pile-up

Then in about eighteen months most of the ideas that still run everything showed up.

Docker was shown at PyCon in March 2013. Containers had existed for years (Linux had the pieces, Solaris and FreeBSD had them earlier), but Docker gave them an image format and a one-line command, and that was enough. Suddenly “it works on my machine” was a file you could ship.

Kubernetes was announced by Google in June 2014, with 1.0 in 2015. It answered the question Docker created: fine, I have a hundred containers, now who puts them on machines and restarts them when they die. There were competitors, Mesos and Docker’s own Swarm, and for a couple of years it was a real fight. Kubernetes won, I think mostly because Google gave it away and every cloud could offer it without handing Docker the company any power.

AWS Lambda was announced in November 2014. Upload a function and it runs when something happens, with usage-based billing. “Serverless” is a silly word (there are servers, you just don’t get to see them) and the idea was good. For glue code and event handling it is still the right default.

And Terraform, from HashiCorp, first release in July 2014. Describe your infrastructure in text files, then run plan and apply. Infrastructure as code existed before it, but Terraform made working across clouds feel approachable to me. It stayed the standard for a decade, until HashiCorp changed the licence in 2023 and the community forked it as OpenTofu within weeks. Then IBM bought HashiCorp. The workflow survived all of that. I care more about whether I can still understand the plan.

Managed everything

The pattern from about 2016 onward was simple: whatever you were running yourself, the cloud would soon run for you. Databases first (RDS was old by then, Aurora was announced in 2014). Then Kubernetes itself: Google’s GKE in 2015, AWS’s EKS in 2018, and after that running your own control plane was something you did for fun or for compliance. Then queues, search, caches, secrets, certificates. Then the containers themselves, with Fargate and Cloud Run, so you could have containers without having nodes.

I have mixed feelings. Every managed service removes some work from the on-call list, which is great. It can also make moving harder, with prices set by someone else. The 37signals people made a lot of noise in 2022 and 2023 about leaving the cloud and buying their own servers again, and while I don’t think most companies should copy them, I think they were right that a lot of people never did the maths.

The edge

Cloudflare Workers was announced in 2017: run a bit of JavaScript in every one of their data centres, close to the user, with no cold start to speak of. Vercel (Zeit until 2020) built something similar around Next.js, where the framework knows which parts of your app can run at the edge and which need a real server. For a while everyone was excited about “edge computing” and then it settled into what it actually is: a good place for the first few milliseconds of a request. Auth, redirects, caching, personalisation. The database is still in one region, so the heavy stuff still goes there.

Platform engineering, then the GPUs

By 2022 the average company had so many cloud services, clusters, pipelines and dashboards that developers couldn’t find anything. The answer got a name, platform engineering, and a product category, the internal developer platform. Backstage, the portal Spotify open-sourced, became the usual starting point. A small team builds a nice paved road so the other teams stop building their own. DevOps rebranded, basically. Good rebrand though.

Then in 2023 demand for GPUs became hard to ignore. Companies wanted to train or run models, and Nvidia’s H100 kept coming up in those conversations. Waiting lists ran to months. New clouds appeared that were just GPUs in a warehouse with an API in front, CoreWeave being the big one. The old clouds started designing their own chips in earnest. For about two years the most important question in infrastructure was “can you get me capacity” and everything else came second.

The part I’m watching now is the cost of running the models. Training is still a big deal for a few companies. Inference is everyone’s problem: serving a model to users, or to agents, at a cost that doesn’t sink the business. Batching, prompt caching, quantisation, picking the right chip for the right model. It’s a new kind of capacity planning, and a lot of the people doing it are the same people who used to tune JVMs.

So, from renting a VM in 2012 to renting a slice of a GPU in 2026. Same shape, really. I still think Heroku had it right.