Gestión de datos nativos de la nube en Kubernetes

Capítulo 1. Introducción a la Infraestructura de Datos Nativa de la Nube: Persistencia, Streaming y Análisis por Lotes

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¿Trabajas resolviendo problemas de datos y te encuentras ante la necesidad de modernización? ¿Tu aplicación nativa en la nube se limita al uso de microservicios y malla de servicios? Si implementas aplicaciones en Kubernetes (a veces abreviado como "K8s") sin incluir datos, no has adoptado plenamente la nube nativa. Cada elemento de tu aplicación debe incorporar los principios nativos de la nube de escala, elasticidad, autorreparación y observabilidad, incluida la forma en que manejas los datos.

Los ingenieros que trabajan con datos se ocupan principalmente de los servicios con estado, y éste será nuestro enfoque: aumentar tus habilidades para gestionar datos en Kubernetes. Al leer este libro, nuestro objetivo es enriquecer tu viaje hacia los datos nativos de la nube. Si estás empezando con las aplicaciones nativas de la nube, no hay mejor momento para incluir todos los aspectos de la pila. Esta convergencia es el futuro de cómo consumiremos los recursos de la nube.

Entonces, ¿qué es este futuro que estamos creando juntos?

Durante demasiado tiempo, los datos han vivido fuera de Kubernetes, creando mucho esfuerzo y complejidad adicionales. Entraremos en razones válidas para ello, pero ahora es el momento de combinar toda la pila para crear aplicaciones más rápidamente, a la escala necesaria. Basándonos en la tecnología actual, esto es muy posible. Nos hemos alejado del pasado de la implementación de servidores individuales y nos acercamos a un futuro en el que podremos implementar centros de datos virtuales enteros. Los ciclos de desarrollo que antes llevaban meses y años ahora pueden gestionarse en días y semanas. Los componentes de código abierto pueden combinarse ahora en una única implementación en Kubernetes que es portátil, desde tu portátil hasta el mayor proveedor en la nube.

La contribución del código abierto tampoco es una minucia. Kubernetes y los proyectos que tratamos en este libro están bajo la Licencia Apache 2.0 a menos que se indique lo contrario, y por una buena razón. Si construimos una infraestructura que pueda funcionar en cualquier lugar, necesitamos un modelo de licencia que nos dé libertad de elección. El código abierto es libre como la cerveza y libre como la libertad, y ambas cosas cuentan a la hora de crear aplicaciones nativas de la nube en Kubernetes. El código abierto ha sido el combustible de muchas revoluciones en infraestructura, y ésta no es una excepción.

Eso es lo que estamos construyendo: la realidad de un futuro próximo de aplicaciones Kubernetes totalmente realizadas. El último componente es el más importante, y eres tú. Como lector de este libro, eres una de las personas que crearán este futuro. Crear es lo que hacemos como ingenieros. Reinventamos continuamente la forma de implementar infraestructuras complicadas para responder a la creciente demanda. Cuando en 1960 se puso en línea el primer sistema de base de datos electrónica para American Airlines, un pequeño ejército de ingenieros se aseguró de que permaneciera en línea y funcionara las 24 horas del día. El progreso nos llevó de los mainframes a los miniordenadores, a los microordenadores y, finalmente, a la gestión de flotas que hacemos hoy. Ahora, esa misma progresión continúa hacia la nube nativa y Kubernetes.

Este capítulo examinará los componentes de las aplicaciones nativas de la nube, los retos de ejecutar cargas de trabajo con estado, y las áreas esenciales tratadas en este libro. Para empezar, veamos los componentes básicos que componen la infraestructura de datos.

Tipos de infraestructuras

En los últimos 20 años, el enfoque de la infraestructura se ha bifurcado lentamente en dos áreas que reflejan cómo implementamos las aplicaciones distribuidas (como se muestra en la Figura 1-1):

Servicios sin estado

Se trata de servicios que mantienen la información sólo durante el ciclo de vida inmediato de la solicitud activa: por ejemplo, un servicio para enviar información formateada de la cesta de la compra a un cliente móvil. Un ejemplo típico es un servidor de aplicaciones que realiza la lógica de negocio para el carrito de la compra. Sin embargo, la información sobre el contenido de la cesta de la compra reside fuera de estos servicios. Sólo necesitan estar en línea durante un breve periodo de tiempo desde la solicitud hasta la respuesta. La infraestructura utilizada para prestar el servicio puede crecer y decrecer fácilmente con escaso impacto en la aplicación global, escalando los recursos informáticos y de red bajo demanda cuando sea necesario. Como no almacenamos datos críticos en el servicio individual, esos datos pueden crearse y destruirse rápidamente, con poca coordinación. Los servicios sin estado son un elemento de arquitectura crucial en los sistemas distribuidos.

Servicios con estado

Estos servicios necesitan mantener la información de una petición a la siguiente. Los discos y la memoria almacenan datos para su uso a través de múltiples peticiones. Un ejemplo es una base de datos o un sistema de archivos. El escalado de los servicios con estado es más complejo, ya que la información suele requerir replicación para una alta disponibilidad. Esto crea la necesidad de consistencia y mecanismos para mantener los datos sincronizados entre réplicas. Estos servicios suelen tener diferentes métodos de escalado, tanto vertical como horizontal. Como resultado, requieren diferentes conjuntos de tareas operativas que los servicios sin estado.

Figura 1-1. Servicios sin estado frente a servicios con estado

Además de la forma en que se almacena la información, también hemos visto un cambio hacia el desarrollo de sistemas que adoptan la implementación automatizada de infraestructuras. Entre estos avances recientes se incluyen los siguientes:

• Los servidores físicos han dado paso a las máquinas virtuales (VM), fáciles de implementar y mantener.

• Las máquinas virtuales se han simplificado y centrado en aplicaciones específicas para los contenedores.

• Los contenedores han permitido a los ingenieros de infraestructuras empaquetar los requisitos del sistema operativo de una aplicación en un único ejecutable.

Sin duda, el uso de contenedores ha aumentado la coherencia de las Implementaciones, lo que ha facilitado el despliegue y la ejecución de infraestructuras en masa. Pocos sistemas surgieron para orquestar la explosión de los contenedores como Kubernetes, lo que es evidente por su increíble crecimiento. Esto habla de lo bien que resuelve el problema. La documentación oficial describe Kubernetes de la siguiente manera:

Kubernetes es una plataforma portátil, extensible y de código abierto para gestionar cargas de trabajo y servicios en contenedores que facilita tanto la configuración declarativa como la automatización. Cuenta con un ecosistema amplio y en rápido crecimiento. Los servicios, el soporte y las herramientas de Kubernetes están ampliamente disponibles.

Kubernetes se diseñó originalmente para cargas de trabajo sin estado, y eso es lo que tradicionalmente ha hecho mejor. Kubernetes ha desarrollado una reputación como "plataforma para construir plataformas" de forma nativa en la nube. Sin embargo, existe el argumento razonable de que una solución completa nativa de la nube debe tener en cuenta los datos. Ese es el objetivo de este libro: explorar cómo hacemos posible construir soluciones de datos nativas de la nube en Kubernetes. Pero primero, vamos a desentrañar qué significa "nativo de la nube".

¿Qué son los datos nativos de la nube?

Empecemos a definir los aspectos de los datos nativos de la nube que pueden ayudarnos con una definición final. En primer lugar, empecemos con la definición de nube nativa de la Cloud Native Computing Foundation (CNCF):

Las tecnologías nativas de la nube permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos, como nubes públicas, privadas e híbridas. Los contenedores, las mallas de servicios, los microservicios, la infraestructura inmutable y las API declarativas ejemplifican este enfoque.

Estas técnicas permiten que los sistemas poco acoplados sean resistentes, manejables y observables. Combinadas con una automatización robusta, permiten a los ingenieros realizar cambios de gran impacto de forma frecuente y predecible con un esfuerzo mínimo.

Observa que esta definición describe un estado objetivo, características deseables y ejemplos de tecnologías que encarnan ambos. Basándonos en esta definición formal, podemos sintetizar las cualidades que diferencian una aplicación nativa de la nube de otros tipos de implementaciones en cuanto a cómo maneja los datos. Echemos un vistazo más de cerca a estas cualidades:

Escalabilidad

Si un servicio puede producir una unidad de trabajo por una unidad de recursos, añadir más recursos debería aumentar la cantidad de trabajo que un servicio puede realizar. La escalabilidad describe la capacidad del servicio de aplicar recursos adicionales para producir trabajo adicional. Idealmente, los servicios deberían escalar infinitamente dada una cantidad infinita de recursos informáticos, de red y de almacenamiento. Para los datos, esto significa escalar sin necesidad de tiempo de inactividad. Los sistemas heredados requerían un periodo de mantenimiento mientras se añadían nuevos recursos, durante el cual todos los servicios tenían que apagarse. Con las necesidades de las aplicaciones nativas de la nube, el tiempo de inactividad ya no es aceptable.

Elasticidad

Mientras que la escala consiste en añadir recursos para satisfacer la demanda, la elasticidad es la capacidad de liberar esos recursos cuando ya no se necesitan. La diferencia entre escalabilidad y elasticidad se destaca en la Figura 1-2. La elasticidad también puede denominarse infraestructura a la carta. En un entorno restringido, como un centro de datos privado, es fundamental para compartir recursos limitados. Para la infraestructura en nube que cobra por cada recurso utilizado, es una forma de evitar pagar por ejecutar servicios que no necesitas. Cuando se trata de gestionar datos, esto significa que necesitamos capacidades para recuperar espacio de almacenamiento y optimizar nuestro uso; por ejemplo, moviendo los datos más antiguos a niveles de almacenamiento menos caros.

Figura 1-2. Comparación entre escalabilidad y elasticidad

Autocuración

Las cosas malas ocurren. Cuando ocurran, ¿cómo responderá tu infraestructura? La infraestructura autorreparable redirigirá el tráfico, reasignará recursos y mantendrá los niveles de servicio. Con la implementación de aplicaciones distribuidas más grandes y complejas, éste es un atributo cada vez más importante de una aplicación nativa de la nube. Esto es lo que evita que te despierten a las 3 de la mañana. Para los datos, esto significa que necesitamos capacidades para detectar problemas con los datos, como datos que faltan y calidad de los datos.

Observabilidad

Si algo falla y no lo estás monitoreando, ¿ha ocurrido? Por desgracia, no sólo la respuesta es sí, sino que puede ser un escenario aún peor. Las aplicaciones distribuidas son muy dinámicas, y la visibilidad de cada servicio es fundamental para mantener los niveles de servicio. Las interdependencias pueden crear escenarios de fallo complejos, y por eso la observabilidad es una parte clave de la construcción de aplicaciones nativas de la nube. En los sistemas de datos, los volúmenes que son habituales necesitan formas eficientes de monitorizar el flujo y el estado de la infraestructura. En la mayoría de los casos, las alertas tempranas de problemas pueden ayudar a los operadores a evitar costosos tiempos de inactividad.

Con todas las definiciones anteriores, vamos a intentar una definición que exprese estas propiedades:

Los enfoques dedatos nativos de la nube facultan a las organizaciones que han adoptado la metodología de aplicaciones nativas de la nube para incorporar los datos de forma holística, en lugar de emplear el legado de personas, procesos y tecnología, de modo que los datos puedan escalarse hacia arriba y hacia abajo elásticamente, y promover la observabilidad y la autorreparación. Un ejemplo de ello son los datos en contenedores, los datos declarativos, las API de datos, las mallas de datos y la infraestructura de datos nativa de la nube (es decir, bases de datos, streaming y tecnologías analíticas que a su vez están diseñadas como aplicaciones nativas de la nube).

Para que la infraestructura de datos mantenga la paridad con el resto de nuestra aplicación, necesitamos incorporar cada pieza. Esto incluye la automatización de la escala, la elasticidad y la autorreparación. Las API son necesarias para desacoplar los servicios y aumentar la velocidad del desarrollador, así como para permitirle observar toda la pila de su aplicación para tomar decisiones críticas. En conjunto, tu aplicación y tu infraestructura de datos deben parecer una unidad.

Más infraestructuras, más problemas

Tanto si tu infraestructura está en la nube, en las instalaciones o en ambas (lo que comúnmente se denomina híbrida), podrías pasar mucho tiempo realizando la configuración manual. Escribir cosas en un editor y realizar un trabajo de configuración increíblemente detallado requiere un profundo conocimiento de cada tecnología. En los últimos 20 años, se han producido avances significativos en la comunidad DevOps, tanto en el código como en la forma de implementar nuestra infraestructura. Se trata de un paso fundamental en la evolución de la infraestructura moderna. DevOps nos ha mantenido por delante de la escala requerida para las aplicaciones, pero apenas. Podría decirse que se necesita la misma cantidad de conocimientos para programar completamente la implementación de un servidor de base de datos. Sólo que ahora podemos hacerlo un millón de veces (si es necesario) con plantillas y scripts. Lo que ha faltado es una conexión entre los componentes y una visión holística de toda la pila de aplicaciones. Abordemos juntos este problema. (Premonitorio: es un problema que hay que resolver).

Como con cualquier buen problema de ingeniería, dividámoslo en partes manejables. La primera es la gestión de recursos. Independientemente de las muchas formas que hemos desarrollado para trabajar a escala, fundamentalmente, estamos tratando de gestionar tres cosas de la forma más eficiente posible: computación, red y almacenamiento, como se muestra en la Figura 1-3. Estos son los recursos críticos que toda aplicación necesita y el combustible que se quema durante el crecimiento. No es sorprendente que también sean los recursos que aportan el componente monetario a una aplicación en funcionamiento. Nos recompensan cuando utilizamos los recursos sabiamente y pagamos un precio literalmente alto si no lo hacemos. Dondequiera que ejecutes tu aplicación, éstas son las unidades más primitivas. Cuando está en Prem, todo se compra y se posee. Cuando usamos la nube, lo alquilamos.

Figura 1-3. Recursos fundamentales de las aplicaciones en la nube: computación, red y almacenamiento

La segunda parte del problema es hacer que toda una pila actúe como una sola entidad. DevOps ha proporcionado muchas herramientas para gestionar los componentes individuales, pero el tejido conectivo entre ellos proporciona el potencial para una eficiencia increíble, de forma similar a cómo se empaquetan las aplicaciones para el escritorio, pero trabajando a escala de centro de datos. Ese potencial ha lanzado toda una comunidad en torno a las aplicaciones nativas de la nube. Estas aplicaciones son similares a las que siempre hemos implementado. La diferencia es que las aplicaciones modernas en la nube no son un único proceso con lógica empresarial. Son una compleja coordinación de muchos procesos en contenedores que necesitan comunicarse de forma segura y fiable. El almacenamiento tiene que ajustarse a las necesidades actuales de la aplicación, pero siendo consciente de cómo contribuye a la estabilidad de la aplicación. Cuando pensamos en la implementación de aplicaciones sin estado sin datos gestionados en el mismo plano de control, suena incompleto porque lo es. Dividir los componentes de tu aplicación en diferentes planos de control crea más complejidad y, por tanto, va en contra de los ideales de la nube nativa.

Kubernetes lidera el camino

Como ya se ha mencionado, la automatización de DevOps nos ha mantenido en el perímetro de vanguardia para satisfacer las necesidades de escala. La contenedorización produjo la necesidad de una orquestación mucho mejor, y Kubernetes ha respondido a esa necesidad. Para los operadores, describir una pila completa de aplicaciones en un archivo de implementación constituye una infraestructura reproducible y portátil. Esto se debe a que Kubernetes ha ido mucho más allá de la simple gestión de la implementación popular en la bolsa de herramientas DevOps. El plano de control de Kubernetes aplica el requisito de implementación en la informática, la red y el almacenamiento subyacentes para gestionar todo el ciclo de vida de la infraestructura de la aplicación. El estado deseado de tu aplicación se mantiene incluso cuando cambia el hardware subyacente. En lugar de desplegar máquinas virtuales, ahora desplegamos centros de datos virtuales como una definición completa, como se muestra en la Figura 1-4.

El aumento de la popularidad de Kubernetes ha eclipsado a todas las demás herramientas de orquestación de contenedores utilizadas en DevOps. Ha superado a todas las demás formas de implementación de infraestructuras y no muestra signos de desaceleración. Sin embargo, la mayor parte de su adopción inicial se produjo principalmente en servicios sin estado.

La gestión de la infraestructura de datos a gran escala era un problema mucho antes del paso a los contenedores y Kubernetes. Los servicios con estado, como las bases de datos, siguieron un camino distinto, paralelo a la curva de adopción de Kubernetes. Muchos expertos aconsejaron que Kubernetes era la forma equivocada de ejecutar servicios con estado y que esas cargas de trabajo debían permanecer fuera de Kubernetes. Ese enfoque funcionó hasta que dejó de hacerlo, y muchos de esos mismos expertos están impulsando ahora los cambios necesarios en Kubernetes para hacer converger toda la pila.

Figura 1-4. Pasar de servidores virtuales a centros de datos virtuales

Entonces, ¿cuáles son los retos de los servicios con estado? ¿Por qué ha sido difícil implementar una infraestructura de datos con Kubernetes? Consideremos cada componente de nuestra infraestructura.

Gestión de la informática en Kubernetes

En la infraestructura de datos, contar con la ley de Moore ha convertido la actualización en un acontecimiento regular. La ley de Moore predijo que la capacidad informática se duplicaría cada 18 meses. Si tus necesidades se duplican cada 18 meses, puedes seguir el ritmo sustituyendo el hardware. Con el tiempo, la potencia de cálculo bruta empezó a estabilizarse. Los proveedores empezaron a añadir más procesadores y núcleos para seguir el ritmo de la ley de Moore, lo que llevó a compartir recursos de un solo servidor con máquinas virtuales y contenedores, y nos permitió aprovechar las enormes reservas de potencia informática que quedaban abandonadas en islas de servidores físicos. Kubernetes amplió el alcance de la gestión de los recursos informáticos al considerar el centro de datos total como una gran reserva de recursos a través de múltiples dispositivos físicos.

Compartir recursos informáticos con otros servicios es algo tabú en el mundo de los datos. Las cargas de trabajo de datos suelen consumir muchos recursos, y la posibilidad de que un servicio afecte a otro (conocido como el problema del vecino ruidoso) ha llevado a políticas de mantenerlos aislados de otras cargas de trabajo. Este enfoque de talla única elimina la posibilidad de beneficios más significativos. La primera es la suposición de que todos los requisitos de recursos de los servicios de datos son iguales. Los brokers de Apache Pulsar pueden tener muchos menos requisitos que un trabajador de Apache Spark, y ninguno de ellos es similar a una instancia MySQL de tamaño considerable utilizada para la elaboración de informes de procesamiento analítico en línea (OLAP). En segundo lugar, la capacidad de desacoplar el hardware subyacente de las aplicaciones en ejecución proporciona a los operadores una gran flexibilidad infravalorada. Las aplicaciones nativas de la nube que necesitan escala, elasticidad y autorreparación necesitan lo que Kubernetes puede ofrecer. Los datos no son una excepción.

Gestionar la red en Kubernetes

Construir una aplicación distribuida, por naturaleza, requiere una red fiable y segura. Las aplicaciones nativas de la nube aumentan la complejidad de añadir y quitar servicios, lo que convierte la configuración dinámica de la red en un nuevo requisito. Kubernetes gestiona todo esto dentro de tu centro de datos virtual de forma automática. Cuando entran en funcionamiento nuevos servicios, es como si un equipo de red virtual entrara en acción. Se asignan direcciones IP, se crean rutas, se añaden entradas DNS, el equipo de seguridad virtual se asegura de que se aplican las reglas del cortafuegos y, cuando se solicita, los certificados de Seguridad de la Capa de Transporte (TLS) proporcionan cifrado de extremo a extremo.

La infraestructura de datos tiende a ser mucho menos dinámica que algo como los microservicios. Una IP fija con un nombre de host ha sido la norma para las bases de datos. Los sistemas analíticos como Apache Flink son dinámicos en el procesamiento, pero tienen asignaciones de direccionamiento de hardware fijas. La calidad del servicio suele estar en lo más alto de la lista de requisitos y, como resultado, el deseo de hardware dedicado y redes dedicadas ha alejado a los administradores de Kubernetes.

La ventaja de que la infraestructura de datos se ejecute en Kubernetes es que se trata menos de los requisitos del pasado y más de lo que se necesita para el futuro. Escalar recursos dinámicamente puede crear una cascada de dependencias. La automatización es la única forma de mantener unas redes limpias y eficientes, que son el alma de los sistemas distribuidos sin estado. El futuro de las aplicaciones nativas de la nube incluirá más componentes y nuevos retos, como dónde se ejecutarán las aplicaciones. Podemos añadir el cumplimiento normativo y la soberanía de los datos a las preocupaciones anteriores sobre la latencia y el rendimiento. La naturaleza declarativa de las redes Kubernetes hace que encaje perfectamente en la infraestructura de datos.

Gestión del almacenamiento en Kubernetes

Cualquier servicio que proporcione persistencia o análisis sobre grandes volúmenes de datos necesitará el tipo adecuado de dispositivo de almacenamiento. Las primeras versiones de Kubernetes consideraban el almacenamiento una parte básica de la pila y daban por sentado que la mayoría de las cargas de trabajo eran efímeras. Para los datos, esto era un gran desajuste: no puedes dejar que tus archivos de datos Postgres se borren cada vez que se mueve un contenedor. Además, al principio, el almacenamiento en bloque subyacente variaba desde discos NVMe de alto rendimiento hasta viejos discos giratorios de 5400 RPM, y no siempre podías estar seguro de qué tipo de hardware te tocaría. Afortunadamente, éste ha sido un aspecto esencial de Kubernetes en los últimos años y ha mejorado significativamente.

Con la incorporación de funciones como StorageClasses, es posible abordar requisitos específicos de rendimiento, capacidad o ambos. Con la automatización, podemos evitar el momento en que no tengas suficiente de ninguna de las dos cosas. Evitar sorpresas es el dominio de la gestión de la capacidad: tanto inicializar la capacidad necesaria como crecer cuando sea necesario. Cuando te quedas sin capacidad en tu almacenamiento, todo se paraliza.

Acoplar la naturaleza distribuida de Kubernetes con el almacenamiento de datos abre más posibilidades de autocuración. Las copias de seguridad e instantáneas automatizadas te mantienen preparado para posibles escenarios de pérdida de datos. Colocar juntos el cálculo y el almacenamiento minimiza los riesgos de fallo del hardware y permite la recuperación automática al estado deseado cuando se produce el inevitable fallo. Todo esto hace que los aspectos de almacenamiento de datos de Kubernetes sean mucho más atractivos.

Componentes de datos nativos de la nube

Ahora que hemos definido los recursos que consumen las aplicaciones nativas de la nube, aclaremos los tipos de infraestructura de datos que las alimentan. En lugar de una lista exhaustiva de todos los productos posibles, los dividiremos en cubos más grandes con características similares:

Persistencia

Esta es probablemente la categoría en la que piensas primero cuando hablamos de infraestructura de datos. Estos sistemas almacenan datos y proporcionan acceso mediante algún método de consulta: bases de datos relacionales como MySQL y Postgres, y sistemas NoSQL como Apache Cassandra y MongoDB. Éstos han sido los últimos en migrar a Kubernetes debido a sus estrictas necesidades de recursos y requisitos de alta disponibilidad. Las bases de datos suelen ser críticas para una aplicación en funcionamiento y centrales para cualquier otra parte del sistema.

Streaming

La función más básica del streaming es facilitar el movimiento a alta velocidad de datos de un punto a otro. Los sistemas de streaming proporcionan una variedad de semánticas de entrega basadas en un caso de uso. En algunos casos, los datos pueden entregarse a muchos clientes, o cuando se necesitan controles estrictos, entregarse sólo una vez. Otra mejora del streaming es la adición de procesamiento: alterar o mejorar los datos a mitad del transporte. La necesidad de obtener información más rápida sobre los datos ha impulsado la analítica de flujo a un estado de misión crítica, alcanzando a los sistemas de persistencia en términos de importancia. Ejemplos de sistemas de streaming que mueven datos son Apache Flink y Apache Kafka, mientras que ejemplos de sistemas de procesamiento son Apache Flink y Apache Storm.

Análisis de lotes

Uno de los primeros problemas de los big data es analizar grandes conjuntos de datos para obtener información o reconvertirlos en nuevos datos. Apache Hadoop fue el primer sistema a gran escala para el análisis por lotes que estableció las expectativas en torno al uso de grandes volúmenes de computación y almacenamiento, coordinados de forma que produjeran los resultados de procesos analíticos complejos. Normalmente, éstos se emiten como trabajos distribuidos por todo el clúster, como es habitual con Spark. La preocupación por los costes puede ser mucho mayor en estos sistemas debido al gran volumen de recursos necesarios. Los sistemas de orquestación ayudan a mitigar los costes mediante una asignación inteligente.

De cara al futuro

Hay un futuro convincente con los datos nativos de la nube. El camino que tomemos entre lo que tenemos disponible hoy y lo que podemos tener en el futuro depende de nosotros: la comunidad de personas responsables de la infraestructura de datos. Como siempre hemos hecho, vemos un nuevo reto y lo asumimos. Aquí hay mucho que hacer para todos, pero el resultado podría ser bastante sorprendente y elevar el listón una vez más.

Una llamada a las bases de datos para modernizarse en Kubernetes

Con Rick Vasquez, Director Senior de Iniciativas Estratégicas de Western Digital

Esto es algo para cualquiera que trabaje con bases de datos en la década de 2020. Kubernetes está liderando la construcción de sistemas distribuidos y nativos de la nube. Los sistemas de datos no están aprovechando toda la capacidad y el conjunto de funciones posibles si estuvieran mejor integrados con Kubernetes. Soy un converso de la forma de pensar "nunca debes ejecutar una base de datos en un contenedor". Ahora, creo que deberíamos empujar a todo el mundo a tener la implementación principal en Kubernetes. Mi experiencia siempre ha sido en casos de uso empresarial a escala. No veo esto como una moda pasajera. Observo la aplicabilidad a escala global de algunas de las mayores empresas del mundo.

Una línea de pensamiento que tenemos que superar es tratar a Kubernetes como un sistema operativo que permite que otras aplicaciones se ejecuten en él. Esa es la forma equivocada de ver la ejecución de cargas de trabajo de datos. Si tu sistema se ejecuta en un contenedor, por supuesto que funcionará en Kubernetes, ¿verdad? ¡No! Reaccionará a la forma en que el plano de control despliegue y ejecute tu aplicación, y el resultado puede o no ser el que deseas. ¿Y si los sistemas de datos estuvieran más estrechamente integrados con Kubernetes y pudieran descargar funciones para que las gestionara el plano de control de Kubernetes? El descubrimiento de servicios, el equilibrio de carga, la orquestación del almacenamiento, los rollouts y rollbacks automatizados, el empaquetado automatizado de contenedores, la autorreparación y la gestión de secretos y configuraciones son cosas muy potentes que te permiten tener una experiencia coherente para el desarrollador y el SRE. La clave de Kubernetes es la coherencia. Puedes utilizar Kubernetes para ser globalmente coherente en todas tus Implementaciones y hacerlas de la misma manera una y otra vez. Pero eso debe incluir los sistemas de bases de datos. Imagina que tuvieras Postgres, MongoDB, MySQL o Cassandra, y que estuvieran construidos de forma nativa en Kubernetes. ¿Qué harías?

Tener acceso para utilizar diferentes niveles de almacenamiento, ya sea disco local o remoto, todo ello es declarativo en algunos objetos de configuración. Quiero configurarlo en y con la base de datos. Si utilizo MySQL, quiero que los registros estén en el disco local, porque no quiero cuellos de botella. Quiero que ciertas tablas estén en un disco más lento que puede estar en la red. Y quiero que los datos de los últimos siete días estén en discos NVMe calientes y locales, utilizando toda la capacidad que tengas con réplicas que realmente hagan cosas -como descargar lecturas o múltiples nodos de escritura- y un gran agregado para análisis. Todo esto debería ser posible con una implementación basada en Kubernetes con una base de datos nativa de la nube.

Las bases de datos no razonan ni opinan sobre su tamaño. Si haces más grande una base de datos, simplemente necesitará más recursos. Puedes configurar el autoescalado para hacerla más grande, o el escalado horizontal. ¿Qué ocurre cuando quieres utilizar la verdadera elasticidad que te proporciona Kubernetes? No es sólo la escala hacia arriba y hacia fuera. ¡Es la escala hacia atrás y hacia abajo! ¿Por qué las bases de datos no hacen eso? Es muy importante maximizar el valor que obtienes de una implementación basada en Kubernetes o, más ampliamente, de una implementación basada en una nube nativa. Tenemos mucho trabajo por hacer, pero el futuro merece la pena.

El punto de Rick se refiere específicamente a las bases de datos, pero podemos extrapolar su llamada a la acción para nuestra infraestructura de datos que se ejecuta en Kubernetes. A diferencia de la implementación de una aplicación de datos en servidores físicos, la introducción del plano de control de Kubernetes requiere una conversación con los servicios que ejecuta.

Prepararse para la Revolución

Como ingenieros que crean y ejecutan infraestructuras de datos, tenemos que estar preparados para los próximos avances, tanto en la forma de operar como en la mentalidad que tenemos sobre el papel de la infraestructura de datos. Las siguientes secciones describen lo que puedes hacer para estar preparado para el futuro de los datos nativos de la nube que se ejecutan en Kubernetes.

Adoptar una mentalidad SRE

El papel de la ingeniería de fiabilidad del sitio (SRE) ha crecido con la adopción de metodologías nativas de la nube. Si pretendemos que nuestra infraestructura converja, los ingenieros de infraestructuras de datos debemos aprender nuevas habilidades y adoptar nuevas prácticas. Empecemos con la definición de SRE de Wikipedia:

La ingeniería de fiabilidad de sitios web es un conjunto de principios y prácticas que incorpora aspectos de la ingeniería de software y los aplica a problemas de infraestructura y operaciones. Los objetivos principales son crear sistemas de software escalables y altamente fiables. La ingeniería de fiabilidad del sitio está estrechamente relacionada con DevOps, un conjunto de prácticas que combinan el desarrollo de software y las operaciones de TI, y la SRE también se ha descrito como una implementación específica de DevOps.

La implementación de la infraestructura de datos se ha centrado principalmente en los componentes específicos implementados: el "qué". Por ejemplo, puede que te encuentres centrado en la implementación de MySQL a escala o en el uso de Spark para analizar grandes volúmenes de datos. Adoptar una mentalidad de SRE significa ir más allá de lo que estás implementando y centrarte más en el cómo. ¿Cómo funcionarán juntas todas las piezas para alcanzar los objetivos de la aplicación? Una visión holística de la implementación tiene en cuenta el modo en que interactuará cada pieza, el acceso necesario, incluida la seguridad, y la observabilidad de cada aspecto para garantizar el cumplimiento de los niveles de servicio.

Si tu función principal o secundaria actual es la de administrador de bases de datos (DBA), no hay mejor momento para hacer la transición. La tendencia en LinkedIn muestra un descenso interanual del papel de DBA y un aumento masivo para los SRE. Los ingenieros que han aprendido las habilidades necesarias para gestionar infraestructuras críticas de bases de datos tienen una base esencial que se traduce en lo que se necesita para gestionar datos nativos de la nube. Estas necesidades incluyen lo siguiente

• Disponibilidad

• Latencia

• Gestión del cambio

• Respuesta de emergencia

• Gestión de la capacidad

Hay que añadir nuevas habilidades a esta lista para adaptarse mejor a la responsabilidad más importante de toda la aplicación. Se trata de habilidades que quizá ya tengas, pero que incluyen las siguientes:

Canalizaciones CI/CD

Adopta la visión global de llevar el código del repositorio a la producción. No hay nada que acelere más el desarrollo de aplicaciones en una organización. La integración continua (IC) crea nuevo código en la pila de aplicaciones y automatiza todas las pruebas para garantizar la calidad. La entrega continua (CD) toma las compilaciones totalmente probadas y certificadas y las despliega automáticamente en producción. Utilizadas en combinación (pipeline), las organizaciones pueden aumentar drásticamente la velocidad y la productividad de los desarrolladores.

Observabilidad

A los profesionales de DevOps les gusta distinguir entre el "qué" (el servicio real que estás implementando) y el "cómo" (la metodología de implementación de ese servicio). El monitoreo es algo con lo que todos los que tienen experiencia en infraestructura están familiarizados. En la parte "qué" de DevOps, las propiedades que monitorizas te permiten saber que tus servicios están en buen estado y te dan la información necesaria para diagnosticar problemas. La capacidad de observación amplía el monitoreo al "cómo" de tu aplicación, al considerar todo como un todo: por ejemplo, rastrear el origen de la latencia en una aplicación altamente distribuida, proporcionando información sobre cada salto que dan los datos al atravesar tu sistema.

Conocer el código

Cuando las cosas van mal en una aplicación grande y distribuida, la causa no siempre es un fallo del proceso. En muchos casos, el problema puede ser un error en el código o un sutil detalle de implementación. Al ser responsable de toda la salud de la aplicación, necesitarás comprender el código que se ejecuta en el entorno proporcionado. Una observabilidad correctamente implementada te ayudará a encontrar problemas, y eso incluye la instrumentación del software. Los SRE y los equipos de desarrollo deben mantener una comunicación clara y regular, y el código es terreno común.

Adoptar la informática distribuida

Implementar tus aplicaciones en Kubernetes significa adoptar todo lo que ofrece la informática distribuida. Cuando estás acostumbrado a pensar en un solo sistema, esa transición puede ser difícil, principalmente por el cambio de mentalidad en torno a las expectativas y la comprensión de dónde surgen los problemas. Por ejemplo, con todos los procesos contenidos en un único sistema, la latencia será cercana a cero. No es lo que tienes que gestionar. Los recursos de CPU y memoria son la principal preocupación en este caso. En los años 90, Sun Microsystems lideraba el creciente campo de la informática distribuida y publicó esta lista de ocho falacias comunes de la informática distribuida:

• La red es fiable.

• La latencia es cero.

• El ancho de banda es infinito.

• La red es segura.

• La topología no cambia.

• Hay un administrador.

• El coste de transporte es cero.

• La red es homogénea.

Detrás de cada una de estas falacias está seguramente la historia de un desarrollador que hizo una mala suposición, obtuvo un resultado inesperado y perdió incontables horas intentando resolver el problema equivocado. Abrazar las metodologías distribuidas merece la pena a largo plazo. Nos permiten construir aplicaciones a gran escala y seguirán haciéndolo durante mucho tiempo. El reto merece la recompensa, y para los que hacemos esto a diario, ¡también puede ser muy divertido! Las aplicaciones Kubernetes pondrán a prueba cada una de estas falacias, dada su naturaleza distribuida por defecto. Cuando planifiques tu implementación, ten en cuenta aspectos como el coste del transporte de un lugar a otro o las implicaciones de la latencia. Te ahorrarán mucho tiempo perdido y rediseños.

Principios de la infraestructura de datos nativa de la nube

Como profesionales de la ingeniería, buscamos normas y buenas prácticas en las que basarnos. Para que los datos sean lo más "nativos de la nube" posible, tenemos que adoptar todo lo que ofrece Kubernetes. Un enfoque verdaderamente nativo de la nube significa adoptar elementos clave del paradigma de diseño de Kubernetes y construir a partir de ahí. Toda aplicación nativa de la nube que incluya datos debe poder ejecutarse eficazmente en Kubernetes. Exploremos algunos principios de diseño de Kubernetes que señalan el camino.

Principio 1: Aprovechar la computación, la red y el almacenamiento como APIs básicas

Una de las claves del éxito de la computación en nube es la comoditización de la informática, las redes y el almacenamiento como recursos que podemos suministrar mediante sencillas API. Considera esta muestra de servicios de AWS:

Calcula

Asignamos máquinas virtuales mediante Amazon Elastic Compute Cloud (EC2) y grupos de Autoescalado (ASG).

Red

Gestionamos el tráfico mediante Elastic Load Balancers (ELB), Route 53 y peering de nube privada virtual (VPC).

Almacenamiento

Persistimos los datos utilizando opciones como Simple Storage Service (S3) para el almacenamiento de objetos a largo plazo, o volúmenes de Elastic Block Store (EBS) para nuestras instancias de cálculo.

Kubernetes ofrece sus propias API para proporcionar servicios similares a un mundo de aplicaciones en contenedores:

Calcula

Pods, Implementaciones y ReplicaSets gestionan la programación y el ciclo de vida de los contenedores en el hardware informático.

Red

Los Servicios y la Entrada exponen las interfaces de red de un contenedor.

Almacenamiento

Los PersistentVolumes (PVs) y los StatefulSets permiten la asociación flexible de contenedores al almacenamiento.

Los recursos de Kubernetes promueven la portabilidad de las aplicaciones entre distribuciones de Kubernetes y proveedores de servicios. ¿Qué significa esto para las bases de datos? Son simplemente aplicaciones que aprovechan los recursos de computación, redes y almacenamiento para proporcionar los servicios de persistencia y recuperación de datos:

Calcula

Una base de datos necesita suficiente potencia de procesamiento para procesar los datos y las consultas entrantes. Cada nodo de la base de datos se despliega como un Pod y se agrupa en StatefulSets, lo que permite a Kubernetes gestionar el escalado de salida y de entrada.

Red

Una base de datos necesita exponer interfaces para datos y control. Podemos utilizar los Servicios de Kubernetes y los controladores Ingress para exponer estas interfaces.

Almacenamiento

Una base de datos utiliza PersistentVolumes de una StorageClass especificada para almacenar y recuperar datos.

Pensar en las bases de datos en términos de sus necesidades de computación, red y almacenamiento elimina gran parte de la complejidad que conlleva la implementación en Kubernetes.

Principio 2: Separar los planos de control y de datos

Kubernetes promueve la separación de los planos de control y de datos. El servidor API de Kubernetes es la puerta de entrada del plano de control, proporcionando la interfaz utilizada por el plano de datos para solicitar recursos informáticos, mientras que el plano de control gestiona los detalles de la asignación de esas solicitudes a una plataforma subyacente de infraestructura como servicio (IaaS).

Podemos aplicar este mismo patrón a las bases de datos. Por ejemplo, el plano de datos de una base de datos consta de puertos expuestos para los clientes y, en el caso de las bases de datos distribuidas, de puertos utilizados para la comunicación entre los nodos de la base de datos. El plano de control incluye interfaces proporcionadas por la base de datos para la administración y la recopilación de métricas y herramientas que realizan tareas de mantenimiento operativo. Gran parte de esta capacidad puede y debe implementarse mediante el patrón de operador de Kubernetes. Los operadores definen recursos personalizados (CRD) y proporcionan bucles de control que observan el estado de esos recursos, tomando medidas para moverlos hacia el estado deseado, ayudando a ampliar Kubernetes con lógica específica del dominio.

Principio 3: Facilitar la observabilidad

Los tres pilares de los sistemas observables son el registro, las métricas y el seguimiento. Kubernetes proporciona un gran punto de partida al exponer los registros de cada contenedor a soluciones de agregación de registros de terceros. Existen múltiples soluciones para las métricas, el rastreo y la visualización, y exploraremos varias de ellas en este libro.

Principio 4: Haz que la configuración por defecto sea segura

La red de Kubernetes es segura por defecto: los puertos deben exponerse explícitamente para que se pueda acceder a ellos desde el exterior de un pod. Esto sienta un valioso precedente para la implementación de bases de datos, obligándonos a pensar detenidamente cómo se expondrá cada interfaz del plano de control y del plano de datos, y qué interfaces deben exponerse a través de un Servicio Kubernetes. Kubernetes también proporciona facilidades para la gestión de secretos que pueden utilizarse para compartir claves de cifrado y configurar cuentas administrativas.

Principio 5: Prefiere la configuración declarativa

En el enfoque declarativo de Kubernetes, especificas el estado deseado de los recursos, y los controladores manipulan la infraestructura subyacente para alcanzar ese estado. Los operadores de la infraestructura de datos pueden gestionar los detalles de cómo escalar de forma inteligente: por ejemplo, decidir cómo reasignar fragmentos o particiones al escalar nodos adicionales o seleccionar qué nodos eliminar para escalar elásticamente hacia abajo.

La próxima generación de operadores debería permitirnos especificar reglas para el tamaño de los datos almacenados, el número de transacciones por segundo, o ambos. Quizá podamos especificar tamaños de clúster máximos y mínimos, y cuándo trasladar los datos de uso menos frecuente al almacenamiento de objetos. Esto permitirá una mayor automatización y eficacia en nuestra infraestructura de datos.

Resumen

Llegados a este punto, esperamos que estés preparado para el emocionante viaje de las próximas páginas. El paso a las aplicaciones nativas de la nube debe incluir los datos, y para ello aprovecharemos Kuberentes para incluir servicios sin estado y con estado. En este capítulo se ha tratado la infraestructura de datos nativa de la nube que puede escalar elásticamente y resistir cualquier tiempo de inactividad debido a fallos del sistema, y cómo construir estos sistemas. Como ingenieros, debemos adoptar los principios de la infraestructura nativa de la nube y, en algunos casos, aprender nuevas habilidades. Enhorabuena: has iniciado un fantástico viaje hacia el futuro de la creación de aplicaciones nativas de la nube. Pasa página y ¡adelante!