The 30-Tab Problem

You want to spin up a VM. Pick a size, attach a disk, give it a public IP, done. That should be one screen and ninety seconds.

Instead you open a tab for the compute service. Then a tab for the VPC, because the VM needs a subnet. Then a tab for the security group, because the subnet needs rules. Then a tab for the gateway, because the rules need a route out. Then a tab for the IAM policy, because your role can’t attach a disk yet. Then a tab for the docs to remember what an “availability domain” is this week. By the time the machine boots you have thirty tabs open and a half-finished certification you never asked for.

How the maze got built

No one designed this. It accreted.

A cloud ships one service. It works. Then it ships another, and another, and after a decade there are two hundred of them, each with its own console, its own nouns, its own pricing page. Nothing was ever removed, because someone, somewhere, depends on it. So the surface area only grows.

The nouns multiply with it. The same idea — “a network your machines live in” — is a VPC here, a virtual network there, a tenancy somewhere else. Egress is metered six different ways depending on which boundary the packet crosses. A “free” API call is free until you make ten million of them. You stop reasoning about your system and start reasoning about the provider’s taxonomy, which is a different and much worse job.

And the pricing follows the same logic. Reserved instances. Spot bids. Committed-use discounts. Savings plans that overlap the reserved instances. You need a spreadsheet, and then you need a person whose job is the spreadsheet.

The cost is not the bill

The obvious cost is money. The real cost is everything around it.

• Onboarding. A new engineer can’t ship for days because the platform itself is the thing they’re learning, not your product.
• Mistakes. Thirty tabs is thirty chances to leave a default wrong. Most cloud breaches aren’t clever attacks — they’re an 0.0.0.0/0 someone left on a security group at 6pm on a Friday.
• Security by exhaustion. When correct setup requires four hours of docs, people stop reading the docs. Complexity isn’t neutral. It actively produces misconfiguration.

Every screen you have to visit is a place to get it wrong. The sprawl isn’t a feature you grew into. It’s a tax you pay forever.

What we did instead

Kaligon ships a deliberately small set of primitives, and we stopped there.

Compute. Block storage and S3-compatible object storage. Networking — VPCs, subnets, firewalls, floating IPs. DNS. That’s the surface. It covers the overwhelming majority of what teams actually run, and it fits in your head.

The defaults are sane, so you don’t have to assemble the safe path from parts. A new VM lands in a working network with a firewall that isn’t wide open. The words mean what they say — a firewall is a firewall, a volume is a volume. Snapshots, backups, API calls, DNS queries, panel access, and support tickets are not line items; they’re just included, so there’s nothing to model.

Pricing is one flat price per resource. No reserved tiers, no spot bidding, no savings-plan algebra. Per-second billing that caps monthly, so a long-running box settles at a fixed price you can say out loud. There is no spreadsheet, because there is nothing to optimize.

The result is boring in the best way. You open the panel, you create the thing, you close the tab. One tab. See it on the pricing page — the configurator is the whole mental model, on one screen.

A cloud should disappear into the background while you build. Ours is trying very hard to be forgettable.