¿O quizá sean «lágrimas» de frustración? ¯\_(ツ)_/¯ Tal vez sean ambas cosas.
Existe una relación entre las arquitecturas de red y de aplicaciones. Normalmente solemos hablar de cómo los cambios y las transformaciones en las arquitecturas de aplicaciones afectan a la red, tanto en lo que respecta a las soluciones como a su arquitectura. Pero lo contrario también es cierto: la arquitectura y el comportamiento de la red pueden tener un impacto bastante drástico en las aplicaciones y en su arquitectura.
De hecho, una de las razones por las que estamos viendo cómo los monolitos se descomponen en numerosos microservicios ahora y no durante la época de la SOA es la red. O, para ser más precisos, la velocidad de la red. En la época de la SOA, la propia naturaleza de las redes (y las leyes de la física) imponía limitaciones que hacían imposible generar una única respuesta a partir de más de tres o cuatro servicios. Bueno, no imposible, pero sí poco recomendable debido a la latencia que introducía cada llamada.
Hoy en día, contamos con redes más rápidas y de mayor capacidad, así como con una potencia de cálculo diez veces superior, lo que hace viable esa descomposición. También contribuye a facilitarla la naturaleza de los contenedores, que tan a menudo van de la mano de los microservicios como el café y los donuts. Dado que «la red» entre dos servicios que necesitan comunicarse suele ser una construcción virtual (los paquetes nunca llegan a salir del servidor anfitrión y, por tanto, no sufren la latencia que supone «enviarlos por la red»), el número de servicios que se pueden invocar para responder a una única solicitud es mucho mayor de lo que razonablemente podíamos lograr en la época de la SOA.
Sin embargo, eso no significa que debamos ignorar cuántas conexiones y saltos hay que atravesar para responder a una solicitud, ni el impacto que tiene la arquitectura en el rendimiento de las aplicaciones. Porque, aunque la capacidad de procesamiento sea mayor y el ancho de banda más amplio, la sobrecarga operativa sigue siendo algo con lo que tenemos que lidiar y que continúa afectando al rendimiento. Una de las formas más sencillas de reducir la sobrecarga operativa (y mejorar el rendimiento) es disminuir la complejidad eliminando las capas innecesarias de una arquitectura.
Reducir la complejidad de los entornos de contenedores
La mayoría de las implementaciones de contenedores utilizan algún tipo de balanceador de carga dentro del clúster para gestionar el escalado de los microservicios y las aplicaciones del entorno de contenedores. Esto se debe a que suelen encargarse del enrutamiento de nivel 7 de las API (es decir, del control de entrada), mientras que los mecanismos nativos de balanceo de carga se basan en iptables, que, por supuesto, no entiende HTTP, el lenguaje del enrutamiento de nivel 7. Por eso hay numerosos balanceadores de carga de nivel 7 dentro del clúster de contenedores.
Ahora bien, la mayoría de las implementaciones también necesitarán balanceo de carga fuera del clúster para dirigir el tráfico externo al balanceador de carga adecuado dentro del clúster. Para ello, utilizan el balanceo de carga tradicional para distribuir las solicitudes al balanceador de carga interno adecuado.
Al balanceador de carga externo lo llamaremos BIG-IP y al que está dentro del clúster, balanceador de carga interno. Porque es mi blog y punto.
El problema es que el número de instancias del balanceador de carga interno fluctúa (a veces de forma drástica). Cada vez que se produce un cambio, BIG-IP debe estar al tanto. Tradicionalmente, esta ha sido una operación manual que obligaba al responsable de BIG-IP a modificar el pool a mano. Esto resulta frustrante para los equipos de desarrollo y DevOps, y tedioso para NetOps. En otras palabras, nadie quiere hacerlo así.
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 supervisa el entorno. Cuando se produce un cambio que afecta a un balanceador de carga interno, se activa un proceso para actualizar BIG-IP. Esto significa que, a medida que la demanda aumenta o disminuye, BIG-IP se mantiene actualizado automáticamente y puede distribuir adecuadamente las solicitudes a un balanceador de carga interno activo y en buen estado. No es necesario realizar ninguna modificación manual.
Esta arquitectura de escalado de dos niveles ofrece la ventaja de proporcionar un punto de entrada práctico (BIG-IP) en el que se puede finalizar SSL/TLS, lo que aporta mejoras de rendimiento cuantificables. Estupendo.
Pero ¿por qué quedarse ahí? BIG-IP puede proporcionar enrutamiento de capa 7. Si utiliza los servicios de F5 Container Connector, puede mejorar aún más el rendimiento (y reducir la carga operativa) eliminando por completo el balanceador de carga interno . De verdad. BIG-IP puede actuar como controlador de entrada para Kubernetes y Red Hat OpenShift.
Al trasladar la responsabilidad del ingreso a BIG-IP, se elimina todo un nivel de escalado (el balanceador de carga interno), lo que mejora inmediatamente el rendimiento. Dado que el balanceador de carga externo es un F5 BIG-IP, también se pueden implementar servicios de aplicaciones centrados en la seguridad, como un WAF avanzado con protección contra bots, en el punto de contacto en lugar de dentro del clúster de contenedores (o no implementarlos en absoluto).
Choque de clanes de operaciones
A medida que los contenedores se desplieguen en producción con mayor frecuencia (y así será), será necesaria una mayor colaboración entre DevOps y NetOps para implementar este tipo de mejoras y garantizar la escalabilidad, la velocidad y la seguridad de las aplicaciones. Al fin y al cabo, no se trata solo de pulsar botones y utilizar canalizaciones de autoservicio. La arquitectura es un componente fundamental que deberá diseñarse con las aportaciones tanto de DevOps como de NetOps para no pasar por alto oportunidades de mejorar aspectos como el rendimiento de las aplicaciones.
Porque el rendimiento de las aplicaciones es un trabajo en 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 aplicaciones utilizados para proteger y escalar la aplicación (NetOps). Aplicar una optimización arquitectónica eliminando capas siempre que sea posible tiene sentido tanto desde el punto de vista operativo como empresarial. Pero requiere la participación de todos los miembros del equipo.
Así que pedid unas pizzas y unas cervezas, reunid a los equipos de DevOps y NetOps y empezad a hablar. Averiguad si vosotros también podéis mejorar el rendimiento de las aplicaciones eliminando capas innecesarias de vuestro entorno de contenedores.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.