--- title: "The cloud-first problem: when fear masquerades as prudence" description: "Cloud was built for uncertain spikes; today it is used by inertia even when a VPS would do. An invitation to choose infrastructure on purpose." date: 2026-07-18 locale: en url: https://escribano.dev/en/blog/004-cloud-first-problem/ --- When Amazon launched EC2 in 2006, the pitch wasn't "put everything in the cloud." It was something else: how much capacity do you need when you don't know? The original cloud story (pay-as-you-go, instances in minutes, scale up and down with demand) addressed a concrete problem. Avoid buying hardware upfront. Don't get caught short if a Digg or Slashdot link multiplies your traffic overnight. Turn fixed costs into variable ones when uncertainty was high. That fit was real. For a startup with no users yet, for a product that might never take off or might explode without warning, for a retailer that needs to absorb Black Friday without running double the servers the rest of the year, elasticity made sense. Cloud wasn't a luxury: it was demand-risk management. The promise was real. Over time it became the default (*cloud-first*) even when demand risk no longer justified the bet. ## Cloud-first is not cloud when it fits **Cloud-first** is an organizational policy: "we start on the hyperscaler and figure it out later." Sometimes that's deliberate and reasonable. Other times it replaces analysis altogether. The distinction matters. Choosing cloud after evaluating load, cost, operations, and reversibility is a technical decision. Choosing cloud because nothing else was considered is inertia with slides. In this post, when I say **hyperscaler**, I mean the large-scale cloud providers that dominate the market: AWS, Azure, and GCP. I'm not criticizing those providers as such, they offer powerful services and, in many contexts, the right choice. I'm criticizing the automatic use of their platform when the load profile doesn't call for it. ## "Nobody ever got fired for buying IBM" There's a phrase attributed to IBM in the 1980s: *"Nobody ever got fired for buying IBM."* It captures an asymmetry that still holds: the career-safe decision doesn't always match the problem-appropriate one. The phrase comes from another era, but it maps cleanly onto hyperscalers. *"Nobody ever got fired for buying AWS"* (or Azure, or GCP) sounds like a joke in a technical meeting, but it describes a real incentive. The cost of choosing too much cloud is diffuse: a vague bill, accumulated complexity, dependency that takes months to become visible. The cost of choosing "too simple" (a VPS, a dedicated server, a Docker Compose deployment) can be personal and immediate: you're labeled a hack, non-scalable, not "serious." Technology choice stops being technical and becomes philosophy driven by fear. You don't pick cloud because the problem demands it; you pick it because simplifying is scary. ## From uncertainty to everything-in-cloud Over time, the original narrative thinned out. Cloud ceased to be the tool for maximum uncertainty and became the default home for almost everything: * Internal apps with bounded users and predictable growth. * Back-office tools with stable month-to-month load. * MVPs that could live on a single server for months. * Systems where the main risk isn't traffic, but budget and operations. Inertia has several sources. Tutorials and certifications that assume cloud. Architecture templates imported from big tech. Consultants whose business model depends on complexity. And a job market that rewards years of AWS on a CV even when the product has a hundred users. None of those forces answer the central question: how much demand uncertainty do I actually have? ## When cloud still makes sense To be fair: there are contexts where hyperscaler is the sensible answer. * **Unpredictable demand**: you don't know whether you'll have ten users or ten million. * **Occasional spikes**: campaigns, events, Black Friday; pay for extra capacity only when needed. * **Managed services you don't want to operate**: complex databases, queues, global CDN, compliance the provider absorbs better than your team. * **Teams that prefer OpEx and fast provisioning** over running their own machines, when the context allows it. In the [post on the RPS principle](/blog/002-rps-principle/) cloud fits **paper**: pay upfront work and complexity for risk control. When the risk is real (failure is expensive, scale is unpredictable, the system will live for years) that paper is authentic. The failure is using paper out of fear when the real cost of failure was low and **rock** would have been enough: a VPS, a simple deployment, sufficient for the context. ## IaaS, serverless, and "scale to zero" Worth not mixing generations. Classic cloud (IaaS: EC2, instances, clusters) offered elasticity with running instances: you scaled fast, but still paid for reserved capacity even when you used little of it. **Scale to zero** (pay only when there are executions) came later with **serverless** (functions, on-demand containers). There the "maybe nobody will use it" argument gets even stronger: you don't keep idle infrastructure. If your load is sporadic or highly irregular, serverless may be the right tool. If your load is stable and predictable, staying on IaaS cloud by inertia loses the original benefit: you keep paying for elasticity you don't need. ## When a VPS is the ideal answer Consider an internal app: inventory management, HR portal, reporting tool. 150 users today; forecast of 300 in two years, linear growth, no seasonal spikes. Modest HTTP traffic, one relational database, an occasional worker. A profile like that doesn't need to absorb a Twitter viral moment. It has no Black Friday. The question "what if I get a million requests tomorrow?" is theoretical, not operational. Running that on a hyperscaler (managed containers, load balancer, managed database, native monitoring, several coupled services) can cost several hundred euros a month before counting the time spent maintaining the cloud template. The same stack on a €20–40/month VPS with backups, reverse proxy, and reproducible deployment is usually enough. Fixed capacity for fixed demand. Why does it end up on AWS anyway? Rarely for technical need. Because "everyone does it," because the previous architect left it there, because nobody wants to defend a VPS on a slide, because *"scaling is free in the cloud"*, until you read the bill. In the RPS framework, that's rock done right: sufficient pragmatism when reversibility is high, failure is bounded, and uncertainty is low. Matching the tool to real risk, not a hack. ## So what would scissors be? So far this post can read like a VPS-versus-cloud binary. But in the [RPS post](/blog/002-rps-principle/) bare metal fits **scissors**: maximum long-term potential, more control, more complexity, more operational risk, chosen on purpose when the context justifies it. On the cloud-first axis, scissors enters when neither rock nor paper quite fit. You don't need hyperscaler elasticity, but a lone VPS isn't enough either: load is large or critical, you want independence from the cloud provider, and you accept operational cost in exchange for your own platform. Typical cases: * **Self-managed owned hardware**: colo servers, dedicated machines, or a home rack when scale and control make it worth it. * **Orchestration on your own infra**: Kubernetes, Nomad, or another platform on metal or VPS you operate, not EKS/GKE/AKS: scale or homogenize services without delegating to the hyperscaler. Kubernetes is a tool, not scissors by definition. K8s on AWS is still paper, cloud with more YAML. K8s on three nodes for a 150-user internal app is usually false scissors: scissors complexity without the benefit. Authentic scissors mean building your platform knowing you own its operations, not deploying it because "it's modern." Scissors aren't the natural next step after discovering a VPS was enough either: it's a different bet, the team that outgrew a simple monolith and needs to scale or orchestrate without anchoring to cloud, or whoever prioritizes sovereignty and cost at scale over managed convenience. ## Fear of simplifying Behind cloud-first there's an unspoken fear: simplifying looks irresponsible. A `docker-compose.yml` on a VPS sounds less "enterprise" than a diagram with seventeen boxes across three regions. But complexity isn't professionalism; sometimes it's noise mimicking safety. More moving parts, more IAM permissions, more failure surface, and the same 150-user app. Simplifying means defending a decision to management, auditors, colleagues used to associating cloud with maturity. It's easier to inherit the default. That's why the IBM line still works: it outsources blame to a brand nobody questions. ## Bridges, anchors, and inertia In the RPS framework, **bridges** are decisions that preserve optionality; **anchors**, vendor lock-in. Accelerated cloud-first often creates anchors: proprietary APIs, services that don't exist outside the provider, data that takes months to migrate. That doesn't invalidate cloud when you need it. But when you chose cloud without needing elasticity, you inherited anchors without buying the benefit. A VPS with free software and standard containers is usually a bridge: tomorrow you can move it, scale vertically, or (if demand truly changes) move to cloud with criteria. Cloud-first inertia also clashes with another theme of this blog: [digital sovereignty](/blog/005-digital-sovereignty/), the ability to decide where your data lives, who operates your infrastructure, and which models process your information. Accumulating hyperscaler dependency by default, without evaluating alternatives, makes that autonomy harder even when you don't care today. ## Choosing consciously I'm not writing this to say cloud is bad or everything should live on a VPS. I'm writing to recover the original question cloud answered well: *how much demand uncertainty do I have?* If the answer is "a lot," elasticity is prudence. If the answer is "little, predictable, internal," staying cloud-first is fear masquerading as prudence: the same logic as "nobody ever got fired for buying AWS," applied to a problem that never needed that scale. What matters is not hiding behind the hyperscaler when rock was the honest decision, using paper when risk is real, and reserving scissors for when the ambition of your own platform is justified, not confused with fashion or fear of the simple option. In the [introduction post](/blog/001-introduction/) I promised to discuss self-hosting and informed decisions against the prevailing *cloud-first* mindset. This post names the problem. Next ones will get concrete (DNS, reverse proxy, identity) with the same criterion: not recipes for their own sake, but knowing what you're paying for when you choose.