¿Qué viene después de Kubernetes?

0
114

«Aburrido”. Ese es uno de los mejores cumplidos que puede hacérsele a una tecnología de infraestructura. Nadie quiere ejecutar sus aplicaciones de misión crítica en algo «picante” ¿Pero aburrido? Aburrido está bien.

Aburrido significa que una tecnología ha alcanzado un cierto nivel de ubicuidad y confianza, que es comprendida de manera adecuada y fácil de administrar. Se podría decirse que Kubernetes, en la producción del 78% de las empresas, ha superado ese punto, siendo ampliamente reconocido como una pipeline estándar que habilita la nube y que «simplemente funciona”.

O, dicho de otro modo, se ha vuelto «aburrido”.

A pesar de que la Cloud Native Computing Foundation ayuda a coordinar el desarrollo de una serie de otros proyectos para completar los espacios en blanco que deja Kubernetes en la capa de infraestructura, la conversación de Kubernetes ha comenzado a cambiar a lo que está sucediendo en la parte superior de la pila. En abril, Kelsey Hightower, la superestrella defensora de los desarrolladores, observó que Kubernetes solo resuelve la mitad del problema en la modernización de las aplicaciones.

«Se está haciendo un montón de esfuerzo tratando de ‘modernizar’ las aplicaciones en la capa de infraestructura, pero sin una inversión igual en la capa de aplicación, los think frameworks y los servidores de aplicaciones, solo estamos resolviendo la mitad del problema”.

¿Qué hacemos al respecto?

Llenar la brecha entre aplicaciones e infraestructura
«Hay una gran brecha entre la infraestructura y la creación de una aplicación completa”, comenta Jonas Bonér, CTO y cofundador de Lightbend, en una entrevista. Bonér ayudó a iniciar el proyecto de código abierto Akka, que tiene como objetivo resolver un complejo problema entre la infraestructura y la aplicación, por encima de Kubernetes en la pila.

Como señala Bonér: «Es un ejercicio para el programador llenar el gran vacío de lo que realmente significa proporcionar SLA a la empresa, todas las cosas que son difíciles en los sistemas distribuidos pero necesarias para que la capa de aplicación aproveche al máximo Kubernetes y su ecosistema de herramientas”.

Aquí es donde una organización necesita que se sitúen cosas entre la aplicación y la infraestructura para hacer que todo funcione, señala Bonér. No se trata de reemplazar nada, sino de agregar más herramientas a la caja de herramientas y ampliar el modelo de infraestructura de aislamiento y las restricciones impuestas por la red, en la aplicación misma -entregada en un modelo de programación intuitivo, flexible y potente, pero simple.

Como dos ingenieros de Tesla discutían en una conferencia el año pasado, Tesla confía en las capacidades del «gemelo digital” que alimentan su red eléctrica, posibles gracias a la combinación de Akka y Kubernetes. «La mayoría de nuestros microservicios funcionan en Kubernetes, y la combinación de Akka y Kubernetes es realmente fantástica”, anotó el ingeniero de Tesla Colin Breck. Él explicó: «Kubernetes puede manejar fallas de grano grueso en el escalado; cosas como escalar pods hacia arriba o hacia abajo, ejecutar sondas de vida o reiniciar un pod fallido con un retroceso exponencial. Luego, utilizamos Akka para manejar fallas de grano fino, como la interrupción de circuitos o el reintento de una solicitud individual y el modelado del estado de entidades individuales, como el hecho de que una batería se está cargando o descargando”.

Según Bonér, hay tres áreas generalmente no resueltas que siguen evolucionando por encima de Kubernetes en la pila nativa de la nube, dando lugar a nuevas abstracciones ofrecidas por tecnologías como Akka: composición de la capa de aplicación, casos de uso con estado y casos de uso de datos en movimiento.

Habilitar la composición de la capa de aplicación declarativa
«Con demasiada frecuencia, las personas usan herramientas, hábitos y patrones antiguos, que suelen originarse a partir de los diseños tradicionales (monolíticos de tres niveles) que inhiben y limitan el modelo de nube entregado por Kubernetes”, señala Bonér. Necesitamos extender el modelo «increíblemente bueno” de contenedores, mallas de servicio y orquestación hasta la lógica de aplicación/empresarial, para que podamos sacarle el máximo provecho manteniendo las garantías de extremo a extremo en nombre de la aplicación, indica.

Serverless señala el camino al elevar el nivel de abstracción y al proporcionar un modelo declarativo donde la plataforma elimina y administra la mayor cantidad posible de repeticiones, infraestructura y operaciones, dejando al desarrollador con la esencia: la lógica empresarial y su flujo de trabajo.

Mejorar el soporte para casos de uso con estado
La mayor parte del ecosistema de la nube aborda principalmente las llamadas aplicaciones de 12 factores; es decir, aplicaciones sin estado. A veces eso puede ser todo lo que se necesita. Pero las aplicaciones no triviales suelen ser una mezcla de casos de uso sin estado y con estado.

«Necesitamos más y mejores herramientas para enfrentar bien el estado”, asegura Bonér. «Hoy en día, el valor suele estar en los datos, y es en los casos de uso con estado donde reside la mayor parte del valor empresarial -asegurándose de que se pueda acceder a esos datos rápidamente, mientras que se garantiza la corrección, la coherencia y la disponibilidad”.

En la nube, a menos que cuente con un modelo realmente bueno y herramientas que lo soporten, uno se ve obligado a volver a la arquitectura de tres capas donde se empuja todo hacia la base de datos, independientemente de si es para la comunicación, coordinación o el almacenamiento a largo plazo del estado.

Es importante destacar que también son necesarios buenos modelos de estado para complementar el enfoque sin estado, ofreciendo más opciones en la caja de herramientas. En la actualidad, el alcance del manejo de casos de uso con estado de Kubernetes solo se apoya en su característica StatefulSets, pero los StatefulSets están diseñados para las personas que implementan infraestructura como bases de datos, señala Bonér, no para los desarrolladores de aplicaciones.

«Así que todavía hay una gran brecha aquí”, indica Bonér. «Ahí es donde Akka realmente entra en juego”.

Manejar casos de uso de datos rápidos o de datos en movimiento
Podría decirse que el ecosistema de Kubernetes aún no ofrece un gran soporte para el streaming y los casos de uso basados en eventos. Las mallas de servicio como Istio están diseñadas en torno a un modelo de solicitud-respuesta y «pueden interferir”, señala Bonér. El streaming también suele ser con estado, y cuenta con etapas que agregan datos en la memoria mientras necesitan estar disponibles, lo que se relaciona con el tema anterior. Bonér insinuó que se está trabajando en la comunidad Knative para abordar esto, pero recién están comenzando.

Gran parte del impulso de estas nuevas direcciones parece ser el low code / no code / conceptos de «desacoplamiento de front-end y back-end» que se acumulan bajo el movimiento serverless.

«Serverless nos acerca a abordar el problema de extender el modelo de Kubernetes a la aplicación misma”, señala Bonér. «De eso se trata. Abstraerse lo más posible y pasar a un modelo declarativo de configuración en lugar de codificación, donde se define lo que debe hacer y no cómo hacerlo”.

Infraestructura de aplicaciones que «simplemente funciona”
A medida que la pila nativa de la nube continúa evolucionando por encima del nivel de infraestructura de Kubernetes, será interesante ver cómo estos conceptos se desarrollan en la capa de aplicación para servir a desarrolladores de idiomas específicos. Si bien muchos de los desafíos más difíciles de la arquitectura de aplicaciones han sido, durante mucho tiempo, parte del dominio del desarrollo de Java del lado del servidor, parece que nos estamos moviendo hacia una arquitectura Jamstack donde, cada vez más, son los desarrolladores de JavaScript los que esperan acceder a una infraestructura de aplicaciones que simplemente funciona, especialmente a medida que los puntos finales se multiplican exponencialmente.

Esto no quiere decir que la infraestructura de back-end no es importante. Más bien, es para reconocer, como Ian Massingham argumenta, que los desarrolladores front-end superan ampliamente a los desarrolladores back-end, y por una buena razón: hay muchas más aplicaciones que necesitan ser creadas, que infraestructura que requiere ser construida para alojarlo. Unir los dos mundos a través de proyectos de código abierto como Akka se vuelve cada vez más importante.

Matt Asay, InfoWorld.com