Servicios de aplicaciones para aplicaciones de Kubernetes: lo mismo de siempre pero nuevo

Hay un largo camino desde la resolución de problemas de VMS VAX hasta la escritura de microservicios sin servidor (aunque con el anuncio del soporte de COBOL en AWS Lambda en re:Invent, la primera vuelta de la lemniscata de TI podría estar completa).

Muchas cosas han cambiado a lo largo del camino. Me parece recordar que podía crear scripts en Perl y me molestaba que hubiera un sistema operativo que te permitiera cambiar de directorio a algún lugar que no existía (bonus: te permitía crearlo una vez que estabas ahí). Ahora parece que podemos dedicar tanto tiempo a decidir el enfoque para resolver un problema como a resolverlo realmente. Y esto es fantástico. La variedad de arquitecturas, el ritmo de desarrollo, la oportunidad digital y el despliegue de creatividad de los desarrolladores que nos ofrecen todos los nuevos juguetes es fantástico. No importa de qué lado del arco del proscenio te encuentres, tanto los desarrolladores como los consumidores disfrutan de aplicaciones nuevas y mejores a un ritmo y con una funcionalidad que hace no mucho tiempo era propiedad de la ciencia ficción.

Los contenedores y su atento supervisor Kubernetes son un ejemplo pertinente. La tecnología de contenedores ha sido indiscutiblemente un acelerador clave de la explosión del desarrollo de aplicação .

Esta semana, en la soleada Seattle (a las 10:46 a. m. del día de redacción de este artículo [Actualización: todavía soleado a la 1:36 p. m.]), más de 8000 personas se están reuniendo para hablar, escuchar y aprender sobre Kubernetes y otras tecnologías relacionadas con el código abierto. La mezcla de conversaciones, aprendizaje práctico y estímulos es la sopa primordial de la innovación. Mientras usted lee esto, se habrán ideado 12 grandes ideas nuevas (y 37 terribles).

Algunas de estas aplicaciones cambiarán vidas, algunas innovarán la arquitectura, algunas harán evolucionar las interfaces de usuario y algunas probablemente serán sólo otra forma de ilustrar lo desconectado que estoy de la cultura juvenil.

Pero algunas necesidades unirán estas diversas aplicações y los marcos que utilizan. Las soluciones pueden parecer diferentes, pero hay componentes críticos que todos deben resolver:

Escala : si quieres triunfar, necesitas poder crecer aún más en el camino (y probablemente, ocasionalmente, volver a crecer).

Estabilidad : todas las aplicaciones necesitan un nivel apropiado de estabilidad, desde “superar la demostración en el escenario” hasta requisitos de tiempo de actividad potencialmente mortales.

Seguridad : Existen personas malas y, a veces, atacarán tus aplicações. La complejidad de los sistemas modernos parece ampliar sin cesar la superficie de ataque de la que debemos preocuparnos.

Observabilidad : ver para creer, lo cual es doblemente importante cuando hay un problema. Obtener la información correcta de la capa OSI para las personas adecuadas rápidamente puede ayudarle a fallar menos, recuperarse más rápido y hacer que el mundo de "usted lo construye, usted lo ejecuta" sea un poco más cómodo.

Estas necesidades no son terriblemente únicas, pero siguen siendo las preocupaciones fundamentales que toda aplicación bien diseñada debe abordar, idealmente antes de que se conviertan en un problema y antes de que se escriba una línea de código.

Mi estimado empleador, F5 Networks, ha creado un negocio multimillonario que satisface estas necesidades y, honestamente, somos bastante buenos en eso (pero yo diría eso). A las cosas que fabricamos para satisfacer estas necesidades las llamamos servicios de aplicação . Servicios de aplicação que protegen el tráfico de aplicação , lo inspeccionan y lo dirigen. Servicios de aplicação que dirigen a los clientes al lugar correcto, servicios de aplicação que extraen, reenvían y muestran telemetría de aplicaciones. Estos son los servicios principales que han mantenido las aplicações de nuestros clientes en funcionamiento, y son el tipo de servicios que las aplicações siguen necesitando, sin importar dónde o cómo se creen.

¿Volver a presentarlo ante el proveedor?

Hasta ahora, todo es un viejo cascarrabias que intenta convencerme de que su tecnología de la vieja escuela sigue siendo relevante. Bueno, esto es lo que se dio vuelta, giró en el aire y aterrizó boca abajo. Empecemos por lo más importante: La forma en que se implementan los servicios.

Una de las tecnologías que han facilitado la adopción de plataformas y prácticas de trabajo han sido los sistemas que vinculan la intención con la acción de forma automatizada e integrada. Los servicios de aplicação deben ser parte de esta cadena, y esto representa un cambio más fundamental que un simple cambio en los tiempos de ejecución.

A veces, es necesario inyectar servicios en componentes existentes, como la visibilidad y el control excepcionales que Aspen Mesh agrega a Istio . Como alternativa, las herramientas de conexión como F5 Container Connector pueden vincular entornos a servicios, de modo que a medida que se agregan o eliminan pods de Kubernetes, se pueden proteger, escalar y observar.

Lo ideal es que el código para crear los servicios de aplicação exista en el mismo repositorio que el código de esa aplicação y se implemente de la misma manera. Las definiciones de servicios de aplicação (por ejemplo, un servicio de firewall de aplicação web) deben existir como código y ser tratadas como código, por lo que un cambio en la definición de servicio y una confirmación en la gestión del código fuente producen una implementación de firewall de aplicação web de producción sin más intervención humana. En noticias de último momento, la locuaz Melaine Cebula de Airbnb describió exactamente ese modelo en su sesión principal del miércoles en Kubecon cuando describió cómo mantener todos los componentes de un servicio, incluidas las definiciones de infraestructura en un solo proyecto (así como otras cincuenta cosas interesantes que hacen para facilitarles la vida a los desarrolladores de aplicaciones).

Este cambio en la instanciación de servicios (junto con la bienvenida muerte de las largas colas de tickets de TI) es dramático y obvio.

El segundo cambio es quizás un poco más mundano, pero aún así crítico. Una de las ventajas de Kubernetes y los contenedores es la portabilidad entre entornos. Su microservicio administrado por Kubernetes se ejecutará en cualquier lugar donde lo haga un motor de contenedores compatible (pista: en todas partes), y los mismos servicios de aplicación también deberían estar allí, no "casi iguales" o "hacen lo mismo de una manera diferente con una interfaz ligeramente diferente". Lo mismo. Esto significa que el número de lugares en los que necesitamos desplegarnos está creciendo todo el tiempo.

La necesidad de trabajar de la misma manera y en los mismos lugares que todas las implementaciones de Kubernetes actuales y potenciales se ha convertido en el principio rector de F5.

Es absolutamente fundamental, ya que nuestros clientes no solo confían en nosotros para mantener sus aplicaciones existentes escalables y seguras, sino que también necesitan saber que protegeremos y observaremos las aplicaciones que, al momento de escribir este artículo, se consideran como una molécula de cafeína rebelde que se une a un receptor de adenosina afortunado que necesita un impulso después del almuerzo.