El punto de partida
La gestión cloud en 2026 se parece en la superficie a la de hace tres años (los mismos proveedores, las mismas primitivas, el mismo vocabulario). Por debajo, la forma de la carga de trabajo ha cambiado lo suficiente como para que haya que reescribir el manual de juego.
Las cargas de inferencia, el gasto de GPU, la regulación sobre la residencia de datos y las realidades operativas de ejecutar funcionalidades de IA a escala de producción han hecho pasar el cloud de una conversación de reducción de costes a una conversación de capacidades. El equipo que solo lo ve como una factura que optimizar ya no es competitivo en lo que la aplicación puede hacer.
Este artículo trata de lo que ha cambiado, del aspecto de los nuevos valores por defecto de operación y de la manera en que SDEN aborda los proyectos cloud en este nuevo entorno.
La factura es el síntoma, no la enfermedad
Los sobrecostes cloud en 2026 son casi siempre un problema de arquitectura, no un problema de descuento.
Un patrón de proyecto familiar es el equipo de finanzas que hace aflorar una factura cloud que se ha doblado en seis meses. El reflejo es negociar más duro con el proveedor o perseguir a los culpables evidentes (instancias inactivas, bases de datos sobredimensionadas, snapshots que nadie usa). El reflejo capta ahorros reales en la primera pasada y casi nada en la segunda.
El verdadero motor de los costes en los despliegues cloud de 2026 suele ser estructural: un patrón de carga de trabajo que no corresponde al modelo de tarificación de los recursos sobre los que se ejecuta. Inferencia de IA a ráfagas sobre instancias siempre activas. Consultas analíticas contra la base de datos operativa. Salida de red entre regiones que nadie notó en la revisión de arquitectura. Logs y trazas recopilados en plena fidelidad, conservados indefinidamente.
Corregir la arquitectura produce ahorros de un orden de magnitud. Negociar el contrato produce ahorros de un solo dígito. El orden importa.
Del aprovisionamiento a la capacidad
La ingeniería cloud sigue comprendiendo el trabajo que siempre ha comprendido: diseño de arquitectura, aprovisionamiento por infraestructura como código, automatización del despliegue, observabilidad y la disciplina operativa de operar la producción. Eso es el suelo.
Lo nuevo es la capa por encima del suelo. La planificación de capacidad para cargas de inferencia con perfiles de GPU a ráfagas y costosos. La arquitectura multirregión que respeta la regulación sobre la residencia de datos en un mundo donde las reglas de la UE, EE. UU. y Suiza divergen de forma notable. Modelos híbridos donde la carga operativa se ejecuta sobre el cómputo más barato disponible y el servicio del modelo se ejecuta donde la latencia y la licencia lo permiten. Ninguno de esos elementos estaba en el núcleo del trabajo del ingeniero cloud hace cinco años. Todos lo están ahora.
Los proyectos cloud de SDEN se parecen cada vez más a proyectos de arquitectura (diseñar la forma del despliegue) que a proyectos de aprovisionamiento. El aprovisionamiento está automatizado desde hace años; el diseño, no.
Valores por defecto de operación para una carga moldeada por la IA
Las cargas de IA rompen algunas de las hipótesis sobre las que se apoyan las arquitecturas cloud clásicas. Son a ráfagas en lugar de estables, costosas por llamada en lugar de por byte, dependientes de proveedores de terceros cuya latencia ni disponibilidad controla el arquitecto cloud, y sensibles a dónde se sitúan físicamente los datos de una manera en que el resto de la aplicación no lo es.
Los valores por defecto de operación que funcionan para esa forma son distintos. La caché, el procesamiento por lotes y la degradación elegante en la capa de aplicación se convierten en preocupaciones de primer plano. La abstracción del proveedor en la capa del modelo se vuelve obligatoria, porque cada trimestre el modelo adecuado es un modelo distinto. Y la observabilidad de los costes debe cablearse en la aplicación misma, no solo en la factura cloud, porque la economía unitaria de una funcionalidad de IA se decide por petición y debe ser visible por petición.
Cuando SDEN diseña una arquitectura cloud para un producto que usa la IA, es ahí donde va la mayor parte del trabajo: no en los manifiestos de Kubernetes, sino en la capa que decide lo que pasa cuando el modelo tarda demasiado, cuesta demasiado o devuelve lo equivocado.
Tres valores por defecto en cada proyecto cloud
No entregamos nubes. Entregamos arquitecturas que resulta que se ejecutan sobre una nube. Los pilares de abajo son aquellos a los que nos atenemos.
Infraestructura como código, de extremo a extremo
Cada pieza de la infraestructura se describe en código, versionada, revisada y reproducible. No hacemos producción a clic. Tampoco hacemos preproducción a clic.
Observabilidad de los costes a nivel de funcionalidad
El coste se atribuye a las funcionalidades y se rastrea hasta las peticiones que lo provocaron. Las sorpresas en la factura se convierten en excepciones, no en la norma.
Portabilidad de región y de proveedor donde importa
Elegimos una nube como base de partida, pero la arquitectura mantiene vías de salida abiertas para las cargas que pudieran necesitarlas, por razones de residencia de datos, nube soberana o coste.
La infraestructura en la que el equipo confía para crecer
El éxito cloud es invisible. El equipo usa la infraestructura y deja de pensar en ella.
Una arquitectura cloud que funciona permite al equipo de ingeniería concentrarse en el producto, no en la fontanería. Los despliegues son rutinarios. La factura es predecible, y cuando no lo es, el equipo puede explicar por qué. La capacidad se aprovisiona por delante de la demanda y se desmantela cuando la demanda termina. Se responde a los reguladores con una documentación que se ha generado, no ensamblado a posteriori.
Cuando SDEN termina un proyecto cloud, la prueba es simple: ¿opera el equipo de ingeniería el sistema sin nosotros, cómodamente, seis meses después? Si nos necesita, no hemos hecho el trabajo.
La tecnología bajo el capó importa menos que esa propiedad. Puede ser AWS, GCP, Azure o un híbrido; puede ser Kubernetes, Nomad o sin servidor. Lo que no puede ser es una caja negra que un solo ingeniero entiende.
Cloud
las preguntas que más nos hacen.
Respuestas directas a las preguntas que más nos hacen. Si la tuya no está, escribe al equipo.