El mundo del desarrollador de aplicaciones y el del arquitecto de redes no podrían ser más distintos, salvo quizá por la forma en que cada uno percibe el ámbito del otro.
Una implementación de una aplicación suele verse así desde la perspectiva de la red:
Mientras tanto, al otro lado del «muro», la perspectiva del desarrollador sobre el despliegue de esa misma aplicación suele ser la siguiente:
Sin duda, ambas son precisas en sus respectivos ámbitos, pero apenas tienen en cuenta la arquitectura real de la otra. Esto ilustra por qué surgen tantos problemas cuando las aplicaciones pasan a producción. Y vaya si surgen. Un estudio señala que, en 2013, «el 90 % de los desarrolladores afirmó que dedicaba fines de semana, festivos y vacaciones a resolver emergencias de las aplicaciones en la fase de producción[1]». Aunque muchas de ellas están relacionadas, sin duda, con defectos y errores del software, muchas otras se deben indudablemente a las numerosas diferencias entre los entornos. Producción no es desarrollo, ni viceversa.
Las aplicaciones actuales aprovechan diversos servicios que existen en los entornos de producción, pero rara vez en los entornos de desarrollo o pruebas: balanceadores de carga para garantizar la escalabilidad, cachés para mejorar el rendimiento y cortafuegos de aplicaciones web para reforzar la seguridad. Estos servicios no solo intervienen en todas y cada una de las solicitudes y respuestas cuando atraviesan la red entre el usuario y la aplicación (o entre la aplicación y la API, si lo prefiere), sino que, en algunos casos, modifican las solicitudes o las respuestas. Un buen ejemplo es la dirección IP del usuario. Este valor se encuentra en las cabeceras HTTP de cada solicitud, pero, cuando pasa por un proxy de balanceo de carga, se convierte en la dirección IP del proxy, no en la del cliente.
Para el desarrollador desprevenido, esto puede hacer que las aplicaciones «dejen de funcionar» y dar lugar a horas de resolución de problemas, además del tiempo necesario para modificar la aplicación. Este tipo de problemas derivados de las diferencias entre entornos explica, sin duda, que el 28 % de los desarrolladores que respondieron a una encuesta[2] a mediados de 2015 afirmara que «más del 50 % de los problemas en producción podrían haberse detectado y solucionado con el entorno de pruebas adecuado». Y más de la mitad (el 52 %) afirmó que «se habría solucionado entre el 25 % y el 50 % de los problemas en producción».
Muchos de los problemas que surgen en producción son directamente atribuibles a diferencias en la aplicación, especialmente en aquellas desarrolladas con metodologías ágiles. Los métodos ágiles pueden aumentar la probabilidad de que este tipo de conflictos se produzcan en producción debido a la frecuencia con la que cambia el código.
Cada vez más, muchos de estos retos, aunque no todos, se resuelven mediante el uso de un proxy programable, ya que así se evita tener que modificar código que ya está en producción y retrasar aún más el lanzamiento de la aplicación al mercado. El problema de la «dirección IP» mencionado anteriormente suele resolverse configurando el proxy para que inserte una nueva cabecera HTTP que contenga la dirección IP real, de modo que los desarrolladores sigan teniendo acceso a esa información. Además, los proxies de equilibrio de carga de capa 7 son capaces de enrutar solicitudes de aplicaciones y API basándose en diversos datos, como el control de versiones y las firmas de API.
Resulta interesante observar que el único componente que suele aparecer destacado tanto en los diagramas de ingeniería de software como en los de redes es el balanceador de carga. Aunque tradicionalmente este proxy lo implementa y gestiona el equipo de redes, es tan importante para las arquitecturas de aplicaciones que casi siempre se incluye como parte de la aplicación. Del mismo modo, hoy en día los desarrolladores reconocen la importancia del balanceo de carga para escalar las aplicaciones y suelen incluirlo en sus diagramas.
También refleja el creciente número de casos en los que los desarrolladores y los equipos de operaciones han asumido la responsabilidad de la escalabilidad y, por tanto, han tomado el control del balanceo de carga de sus aplicaciones. Esto es positivo, porque significa que los equipos de desarrollo y operaciones pueden incluir —y cabe esperar que así lo hagan— el balanceo de carga (con todas las ventajas que ofrece la capa 7) en el pipeline de CI/CD, especialmente durante las pruebas, para garantizar que cualquier posible problema se detecte rápidamente y se resuelva antes de pasar a producción. Desplazar el balanceo de carga hacia las primeras fases del pipeline de CI/CD también permite adoptar un enfoque más integral de la entrega continua, en el que todo el paquete de la aplicación (la arquitectura) se gestiona como código y puede actualizarse simultáneamente. Esto permite que la infraestructura de red (ya que es ahí donde tradicionalmente se encuadra el balanceo de carga) admita una arquitectura inmutable en la que las aplicaciones (o los microservicios, si se opta por ese enfoque) se vuelven a desplegar por completo con nuevas configuraciones, en lugar de limitarse a actualizarlas, evitando así la entropía natural del software, que puede generar dificultades y deuda técnica.
En muchos sentidos, el proxy es el puente que conecta la «red» con la «aplicación», salvando la brecha figurada (más bien un muro, si somos sinceros) que separa a los ingenieros y arquitectos de software de los de redes. Esta es una de las brechas que DevOps debe abordar para que las organizaciones puedan escalar y afrontar los retos de las arquitecturas modernas.
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.