Arquitectura cloud
La arquitectura cloud es un diseño operacional, no una elección de hosting.
Un mapa práctico para contexto de carga, compute, datos, red, identidad, secretos, ambientes, servicios gestionados, escalabilidad, resiliencia, observabilidad, seguridad, costes y evolución.Definición
La arquitectura cloud es el conjunto de decisiones estructurales y operacionales que define cómo se despliegan, protegen, observan, escalan y evolucionan las aplicaciones, los datos y la infraestructura mediante capacidades cloud. Cloud no significa automáticamente microservicios, serverless ni infraestructura global. Mover una aplicación a una máquina virtual no basta; la arquitectura está en las decisiones operativas y sus trade-offs.
Por qué importa la arquitectura cloud
Cloud afecta disponibilidad, despliegue, recuperación, seguridad, escalabilidad, velocidad de entrega, coste, observabilidad, integración y responsabilidad del equipo. Puede reducir carga operativa cuando los servicios gestionados encajan, pero también puede sumar complejidad, dependencia y coste si se eligen servicios por moda.
Problemas que ayuda a aclarar
- Se elige infraestructura antes de entender la carga de trabajo.
- Deployment, release, rollback y migraciones se tratan como el mismo problema.
- Secretos y configuración se copian entre ambientes sin propiedad clara.
- Se adoptan servicios gestionados sin entender límites, observabilidad o coste de migración.
- La escala se piensa solo como tráfico y se ignoran datos, colas, integraciones y costes.
- La confiabilidad se describe como uptime sin rutas de restore o degradación.
- Se acumulan logs sin responder preguntas operativas ni proteger datos sensibles.
- El coste aparece como sorpresa porque arquitectura y capacidad se separaron.
Carga de trabajo y contexto
Las decisiones cloud comienzan por tipo de aplicación, tráfico, criticidad, sensibilidad de datos, latencia, geografía, presupuesto, frecuencia de despliegue, integraciones, crecimiento y capacidad técnica. Un producto en validación no debería heredar la complejidad de una plataforma madura.
- Diseñar para riesgo y crecimiento reales.
- Evitar elegir desde catálogos de proveedores antes de nombrar requisitos.
- Separar validación de producto de necesidades de plataforma.
Modelo de compute
Compute puede ser máquinas virtuales, containers, funciones serverless, plataformas gestionadas, hosting estático, edge o modelos híbridos. Cada opción cambia control, operación, escalado, cold starts, portabilidad, complejidad, coste y observabilidad.
- No asumir que containers o serverless son mejores por defecto.
- Usar hosting estático o plataformas gestionadas cuando la carga es simple.
- No afirmar necesidad de Kubernetes sin evidencia pública.
Datos y almacenamiento
Datos cloud incluye relacional, documentos, object storage, cachés, colas, backups, replicación, lifecycle, retención, recovery, propiedad, consistencia y migraciones. La decisión depende de patrones de acceso, operación y riesgo.
- Diseñar restore, no solo backups.
- Tratar colas y cachés como decisiones con fallas propias.
- Usar Firebase solo como ejemplo gestionado relevante.
Red y límites
Networking define exposición pública o privada, APIs, ingress, egress, DNS, TLS, firewalls, límites de servicio, origin, CDN, proxy, comunicación interna e integraciones externas. Reducir exposición es arquitectura.
- Hacer explícitos los puntos públicos.
- Separar responsabilidades de CDN, proxy y origin.
- No exponer servicios internos si una API basta.
Identidad y acceso
La arquitectura cloud debe distinguir autenticación de aplicación de acceso a infraestructura. Usuarios, servicios, roles, permisos, least privilege, identidades de máquina, acceso administrativo, ambientes, rotación y auditoría deben estar nombrados.
- Separar login de usuario de permisos cloud.
- Aplicar least privilege a personas y servicios.
- Mantener acceso administrativo auditable.
Configuración y secretos
Configuración incluye variables de ambiente, valores runtime o build-time, desarrollo local, CI/CD y deployment. Los secretos necesitan almacenamiento controlado, límites de acceso, rotación y protección frente a source control o builds públicos.
- No tratar .env local como estrategia completa.
- Mantener secretos fuera del código y del output público.
- Planificar rotación por ambiente.
Ambientes y despliegue
Development, staging, production y preview deben aislarse lo suficiente para proteger datos y confianza de release sin volverse teatro operacional. Deployment mueve software; release expone comportamiento.
- Mantener artifacts y configuración predecibles.
- Planificar rollback y migraciones juntos.
- No forzar ambientes complejos en proyectos simples.
Servicios gestionados
Los servicios gestionados reducen mantenimiento, aceleran entrega e integran disponibilidad, pero traen límites, pricing, observabilidad, configuración, dependencia y coste de migración. Managed no siempre es más barato.
- Usarlos cuando reducen riesgo operativo real.
- Entender límites antes de depender de ellos.
- Aceptar lock-in útil de forma deliberada.
Escalabilidad
Escalabilidad incluye vertical, horizontal, stateless workloads, colas, caché, concurrencia, autoscaling, rate limits, backpressure, bottlenecks de datos y coste. Puede significar más usuarios, datos, integraciones, tenants, regiones, equipos o procesos.
- Medir bottlenecks antes de sumar infraestructura.
- Usar colas y backpressure cuando lo síncrono se vuelve frágil.
- No recomendar microservicios automáticamente.
Confiabilidad y resiliencia
La confiabilidad requiere pensar fallas: retries, timeouts, colas, redundancia, backups, restore, degradación, health checks, rollback, dependencias y disaster recovery. No toda app necesita multi-region.
- Diseñar restore, no solo backups.
- Usar degradación cuando disponibilidad total no es realista.
- Ajustar objetivos al impacto de negocio.
Observabilidad
Observabilidad debe responder preguntas operativas con logs, métricas, traces, alertas, health, versión, correlación, latencia, fallas, costes y contexto de usuario o tenant cuando corresponde. Más logs no siempre ayudan.
- Recolectar señales útiles para decisiones.
- Correlacionar frontend, backend y release cuando aporte.
- Evitar registrar datos sensibles.
Seguridad
La seguridad cloud incluye responsabilidad compartida, least privilege, cifrado, secretos, patching, exposición de red, dependencias, backups, auditoría, logging, minimización de datos, incident response y límites de ambiente. No implica seguridad absoluta.
- Minimizar exposición y privilegios.
- Hacer visibles límites de seguridad en deployment y operación.
- No afirmar certificaciones sin evidencia.
Coste y capacidad
Arquitectura y coste se conectan por costes fijos y variables, recursos idle, pricing por request, storage, transfer, logging, servicios gestionados, scaling, budgets, alertas y capacity planning.
- Rastrear drivers de coste temprano.
- Usar budgets y alertas como controles.
- Tratar capacidad como parte de arquitectura.
Portabilidad y dependencia de proveedor
Lock-in no siempre es malo y evitarlo totalmente tampoco es gratis. Portabilidad implica managed services, abstracciones, coste de migración, simplicidad operativa, protocolos estándar y capacidades específicas.
- Evitar capas abstractas sin riesgo real.
- Usar protocolos estándar donde mantengan opciones.
- Documentar coste de migración.
Evolución y deuda técnica
La infraestructura acumula deuda: drift, recursos sin uso, runtimes antiguos, permisos crecientes, deploys manuales, ambientes inconsistentes, upgrades, migraciones y servicios deprecados. Replatforming rara vez es la primera respuesta.
- Limpiar infraestructura sin uso.
- Automatizar operaciones repetibles.
- Evolucionar cloud con madurez de producto y equipo.
Cuándo no sobrearquitecturar
Un sitio estático, producto con poco tráfico, equipo pequeño, datos simples o presupuesto limitado puede necesitar hosting estático, backend gestionado, base administrada o pocas funciones serverless, no una plataforma distribuida compleja.
- Usar complejidad proporcional.
- Preferir deployment simple si el riesgo es bajo.
- No ignorar seguridad, backups u observabilidad básica.
Principios
Diseñar desde la carga
El catálogo del proveedor es insumo, no estrategia. La carga define la forma operacional.
- Nombrar tráfico, datos, latencia y equipo.
- Elegir servicios después de aclarar requisitos.
Usar managed por riesgo real
Managed services son más útiles cuando quitan mantenimiento que el equipo no debería poseer.
- Usarlos deliberadamente.
- Entender límites y migración.
Explicitar identidad y acceso
Los sistemas cloud necesitan permisos claros para personas y máquinas.
- Separar usuarios de infraestructura.
- Auditar caminos administrativos.
Tratar la falla como esperada
Dependencias, deploys y redes fallan. La arquitectura necesita recuperación.
- Planificar retries y timeouts.
- Probar restore.
Ambientes reproducibles
Las diferencias entre ambientes deben ser intencionales y visibles.
- Aislar configuración.
- Evitar drift manual.
Observar antes de escalar
Escalar sin señales suele mover el bottleneck o subir coste.
- Medir latencia, errores y capacidad.
- Escalar la parte limitada.
El coste es arquitectura
La arquitectura decide comportamiento de coste con storage, compute, logs, transfer e idle capacity.
- Agregar budgets y alertas.
- Revisar coste con patrones de uso.
Decisiones arquitectónicas clave
Modelo de compute
Pregunta: ¿dónde corre la carga? VMs, containers, serverless, plataformas gestionadas y hosting estático cambian operación, coste y escala. Riesgo: elegir un modelo que el equipo no puede operar.
- Ajustar compute a la carga.
- Mantener el modelo viable más simple.
Deployment y release
Pregunta: ¿cómo llega el código a producción y se expone al usuario? Trade-off: velocidad frente a rollback y migración. Riesgo: cada deploy se vuelve incidente manual.
- Separar deployment de release.
- Planificar rollback y migraciones.
Data stores
Pregunta: ¿qué almacenamiento encaja con acceso y recovery? Trade-off: conveniencia gestionada frente a límites. Riesgo: datos difíciles de recuperar o evolucionar.
- Elegir por comportamiento de datos.
- Diseñar backups y lifecycle.
Exposición de red
Pregunta: ¿qué debe ser público, privado o proxied? Trade-off: accesibilidad frente a superficie de ataque. Riesgo: capacidades internas expuestas accidentalmente.
- Exponer solo entradas necesarias.
- Clarificar CDN, proxy y origin.
Identidad y acceso
Pregunta: ¿quién puede operar cada capacidad? Trade-off: conveniencia frente a auditoría. Riesgo: permisos crecen hasta volverse ilegibles.
- Modelar identidades humanas y de máquina.
- Rotar y revisar credenciales.
Estrategia de ambientes
Pregunta: ¿cuántos ambientes se necesitan? Trade-off: confianza frente a coste operativo. Riesgo: staging no se parece a producción o datos se filtran.
- Aislar según riesgo.
- Hacer diferencias intencionales.
Managed o self-managed
Pregunta: ¿qué responsabilidades toma el proveedor? Trade-off: menos mantenimiento frente a límites. Riesgo: el equipo posee demasiada operación o queda atado a una mala elección.
- Aceptar lock-in útil.
- Evitar self-managed sin capacidad.
Objetivo de confiabilidad
Pregunta: ¿qué fallas debe soportar el sistema? Trade-off: resiliencia frente a coste. Riesgo: gastar en fallas imaginarias o ignorar fallas reales.
- Definir por impacto de negocio.
- Diseñar degradación.
Modelo de observabilidad
Pregunta: ¿cómo sabrá el equipo qué ocurre? Trade-off: señal frente a ruido, coste y privacidad. Riesgo: incidentes sin contexto o logs sensibles.
- Nombrar preguntas operativas.
- Recolectar señales seguras.
Controles de coste
Pregunta: ¿cómo se traduce uso en gasto? Trade-off: elasticidad frente a previsibilidad. Riesgo: el coste escala más rápido que el valor.
- Agregar budgets y alertas.
- Revisar capacidad idle y logs.
Perspectivas futuras en desarrollo
Estos temas están planificados bajo el hub de arquitectura cloud. Todavía no son rutas públicas.
- Serverless, containers o managed platforms: cómo decidir.
- Arquitectura cloud es más que hosting.
- Cómo diseñar ambientes production, staging y preview.
- Cuándo los servicios gestionados valen el lock-in.
- Confiabilidad sin complejidad multi-region prematura.
- El coste como requisito arquitectónico.