Mudarse a la nube está de moda. Según una encuesta destacada de IDC, Experiencia en Migración de Bases de Datos a la Nube, el 63% de las empresas están migrando activamente sus bases de datos a la nube y otro 29% está considerando hacerlo dentro de los próximos tres años.

Este artículo analiza algunos de los riesgos que los clientes pueden encontrar sin darse cuenta al mover su base de datos a una base de datos como servicio (DBaaS) en la nube, especialmente cuando DBaaS aprovecha el software de base de datos de código abierto como Apache Cassandra, MariaDB, MySQL, Postgres o Redis. . En EDB, clasificamos estos riesgos en cinco categorías: soporte, servicio, estancamiento tecnológico, costo y dependencia. Migrar a la nube sin la suficiente diligencia y mitigación de riesgos puede conducir a sobrecostos significativos y retrasos en los proyectos y, lo que es más importante, puede significar que las empresas no obtengan los beneficios comerciales esperados de la migración a la nube.

Debido a que EDB se enfoca en la base de datos de Postgres, extraeré los detalles de nuestras experiencias con los servicios de Postgres, pero las conclusiones son igualmente válidas para otros servicios de bases de datos de código abierto.

Riesgo de soporte. Los clientes que ejecutan software para aplicaciones de producción necesitan soporte, ya sea que se ejecuten en la nube o en las instalaciones. El soporte para el software de nivel empresarial debe cubrir dos aspectos: el asesoramiento de expertos sobre cómo usar el producto correctamente, especialmente en circunstancias difíciles, y abordar rápidamente los errores y defectos que afectan la producción o el paso a la producción.

Para el software comercial, se incluye un nivel mínimo de soporte con la licencia. Las bases de datos de código abierto no vienen con una licencia. Esto abre la puerta para que un proveedor de bases de datos en la nube cree y opere un servicio de base de datos sin invertir lo suficiente en la comunidad de código abierto para solucionar errores y brindar soporte.

Los clientes pueden evaluar la capacidad de un proveedor de bases de datos en la nube para respaldar su migración a la nube consultando las notas de la versión del software de código abierto e identificando a los miembros del equipo que participan activamente en el proyecto. Por ejemplo, para Postgres, las notas de la versión son disponible de forma gratuita, y nombran a cada persona que ha contribuido con nuevas funciones o correcciones de errores. Otras comunidades de código abierto siguen prácticas similares.

Los proveedores de bases de datos en la nube de código abierto que no participan activamente en el proceso de desarrollo y corrección de errores no pueden proporcionar ambos aspectos del soporte (asesoramiento y respuesta rápida a los problemas), lo que presenta un riesgo significativo para la migración a la nube.

Riesgo de servicio. Las bases de datos son productos de software complejos. Muchos usuarios necesitan asesoramiento de expertos y asistencia práctica para configurar las bases de datos correctamente para lograr un rendimiento óptimo y una alta disponibilidad, especialmente al pasar de implementaciones locales familiares a la nube. Los proveedores de bases de datos en la nube que no ofrecen servicios profesionales de consultoría y expertos para facilitar este movimiento introducen riesgos en el proceso. Dichos proveedores solicitan al cliente que asuma las responsabilidades de un contratista general y que se coordine entre el proveedor DBaaS y los posibles proveedores de servicios profesionales. En lugar de una sola entidad a la que pueden consultar para ayudarlos a lograr una implementación perfecta con los niveles de rendimiento y disponibilidad requeridos, quedan atrapados en el medio, teniendo que coordinar y mitigar los problemas entre los proveedores.

Los clientes pueden reducir este riesgo asegurándose de que entienden claramente quién es responsable del éxito general de su implementación y que esta entidad está en condiciones de ejecutar todo el proyecto con éxito.

Riesgo de estancamiento tecnológico. El modelo de responsabilidad compartida es un componente clave de un DBaaS. Mientras que el usuario maneja la definición del esquema y el ajuste de la consulta, el proveedor de la base de datos en la nube aplica actualizaciones de versiones secundarias y actualizaciones de versiones principales. No todos los proveedores están comprometidos con la actualización de manera oportuna, y algunos pueden retrasarse significativamente. Al momento de escribir este artículo, uno de los principales proveedores de DBaaS de Postgres va a la zaga de la comunidad de código abierto por casi tres años en su implementación de versiones de Postgres. Si bien los proveedores de DBaaS pueden respaldar de manera selectiva las correcciones de seguridad, una aplicación retrasada de nuevas versiones puede poner a los clientes en una situación en la que se pierden las nuevas capacidades de la base de datos, a veces durante años. Los clientes deben inspeccionar el historial de seguimiento de la aplicación de actualizaciones de un proveedor para evaluar esta exposición.

Se presenta un riesgo similar cuando un proveedor propietario de una base de datos en la nube intenta crear su propia bifurcación o versión de un conocido software de código abierto. A veces, esto se hace para optimizar el software para el entorno de la nube o abordar las restricciones de licencia. Las versiones bifurcadas pueden desviarse significativamente del padre más conocido o quedarse atrás de la versión de código abierto. Ejemplos bien conocidos de dichas bifurcaciones o versiones propietarias son Aurora Postgres (un derivado de Postgres), Amazon DocumentDB (con compatibilidad con MongoDB) y Amazon OpenSearch Service (originalmente derivado de Elasticsearch).

Los usuarios deben tener cuidado al adoptar versiones específicas de la nube o bifurcaciones de software de código abierto. Las capacidades pueden variar con el tiempo, y el proveedor de la base de datos en la nube puede o no adoptar las nuevas capacidades de la versión de código abierto.

riesgo de costo. Los principales servicios de bases de datos en la nube no han experimentado aumentos de precios directos significativos. Sin embargo, existe una comprensión cada vez mayor de que la naturaleza de los servicios en la nube puede generar un riesgo de costos significativo, especialmente en el caso del autoservicio y la elasticidad rápida combinada con un modelo de costos poco transparente. En entornos locales, los administradores de bases de datos (DBA) y los desarrolladores deben optimizar el código para lograr el rendimiento con el hardware disponible. En la nube, puede ser mucho más conveniente pedirle al proveedor de la nube que aumente las operaciones de entrada/salida por segundo (IOPS), el cómputo o la memoria aprovisionadas para optimizar el rendimiento. Como cada instancia de aumento aumenta el costo, es probable que una solución a corto plazo tenga impactos negativos en los costos a largo plazo.

Los usuarios mitigan el riesgo de costo de dos maneras: (1) supervisión cercana de los aumentos de IOPS, CPU y memoria para asegurarse de que se equilibren con el costo de la optimización de la aplicación; (2) escrutinio de los modelos de costos de los proveedores de DBaaS para identificar y evitar proveedores con modelos de costos complejos e impredecibles.

Riesgo de bloqueo. Los servicios de bases de datos en la nube pueden crear un efecto de “Hotel California”, donde los datos no pueden volver a salir fácilmente de la nube, de varias maneras. Mientras a menudo se menciona el costo de salida de datos, la gravedad general de los datos y la integración con otras herramientas específicas de la nube para la gestión y el análisis de datos son más impactantes. Gravedad de datos es un concepto complejo que, en un alto nivel, implica que una vez que un conjunto de datos comerciales está disponible en una plataforma en la nube, es probable que se implementen más aplicaciones utilizando los datos en esa plataforma, lo que a su vez hace que sea menos probable que los datos puedan ser trasladado a otro lugar sin un impacto comercial significativo.

Las herramientas específicas de la nube también son un factor significativo para el bloqueo. Todas las plataformas en la nube proporcionan herramientas de análisis y gestión de datos convenientes y patentadas. Si bien ayudan a obtener valor comercial rápidamente, también crean un bloqueo.

Los usuarios pueden mitigar el efecto de bloqueo en la nube evitando cuidadosamente el uso de herramientas de nube patentadas y asegurándose de que solo usan soluciones DBaaS que admitan la replicación de datos eficiente en otras nubes.

Planificación para el riesgo. Mover bases de datos a la nube es, sin duda, un objetivo para muchas organizaciones, pero hacerlo no está exento de riesgos. Las empresas deben investigar y comprender completamente las debilidades potenciales de los proveedores de bases de datos en la nube en las áreas de soporte, servicios, estancamiento tecnológico, costo y bloqueo. Si bien estos riesgos no son una razón para alejarse de la nube, es importante abordarlos por adelantado y comprenderlos y mitigarlos como parte de una estrategia de migración a la nube cuidadosamente considerada.

Este contenido fue producido por EDB. No fue escrito por el equipo editorial de MIT Technology Review.

Ir arriba