Servicios cloud en AWS, Google Cloud y Azure
Diseño e implementación cloud-native con infraestructura como código.
Arquitecturas sin servidor que escalan sin sobresaltos y una factura que se entiende. Terraform o Pulumi para que la infraestructura esté versionada y se pueda reconstruir, y con las transferencias internacionales de datos documentadas, que es donde mira el RGPD.
Para quién es
- Startups que salen de Heroku o Vercel
- Empresas migrando on-premise a cloud
- Equipos que necesitan IaC y CI/CD maduro
Por qué acaba haciendo falta
La factura de la nube casi nunca sube por una decisión: sube por acumulación. Alguien levantó un entorno de pruebas para una demo y sigue encendido, una base de datos se dimensionó para un pico de hace dos años, los registros se guardan sin caducidad. Ninguna de esas cosas es un error, y juntas son la mitad del recibo.
El otro síntoma llega antes: nadie sabe reconstruir la infraestructura. Se montó a clics, la persona que la montó explicó lo esencial de palabra, y ahora cambiar una regla de red da miedo porque no se sabe qué depende de ella. El día que hay que auditarla, migrarla o recuperarla de un desastre, esa falta de plano cuesta semanas.
Ahí es donde importa que la infraestructura esté escrita. No por ortodoxia: porque un fichero versionado se lee, se revisa antes de aplicarse, se despliega igual en pruebas que en producción y se puede volver atrás. Y porque las transferencias internacionales de datos, que es lo primero que mira una auditoría de protección de datos, quedan documentadas por el propio código en vez de en la memoria de alguien.
Qué entrego
- Arquitectura documentada — Diagrama C4, decisiones (ADRs) y diagramas de red.
- Infraestructura como código — Terraform modular con entornos dev/staging/prod.
- CI/CD — GitHub Actions o GitLab CI con deploy canario.
- Observabilidad — Logs, trazas, métricas y alertas.
- Optimización de costes — Análisis mensual de spend y recomendaciones.
- Copias y recuperación probada — Respaldo automático y una restauración ensayada, con su tiempo medido.
Qué incluye
- Diseño de la arquitectura
- Migración y puesta en marcha
- Optimización del gasto
- Documentación y traspaso
Lo que se decide antes de escribir una línea
- Sin servidor o contenedores — No es una cuestión de moda. Las funciones sin servidor salen muy baratas con tráfico irregular y se vuelven caras y difíciles de depurar con carga sostenida; los contenedores cuestan un mínimo fijo y no te sorprenden. Se decide mirando el perfil de tráfico real, no el que se espera tener algún día.
- Un proveedor o varios — Repartirse entre dos nubes suena a prudencia y multiplica el trabajo por dos: dos formas de hacer red, dos de gestionar permisos, dos facturas que cuadrar. Se diseña para que mudarse sea posible y se dice explícitamente qué piezas son propias del proveedor, que no es lo mismo que no usar ninguna.
- Dónde viven los datos — La región no se elige por latencia solamente. Sacar datos personales fuera del Espacio Económico Europeo obliga a documentar la transferencia y a justificar las garantías, y eso condiciona qué servicios gestionados se pueden usar. Se decide antes de construir porque después implica mover datos con el sistema en marcha.
- Qué se rompe primero — Antes de optimizar nada se define qué significa que el sistema esté caído y cuánto tiempo es tolerable. Sin eso, la alta disponibilidad se convierte en gastar de más por todas partes; con eso, se invierte donde de verdad duele y el resto se deja simple.
Lo que no entra
- El coste de la propia nube, que se contrata a tu nombre y con tu tarjeta.
- Desarrollo de funcionalidad nueva de la aplicación: aquí se mueve y se ordena lo que hay.
- Guardias ni soporte 24/7, que se contratan aparte.
- Migrar sistemas cuyo proveedor no permita exportar los datos.
- Auditoría de seguridad: es el servicio de ciberseguridad, y se hace después.
Lo que necesitas tener
- Acceso de administración a las cuentas de nube actuales, o a quien lo tenga.
- Saber qué aplicaciones son críticas y cuánto tiempo pueden estar caídas.
- Una ventana acordada para la migración, si hay servicio en marcha.
- Alguien de tu lado que pueda validar que lo migrado funciona como antes.
Preguntas frecuentes
¿Se puede bajar la factura sin romper nada?
Casi siempre, y lo primero que aparece es lo que está encendido sin usarse. Antes de tocar la arquitectura se mide de dónde sale cada cargo.
¿Qué es infraestructura como código y por qué me importa?
Que tu infraestructura está escrita en ficheros versionados en vez de en clics que nadie recuerda. Importa el día que hay que reconstruirla, auditarla o explicarla.
¿Esto me deja atado a un proveedor?
Se diseña para que mudarse sea posible y se dice explícitamente qué partes son propias del proveedor. Prometer que no lo estarás nunca encarecería todo lo demás sin que lo necesites.
¿Cuánto se tarda?
La auditoría son una o dos semanas y a partir de ahí se trabaja en sprints con plan de vuelta atrás en cada uno. El total depende de cuántos sistemas se mueven, y sale cerrado en el presupuesto.
¿Podéis migrar sin cortar el servicio?
En la mayoría de casos sí, moviendo por partes y manteniendo los dos entornos en paralelo un tiempo. Cuando no se puede, se dice antes y se acuerda la ventana de corte por escrito.
¿Y si mi equipo no sabe Terraform?
El traspaso incluye un manual de operación y dos días de formación. Lo escrito es más fácil de aprender que unos clics que nadie documentó, que es la situación de la que se suele venir.