¿Dónde debe vivir un repositorio académico? Infraestructura propia o servicios en la nube

Costos, control, continuidad y riesgos al elegir entre infraestructura propia y hosting administrado

Durante años, para muchas instituciones tener infraestructura tecnológica significaba algo bastante concreto: comprar servidores, instalarlos en un centro de datos y administrarlos con personal propio.

La nube cambió esa relación.

Hoy una universidad puede operar DSpace, OJS, Dataverse u OMP en sus propios servidores, arrendar infraestructura virtual, contratar una nube pública o delegar prácticamente toda la operación a un proveedor especializado.

La pregunta parece sencilla: ¿es mejor tener infraestructura propia o contratar hosting?

Pero probablemente sea la pregunta equivocada. La discusión realmente importante es otra:

¿Quién tiene la capacidad y la responsabilidad de mantener esa infraestructura funcionando correctamente durante los próximos años?

Tener un servidor es la parte fácil

Un repositorio académico puede funcionar perfectamente en un servidor comprado por la institución. También puede funcionar en una máquina virtual contratada a un proveedor.

En ambos casos seguimos necesitando sistema operativo, almacenamiento, bases de datos, certificados, respaldos, monitoreo, actualizaciones, seguridad, recuperación ante desastres y alguien capaz de intervenir cuando algo deja de funcionar. El servidor es solamente una pieza. La infraestructura es el conjunto.

Esa distinción resulta especialmente importante en plataformas académicas porque normalmente se espera que funcionen durante muchos años y que preserven URLs, metadatos, documentos, identificadores persistentes e integraciones con otros sistemas.

La principal ventaja de la infraestructura propia: control

Mantener infraestructura dentro de la institución entrega un grado importante de control. La organización puede determinar exactamente dónde están almacenados los datos, cómo se configura la red, qué tecnologías se utilizan, qué políticas de respaldo se aplican y quién tiene acceso físico y lógico a los sistemas.

Esto puede ser especialmente relevante cuando existen políticas institucionales estrictas, integración profunda con otros servicios internos o requisitos particulares respecto de ubicación y administración de los datos. También permite aprovechar infraestructura y personal que la institución ya posee.

Si una universidad cuenta con un centro de datos bien administrado, redundancia eléctrica, conectividad, especialistas en Linux, bases de datos, almacenamiento, seguridad y monitoreo, operar localmente puede ser completamente razonable. El problema aparece cuando confundimos tener servidores con tener esas capacidades.

El costo que no aparece en la compra

Cuando comparamos un servidor propio con una mensualidad de hosting, normalmente cometemos un error: comparamos el precio del hardware con el precio de un servicio. Pero no son equivalentes.

El costo real de infraestructura propia incluye adquisición y renovación de equipos, almacenamiento, electricidad, refrigeración, conectividad, respaldo, monitoreo, licencias cuando correspondan, seguridad, horas de especialistas y capacidad de respuesta frente a incidentes. Aquí aparece la obsolescencia. Un servidor adquirido hoy requerirá reemplazo en algún momento y, durante su vida útil, seguirá necesitando mantenimiento. La infraestructura propia puede ser económicamente conveniente, pero solo si calculamos su costo total de operación, no simplemente el precio de compra.

Lo que cambia con la nube

NIST define cloud computing como el acceso bajo demanda a un conjunto compartido de recursos configurables que pueden aprovisionarse y liberarse rápidamente. Entre sus características fundamentales se encuentran autoservicio, acceso por red, agrupación de recursos, elasticidad y medición del consumo. Es precisamente esa elasticidad una de sus ventajas.

No necesitamos necesariamente comprar infraestructura pensando en la demanda máxima de los próximos cinco años. Podemos aumentar almacenamiento, memoria o capacidad de procesamiento a medida que la plataforma lo requiere. Adicionalmente, podemos desplegar infraestructura rápidamente y distribuir recursos entre distintas ubicaciones. Pero ojo la nube tampoco elimina los costos. Los transforma.

En lugar de una inversión inicial importante, aparecen gastos recurrentes asociados con procesamiento, almacenamiento, transferencia de datos, respaldos, snapshots, servicios administrados y otras prestaciones. Una arquitectura mal dimensionada también puede producir facturas considerablemente mayores de lo esperado.

Hosting administrado no es exactamente lo mismo que nube

Aquí conviene hacer otra distinción. Contratar infraestructura en AWS, Azure, Google Cloud o algún proveedor de máquinas virtuales no significa necesariamente que alguien vaya a administrar DSpace u OJS.

Podemos trasladar el servidor desde nuestro centro de datos a una nube y continuar siendo responsables de prácticamente todo lo que ocurre dentro de él. Un servicio administrado agrega otra capa: alguien asume responsabilidades operacionales respecto de la plataforma. Esto puede incluir monitoreo, respaldos, actualizaciones, seguridad, resolución de incidentes y mantenimiento del software.

En el propio ecosistema DSpace esta coexistencia es normal. La comunidad señala explícitamente que las instituciones pueden ejecutar DSpace por sí mismas o utilizar opciones de hosting ofrecidas por proveedores registrados. Estos proveedores ofrecen combinaciones de hosting, mantenimiento, actualizaciones, migración, personalización y soporte. El software sigue siendo abierto. Lo que se contrata es la operación.

La nube tampoco elimina la responsabilidad

Este punto es fundamental. Mover un servicio a la nube no significa externalizar automáticamente seguridad, continuidad o gobernanza.

CISA utiliza el concepto de responsabilidad compartida: dependiendo de si contratamos infraestructura, plataforma o software como servicio, determinadas responsabilidades corresponden al proveedor y otras continúan siendo responsabilidad del cliente. Además, recomienda definir claramente estas obligaciones mediante acuerdos de nivel de servicio.

En una infraestructura IaaS, por ejemplo, el proveedor puede hacerse cargo del centro de datos, almacenamiento físico y virtualización, mientras la institución continúa siendo responsable del sistema operativo, aplicaciones, cuentas, configuraciones y datos.

Por eso un contrato de hosting debería especificar mucho más que CPU, memoria y gigabytes.

Debería indicar quién actualiza, quién monitorea, qué ocurre ante una vulnerabilidad, cuánto demora una restauración, dónde existen copias, cuánto tiempo se conservan, qué disponibilidad se compromete y qué sucede cuando finaliza el contrato.

El riesgo de cambiar una dependencia por otra

La infraestructura propia crea dependencia del conocimiento interno. La nube puede crear dependencia del proveedor.

ENISA identifica el vendor lock-in como uno de los riesgos que deben considerarse en servicios cloud, especialmente cuando mover datos y aplicaciones a otro proveedor resulta costoso o complejo. Entre sus recomendaciones aparecen precisamente los planes de salida, el respaldo en formatos estándar y la comprobación periódica de que una migración sea posible. Para plataformas de código abierto, esto debería ser una ventaja.

DSpace, OJS o Dataverse no deberían convertirse en cajas negras simplemente porque están alojados por un tercero. La institución debería conservar acceso a sus datos, configuraciones relevantes, respaldos y procedimientos que permitan eventualmente migrar hacia otra infraestructura.

Un buen servicio administrado no debería basar su permanencia en impedir que el cliente se vaya. Debería basarla en que no exista una buena razón para irse.

Entonces, ¿qué opción es mejor?

Depende mucho menos de la moda tecnológica que de las capacidades reales de la institución. Si existe un equipo sólido de infraestructura, disponibilidad 24/7, políticas maduras de respaldo y seguridad, renovación tecnológica planificada y capacidad para mantener las aplicaciones, una infraestructura propia puede ofrecer control y costos muy competitivos.

Si esas capacidades no existen —o existen pero están sobrecargadas atendiendo cientos de sistemas institucionales—, un servicio administrado puede transferir una parte importante del riesgo operacional hacia un equipo especializado.

NIST lleva años señalando precisamente que la decisión cloud debe considerar conjuntamente factores económicos, rendimiento, confiabilidad, seguridad y condiciones del servicio, en lugar de asumir que existe una alternativa universalmente superior.

La pregunta correcta es quién se hace cargo

Quizás deberíamos abandonar definitivamente una comparación demasiado simple:

Servidor propio versus servidor en la nube. La unidad de comparación debería ser otra:

Capacidad operacional propia versus capacidad operacional contratada.

Para una universidad, contratar hosting no debería significar perder control sobre su infraestructura académica. Debería significar transferir responsabilidades operacionales bajo condiciones explícitas de seguridad, disponibilidad, portabilidad y recuperación.

Del mismo modo, operar infraestructura internamente no debería justificarse únicamente porque existe una sala con servidores. La infraestructura tecnológica no se define por quién posee la máquina. Se define por la capacidad de mantener un servicio disponible, actualizado, seguro, respaldado y recuperable durante años.

Y esa capacidad —esté dentro o fuera de la institución— tiene un costo.

Referencias: puede consultarse la definición de cloud computing de NIST y su guía sobre beneficios, riesgos y decisiones de adopción; ENISA mantiene su evaluación de riesgos de cloud computing y orientación sobre dependencia y portabilidad; CISA documenta el modelo de responsabilidad compartida en servicios cloud. Para el caso específico de repositorios, DSpace mantiene información sobre opciones oficiales de hosting y proveedores de servicio.