SaaS vs. hosting gestionado vs. autoalojamiento: elige según quién se encargará del trabajo

Empieza por el trabajo que debe realizar la aplicación

Elegir dónde ejecutar una aplicación no es solo decidir entre la nube de un proveedor y tu propio servidor. Se trata de decidir quién operará las capas que permiten que la aplicación funcione y quién tomará las decisiones sobre los datos, el acceso, la configuración y la recuperación.

Empieza por anotar qué función debe cumplir la aplicación, con qué sistemas debe conectarse, quién necesita acceso y qué ocurriría si no estuviera disponible. Después, haz una lista del trabajo operativo que tu equipo puede asumir de forma fiable. Un modelo que parece sencillo al registrarse quizá siga exigiendo trabajo al cliente en materia de identidad, gestión de datos, integraciones o restauración del servicio.

Estas etiquetas son puntos de partida útiles, no contratos completos. El alcance de SaaS, el hosting gestionado y el autoalojamiento puede variar según el proveedor o el acuerdo. Antes de dar algo por sentado, confirma las responsabilidades en la documentación y los contratos del proveedor.

• ¿Qué proceso empresarial depende de la aplicación y cuánto afectaría una interrupción o la pérdida de datos?
• ¿Necesitas modificar la aplicación, su implementación o su configuración subyacente?
• ¿Qué integraciones, controles de identidad y normas de gestión de datos son imprescindibles?
• ¿Quién de tu equipo se encargará de la administración, el seguimiento con el proveedor y las decisiones de recuperación?

Define los modelos según quién opera cada capa

Por lo general, SaaS es una aplicación que un proveedor ofrece y opera. Normalmente, el proveedor gestiona el servicio y la infraestructura que lo sustenta; los clientes usan la aplicación y administran sus propios usuarios, ajustes y procesos empresariales. La división exacta —en especial en cuanto a exportación de datos, identidad, copias de seguridad y respuesta ante incidentes— depende del servicio.

El hosting gestionado significa que un proveedor se encarga de algunas tareas de hosting o infraestructura de una aplicación, mientras que el cliente conserva la responsabilidad de, al menos, algunas decisiones organizativas y de la aplicación. El término no establece un límite universal. Un proveedor puede gestionar la implementación y las operaciones habituales del servicio; otro quizá ofrezca una capa de hosting más limitada. Pregunta qué incluye el servicio, en lugar de deducirlo por la etiqueta.

Con el autoalojamiento, la organización ejecuta la aplicación en una infraestructura que controla o cuya provisión coordina. Esto le da un control más directo sobre la implementación y la configuración, pero también asigna más trabajo operativo a su equipo o a sus contratistas. Usar un proveedor de infraestructura en la nube no convierte automáticamente una aplicación en SaaS: es posible que tu organización siga siendo responsable de operar la aplicación.

Una regla práctica útil: distingue la aplicación de la infraestructura donde se ejecuta. Que un proveedor opere una capa no significa, por sí solo, que se encargue de todas las tareas de las capas superiores o inferiores.

• SaaS: normalmente el proveedor opera el servicio de la aplicación; el cliente sigue siendo responsable de su uso, sus usuarios, sus decisiones sobre datos y su gobernanza.
• Hosting gestionado: el proveedor opera las tareas de hosting acordadas; el cliente conserva las responsabilidades que no se hayan incluido expresamente.
• Autoalojamiento: la organización coordina la operación de la aplicación y su entorno, directamente o a través de sus propios proveedores de servicios.

Usa una matriz de responsabilidades y confirma los límites

La matriz siguiente sirve como herramienta de conversación, no como promesa sobre todos los proveedores. «Normalmente» describe una suposición inicial habitual, no un servicio garantizado. Las responsabilidades varían especialmente en el caso del hosting gestionado. Pide al proveedor que complete la misma tabla para la aplicación y el plan específicos que estás considerando.

Algunas tareas son compartidas. Por ejemplo, un proveedor puede gestionar las copias de seguridad de la infraestructura, mientras que el cliente decide qué datos deben conservarse, quién puede acceder a ellos y cómo responder ante una recuperación. Disponer de una función de copia de seguridad no equivale a tener un plan de recuperación probado.

• Operación de la infraestructura — SaaS: normalmente el proveedor; hosting gestionado: el proveedor, dentro del alcance del hosting contratado; autoalojamiento: la organización o los proveedores de infraestructura que elija.
• Instalación y actualizaciones de la aplicación — SaaS: normalmente el proveedor controla las actualizaciones del servicio, según su proceso de publicación; hosting gestionado: varía, así que aclara quién programa, aplica y valida las actualizaciones; autoalojamiento: la organización las planifica y aplica, salvo que delegue la tarea.
• Copias de seguridad — SaaS: pregunta qué se guarda, durante cuánto tiempo y si el cliente puede restaurar los datos; hosting gestionado: verifica el alcance, la frecuencia, la retención y quién se encarga de la restauración; autoalojamiento: la organización debe coordinar y supervisar las copias de seguridad o contratar ese servicio.
• Acceso e identidad — todos los modelos: el cliente debe definir quién debería tener acceso y gestionar las autorizaciones relacionadas con el negocio. Pregunta qué controles de identidad admite el servicio y qué parte se encarga de las cuentas de la plataforma.
• Datos y gobernanza — todos los modelos: el cliente debe decidir qué datos incorporar a la aplicación, quién puede utilizarlos y qué políticas se aplican. Confirma directamente con el proveedor sus compromisos, las ubicaciones de los datos y las condiciones de gestión.
• Recuperación — todos los modelos: acuerda quién detecta y comunica los incidentes, quién inicia la recuperación, qué opciones existen y qué debe hacer el cliente. No des por hecho que la responsabilidad del hosting garantiza un plazo o un resultado de recuperación.
• Configuración e integraciones — SaaS: están limitadas por los ajustes y las interfaces disponibles en el servicio; hosting gestionado: puede permitir mayor flexibilidad en la implementación, según el servicio; autoalojamiento: normalmente ofrece el control más directo, con el correspondiente trabajo operativo.

Compara las ventajas y desventajas más allá del trabajo operativo

Por lo general, el control y el esfuerzo se mueven en direcciones opuestas, aunque no siempre. SaaS puede reducir la necesidad de operar la pila de aplicaciones, pero quizá limite las opciones de implementación o personalización. El autoalojamiento puede proporcionar un control más directo, pero ese control solo resulta útil si alguien puede mantener el entorno. El hosting gestionado permite delegar tareas operativas definidas, sin que necesariamente se transfiera el control de la aplicación o la responsabilidad de las decisiones empresariales.

Ten en cuenta también las dependencias y la portabilidad. Un servicio puede depender de configuraciones, integraciones, funciones de identidad o formatos de datos específicos del proveedor. Cambiar de modelo puede requerir algo más que copiar una base de datos: también puede ser necesario ocuparse de los archivos de la aplicación, la configuración, las credenciales, las integraciones y el acceso de los usuarios. Pregunta por estos aspectos antes de elegir, no solo cuando estés pensando en marcharte.

• Control: ¿Qué decisiones sobre la aplicación, la implementación y la configuración deben seguir siendo tuyas?
• Personalización: ¿El producto permite los cambios necesarios o estos requieren acceso al entorno de la aplicación?
• Esfuerzo operativo: ¿Quién se encargará de las actualizaciones rutinarias, la supervisión, la comprobación de las copias de seguridad, la resolución de problemas y la coordinación de la recuperación?
• Dependencias: ¿Qué servicios de identidad, almacenamiento, correo electrónico, API u otros deben seguir funcionando para que la aplicación resulte útil?
• Portabilidad: ¿Puedes obtener copias utilizables de tus datos y configuración? ¿Qué habría que reconstruir después de una migración?
• Responsabilidad: Cuando algo falla, ¿hay una persona de contacto designada por el proveedor y un procedimiento claro para las acciones del cliente?

Identifica los requisitos que pueden descartar un modelo

Algunos requisitos son condiciones obligatorias, no preferencias. Si un servicio no admite una integración necesaria, no cumple una norma de gestión de datos o no ofrece el proceso de recuperación que necesitas, una menor carga operativa no compensará esa carencia. Anota primero las condiciones imprescindibles y luego compara las opciones restantes.

Los requisitos de gobernanza pueden referirse a la aprobación del acceso, la capacidad de auditoría, la gestión de datos o quién puede administrar el servicio. Los detalles dependen de tu organización y del proveedor; no des por hecho que el modelo de implementación por sí solo garantiza el cumplimiento. Valida los controles y compromisos contractuales pertinentes con el proveedor y, cuando corresponda, con los especialistas internos.

Las necesidades de recuperación requieren especial atención. Define qué datos y funciones deben restaurarse, quién puede autorizar una restauración y qué pruebas necesitas de que el proceso funciona. Si las respuestas del proveedor no satisfacen tus requisitos, puede ser motivo para reconsiderar el modelo o el proveedor.

• SaaS puede no ser adecuado si no permite una implementación o personalización necesaria, o si la gestión de datos, las integraciones o los mecanismos de acceso del servicio no cumplen un requisito obligatorio.
• El hosting gestionado puede no ser adecuado si tu equipo necesita que el proveedor asuma responsabilidades que no está dispuesto a aceptar, o si no queda claro dónde termina la operación del proveedor y empieza la del cliente.
• El autoalojamiento puede no ser adecuado si nadie puede asumir de forma responsable las actualizaciones, las copias de seguridad, la administración de accesos y la recuperación, o si la organización no puede sostener ese trabajo.
• Cualquier modelo puede no ser adecuado si el proveedor no puede explicar cómo exportar tus datos, cómo se controla el acceso y qué ocurre cuando finaliza el servicio.

Evalúa las ventajas y desventajas con una carga de trabajo realista

Imagina que un pequeño equipo de operaciones busca una aplicación para hacer un seguimiento interno de proyectos. El personal necesita acceso desde el navegador, una conexión con un flujo de trabajo de identidad o notificaciones existente y una manera fiable de recuperar los registros. El equipo no cuenta con especialistas internos en infraestructura.

SaaS podría servirle si el servicio admite el flujo de trabajo y los controles necesarios, y si son aceptables las condiciones del proveedor para la exportación de datos y la recuperación. El hosting gestionado podría funcionar si el equipo necesita una implementación concreta de la aplicación y un proveedor acepta claramente las tareas de infraestructura que no puede gestionar por su cuenta. El autoalojamiento también podría ser viable si la organización cuenta con una persona responsable de operarlo o con soporte contratado, y valora lo suficiente el control necesario como para asumir el trabajo continuo.

Ninguno de esos resultados se deduce únicamente de la descripción de la carga de trabajo. El equipo debe probar la integración real, aclarar quién administra las cuentas, revisar las condiciones de copia de seguridad y restauración y calcular el trabajo que tendrá que asumir. El ejercicio resulta útil porque transforma expresiones como «queremos control» o «queremos que esté gestionado» en requisitos verificables.

• Haz una lista de las funciones e integraciones imprescindibles para el flujo de trabajo.
• Identifica a la persona responsable de administrar la aplicación y modificar los accesos.
• Pide a cada proveedor que explique cómo se realiza una actualización rutinaria y cómo se tramita una solicitud de recuperación de datos.
• Anota qué debe hacer el equipo durante una interrupción, la salida de un empleado o una migración planificada.
• Descarta las opciones que no cumplan los requisitos obligatorios antes de comparar su comodidad de uso.

Pregunta a los proveedores quién se encarga de las operaciones habituales

En una conversación útil con un proveedor se pregunta por flujos de trabajo concretos, no solo por una lista de funciones incluidas. Solicita respuestas tanto sobre el mantenimiento ordinario como sobre problemas inesperados. Siempre que sea posible, pide al proveedor que diferencie entre lo que hace, lo que recomienda y lo que espera que haga el cliente.

Para una implementación gestionada por Airbip, Airbip describe su servicio como la ejecución de instancias de aplicaciones en cargas de trabajo Docker en servidores en la nube de Airbip. Entre las capacidades que declara se incluyen el enrutamiento automatizado y los certificados TLS mediante Traefik y Let’s Encrypt, comprobaciones de DNS, gestión del ciclo de vida del servicio y copias de seguridad diarias, semanales y mensuales configurables. Estas capacidades no resuelven todas las dudas sobre las responsabilidades: confirma directamente cualquier otro requisito, así como el alcance y la retención de las copias de seguridad, los pasos de restauración y las responsabilidades sobre el acceso y los datos. Consulta el sitio web de Airbip para conocer los planes y las condiciones comerciales vigentes.

• ¿Quién instala y aplica las actualizaciones de la aplicación? ¿Puede el cliente elegir cuándo se realizan?
• ¿Qué supervisión y resolución de problemas están incluidas, y qué situaciones requieren la intervención del cliente?
• ¿Qué incluye exactamente una copia de seguridad, durante cuánto tiempo se conserva y cómo se restaura?
• ¿Quién administra las cuentas de la aplicación, el acceso administrativo y la integración de identidad?
• ¿Qué datos y configuraciones puede exportar el cliente, en qué formato y mediante qué proceso?
• ¿Quién se comunica durante un incidente y qué información o acciones se esperan del cliente?
• ¿Qué integraciones, personalizaciones o cambios de implementación son compatibles y cuáles quedan fuera del alcance?
• ¿Dónde se documentan los límites y las exclusiones del servicio?

Planifica la exportación de datos, la migración y el fin del servicio

Es más fácil evaluar la portabilidad antes de adoptar un servicio. Averigua cómo exportar registros y archivos, si es posible trasladar la configuración y la información de usuarios y si habrá que recrear las integraciones. Comprueba si la exportación tiene un formato utilizable en la siguiente opción; que exista una función de exportación no garantiza una migración sencilla.

Documenta un plan de salida proporcional a la importancia de la aplicación. Identifica quién solicita la exportación, quién la verifica, cómo gestionarás el acceso durante la transición y qué debe ocurrir con las copias que conserve el proveedor saliente. Confirma los plazos, las tarifas o las condiciones en los términos vigentes del proveedor, en lugar de basarte en suposiciones.

El modelo adecuado es aquel cuyos límites operativos, nivel de control y vía de salida se ajustan a tus requisitos y capacidades. SaaS, el hosting gestionado y el autoalojamiento pueden ser opciones apropiadas. La decisión práctica no consiste en elegir la etiqueta que parezca más segura, sino en asegurarse de que cada responsabilidad importante tenga una persona encargada.

• Solicita una muestra o una descripción de la exportación de datos antes de comprometerte.
• Identifica los datos de la aplicación, los archivos, la configuración, las cuentas de usuario y las integraciones que quizá deban trasladarse.
• Aclara quién validará los datos exportados y qué se considerará una transición satisfactoria.
• Revisa con el proveedor las condiciones de finalización del servicio, retención de datos y eliminación.
• Mantén un registro de responsabilidades que asigne a una persona del cliente cada tarea que el proveedor no acepte expresamente.