Uso de F5 BIG-IP para eliminar niveles al escalar aplicaciones en contenedores
¿O son ‘lágrimas’ de frustración? ¯\_(ツ)_/¯ Quizás sean ambas.
Existe una relación entre las arquitecturas de red y de aplicação . Generalmente nos gusta hablar sobre cómo los cambios y los cambios en las arquitecturas de aplicação impactan en la red, tanto en términos de soluciones como de su arquitectura. Pero lo contrario también es cierto: la arquitectura y el comportamiento de la red pueden tener un impacto bastante dramático en las aplicações y su arquitectura.
Es decir, una de las razones por las que ahora vemos la descomposición de monolitos en muchos microservicios en lugar de durante los años de SOA es la red. O para ser más precisos, por la velocidad de la red. En los días de SOA existían limitaciones impuestas por la naturaleza de la red (y las leyes de la física) que hacían imposible componer una única respuesta a partir de más de tres o cuatro servicios. Bueno, no es imposible, pero sí indeseable debido a la latencia que genera cada llamada.
Hoy contamos con redes más rápidas y robustas y un poder computacional un orden de magnitud más veloz que hace factible dicha descomposición. Lo que lo hace aún más fácil es la naturaleza de los contenedores que a menudo se combinan con microservicios, como el café con donas. Debido a que “la red” entre dos servicios que necesitan comunicarse es a menudo una construcción virtual (los paquetes nunca salen realmente del servidor host y, por lo tanto, no sufren la latencia que implica “ser puestos en el cable”), la cantidad de servicios que pueden invocarse para responder a una sola solicitud es mucho mayor de lo que razonablemente podíamos lograr en los días de SOA.
Sin embargo, eso no significa que debamos ignorar cuántas conexiones y saltos debemos atravesar para responder a una solicitud o el impacto que tiene la arquitectura en el rendimiento de la aplicação . Porque, si bien el procesamiento es más rápido y las tuberías son más gruesas, la sobrecarga operativa sigue siendo un problema con el que debemos lidiar. Una cosa que todavía impide el rendimiento. Una de las formas más sencillas de lidiar con la sobrecarga operativa (y mejorar el rendimiento) es reducir la complejidad eliminando niveles (innecesarios) en una arquitectura.
Reducción de la complejidad de los entornos de contenedores
La mayoría de las implementaciones de contenedores utilizarán algún tipo de equilibrador de carga dentro del clúster para administrar la escala de microservicios/aplicaciones dentro del entorno de contenedores. Esto se debe a que a menudo se les asigna la tarea de realizar el enrutamiento L7 de las API (eso es control de ingreso) y las construcciones de equilibrio de carga nativas se basan en iptables, que por supuesto no hablan HTTP, el lenguaje del enrutamiento L7. Entonces, hay un montón de balanceadores de carga L7 dentro del contenedor del clúster.
Ahora, la mayoría de las implementaciones también querrán equilibrar la carga fuera del clúster para llevar el tráfico externo al equilibrador de carga correcto dentro del clúster. Para lograrlo, utilizan el tradicional equilibrio de carga para distribuir las solicitudes al equilibrador de carga correcto en su interior.
Llamaremos al balanceador de carga externo a BIG-IP y al interno al clúster lb interno . Porque es mi blog, por eso.
El problema es que el número de instancias lb internas fluctúa (a veces drásticamente). Cada vez que hay un cambio, el BIG-IP necesita saberlo. Tradicionalmente, esta ha sido una operación manual, que requiere que el propietario de BIG-IP salga y modifique el grupo manualmente. Esto es frustrante para los desarrolladores y DevOps, y tedioso para NetOps. En otras palabras, nadie quiere hacerlo de esta manera.
Por eso existen soluciones como F5 Container Connector . F5 Container Connector es un servicio nativo de contenedores que se integra con el orquestador de contenedores y observa el entorno. Cuando hay un cambio que impacta una lb interna, se desencadena un proceso para actualizar BIG-IP . Esto significa que a medida que la demanda aumenta y disminuye, BIG-IP se mantiene actualizado automáticamente y puede distribuir adecuadamente las solicitudes a una lb interna activa y saludable. No es necesaria ninguna modificación manual.
Esta arquitectura de escalamiento de dos niveles tiene la ventaja de proporcionar una ubicación de entrada conveniente (BIG-IP) en la que se puede terminar SSL/TLS, lo que proporciona mejoras de rendimiento mensurables. Lindo.
¿Pero por qué detenerse ahí? BIG-IP es capaz de proporcionar enrutamiento L7 . Si utiliza los servicios de F5 Container Connector, podrá obtener mayores mejoras en el rendimiento (y una menor sobrecarga operativa) al eliminar por completo la lb interna . En realidad. BIG-IP puede actuar como un controlador de ingreso para Kubernetes y Red Hat OpenShift.
Al trasladar la responsabilidad de ingreso a BIG-IP, se elimina un nivel completo de escala (la lb interna), lo que mejora inmediatamente el rendimiento. Debido a que la lb externa es un F5 BIG-IP , puede implementar además servicios de aplicação centrados en la seguridad, como un Advanced WAF con defensa contra bots en el punto de contacto en lugar de dentro del clúster de contenedores (o no en absoluto).
Clanes de Clash of Ops
A medida que los contenedores se incorporen con mayor frecuencia a la producción (y lo harán), será necesaria una mayor colaboración entre DevOps y NetOps para implementar este tipo de mejoras y garantizar la escala, la velocidad y la seguridad de las aplicaciones. Después de todo, no se trata solo de presionar botones y canales de autoservicio. La arquitectura es un componente crítico que deberá diseñarse con el aporte de DevOps y NetOps, para no ignorar oportunidades de mejorar aspectos como el rendimiento de las aplicação .
Porque el rendimiento de las aplicação es un deporte de equipo. Se ve afectado por el código (AppDev), por la plataforma en la que se implementa el código (DevOps), por la arquitectura de red y por los servicios de aplicação utilizados para proteger y escalar la aplicación (NetOps). Utilizar la optimización arquitectónica eliminando niveles cuando sea posible tiene mucho sentido desde el punto de vista operativo y comercial. Pero requiere la participación de todos los jugadores del equipo.
Así que pide pizza y cerveza, reúne a DevOps y NetOps y empieza a hablar. Descubra si usted también puede mejorar el rendimiento de las aplicaciones eliminando niveles innecesarios en su entorno de contenedores.