Análisis de datos escalable en cualquier lugar con arquitectura nativa en la nube

Arquitectar con Kubernetes es la pieza central indispensable que hace que el análisis de datos sea excepcionalmente flexible, ejecutándose en cualquier lugar en el punto de necesidad empresarial —y haciéndolo a escala, con alta concurrencia, rendimiento, eficiencia y disponibilidad.

Miles de empresas en verticales que van desde servicios financieros y seguros hasta manufactura y salud encuentran que necesitan nube pública y privada, híbrida y despliegues en el borde para adaptar mejor sus necesidades de gestión y análisis de datos. No es sorpresa que el concepto de nube distribuida sea parte de la maduración de la nube. Llevar almacenes de datos, lagos de datos y análisis avanzados a una arquitectura de nube distribuida es hacia donde se dirigen los mercados. Extender esta arquitectura para abarcar servicios de gestión y análisis de datos de nivel superior conduce naturalmente a la idea de una nube de datos distribuida. Dentro de una nube de datos distribuida, los almacenes de datos empresariales no solo se usarán para proporcionar análisis a unos pocos cientos de analistas de negocio o científicos de datos en una empresa, sino que finalmente podrán impulsar aplicaciones analíticas en tiempo real usadas directamente por los clientes finales de una empresa, que se cuentan por decenas de miles. Los datos serán inmediatamente accesibles —y generarán insights— en cualquier lugar.

Ver también: Tendencias de adopción en la nube 2021 se amplifican en 2022

Explorando el destino

Nativo en la nube es un término que se usa mucho, pero tiene un significado real cuando la arquitectura de software está diseñada desde cero para aprovechar los beneficios de la nube distribuida. Un almacén de datos nativo en la nube totalmente realizado debería aprovechar lógicamente una arquitectura de nube de datos distribuida. En términos amplios, eso lleva el análisis a los datos dondequiera que residan (no al revés), mitiga el riesgo de concentración, aumenta drásticamente la eficiencia y trae modernización para un gasto controlado y una ventaja competitiva.

Para ser más precisos, una tecnología de gestión y análisis de datos nativa en la nube debería mostrar cinco rasgos clave para alinearse con el plan de nube de datos distribuida:

• Un tiempo de ejecución agnóstico de plataforma que permita el aprovisionamiento de datos y análisis en cualquier lugar
• Una experiencia de usuario común en cualquier lugar
• Características comunes de seguridad y gobernanza en cualquier objetivo de despliegue
• Eficiencia de costos y tecnología en cualquier lugar, minimizando recursos y permitiendo una fuerte gestión de costos (FinOps) y barreras de gasto
• Un único plano de control, vinculando todos los despliegues: nube pública, on-premise y en el borde de la red

Desplegable en el punto de necesidad en cualquier lugar, un almacén de datos nativo en la nube totalmente realizado siguiendo este patrón también abstraerá la complejidad de la infraestructura de nube, on-premise y borde de red de los usuarios finales. El objetivo es liberarlos de los detalles de infraestructura y permitirles enfocarse en generar valor a partir del análisis y la gestión de datos, mientras aún imparten el poder nativo de la nube.

Elegir la guía adecuada

Entonces, ¿cómo se llega a ese destino? Kubernetes, la herramienta de orquestación de contenedores de código abierto, proporciona el camino más popular hacia operaciones nativas en la nube. Aunque la idea de particionar cargas de trabajo en Unix existe desde los años 70, fue hace solo una década que los contenedores se implementaron ampliamente para hacer el desarrollo de aplicaciones más fácil, portátil y eficiente en el uso de recursos. Pero desplegar cientos o miles de aplicaciones en una vasta arquitectura de microservicios resultó extremadamente complicado. Aunque existen otras opciones, el proyecto Kubernetes de código abierto de Google, ahora mantenido por la Cloud Native Computing Foundation, saltó a la prominencia para resolver la orquestación de aplicaciones de microservicios —permitiendo que las aplicaciones se ejecuten en infraestructura genérica, sean monitoreadas y gestionadas de formas estándar, y autenticadas usando estándares abiertos.

Eso está bien para aplicaciones. Pero, ¿qué pasa con el mundo de los datos? La misma orquestación de contenedores fundamental se requiere para que los almacenes de datos nativos en la nube ofrezcan elasticidad y flexibilidad de despliegue en nubes públicas y privadas, borde de red, híbridas y completamente distribuidas.

La re-arquitectura nativa en la nube para aplicaciones web de escalamiento horizontal es común, pero las bases de datos mayormente solo se han «levantado y desplazado» al mundo nativo en la nube. Meter una base de datos en un contenedor le permite ejecutarse en infraestructura moderna, pero no ofrece una experiencia que demuestre todos los beneficios de la nube. El software ignora en gran medida que se ejecuta en un entorno de contenedores, y operaciones como gestionar clústeres elásticos deben manejarse torpeamente desde fuera de la base de datos a mano usando Operators y manipulando gráficos Helm. Características como permitir que múltiples clústeres de computación elásticos bajo demanda compartan los mismos datos subyacentes en almacenamiento de objetos a menudo no están disponibles. Los usuarios que buscan valor empresarial de un almacén de datos elástico basado en la nube no quieren saber sobre gráficos Helm, pods, nodos o archivos de configuración. Quieren simplemente aprovisionar almacenes de datos, gestionar clústeres elásticos y obtener insights de sus datos.

Proporcionar una interfaz SQL sobre Kubernetes para aprovisionar múltiples clústeres elásticos bajo demanda y ocultar las complejidades de Kubernetes a DBAs y usuarios finales es la respuesta.

De esta manera, diferentes usuarios pueden ser asignados para ejecutar cargas de trabajo en diferentes clústeres de computación, y el clúster en uso puede cambiarse en tiempo de ejecución mediante SQL, sujeto a permisos. Los clústeres pueden configurarse para suspenderse automáticamente tras un período de inactividad y reiniciarse bajo demanda. Por ejemplo, un clúster de computación separado podría crearse para ejecutar procesos ETL cuando se necesite, uno para BI ad-hoc y múltiples clústeres de ciencia de datos. Los clústeres de computación pueden expandirse en línea durante períodos de uso intensivo o apagarse durante períodos tranquilos para ahorrar dinero. Los clústeres pueden crearse para ejecutar tareas de informes por lotes diarios, semanales o mensuales que solo están activos durante esos períodos. Tanto el tamaño de los nodos en el clúster de computación como el número de nodos son controlables en este modelo, y se pueden establecer límites en el consumo de recursos a nivel de instancia para previsibilidad. De igual forma, es posible configurar un sistema de réplica de bajo costo que reciba tráfico de replicación de una instancia principal de almacén de datos, que luego puede escalarse bajo demanda cuando la réplica necesite usarse.

Este tipo de elasticidad se implementa no solo integrando profundamente con Kubernetes, sino usando el propio SQL como «interfaz de usuario» para crear, suspender, reanudar y gestionar clústeres en lugar de herramientas de desarrollador. Kubernetes es la fuente autorizada de verdad para el estado de todos los clústeres. Las vistas del sistema que muestran el estado de los clústeres obtienen sus datos de Kubernetes usando sus APIs. Cuando se ingresan declaraciones SQL de gestión de clústeres, el almacén de datos nativo en la nube se comunica con Kubernetes para cambiar el estado deseado de una instancia; Kubernetes luego implementa los cambios necesarios. Si un nodo en el clúster se vuelve insalubre, Kubernetes pondrá un reemplazo en línea.

Esto representa una relación única, de adentro hacia afuera, con Kubernetes: en lugar de que Kubernetes sea la «interfaz de usuario» para impulsar el estado del clúster, la propia base de datos, que es gestionada por Kubernetes, se convierte en la interfaz de usuario. Esta arquitectura crea una relación simbiótica que ofrece una experiencia nativa en la nube única y totalmente realizada. El poder y la flexibilidad multiplataforma de Kubernetes se vuelven disponibles para un almacén de datos, impulsados completamente a través de SQL.

A medida que se generan más datos y se despliegan más casos de uso, es fácil para las empresas entrar en un ciclo vicioso donde su ecosistema se arraiga cada vez más en una nube particular. Los riesgos sistémicos pueden surgir en esa única nube que presenta demasiada exposición para infraestructura TI crítica en sectores fuertemente regulados como servicios financieros y seguros. Arquitectar con Kubernetes no es el único concepto central que da vida a un almacén de datos nativo en la nube totalmente realizado. No es el único componente arquitectónico alineado con el patrón de nube de datos distribuida. Pero es la pieza central indispensable que hace que el análisis de datos sea excepcionalmente flexible, ejecutándose en cualquier lugar en el punto de necesidad empresarial —y haciéndolo a escala y con alta concurrencia, rendimiento, eficiencia y disponibilidad. El resultado es que miles de usuarios en una empresa dada, en diferentes líneas de negocio y regiones geográficas, pueden tomar decisiones extremadamente rápidas y generar valor a partir del análisis en movimiento en tiempo casi real.