Tu producto necesita salir, pero también necesita seguir funcionando cuando lleguen los primeros clientes, crezca el equipo o falle una dependencia. La arquitectura cloud consiste en decidir qué proteger hoy y qué complejidad merece la pena añadir después.

Este workshop propone tres fases para ordenar esas decisiones: construir una base operable, ganar fiabilidad y demostrar control. No son niveles de prestigio ni una lista de herramientas que haya que comprar. Puedes quedarte en la primera fase durante años si cubre las necesidades del negocio.

La pregunta útil no es «¿qué tecnología nos falta?», sino «¿qué riesgo o limitación necesitamos resolver ahora?».

El mapa: entregar → operar → gobernar

01 · Base operable

Objetivo: publicar y aprender sin depender de una persona ni poner los datos en juego.

Empieza con una aplicación que el equipo entienda, responsabilidades separadas dentro del código y una base de datos con acceso restringido. Elige entre un servicio gestionado o uno operado por tu equipo según presupuesto, experiencia y capacidad real de mantenimiento.

Lo que debe quedar resuelto

• Despliegues repetibles. El código genera un artefacto versionado; conoces qué versión está en producción y cómo volver a la anterior. Los cambios de base de datos necesitan su propio plan de compatibilidad.
• Datos persistentes. Base de datos y archivos sobreviven a la sustitución del contenedor. Una copia solo aporta garantías cuando has probado cómo restaurarla.
• Acceso seguro. HTTPS, secretos fuera del repositorio, permisos mínimos y base de datos fuera del acceso público.
• Visibilidad básica. Logs útiles, comprobaciones de salud y alertas de los fallos que requieren intervención.
• Un límite de gasto. Presupuesto, avisos y una persona responsable de revisar el consumo.

Ejemplo de partida: proxy HTTPS → aplicación → base de datos privada, con archivos en almacenamiento persistente. El pipeline publica versiones; las copias se guardan fuera del fallo que deben cubrir.

Señal para avanzar: los despliegues, los incidentes o la carga empiezan a afectar al servicio de forma medible. «Quizá algún día tengamos mucho tráfico» no es una señal suficiente.

02 · Operación fiable

Objetivo: sostener el servicio cuando crece el uso y reducir el impacto de los fallos.

Antes de añadir infraestructura, mide dónde se consume el tiempo: consultas, dependencias externas, tareas largas, CPU, memoria o almacenamiento. Una consulta optimizada puede resolver un problema que parecía exigir más servidores.

Añade capacidad donde haga falta

• Define qué significa funcionar bien. Por ejemplo: proporción de solicitudes correctas y latencia del recorrido principal. Fija objetivos con el negocio y un periodo de medición.
• Prueba el cuello de botella. Reproduce carga representativa y compara antes y después de cada cambio.
• Separa el trabajo lento. Una cola y workers pueden sacar los procesos largos de las peticiones web. Necesitan reintentos, límites e idempotencia para evitar efectos duplicados.
• Escala con las condiciones resueltas. Varias réplicas requieren tratar sesiones, archivos, tareas programadas y conexiones a la base de datos. Multiplicar contenedores no elimina esos problemas.
• Ensaya la recuperación. Acordad cuántos datos se pueden perder y cuánto puede durar una interrupción; comprobad que la restauración cumple esos límites.

Ejemplo de evolución: balanceador → réplicas de aplicación; procesos largos → cola → workers. La base de datos y los archivos siguen teniendo una estrategia explícita de capacidad y recuperación. La caché se introduce cuando hay un uso concreto y una política de invalidación.

Señal para avanzar: aparecen varios equipos, clientes con exigencias de evidencia o requisitos contractuales que necesitan controles consistentes y responsables identificados.

03 · Control demostrable

Objetivo: poder explicar quién accedió, qué cambió y cómo se recupera el servicio, con evidencias.

La seguridad ya estaba en la primera fase. Aquí formalizas su gestión: los controles dejan de depender de acuerdos informales y pasan a tener responsables, revisiones y registros verificables.

• Identidades y accesos. Revisión periódica de permisos, bajas, cuentas técnicas y acceso de emergencia.
• Cambios trazables. Relaciona una entrega con su código, revisión, pruebas y despliegue. Define quién puede aprobar cambios y cómo gestionar una urgencia.
• Infraestructura reproducible. Versiona la configuración y detecta diferencias entre lo declarado y lo que realmente está ejecutándose.
• Continuidad probada. Registra resultados de restauraciones y ejercicios de fallo, responsables y acciones pendientes.
• Coste y propiedad. Asigna cada servicio a un equipo o responsable, revisa su consumo y retira recursos que ya no hacen falta.

Entregable de esta fase: un mapa de servicios y responsables, un registro de decisiones y evidencias de los controles acordados. Añadir logs o una herramienta de seguridad no demuestra por sí solo el cumplimiento de una norma: hay que comprobar los requisitos aplicables al caso.

Un mismo producto, tres decisiones distintas

Imagina un portal de clientes que permite subir documentos y solicitar informes.

1. Al lanzar: una aplicación, datos persistentes, accesos limitados y una restauración ensayada. El equipo puede publicar sin entrar a configurar el servidor a mano.
2. Cuando crece el uso: los informes bloquean las peticiones. Se procesan en workers; el portal mantiene tiempos de respuesta y cada solicitud se puede reintentar sin generar dos informes.
3. Cuando entran nuevos equipos o contratos: se revisan accesos, se identifica al responsable de cada servicio y se conservan evidencias de cambios y recuperación.

El producto evoluciona porque cambia una necesidad concreta. Ninguna fase obliga a adoptar microservicios, Kubernetes o varias regiones: esas decisiones necesitan su propia justificación y un equipo capaz de operarlas.

El ejercicio: una hoja de ruta en 45 minutos

Hazlo con alguien de producto y alguien que conozca la operación. El resultado debe caber en una página.

1. 10 minutos · Dibuja el sistema. Usuarios, aplicación, datos, archivos y dependencias. Marca dónde hay estado persistente y quién mantiene cada pieza.
2. 10 minutos · Elige el fallo más costoso. ¿Qué ocurre si falla esa pieza hoy? Anota el impacto, cómo se detectaría y cómo se recuperaría.
3. 15 minutos · Decide el siguiente cambio. Define un problema, una medida de éxito y la alternativa más sencilla que pueda resolverlo.
4. 10 minutos · Pon responsable y fecha. Escribe cómo comprobarás el resultado y qué harás si el cambio no funciona.

Tu ficha de decisión: problema → evidencia → cambio propuesto → responsable → fecha → prueba de éxito → plan de vuelta atrás.

Antes de cerrar, comprueba esto

• ¿Sabemos qué versión está en producción y cómo repetir el despliegue?
• ¿Hemos restaurado los datos y archivos, además de hacer copias?
• ¿La próxima inversión resuelve un límite que podemos demostrar?
• ¿Hay alguien responsable de operar y revisar cada componente?

Si no puedes responder a las dos primeras, empieza por la base. Si la base funciona, prioriza el problema que más afecta al cliente. Lo crítico no se improvisa: se diseña, se prueba y se revisa.

Para profundizar

Este modelo de tres fases es una guía de trabajo de YAS. Puedes contrastar las decisiones con el AWS Well-Architected Framework y profundizar en la elección de indicadores y objetivos con el capítulo de objetivos de servicio de Google SRE.