--- title: "El problema del cloud-first: cuando el miedo disfraza de prudencia" description: "El cloud nació para picos inciertos; hoy se usa por inercia aunque un VPS bastara. Una invitación a elegir infraestructura con conciencia." date: 2026-07-18 locale: es url: https://escribano.dev/es/blog/004-cloud-first-problem/ --- Cuando Amazon lanzó EC2 en 2006, el discurso no era "mete todo en la nube". Era otro: ¿cuánta capacidad necesitas si no lo sabes? El pitch original del cloud (pay-as-you-go, instancias en minutos, escalar arriba y abajo según la demanda) respondía a un problema concreto. Evitar comprar hardware por adelantado. No quedarte corto si un enlace en Digg o Slashdot te multiplica el tráfico de la noche a la mañana. Convertir costes fijos en costes variables cuando la incertidumbre era alta. Ese encaje era real. Para una startup sin usuarios, para un producto que podía no despegar o explotar sin aviso, para un comercio que necesita absorber el pico de Black Friday sin mantener el doble de servidores el resto del año, la elasticidad tenía sentido. El cloud no era un lujo: era gestión del riesgo de demanda. La promesa era real. Con el tiempo se convirtió en default (*cloud-first*) incluso cuando el riesgo de demanda ya no justificaba la apuesta. ## Cloud-first no es cloud cuando toca **Cloud-first** es una política organizacional: "empezamos en el hyperscaler y ya veremos". A veces es deliberada y razonada. Otras veces sustituye al análisis. La distinción importa. Elegir cloud después de evaluar carga, coste, operación y reversibilidad es una decisión técnica. Elegir cloud porque no se contempló otra cosa es inercia con PowerPoint. En este post, cuando digo **hyperscaler**, me refiero a los proveedores cloud de gran escala que concentran la mayor parte del mercado: AWS, Azure y GCP. No critico a esos proveedores en sí, ofrecen servicios potentes y, en muchos contextos, la opción correcta. Critico el uso automático de su plataforma cuando el perfil de carga no lo pide. ## "Nunca han despedido a nadie por contratarnos" Existe una frase atribuida a IBM en los años ochenta: *"Nunca han despedido a nadie por contratarnos"* (*Nobody ever got fired for buying IBM*). Resume una asimetría que sigue vigente: la decisión segura para la carrera no siempre coincide con la decisión adecuada para el problema. La frase nació en otro contexto, pero encaja de sobra en el de los hyperscalers. *"Nadie ha despedido a nadie por contratar AWS"* (o Azure, o GCP) suena a broma en una reunión técnica, pero describe un incentivo real. El coste de elegir cloud de más se reparte: factura difusa, complejidad acumulada, dependencia que tarda meses en hacerse visible. El coste de elegir "demasiado simple" (un VPS, un servidor dedicado, un despliegue con Docker Compose) puede ser personal e inmediato: te tachan de chapucero, de no escalar, de no ser "serio". Así, la elección de tecnología deja de ser técnica y pasa a ser filosófica por miedo. No se elige cloud porque el problema lo exige; se elige porque simplificar da miedo. ## De la incertidumbre al todo-en-cloud Con los años, el relato original se diluyó. El cloud dejó de ser la herramienta para la incertidumbre máxima y se convirtió en el sitio por defecto para casi todo: * Aplicaciones internas con usuarios acotados y crecimiento predecible. * Herramientas de backoffice con carga estable mes a mes. * MVPs que podrían vivir en un solo servidor durante meses. * Sistemas donde el mayor riesgo no es el tráfico, sino el presupuesto y la operación. La inercia tiene varias fuentes. Tutoriales y certificaciones que asumen cloud. Plantillas de arquitectura importadas de big tech. Consultores cuyo modelo de negocio depende de la complejidad. Y un mercado laboral que premia años de experiencia en AWS en el CV aunque el producto tenga cien usuarios. Ninguna de esas fuerzas responde a la pregunta central: ¿cuánta incertidumbre de demanda tengo realmente? ## Cuándo el cloud sigue teniendo sentido Ser justos: hay contextos donde hyperscaler es la respuesta sensata. * **Demanda impredecible**: no sabes si tendrás diez usuarios o diez millones. * **Picos puntuales**: campañas, eventos, Black Friday; pagar capacidad extra solo cuando hace falta. * **Servicios gestionados que no quieres operar**: bases de datos complejas, colas, CDN global, compliance que el proveedor absorbe mejor que tu equipo. * **Equipos que prefieren OpEx y velocidad de provisión** a operar máquinas propias, y el contexto lo permite. En el [post sobre el principio RPS](/blog/002-rps-principle/) cloud encaja en **papel**: pagar trabajo y complejidad inicial a cambio de control del riesgo. Cuando el riesgo es real (el fallo es caro, la escala es impredecible, el sistema vivirá años) ese papel es auténtico. El fallo está en usar papel por miedo cuando el coste real del fallo era bajo y bastaba **piedra**: un VPS, un despliegue simple, suficiente para el contexto. ## IaaS, serverless y "escala a cero" Conviene no mezclar generaciones. El cloud clásico (IaaS: EC2, instancias, clústeres) ofrecía elasticidad con instancias encendidas: escalabas rápido, pero seguías pagando por capacidad reservada aunque la usaras poco. La **escala a cero** (pagar solo cuando hay ejecuciones) llegó más tarde con el modelo **serverless** (funciones, contenedores bajo demanda). Ahí el argumento de "puede que nadie lo use" cobra aún más fuerza: no mantienes infraestructura inactiva. Si tu carga es esporádica o muy irregular, serverless puede ser la herramienta correcta. Si tu carga es estable y predecible, seguir en IaaS cloud por inercia pierde el beneficio original: sigues pagando elasticidad que no necesitas. ## Cuando un VPS es la respuesta ideal Piensa en una aplicación interna: gestión de inventario, portal de RR. HH., herramienta de reporting. 150 usuarios hoy; previsión de 300 en dos años, crecimiento lineal, sin picos estacionales. Tráfico HTTP modesto, una base de datos relacional, un worker ocasional. Un perfil así no necesita absorber un viral de Twitter. No tiene Black Friday. La pregunta "¿y si mañana tengo un millón de peticiones?" es teórica, no operativa. Montar eso en un hyperscaler (contenedores gestionados, balanceador, base de datos administrada, monitorización nativa, varios servicios acoplados) puede costar varios cientos de euros al mes sin incluir el tiempo de quien mantiene la plantilla cloud. El mismo stack en un VPS de 20–40 €/mes con backups, reverse proxy y despliegue reproducible suele bastar. Es capacidad fija para demanda fija. ¿Por qué entonces acaba en AWS? Rara vez por necesidad técnica. Porque "así lo hace todo el mundo", porque el arquitecto anterior lo dejó ahí, porque nadie quiere defender un VPS en una slide, porque *"escalar es gratis en la nube"*, hasta que miras la factura. En el marco RPS, eso es piedra bien entendida: pragmatismo suficiente cuando la reversibilidad es alta, el fallo es acotado y la incertidumbre es baja. Es ajustar la herramienta al riesgo real, no una chapuza. ## Y entonces, ¿qué serían tijeras? Hasta aquí el post puede leerse como un binomio VPS versus cloud. Pero en el [post RPS](/blog/002-rps-principle/) bare metal encaja en **tijeras**: máximo potencial a largo plazo, más control, más complejidad, más riesgo operativo, elegido a propósito cuando el contexto lo justifica. En el eje cloud-first, tijeras entra cuando ni piedra ni papel encajan del todo. No necesitas la elasticidad de un hyperscaler, pero tampoco te basta un VPS suelto: la carga es grande o crítica, quieres independencia del proveedor cloud, y aceptas pagar operación a cambio de una plataforma propia. Casos típicos: * **Hardware propio autogestionado**: servidores en colo, dedicados o un rack en casa cuando la escala y el control lo compensan. * **Orquestación sobre infra propia**: Kubernetes, Nomad u otra plataforma sobre metal o VPS que tú operas, no EKS/GKE/AKS: escalas u homogeneizas servicios sin delegar en el hyperscaler. Kubernetes es una herramienta, no tijeras por definición. K8s en AWS sigue siendo papel, cloud con más YAML. K8s en tres nodos para la app interna de 150 usuarios suele ser falsas tijeras: complejidad de tijeras sin el beneficio. Las tijeras auténticas consisten en construir tu plataforma sabiendo que asumes su operación, no montarla porque "es lo moderno". Tijeras tampoco es el siguiente paso natural tras descubrir que un VPS bastaba: es otra apuesta, la del equipo que ya superó el monolito simple y necesita escalar u orquestar sin anclarse al cloud, o la de quien prioriza soberanía y coste a escala sobre comodidad gestionada. ## Miedo a simplificar Detrás del cloud-first hay un miedo poco dicho: simplificar parece irresponsable. Un `docker-compose.yml` en un VPS suena menos "enterprise" que un diagrama con diecisiete cajas en tres regiones. Pero la complejidad no es profesionalidad; a veces es ruido que imita seguridad. Más piezas móviles, más permisos IAM, más superficie de fallo, y la misma aplicación de 150 usuarios. Simplificar exige defender una decisión ante dirección, ante auditores, ante compañeros acostumbrados a asociar cloud con madurez. Es más cómodo heredar el default. Por eso la frase de IBM sigue funcionando: externaliza la culpa hacia una marca que nadie cuestiona. ## Puentes, anclas e inercia En el marco RPS, los **puentes** son decisiones que mantienen opcionalidad; las **anclas**, vendor lock-in. El cloud-first acelerado suele crear anclas: APIs propietarias, servicios que no existen fuera del proveedor, datos que migrar cuesta meses. Eso no invalida el cloud cuando lo necesitas. Pero cuando elegiste cloud sin necesidad de elasticidad, heredaste anclas sin haber comprado el beneficio. Un VPS con software libre y contenedores estándar suele ser un puente: mañana puedes moverlo, escalarlo verticalmente o, si la demanda cambia de verdad, subir al cloud con criterio. La inercia cloud-first también choca con otro eje de este blog: la [soberanía digital](/blog/005-digital-sovereignty/), la capacidad de decidir dónde viven tus datos, quién opera tu infraestructura y qué modelos procesan tu información. Acumular dependencia de un hyperscaler por default, sin evaluar alternativas, dificulta esa autonomía aunque hoy no te importe. ## Elegir con conciencia No escribo esto para decir que el cloud es malo ni que todo debería vivir en un VPS. Escribo para recuperar la pregunta original que el cloud respondía bien: *¿cuánta incertidumbre de demanda tengo?* Si la respuesta es "muchísima", la elasticidad es prudencia. Si la respuesta es "poca, predecible, interna", seguir en cloud-first es miedo disfrazado de prudencia: la misma lógica de "nadie ha despedido a nadie por contratar AWS", aplicada a un problema que nunca necesitó esa escala. Importa no esconderse detrás del hyperscaler cuando piedra era la decisión honesta, usar papel cuando el riesgo es real, y reservar tijeras para cuando la ambición de plataforma propia esté justificada, no confundida con moda ni con miedo a lo simple. En el [post de presentación](/blog/001-introduction/) prometí hablar de autoalojamiento y de decisiones informadas frente al *cloud-first* imperante. Este post nombra el problema. Los siguientes bajarán a herramientas concretas (DNS, reverse proxy, identidad) con el mismo criterio: no recetas por recetas, sino saber qué estás pagando cuando eliges.