Define la infraestructura que necesita algo más que un prototipo

Empieza por el sistema generado

Considera una plataforma ficticia de prototipos. Crea un contenedor web, una base de datos PostgreSQL gestionada y una URL pública. El flujo funciona correctamente con registros de ejemplo. Es un resultado útil: permite evaluar la función antes de financiar una implementación mayor.

Ahora la empresa quiere almacenar contratos confidenciales y usar su proveedor de identidad de empleados. El sistema necesario ha cambiado. Desplegar correctamente un contenedor no demuestra autorización, tratamiento de datos aprobado, capacidad de recuperación ni responsabilidad sobre el servicio.

Cada plataforma de desarrollo ofrece capacidades distintas. Inspecciona el servicio y la configuración reales. No supongas que todas las herramientas de prototipado tienen los mismos límites ni que un nombre conocido de nube satisface la política de la empresa.

Plantea siete preguntas sobre producción

Las respuestas pueden usar servicios empresariales existentes. No necesitas crear un sistema de identidad o una plataforma de monitorización para cada aplicación. Conecta con las capacidades autorizadas y registra las carencias restantes.

AWS Well-Architected considera conjuntamente operación, seguridad, fiabilidad, rendimiento, coste y sostenibilidad. Recuerda que un despliegue funcional es solo parte de una evaluación de arquitectura. Lee el marco.

Define los límites entre entornos

Identifica los recursos de desarrollo, pruebas y producción. Define qué identidades pueden cruzar esos límites. No copies registros de producción en un entorno de vista previa cómodo sin un proceso de tratamiento autorizado.

Inspecciona las conexiones salientes además del acceso entrante. Una base de datos privada puede alimentar un servicio público de logs a través de la aplicación. Las llamadas del agente de programación al modelo constituyen otro flujo que debe evaluarse por separado.

Registra quién es responsable de la cuenta de nube, DNS, certificado, claves de cifrado y relación de facturación. Un proyecto que depende de la cuenta personal de un empleado que se marcha tiene un problema de responsabilidad, aunque el código de la aplicación esté disponible.

Prueba el reparto de responsabilidades

Un proveedor de base de datos gestionada puede operar el servicio subyacente mientras tu organización controla usuarios, acceso a datos, cambios de esquema y ajustes de conservación. El reparto exacto depende del servicio y del contrato. Pídelo explícitamente.

Para la aplicación de contratos, realiza un ejercicio ficticio de restauración. Mide el tiempo real de recuperación e identifica la posible pérdida de datos. Compara el resultado con el requisito del negocio. Una casilla que diga «copias de seguridad activadas» no aporta la misma prueba.

Prueba también la retirada de acceso. Elimina un empleado ficticio de la fuente de identidades y verifica el cambio de acceso previsto. Incluye sesiones activas, roles de administración e identidades de automatización en el diseño.

Conecta la infraestructura con el sistema de entrega

Las definiciones de infraestructura, la configuración de entornos, los pipelines y el código de la aplicación necesitan cambios coordinados. El agente debe planificar con el entorno real de destino como referencia. De lo contrario, puede generar un despliegue que contradiga los requisitos de red, identidad o responsabilidad.

Aquí se encuentran platform engineering y la fábrica de software. La plataforma aporta capacidades admitidas y límites. El sistema de entrega debe usarlos, producir pruebas y conservar un traspaso operativo claro. Continúa con platform engineering.