This week I've been moving an Elixir application from Fly to Gigalixir. It shouldn't have taken a week except that I hate this kind of work, so I find all kinds of other things to do instead. Been getting a lot of writing done. Started lifting weights.
The whole time I'm doing it I'm wondering, why? Why not just move straight onto AWS or GCP? Sure, I hate writing the Terraform but – we probably will, if this thing ever gets any real revenue. I like Gigalixir fine but it's basically a convenient wrapper around Kubernetes and Cloud SQL. Useful for getting started, sure, but honestly what I'd like is to be running the BEAM directly on EC2 instances – and to be able to configure everything about the database myself. I don't need a platform for that. Mostly the platform gets in the way. Mainly it's a way to avoid writing Terraform for something I'm not sure if I'll still be working on in six months.
I spent five years working on platforms. There are times they're appropriate and problems they solve really well. But except for that job, where I was on the inside of the thing – platforms have largely been absent. I've worked with exactly one client that had their application deployed to Heroku – a tiny early stage startup with like, two engineers. I've worked with a client since then that built their own internal platform but even that was a kind of esoteric use case. For the most part, software as a service companies build their own, bespoke infrastructure, and that seems to work fine for them.
We moved in the first place because Fly doesn't give us a managed database. I could have set up a managed database on some other service and connected the Fly application to it, but, like, why? Why have two vendors, my credit card in two places, two relationships to manage, two sources of problems, when I can just switch over to a platform that does provide a managed database?
That same logic cascades out, fractal-like, until you bottom out on straight AWS, paying the Terraform tax and liking it.
I see some point to special-purpose platforms. Webflow, for instance – that's a platform. Square is a platform. Shopify is a platform. Platforms integrated with business logic, where I'm getting something other than automated provisioning of infrastructure components – sure.
Maybe I'm just thinking this way because I can do automated provisioning of infrastructure components – I'm undervaluing my own skillset. But what decent-sized company doesn't have that skill set, somewhere?
And I can see some purpose, in some cases, to internal platforms. Highly regulated industries where applications must meet certain security standards – sure. Build the platform, get the authorization to operate, now you can automatically certify everything on the platform, fantastic.
Again. There's some kind of value add, something beyond, "You don't have to set up your own Docker registry!"
So much of "platform engineering" treats the application process itself as the main event. Sure, great, you make it easy for me to run hundreds of Nginx's with whatever-the-fuck behind them, and restart and blue-green deploy and autoscale. Great. That's not my performance bottleneck.
I have never seen a company whose problem with their application was that they couldn't throw enough memory or CPU at the application server itself. The problem is always the database. And platforms tend to treat the data services as an afterthought. You get them from somewhere and you hook them up to your lovingly-orchestrated containers.
I hope I'm wrong. I like the promise of platforms. I like working on platforms. The basic idea – solve these problems for every app, once, and do it right – seems solid. They absolutely make experimenting easier – I'm glad that Fly and Gigalixir and Render all exist.
But I increasingly see them as kind of a niche technology, useful for a subset of the industry under some conditions. That "niche" happens to contain "Google," so we've gone through a period of mania for them. But I wonder if the long term direction for most applications isn't "bespoke infrastructure, built out of generic components."