On-premise frente a nube: costes, soberanía y operación de software empresarial

La diferencia más citada es que on-premise exige inversión inicial y la nube convierte esa inversión en gasto recurrente. Es cierto, pero incompleto. Lo que importa es el coste total a lo largo de la vida del sistema, y ahí aparecen partidas que no figuran en ninguna factura de hardware ni en la calculadora del proveedor. No damos precios porque dependen del volumen, del proveedor, de la región y de las condiciones negociadas; sí podemos ordenar los componentes que hay que poner sobre la mesa.

Dos factores suelen decidir la comparación. El primero es el perfil de carga: un sistema con uso estable y predecible aprovecha bien un servidor dimensionado una vez, mientras que una carga con picos estacionales o un crecimiento incierto se beneficia de la elasticidad. El segundo es la disciplina de gestión: en la nube, los recursos olvidados, los entornos de prueba encendidos de noche o los volúmenes de copia sin política de retención hacen crecer la factura sin que nadie lo decida conscientemente.

Soberanía no es lo mismo que residencia. La residencia responde a dónde están físicamente los datos; la soberanía, a quién puede acceder a ellos y bajo qué jurisdicción. Con servidores propios ambas preguntas tienen una respuesta directa, aunque eso no elimina obligaciones: seguís siendo responsables de la seguridad y del cumplimiento que corresponda. En la nube, la mayoría de los proveedores permiten elegir región, pero hay que revisar también dónde se procesan los registros de actividad, las copias, el soporte técnico y los servicios auxiliares.

• Qué datos tratáis: personales, de salud, secretos industriales, información clasificada o sujeta a contratos con terceros.
• Qué exigen vuestros contratos con clientes, la normativa aplicable o las condiciones de una licitación pública.
• Quién es el proveedor, a qué jurisdicción está sometido y qué dicen sus condiciones sobre accesos por parte de autoridades.
• Si los subencargados del proveedor y su soporte técnico pueden acceder desde fuera del ámbito acordado.
• Si podéis mantener el cifrado con claves que controláis vosotros y qué implica en la operación diaria.

La interpretación jurídica de estos puntos corresponde a vuestra asesoría. Lo que el diseño técnico puede aportar es una arquitectura que haga verificable la respuesta: inventario de dónde se guarda cada tipo de dato, registros de acceso y segregación de entornos.

La nube no elimina la operación; la desplaza. Con servidores propios alguien tiene que aplicar parches al sistema operativo, vigilar discos, renovar certificados, probar restauraciones y atender el hardware cuando falla. En la nube pública el proveedor se ocupa de la infraestructura física y, según el servicio, de parte del software base, pero la organización sigue siendo responsable de configurar permisos, redes, secretos, copias y alertas. Este reparto se suele llamar modelo de responsabilidad compartida y cada proveedor lo documenta para cada servicio.

• ¿Tenéis personal propio o un proveedor de confianza que pueda administrar servidores con guardias fuera de horario?
• ¿Quién decide y ejecuta las actualizaciones, y con qué ventana de mantenimiento?
• ¿Quién revisa el gasto y los permisos en la nube con una periodicidad fija?
• ¿Están documentados los procedimientos de recuperación y se han ensayado alguna vez?

Ninguna de las dos opciones es segura o insegura por definición. On-premise ofrece control físico y la posibilidad de aislar la red, pero exige mantener al día un perímetro, parches y monitorización con medios propios; un servidor olvidado sin actualizar en una nave es un riesgo serio. La nube pública ofrece mecanismos maduros de cifrado, identidad y registro, pero un error de configuración, como un almacenamiento expuesto o permisos demasiado amplios, puede publicar datos sin que nadie lo note.

En ambos casos las preguntas de diseño son parecidas: cómo se autentican personas y servicios, dónde se guardan las credenciales, cómo se segregan entornos, qué se registra y quién revisa los registros, y cómo se restaura un sistema comprometido. La diferencia está en qué herramientas tenéis a mano y quién las maneja.

Una decisión de alojamiento se toma con la información de hoy, y dentro de unos años puede no ser la adecuada. Por eso conviene evaluar cuánto cuesta salir. En on-premise, la dependencia suele estar en el hardware y en licencias concretas. En la nube, en los servicios propietarios del proveedor: colas, bases de datos gestionadas o funciones que no tienen equivalente directo en otro sitio. La Comisión Europea presenta el Reglamento de Datos como un marco para facilitar que los clientes cambien entre proveedores de servicios de tratamiento de datos; aun así, la portabilidad real depende sobre todo de cómo se haya diseñado el sistema.

• Separar la lógica de negocio de los servicios específicos del proveedor mediante interfaces propias.
• Preferir formatos de datos y protocolos abiertos donde no haya una ventaja clara en lo propietario.
• Describir la infraestructura como código para poder reconstruirla en otro entorno.
• Probar periódicamente una exportación completa de datos y comprobar que se puede leer fuera.
• Revisar en el contrato las condiciones de salida: plazos, formatos y asistencia.

1. Escribid qué datos tratáis y qué restricciones de ubicación y acceso aplican, con la ayuda de vuestra asesoría.
2. Describid el perfil de carga esperado y su evolución en los próximos años.
3. Haced un inventario honesto de la capacidad de operación disponible, propia o contratada.
4. Comparad el coste total por componentes, no solo la cuota mensual o la factura del servidor.
5. Valorad el coste de salida de cada opción y diseñad para reducirlo.
6. Si ninguna opción encaja del todo, considerad una arquitectura híbrida y definid qué vive en cada lado.

Ninguna modalidad está disponible por defecto en todos los proyectos: la elección sale de una evaluación técnica del caso. Lo que sí podemos hacer es diseñar el software para que la decisión de alojamiento no lo condicione más de lo necesario.