Depending on someone else's cloud: what we learned running on one machine

Where we are

Let us be concrete, because generic cloud advice is worth nothing. Our corporate site and several of our services run on a single machine at a European provider: a server with 8 GB of RAM, nginx in front and processes managed by PM2.

This is not an ideological stance or a universal recommendation. It is a decision about size: for the load we carry, one well-maintained machine costs an order of magnitude less than the managed equivalent, and its failure mode is one we understand end to end.

The trade-off is real and worth saying out loud: if that machine goes down, everything on it goes with it. We accept that because the cost of that outage, for our service profile, is lower than the permanent cost of the alternative. That calculation changes the day a customer signs a service-level agreement, and on that day the architecture changes, not the excuse.

The useful question is not "which provider"

When someone asks which cloud to choose, they are usually asking the small question. The large one is: what does it cost me to change my mind in two years?

That figure appears on no invoice, but it can be estimated by looking at three things:

• How many proprietary services you have wired in. A standard managed database migrates. A provider-specific queue product, with its particular semantics, is code that has to be rewritten.
• Where the state lives. Data is the heavy part. Moving 200 GB between clouds is expensive in egress and slow in a maintenance window; moving compute is nearly free by comparison.
• How much of your deployment is provider-specific. If your infrastructure as code describes only one provider, you do not have infrastructure as code. You have that provider, written differently.

None of the three requires moving to the cheapest cloud or avoiding managed services. They require knowing the number. A commitment you have measured is a decision; one you have not is a bet.

The risk nobody models: the counterparty

What The Economist's piece adds is a risk most engineering teams do not have on their spreadsheet: their provider's finances. We are used to modelling outages, latency and regions. We are not used to asking whether the company renting us GPUs can refinance its debt.

With the hyperscalers that question is close to rhetorical. With specialist providers growing fast on leveraged hardware, it is not. And the practical consequence is the same as with any critical supplier: it is not that you must avoid them, it is that you must know what happens to you if they disappear.

A provider you cannot leave is not a provider. It is a partner you did not choose.

What actually breaks is not the machine

After a while operating this way, the list of real incidents looks nothing like the one you imagine before starting. The machine is almost never the problem. A serious provider's hardware holds; what fails is everything around it.

• Certificates expiring. The number one cause of perceived downtime in small installations, and entirely avoidable with automatic renewal and an alert that fires before, not after.
• Deploys stepping on themselves. Building over the directory the server is reading produces intermittent errors during the deploy, on a different route every time. It is the hardest failure to see because it clears up on its own.
• Secrets deleted quietly. A badly scoped file sync can take production environment variables with it while nothing fails at the time. You find out when a form stops delivering.
• Full disk. Unglamorous and surprisingly frequent: logs nobody rotates, backups nobody expires.

All four are process problems, not architecture problems. Moving to a managed cloud solves none of them automatically: it changes their shape. Which is the honest argument for starting simple — an architecture you understand end to end teaches you what actually breaks in your case before you pay to avoid what you assumed would.

What we do, concretely

Our approach comes down to three unheroic rules. First: state is stored in standard formats. Databases and files that can be dumped and restored elsewhere without a translator in between.

Second: the deployment is written down. Ours is a script in the repository, not a sequence somebody remembers. That started as hygiene and ended up being what let us change things without fear — including fixing a bug that had been serving errors during every deploy for weeks without anyone noticing.

Third: the restore is tested, not the backup. A backup nobody has ever restored is a folder with hope in it.