El poder del proxy: Reduciendo la brecha entre desarrollo y producción
El mundo del desarrollador de aplicaciones y del arquitecto de redes no podrían ser más diferentes, excepto, quizás, en la forma en que cada uno ve el dominio del otro.
Una perspectiva de red típica de la implementación de una aplicação suele verse así:
Mientras que, del otro lado del “muro”, la perspectiva del desarrollador sobre la implementación de la misma aplicação a menudo se ve así:
Sin duda, ambos son precisos en sus ámbitos, pero muy indiferentes hacia la arquitectura real del otro. Esto ilustra por qué surgen muchos problemas cuando las aplicações pasan a producción. Y se levantan. La investigación señala que en 2013 “el 90% de los desarrolladores dijeron que dedicaban fines de semana, días festivos y vacaciones a solucionar emergencias de aplicaciones en la fase de producción. [1]”. Si bien muchos de ellos están ciertamente relacionados con defectos y errores de software, muchos otros son indudablemente causados por las muchas diferencias en los entornos. La producción no es desarrollo y viceversa.
Las aplicações actuales aprovechan una variedad de servicios que existen en entornos de producción, pero rara vez en entornos de desarrollo o prueba: balanceadores de carga para escalabilidad, cachés para mejorar el rendimiento y firewalls de aplicaciones web para seguridad. Estos servicios no solo tocan cada solicitud y respuesta a medida que recorren la red entre el usuario y la aplicación (o la aplicación y la API, si lo prefiere), sino que en algunos casos modifican las solicitudes y/o respuestas. Un buen ejemplo de esto es la dirección IP del usuario. Este valor se encuentra en los encabezados HTTP de cada solicitud, pero cuando pasa por un proxy de equilibrio de carga, se convierte en la dirección IP del proxy , no del cliente.
Para el desarrollador desprevenido, esto puede provocar que las aplicações fallen y requerir horas de resolución de problemas, además del tiempo necesario para modificarlas. Este tipo de problemas derivados de las diferencias en el entorno son, sin duda, la razón por la que el 28 % de los desarrolladores que respondieron a una encuesta... [2] A mediados de 2015, afirmó que “más del 50% de los problemas de producción podrían haberse detectado y solucionado con el entorno de prueba adecuado”. Y más de la mitad (52%) dijo que “entre el 25% y el 50% de los problemas de producción se habrían solucionado”.
Muchos de los problemas que surgen en la producción son directamente atribuibles a diferencias en las aplicação, y particularmente en aquellas desarrolladas utilizando metodologías ágiles. Los métodos ágiles pueden aumentar la probabilidad de que surjan este tipo de conflictos en la producción debido a la frecuencia con la que cambia el código.
Cada vez más, muchos de estos desafíos (aunque de ninguna manera todos) se resuelven mediante el uso de un proxy programable, ya que al hacerlo se elimina la necesidad de cambiar el código que ya está en producción y retrasar aún más la entrega de la aplicação al mercado. El problema de la “dirección IP” antes mencionado generalmente se resuelve instruyendo al proxy para que inserte un nuevo encabezado HTTP que contenga la dirección IP real para que los desarrolladores sigan teniendo acceso a esa información y los proxies de equilibrio de carga de capa 7 son expertos en enrutar solicitudes de aplicação y API en función de una variedad de datos, incluidas las versiones y las firmas de API.
Es interesante observar que el componente que a menudo se menciona en los diagramas de ingeniería de software y de red es el equilibrador de carga. Si bien este proxy tradicionalmente lo implementa y administra el equipo de red, es lo suficientemente crítico para las arquitecturas de aplicação como para que casi siempre se incluya como parte de la aplicação. De manera similar, los desarrolladores reconocen hoy la importancia del equilibrio de carga para escalar aplicações y generalmente lo incluyen en sus diagramas.
También refleja los casos cada vez mayores en los que los desarrolladores y las operaciones han asumido la responsabilidad de la escalabilidad y, por lo tanto, han tomado el control del equilibrio de carga de sus aplicações. Esto es bueno, porque significa que los equipos de desarrollo y operaciones pueden (y esperan que lo hagan) incluir el equilibrio de carga (y toda la bondad de la capa 7) en el flujo de trabajo de CI/CD, particularmente durante las pruebas, para garantizar que cualquier problema potencial se pueda detectar rápidamente y resolver antes de pasar a producción. Desplazar el equilibrio de carga hacia el flujo de trabajo de CI/CD también permite un enfoque más holístico para la entrega continua en el que todo el paquete de aplicação (arquitectura) se gestiona como código y se puede actualizar simultáneamente. Esto permite que la infraestructura de red (porque ahí es donde tradicionalmente cae el equilibrio de carga cuando se describe) admita una arquitectura inmutable en la que las aplicações (o microservicios, si se elige esa ruta) se reimplementan completamente con nuevas configuraciones en lugar de simplemente actualizarse, evitando la entropía natural del software que puede introducir desafíos y deuda técnica.
El proxy es en muchos sentidos el puente que conecta la “red” con la “aplicação” a través del abismo figurativo (más bien un muro, si somos honestos) que separa a los ingenieros y arquitectos de software y redes. Esta es una de las brechas que DevOps debe cubrir si las organizaciones van a poder escalar para enfrentar los desafíos de las arquitecturas modernas.
[1] http://solutions-review.com/mobile-application-development/5000-developer-survey-mobile-app-development-insights-revealed/
[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastructure-survey-results/