En La Economía de las Bases de Datos Multi-cloud analizamos el argumento financiero para distribuir las cargas de trabajo de las bases de datos entre AWS, Azure y Google Cloud Platform (GCP): de dónde provienen los ahorros en los costes, por qué evitar la dependencia con el proveedor (vendor lock-in) tiene un peso económico real, y cómo las tarifas de salida de datos y la sobrecarga operativa pueden anular silenciosamente esos ahorros si no se gestionan adecuadamente. Ese artículo planteaba que el enfoque multi-cloud es una opción estratégica legítima, no una mejor práctica universal, y que solo resulta rentable cuando se gestiona de forma activa en lugar de dejar que se acumule por accidente.

Este artículo retoma el tema donde lo dejó el anterior. Si la economía tiene sentido, la siguiente pregunta es operativa: ¿cómo se ejecuta realmente un entorno de bases de datos multi-cloud en el día a día sin que la complejidad devore los ahorros? En la actualidad, cada vez más organizaciones ejecutan bases de datos con más de un proveedor en el cloud, a menudo AWS, Azure y Google Cloud Platform (GCP) al mismo tiempo. A veces esto ocurre por diseño, como una estrategia deliberada de resiliencia. Más a menudo ocurre por acumulación: un equipo estandariza sobre AWS RDS para un proyecto, otro despliega Azure SQL Database para una nueva aplicación, y un grupo de ciencia de datos construye sobre BigQuery o Cloud SQL porque es lo que se integra con sus herramientas. De cualquier manera, el resultado es el mismo: una infraestructura de bases de datos repartida en tres consolas diferentes, tres modelos de facturación distintos y tres conjuntos de peculiaridades operativas.

Por qué los equipos adoptan un enfoque multi-cloud

Los motivos rara vez son arbitrarios. Evitar la dependencia con un proveedor es un factor clave: distribuir las cargas de trabajo entre diferentes proveedores reduce la dependencia frente a los cambios de precios o las interrupciones de servicio de un único proveedor. Los requisitos normativos y de residencia de datos empujan algunas cargas de trabajo hacia la infraestructura de regiones con un proveedor específico. Las fusiones y adquisiciones frecuentemente heredan decisiones de la arquitectura y de la infraestructura tomadas por una empresa totalmente distinta. Y, en algunos casos, los equipos simplemente eligen la mejor herramienta para el trabajo: Azure por sus integraciones corporativas con Microsoft, GCP por su stack de analítica e Inteligencia Artificial / Machine Learning, y AWS por su gran amplitud de opciones de bases de datos gestionadas y bases de datos serverless.

Los verdaderos costes de la fragmentación

Los beneficios son reales, pero también lo son los costes, y tienden a manifestarse en tres áreas:

• Sobrecarga operativa. Cada proveedor cloud tiene su propia consola de administración, su propia sintaxis de línea de comandos (CLI) y sus propias peculiaridades en la forma de gestionar las copias de seguridad (backups), la replicación y el escalado. Los ingenieros acaban cambiando de contexto entre interfaces solo para realizar tareas rutinarias, y ese coste de cambio se acumula en todo el equipo.
• Visibilidad inconsistente. Cuando los datos de rendimiento para la monitorización de la base de datos, los registros de consultas (query logs) y la documentación de los esquemas viven en tres silos separados, obtener una imagen unificada de todo el entorno se convierte en un ejercicio manual y propenso a errores, que generalmente se reconstruye a posteriori en hojas de cálculo.
• Duplicación de habilidades y herramientas. Los equipos a menudo necesitan personal que se sienta cómodo con los productos de más de un proveedor, o bien construyen scripts y procesos redundantes para tareas que son conceptualmente idénticas pero que se implementan de forma diferente en cada cloud.

Ninguno de estos costes es un factor decisivo por sí solo, pero en conjunto erosionan la agilidad y el ahorro de costes que motivaron el enfoque multi-cloud en primer lugar.

Gestionar la complejidad con una capa unificada

El denominador común de estos inconvenientes es la fragmentación, y la solución práctica es una capa de gestión que se sitúe por encima de las consolas cloud individuales en lugar de reemplazarlas. Aquí es donde una herramienta como Navicat Premium encaja en una estrategia multi-cloud.

Navicat Premium se conecta a bases de datos en los tres principales proveedores desde una única aplicación, incluyendo Amazon RDS, Aurora y Redshift en AWS. Azure SQL Database y Azure Cosmos DB for MongoDB en Azure y Google Cloud SQL en GCP, junto con instancias locales (on-premises) de MySQL, PostgreSQL, SQL Server, Oracle, MongoDB y otros motores. Las conexiones se pueden proteger de forma segura mediante túneles SSH, túneles HTTP/HTTPS o SSL, independientemente de qué cloud esté alojando la base de datos en el otro extremo.

Para un equipo multi-cloud, el valor práctico no es solo la amplitud de motores compatibles, es la consistencia. Un administrador de bases de datos (DBA) que escribe una consulta, compara esquemas o ejecuta una sincronización de datos no necesita volver a aprender el flujo de trabajo para la consola de cada proveedor; la interfaz, el editor de consultas (query editor) y el diseñador de objetos (object designer) se comportan de la misma manera ya sea que el destino sea una base de datos de AWS, Azure o GCP. Navicat también permite sincronizar perfiles de conexión, modelos y consultas guardadas con un servicio de colaboración cloud, de modo que un equipo distribuido que trabaja con varios proveedores puede compartir configuraciones en lugar de tener que reconstruirlas de forma individual.

Empezar sin abarcar demasiado

Los equipos que consideran implementar una capa de gestión unificada no necesitan migrar nada para adoptarla; el valor reside en conectar las bases de datos existentes tal y como están. Un punto de partida sensato es auditar qué bases de datos existen y en qué proveedores, para luego reunirlas bajo una sola interfaz para tareas diarias de ejecución de consultas, monitorización y comparación de esquemas, antes de abordar problemas más complejos como la sincronización de datos entre clouds o la planificación de la recuperación ante desastres (disaster recovery).