Bloated Clouds, Anyone?

Viktor Rozenko — Fri, 18 Sep 2026 19:25:58 +0000

TL;DR

Conventional cloud platforms had to serve everyone, and they became bloated with features. Chasing the next big thing, they abandoned any attempt at improving developer experience, which is the reason clouds blew up in the first place. Big tech companies have the money to pay for DevOps. The rest of us have to choose between wasting developer time on it or delegating it to an AI agent that can't be held responsible when it all comes crashing down.

You can rent a plain VM, but

regular deployments have to arrive via SSH or some elaborate CI setup (we'll look at the options in the next post),
you'll be paying for more compute than you actually use,
and when your service becomes popular enough to use its entire CPU/RAM allowance, you have to scale it up manually.

You can go serverless and it will scale up and down automatically, but

servers with stateful functionality will underperform (for instance, Next.js has server-side caching, and it doesn't work when you run it as a scale-to-zero container),
Firebase Cloud Functions are public by default and weird to set up (they have their own CLI just to package and deploy them, and only JS/Python are allowed),
a few providers let you create a cloud function right in the cloud console. That's terrible, because it's a piece of code that lives in a weird online editor and isn't type-checked against your latest code changes. You will forget to update it sooner or later, and it will crash with a bug.

Suppose you do want the scalability, smooth CI deploys that just make sense, and all your code living in a GitHub repo you control. Welcome to Kubernetes and the 4,000 lines of YAML config that come with it.

Welcome to provisioning a Docker image registry.
Welcome to setting up Traefik for TLS termination.
Welcome to setting up security groups and service accounts.
Welcome to configuring ingress and egress rules.
Welcome to not understanding why this call from "web" to "api" times out. (Is it egress, ingress, or both? Or is it because the "api" service link you put into the "web" env is cluster-local, and "web" lives in a different cluster?)

I can hear you thinking, "Claude can do that for me, no problem," and you're right... but every time? For every project you start from scratch? And remember, all this setup bought you a nicer dev experience (aside from having to set it up and maintain it), but Kubernetes runs on top of real VMs! So the money problem isn't solved. It might even have gotten worse!

Here's what I came up with

Put your Next.js app on Vercel (for most of us, their $20/mo tier is enough).
Provision managed resources (Postgres, MongoDB, Kafka, RabbitMQ, etc.) from DigitalOcean, Supabase, Scaleway, AWS, or Google Cloud. It doesn't really matter which; they all offer good SLAs.
Put your API on DigitalOcean or Scaleway, either as serverless or on App Platform.
Set up a GitHub Actions workflow (lint + test + build + deploy) as early as possible.

Doing this for every project is still a stretch, but when it's done properly, you can git push to main and it'll just deploy, without having to run your own k8s.

This rant covers only a fraction of what's wrong with today's cloud infra. As a developer, I have to live with it every day. So I said "enough," and now I'm building Gagarin Cloud, where deploying a web app is just:

gg resource add gagarin/pg postgres
gg ship         gagarin/api:8080 --deps pg
gg ship         gagarin/web:3000 --deps api
gg domain   add gagarin/web
# => Live at https://web-3cnciet6.apps.gagarin.cloud/