La ruta nativa de la nube a los datos en cualquier lugar

La arquitectura 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 comercial, y haciéndolo a escala y con alta concurrencia, rendimiento, eficiencia y disponibilidad.

Miles de empresas en verticales que van desde servicios financieros y seguros hasta manufactura y atención médica están descubriendo que necesitan implementaciones de nube pública y privada, híbridas y perimetrales para adaptarse mejor a sus necesidades de análisis y gestión de datos. Por lo tanto, no sorprende 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 análisis y gestión de datos de nivel superior conduce naturalmente a la idea de una nube de datos distribuidos . Dentro de una nube de datos distribuidos, los almacenes de datos empresariales no solo se utilizarán para proporcionar análisis a unos pocos cientos de analistas comerciales o científicos de datos en una empresa, sino que, en última instancia, podrán impulsar aplicaciones analíticas en tiempo real que son utilizadas directamente por el final de una empresa. clientes que se cuentan por decenas de miles. Se podrá acceder de inmediato a los datos, y se obtendrán conocimientos, en cualquier lugar.

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

Explorando el destino

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

Para ser más precisos, una tecnología de análisis y gestión de datos nativa de la nube debe mostrar cinco características clave para alinearse con el modelo de nube de datos distribuidos:

• Un tiempo de ejecución independiente de la plataforma que permite 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 destino de implementación
• Eficiencia tecnológica y de costes en cualquier lugar, minimizando los recursos y permitiendo una sólida gestión de costes (FinOps) y medidas de protección de gastos
• Un único plano de control que une todas las implementaciones, en la nube pública, en las instalaciones y en el perímetro de la red

Implementable en el punto de necesidad en cualquier lugar, un almacén de datos nativo de la nube completamente realizado que sigue este patrón también abstraerá la complejidad de la infraestructura de la nube, local y de red de los usuarios finales. El objetivo es liberarlos de los detalles de la infraestructura y permitirles concentrarse en generar valor a partir de análisis y administrar datos sin dejar de impartir 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 la ruta más popular para las operaciones nativas de la nube. Si bien la idea de particionar cargas de trabajo en Unix ha existido desde la década de 1970, fue solo hace una década que los contenedores se implementaron ampliamente para hacer que el desarrollo de aplicaciones sea más fácil, más portátil y eficiente en el uso de recursos. Pero implementar cientos o miles de aplicaciones en una gran arquitectura de microservicios resultó extremadamente complicado. Si bien existen otras opciones, el proyecto Kubernetes de código abierto de Google, ahora mantenido por Cloud Native Computing Foundation, saltó a la fama para resolver la orquestación de aplicaciones de microservicios, lo que permite que las aplicaciones se ejecuten en una infraestructura genérica, se supervisen y administren de manera estándar y se autentiquen mediante estándares abiertos.

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

La rearquitectura nativa de la nube para aplicaciones web escalables es un lugar común, pero las bases de datos en su mayoría simplemente se han "elevado y cambiado" al mundo nativo de la nube. Colocar una base de datos en un contenedor le permite ejecutarse en una infraestructura moderna, pero no ofrece una experiencia que demuestre todos los beneficios de la nube. El software ignora en gran medida el hecho de que se ejecuta en un entorno de contenedor, y las operaciones, como la administración de clústeres elásticos, deben manejarse torpemente desde fuera de la base de datos a mano utilizando operadores y pirateando gráficos de Helm. Las funciones como permitir que varios clústeres de computación elásticos bajo demanda compartan los mismos datos subyacentes en el almacenamiento de objetos a menudo no están disponibles. Los usuarios que buscan obtener valor empresarial de un almacén de datos elástico basado en la nube no quieren saber nada sobre gráficos, pods, nodos o archivos de configuración de Helm. Solo quieren aprovisionar almacenes de datos, administrar clústeres elásticos y obtener información de sus datos.

La respuesta es proporcionar una interfaz SQL a través de Kubernetes para aprovisionar múltiples clústeres elásticos bajo demanda y para ocultar las complejidades de Kubernetes de los administradores de bases de datos y los usuarios finales.

De esta manera, se pueden asignar diferentes usuarios para ejecutar cargas de trabajo en diferentes clústeres de cómputo, y el clúster de cómputo en uso se puede cambiar en tiempo de ejecución a través de SQL, sujeto a permiso. Los clústeres se pueden configurar para que se suspendan automáticamente después de un período de inactividad y vuelvan a activarse a pedido. Por ejemplo, se podría crear un clúster de cómputo separado para ejecutar procesos ETL cuando sea necesario, uno para inteligencia empresarial (BI) ad-hoc y múltiples clústeres de ciencia de datos. Los clústeres de cómputo se pueden expandir en línea durante los períodos de uso intensivo o apagarse durante los períodos de tranquilidad para ahorrar dinero. Los clústeres se pueden crear para ejecutar tareas de informes por lotes diarias, semanales o mensuales que solo están activas durante esos períodos de tiempo. Tanto el tamaño de los nodos en el clúster de cómputo como la cantidad de nodos son controlables en este modelo, y los límites en el consumo de recursos se pueden establecer a nivel de instancia para la previsibilidad. Del mismo modo, es posible configurar un sistema de réplica de bajo costo que reciba el tráfico de replicación de una instancia de almacén de datos principal, que luego se puede escalar a pedido cuando se necesita usar la réplica.

Este tipo de elasticidad se implementa no solo mediante una integración profunda con Kubernetes, sino mediante el uso de SQL como la "interfaz de usuario" para crear, suspender, reanudar y administrar clústeres en lugar de herramientas de desarrollo. 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 utilizando sus API. Cuando se ingresan las declaraciones SQL de administración de clústeres, el almacén de datos nativo de la nube se comunica con Kubernetes para cambiar el estado deseado de una instancia; Luego, Kubernetes implementa los cambios necesarios. Si un nodo en el clúster se vuelve defectuoso, Kubernetes traerá 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 controlar el estado del clúster, la base de datos en sí, que es administrada por Kubernetes, se convierte en la interfaz de usuario. Esta arquitectura crea una relación simbiótica que ofrece una experiencia de nube única y totalmente realizada. El poder y la flexibilidad multiplataforma de Kubernetes están disponibles para un almacén de datos, impulsado completamente a través de SQL.

A medida que se generan más datos y se implementan más casos de uso, es fácil para las empresas entrar en un círculo vicioso en el que su ecosistema se arraiga cada vez más dentro de una nube en particular. Pueden surgir riesgos sistémicos en esa nube única que presenta demasiada exposición para la infraestructura de TI crítica en sectores fuertemente regulados como los servicios financieros y los seguros. La arquitectura con Kubernetes no es el único concepto central que da vida a un almacén de datos nativo de la nube totalmente realizado. No es el único componente arquitectónico alineado con el patrón de nube de datos distribuidos. 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 comercial, y haciéndolo a escala y con alta concurrencia, rendimiento, eficiencia y disponibilidad. El resultado es que miles de usuarios en cualquier empresa determinada, en diferentes líneas de negocio y regiones geográficas, pueden tomar decisiones extremadamente rápidas y generar valor a partir de análisis en movimiento casi en tiempo real.