Arquitectura y despliegue
Despliegue en nube pública: qué decides tú y qué gestiona el proveedor
01 · Acceso
- Usuarios por HTTPS
- Equipo técnico con autenticación reforzada
02 · Entrada
- Balanceador con TLS
- Cortafuegos de aplicación
03 · Ejecución
- Contenedores en varias zonas
- Base de datos gestionada
- Gestor de secretos
04 · Operación
- Registros y métricas centralizados
- Alertas de coste y de servicio
05 · Salida
- Exportación periódica de datos
- Infraestructura como código
El problema
Por qué hay que decidirlo bien
Es frecuente que un sistema llegue a la nube sin un diseño de base: cuentas con permisos de administrador compartidos, claves de acceso pegadas en el código, una única zona de disponibilidad y una factura que crece cada mes sin que nadie sepa por qué. Al principio todo funciona, porque el proveedor resuelve lo más visible. Los problemas surgen con el primer incidente, con una auditoría de accesos o cuando dirección pregunta dónde están almacenados los datos de los clientes y nadie puede responder con precisión. Diseñar el despliegue desde el inicio evita tener que rehacerlo con el sistema ya en producción.
Escenarios
Situaciones en las que se plantea
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Aplicación con demanda irregular
Un portal de pedidos tiene picos en campañas concretas y mucha menos actividad el resto del año. Se estudia qué componentes pueden escalar automáticamente y cuáles conviene dimensionar fijos, comparando el coste estimado de ambos enfoques con datos de uso reales.
02
Datos que deben permanecer en una región concreta
El contrato con un cliente exige que la información se almacene dentro del Espacio Económico Europeo. Se elige la región, se revisa qué servicios gestionados replican o procesan datos fuera de ella y se documenta la configuración para poder demostrarla.
03
Sistema nuevo sin equipo propio de sistemas
Una empresa mediana no tiene personal para operar servidores. Los servicios gestionados reducen ese trabajo, pero sigue habiendo que acordar quién revisa alertas, quién aplica cambios de configuración y quién responde ante un incidente fuera de horario.
04
Preparar una salida ordenada
La dirección quiere poder cambiar de proveedor o volver a infraestructura propia si cambian las condiciones. Se priorizan componentes portables, se documentan las dependencias de servicios propietarios y se prueba la exportación completa de datos.
Decisiones técnicas
Qué hay que decidir y con qué criterio
01
Modelo de responsabilidad compartida
Se identifica qué asegura el proveedor (centros de datos, hardware, capa de virtualización) y qué queda del lado del proyecto: sistema operativo si lo hay, configuración de red, permisos, cifrado, copias de datos de la aplicación y actualizaciones.
02
Identidades, permisos y secretos
Cuentas separadas por entorno, acceso de personas con autenticación reforzada, roles de mínimo privilegio para cada servicio y un gestor de secretos en lugar de claves en archivos o variables sin control. Los accesos se revisan periódicamente.
03
Región y redundancia
Se decide en qué región se despliega y si los componentes se reparten entre varias zonas de disponibilidad. Repartir aumenta la resistencia a fallos, pero también el coste y la complejidad; la elección depende de lo que el negocio necesite tolerar.
04
Observabilidad desde el primer despliegue
Registros centralizados, métricas de aplicación y de infraestructura, trazas entre servicios y alertas con un destinatario claro. Sin esto, la elasticidad de la nube oculta problemas en vez de resolverlos.
05
Control de costes variables
Etiquetado de recursos por proyecto y entorno, presupuestos con avisos, revisión de recursos olvidados y estimaciones antes de activar servicios que cobran por volumen de datos, peticiones o transferencia de salida.
06
Reversibilidad y dependencia del proveedor
Infraestructura descrita como código, contenedores donde tenga sentido, formatos de datos abiertos y una lista explícita de servicios propietarios usados, con la alternativa que habría que construir si se abandona cada uno.
Riesgos y límites
Lo que conviene tener presente
- La factura puede crecer de forma inesperada si no se vigila: transferencia de datos, almacenamiento acumulado o recursos que se quedaron encendidos tras una prueba.
- Una configuración errónea de permisos o de almacenamiento expone datos aunque la infraestructura del proveedor sea sólida; la mayoría de incidentes nacen de la configuración del cliente.
- Elegir una región no resuelve por sí solo la residencia de datos: soporte, copias, registros o servicios auxiliares pueden procesar información en otros lugares según las condiciones del proveedor.
- Cuantos más servicios propietarios se usen, más cuesta cambiar de proveedor; no siempre es un error, pero debe ser una decisión consciente.
Preguntas frecuentes
¿La nube pública es siempre más barata que un servidor propio?
No. Suele serlo cuando la demanda varía mucho o cuando evita contratar operación de sistemas, pero una carga estable y alta puede salir más cara a medio plazo. Conviene estimar el coste con el uso previsto y revisarlo tras los primeros meses.
¿Quién es responsable si hay una brecha de seguridad?
Depende de dónde se produzca. El proveedor responde de su infraestructura según sus condiciones; la configuración, los permisos y los datos de la aplicación son responsabilidad de quien despliega y opera el sistema. Por eso el reparto debe quedar escrito en cada proyecto.
¿Con qué proveedor de nube trabajáis?
La elección se hace en cada proyecto según requisitos de región, servicios necesarios, coste y la infraestructura que ya use la empresa. No partimos de un proveedor fijo y procuramos que la arquitectura no quede atada a uno sin necesidad.
Sectores, capacidades y lecturas relacionadas
Sectores donde se plantea
Capacidades relacionadas
- Arquitectura SaaSBases técnicas para un producto de software que sirve a muchos clientes: aislamiento, suscripciones, administración y control de costes.
- Seguridad de aplicacionesControles de seguridad pensados desde el diseño de cada aplicación: amenazas identificadas, secretos protegidos, dependencias vigiladas y pruebas en el ciclo de desarrollo.
- Identidad y permisosModelos de permisos que dan a cada persona acceso solo a lo que necesita, separan organizaciones y dejan registro de las acciones relevantes.
Más en arquitectura y despliegue
Cuéntanos qué quieres desplegar y qué requisitos de datos y coste tienes
Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.