Infraestructura en la nube: la base común de todos sus proyectos

Un sitio web, después un CRM, después algunas automatizaciones y después un primer asistente de IA. Si cada proyecto llega con sus propios accesos, su propio alojamiento y su propia factura, al cabo de unos años nadie sabe ya quién tiene qué claves, qué datos tienen copia de seguridad ni por qué ha subido la factura. Una infraestructura en la nube se construye al revés: primero una base común, sobre la que se apoya cada proyecto.

Esta guía de nuestra sección Infraestructura y nube explica qué contiene esa base, dónde montarla, cuánto cuesta y qué la hace durar en el tiempo. Si hoy sus herramientas viven en suscripciones que le gustaría volver a controlar, nuestra salida del SaaS monta esa base en un servidor suyo, con copias de seguridad probadas y documentación incluidas.

En resumen

• La base, que los grandes proveedores llaman landing zone, reúne lo que comparten todos sus proyectos: cuentas, identidades y permisos, red, registros, copias de seguridad, presupuestos, secretos y documentación.
• Google recomienda montarla antes del primer proyecto, y precisa que la primera versión a menudo no es la última.
• El lugar se elige con cuatro criterios: la naturaleza de los datos, las competencias disponibles, el coste a largo plazo y la facilidad para salir.
• En un gran proveedor, la factura sigue el uso: presupuestos y alertas desde el primer día. En Microsoft Azure, una alerta avisa, no detiene el consumo.
• Una base vale lo que vale su explotación: copias de seguridad restauradas de verdad, supervisión, actualizaciones, plan de recuperación por escrito.

¿Qué es una base de infraestructura en la nube?

Los tres grandes proveedores tienen un nombre para ello. En su guía de diseño de landing zones, Google Cloud la describe como «una configuración modular y escalable» que permite a una organización adoptar su nube, la llama también «base en la nube» y añade que es «a menudo un requisito previo» para desplegar las cargas de trabajo de una empresa (traducción propia). AWS, en la página «Landing zone» de su guía de migración, la convierte en una base para empezar con una arquitectura multicuenta, la gestión de identidades y accesos, la gobernanza, la seguridad de los datos, el diseño de la red y el registro. Microsoft, en su presentación de la zona de aterrizaje de Azure, distingue la zona de plataforma, «la base centralizada que establece la gobernanza, la seguridad y los recursos compartidos para todas sus cargas de trabajo», de las zonas en las que los equipos despliegan sus proyectos.

La palabra viene de los grandes proveedores, pero la cuestión no les pertenece: en un servidor dedicado o un VPS también hay que decidir quién tiene acceso, adónde van las copias de seguridad y a quién se avisa de una avería. Por eso hablamos de base, esté donde esté montada.

¿Qué contiene una landing zone?

Google enumera cuatro elementos que una landing zone exige diseñar: el aprovisionamiento de identidades, la jerarquía de recursos, la red y los controles de seguridad. Añade otros según las necesidades de la empresa, entre ellos la supervisión y el registro, la estrategia de copias de seguridad y de recuperación ante desastres, el cumplimiento y el control de costes. Para una pyme, queda así.

La infrastructure as code describe la base en archivos en lugar de configurarla a golpe de clic en una consola. Google la aconseja, por ejemplo con Terraform, porque hace el despliegue «repetible y modular» (traducción propia): el día en que hay que reconstruir o marcharse a otro sitio, la receta existe. La documentación, por su parte, no aparece en ningún esquema, pero es la que permite que alguien distinto de su autor intervenga un domingo.

La caja fuerte, por último, hace algo más que guardar los secretos: bien conectada, permite que sus automatizaciones y sus agentes de IA usen una clave sin leerla nunca. Es el tema de nuestro artículo sobre la caja fuerte de secretos.

Nada obliga a montarlo todo el primer día. Google lo dice él mismo: la primera iteración de una landing zone a menudo no es la versión final, y aconseja centrar el diseño inicial en lo que piden los primeros proyectos y añadir el resto más tarde (traducción propia).

¿Por qué la base es el denominador común de sus proyectos?

Tomemos una pyme de cuarenta personas, un ejemplo construido para la ocasión. Su sitio web lo aloja la agencia que lo hizo, su CRM es una suscripción, sus automatizaciones funcionan en la cuenta personal de un empleado y un asistente de IA acaba de conectarse a la tarjeta bancaria de otro. Nada escandaloso, proyecto por proyecto. El día en que se va el primer empleado, nadie sabe qué automatizaciones se detienen, qué claves tenía ni dónde están las copias de seguridad del CRM, si es que las hay.

Cada proyecto ha improvisado las mismas respuestas: quién tiene acceso, qué se copia, quién paga y cuánto. La base responde una vez, y cada proyecto hereda la respuesta. Microsoft lo formula a su manera: «cada suscripción y sus recursos de Azure heredan las directivas de gobernanza y seguridad» establecidas por encima de ellos, y la zona de aterrizaje acoge las tecnologías nuevas, IA incluida, «sin necesidad de modificar la arquitectura global». El mismo texto pone un límite sano: centralizar solo lo que aporta «ventajas económicas, operativas o de gobernanza claras en varias cargas de trabajo». La base no es un proyecto más: es lo que sus proyectos tienen en común, y nada más.

Así funcionamos con nuestras propias herramientas.

¿Dónde montar su infraestructura: gran proveedor, nube europea o servidor dedicado?

Para el alojamiento en la nube de una empresa hay tres familias de opciones, que no se excluyen entre sí.

• Un gran proveedor (AWS, Google Cloud, Microsoft Azure). Un catálogo de servicios inmenso y una factura que sigue el uso. En AWS, la landing zone se crea con el servicio AWS Control Tower o a medida, y «cada opción requiere un nivel distinto de conocimiento de AWS» (traducción propia). Es la buena elección cuando sus proyectos necesitan esos servicios y alguien sabe explotarlos.
• Una nube europea. En Francia, la agencia de ciberseguridad ANSSI cualifica ciertas ofertas con el nombre SecNumCloud. En su página dedicada a la nube, las describe como ofertas «de confianza» cuyo uso se «recomienda para la protección de los datos sensibles».
• Un servidor dedicado o un VPS. Un coste fijo y previsible, pero una explotación que le corresponde casi por completo: actualizaciones, copias de seguridad, supervisión. Es nuestra elección para nuestras propias herramientas.

Para decidir, cuatro criterios:

1. La naturaleza de los datos. Datos de salud, datos personales en volumen, secretos industriales: a menudo deciden el lugar antes que todo lo demás.
2. Las competencias disponibles. Un gran proveedor exige conocer su consola, sus permisos y su facturación; un servidor, saber mantenerlo. Elija lo que alguien, en su empresa o en un proveedor, seguirá sabiendo explotar dentro de dos años.
3. El coste a largo plazo. Compare a tres años, horas de explotación incluidas, no con el precio del primer mes.
4. La dependencia del proveedor. Una base descrita en código y unos datos en formatos abiertos mantienen abierta la puerta de salida.

La cuestión de la soberanía va más allá de esta guía: la tratamos en nuestro análisis de la dependencia de Europa de la nube estadounidense.

Nada impide combinar: sus herramientas de gestión en un servidor suyo, un proyecto con mucha necesidad de cálculo en un gran proveedor. La base sigue siendo entonces un solo conjunto de reglas, aplicado en ambos lugares.

¿Cuánto cuesta la base y cómo evitar la factura sorpresa?

Una base cuesta dos veces: en la puesta en marcha y después cada mes en explotación, y este segundo coste se cuenta sobre todo en horas. Google advierte de que el diseño y el despliegue de una landing zone pueden llevar varias semanas (traducción propia). Para compararlo con sus suscripciones actuales, nuestro método se detalla en el coste real de una salida del SaaS a tres años.

En un gran proveedor, la factura sigue el uso, y un recurso olvidado sigue costando. Google cita, de hecho, las herramientas para gestionar el reparto interno de los costes entre las razones para montar una landing zone antes del primer proyecto (traducción propia). Fije, por tanto, un presupuesto por proyecto y alertas desde el primer día.

Además, hay que saber lo que hace una alerta. La documentación de Microsoft sobre los presupuestos de Azure es clara: cuando se supera un umbral, «los recursos no se ven afectados y su consumo no se detiene». La alerta llega también con retraso, y una desviación del lunes puede no notificarse hasta el martes.

Para actuar automáticamente, hay que vincular el presupuesto a un «grupo de acciones». Los demás proveedores tienen sus propias reglas: lea las del suyo antes de contar con una alerta.

El mismo razonamiento vale fuera de las grandes nubes. En Palmora Property, un portal inmobiliario que operamos, había automatizaciones que funcionaban en un servicio de integración continua facturado por minuto; tras tres noches con más de cuatro horas de minutos facturados, las trasladamos a un servidor dedicado. A la inversa, algunos componentes cuestan poco: el plan de copias de seguridad fuera del servidor de Palmora Property sale por unos 6 dólares al mes. Lo que cuesta son las horas dedicadas a la explotación.

¿Por qué la explotación cuenta más que la instalación?

Una base no se rompe el día de su instalación. Se degrada en silencio: una copia de seguridad que falla, un certificado que caduca, una actualización aplazada, un acceso nunca retirado. Cuatro rutinas marcan la diferencia.

• Copias de seguridad restauradas de verdad. Una copia nunca restaurada sigue siendo una hipótesis. En Palmora Property juzgamos una restauración por el número de tablas y registros recuperados, no por el código de retorno de la herramienta, que señala un error ante simples avisos. El detalle está en nuestra guía de copias de seguridad de un servidor propio.
• Una supervisión que avisa. Google habla de paneles y alertas que señalan «cualquier anomalía que requiera actuar» (traducción propia). Además, una persona tiene que recibirlas y leerlas.
• Actualizaciones planificadas, con un medio de volver atrás si una de ellas rompe un servicio. Nuestra guía de n8n autoalojado en producción lo muestra con una herramienta que cambia casi cada semana.
• Un plan de recuperación por escrito. Google incluye la estrategia de copias de seguridad y de recuperación ante desastres entre los elementos de una landing zone; para una pyme, es una página que dice qué volver a arrancar, en qué orden y a quién avisar.

Hablamos por experiencia.

Si parte de suscripciones, el orden en que las traslade a su base también cuenta: lo detallamos en las herramientas que conviene sacar primero del SaaS.

Lo que proponemos y lo que podemos demostrar

Dos casos, según el lugar elegido.

Su base en un servidor suyo. Es nuestra oferta de salida del SaaS: la auditoría de sus suscripciones y de su coste real a tres años, hasta cinco herramientas instaladas, sus datos migrados y verificados, copias de seguridad fuera del servidor con restauración probada y una documentación de explotación. Cuesta 5.500 € y dura tres semanas; la gestión externalizada, opcional, cuesta 450 € al mes y cubre la supervisión, las actualizaciones y copias de seguridad probadas.

Su base en un gran proveedor o en una nube europea. La montamos en el proveedor que usted haya elegido, o que elijamos juntos con los criterios anteriores: organización de las cuentas, identidades y permisos, presupuestos y alertas, registros, copias de seguridad, infraestructura descrita en código y documentación. Después, la explotamos, o se la entregamos con su documentación.

Lo que podemos demostrar es nuestra propia base: un único servidor y una docena de servicios, con las decisiones y los incidentes que eso supone. No reivindicamos bases ya montadas en AWS, Google Cloud o Microsoft Azure. Las tres guías citadas más arriba lo muestran: los componentes de una base se parecen de un proveedor a otro, lo que cambia son las herramientas. Y si su proyecto requiere una experiencia muy especializada en un proveedor que no tenemos, se lo diremos antes de empezar.

Por dónde empezar

1. 01Haga inventario.

   Las cuentas en la nube y las suscripciones, quién tiene acceso de administrador, qué datos viven en ellas, qué facturas llegan cada mes.

2. 02Clasifique sus datos.

   Los sensibles y los que no lo son: esta clasificación decide a menudo el lugar.

3. 03Monte el mínimo del primer día.

   Accesos nominativos con autenticación fuerte, un presupuesto y alertas, copias de seguridad fuera del lugar principal con una restauración probada, y una página de documentación.

4. 04Incorpore un primer proyecto poco crítico.

   Google aconseja desplegar primero las cargas de trabajo que funcionan con más facilidad en su nube (traducción propia): es con ese primer proyecto con el que la base se rodará.

5. 05Añada el resto proyecto a proyecto.

   Cada nuevo proyecto comprueba que la base aguanta y la completa si es necesario. Para trasladar lo que ya funciona sin romper nada, avance carga por carga: detallamos el método en Migración a la nube: trasladar lo existente sin romperlo todo.

Si quiere esta base en un servidor suyo, nuestra salida del SaaS la instala en tres semanas, con copias de seguridad probadas y documentación incluidas. Si debe vivir en un gran proveedor o en una nube europea, descríbanos sus proyectos y el proveedor previsto: le diremos lo que debe contener su base.

Preguntas frecuentes

Fuentes

1. Guía de diseño de landing zones (nueva pestaña)docs.cloud.google.com
2. La página «Landing zone» de su guía de migración (nueva pestaña)docs.aws.amazon.com
3. Su presentación de la zona de aterrizaje de Azure (nueva pestaña)learn.microsoft.com
4. Su página dedicada a la nube (nueva pestaña)cyber.gouv.fr
5. Documentación de Microsoft sobre los presupuestos de Azure (nueva pestaña)learn.microsoft.com