Por qué es importante la infraestructura para los desarrolladores que utilizan contenedores
Hoy en día, una de las preguntas más frecuentes en los pasillos de un proveedor de infraestructura es cómo explicar el valor de esa infraestructura a la comunidad de desarrolladores. El problema es que la mayoría de los beneficios de la infraestructura se obtienen después de la entrega a producción. Ninguno de ellos aporta realmente valor directo al desarrollador, al menos no de una forma significativa que afecte su rutina diaria.
Los beneficios adicionales al desarrollo son algo de lo que los desarrolladores seguramente son conscientes. En nuestro informe Estado de la entrega de aplicação de 2018 tuvimos un pequeño porcentaje de desarrolladores representados. Pero ese porcentaje hablaba mucho sobre el tema de los servicios de aplicação que querían implementar. Algunos de esos servicios de aplicação (equilibrio de carga, almacenamiento en caché y aceleración) se implementan con tanta frecuencia como parte de la propia aplicação como de la infraestructura. Las optimizaciones de TCP y WAF son casi siempre servicios de infraestructura, implementados en sentido ascendente (en la ruta de datos) frente a las aplicações (ya sean monolíticas o microservicios).
Hay valor en todos estos servicios de aplicação . Reducción de riesgos, mejora del rendimiento, escalabilidad. Pero estos son beneficios de aplicação y de negocio; benefician a los desarrolladores después de la entrega de la aplicação a producción. Es difícil encontrar –y mucho menos articular– los beneficios de la infraestructura antes de la entrega, es decir, como parte del ciclo de vida del desarrollo.
Pero a medida que continuamos adoptando contenedores y microservicios, el valor de la infraestructura antes y después de la entrega se hace más obvio.
Como ocurre con la mayoría de las tecnologías emergentes, los primeros días de una nueva arquitectura de aplicação traen consigo muy poca infraestructura. Puede resultar sorprendente para los desarrolladores saber que la arquitectura de la aplicação determina significativamente la infraestructura de los servicios de la aplicação . Del paso a aplicaciones web de tres niveles surgió la escalabilidad (equilibrio de carga). A partir de la adopción de la Web 2.0 con su capa de presentación responsiva, surgió la infraestructura de aceleración del frontend. Con la llegada de la tecnología móvil y la creciente digitalización de todas las industrias, vimos cómo la infraestructura reaccionaba con servicios de seguridad como WAF, DDoS y defensa contra bots.
Lo que vemos que está sucediendo ahora es que los desarrolladores están codificando las capacidades del servicio de infraestructura en sus aplicações. Los desarrolladores están poniendo en código lo que tradicionalmente ha sido responsabilidad de los servicios upstream. Reintentos de los balanceadores de carga. mTLS desde las plataformas o proxies. Control de acceso para restringir la comunicación a clientes legítimos.
Se trata de responsabilidades de infraestructura que, debido a la naturaleza incipiente de los marcos de contenedores y las rápidas tasas de adopción, han sido asumidas por los desarrolladores.
Pero como siempre ha sucedido, eso está cambiando. Así como las arquitecturas de aplicaciones anteriores han impulsado respuestas en la infraestructura de red, también lo hacen los contenedores y los microservicios. Sólo que esta vez los cambios no llegarán en forma de una nueva caja. Lo que está sucediendo ahora es el movimiento hacia la integración de los servicios de aplicação que los desarrolladores necesitan en el entorno de contenedores. Ahí es donde entra en juego la malla de servicios, que ofrece un valor real y cuantificable directamente para los desarrolladores.
Como explicó Andrew Jenkins, arquitecto principal de Aspen Mesh, en una entrevista con Linux.com :
“Es sorprendente lo fácil que es comenzar a crear un servicio web hoy en día. Puedes incluir el código en un tweet. Sin embargo, este no es un servicio web real. Para que sea resistente y escalable, debe agregar algunas cosas al plano de datos de la aplicación. Debe realizar TLS, debe reintentar los errores, debe aceptar solo solicitudes de este servicio pero no de ese, debe verificar la autenticación del usuario, etc. Una malla de servicios puede ayudarle a obtener esa funcionalidad del plano de datos sin tener que agregar código a la aplicación”.
El valor previo a la entrega está en la reducción del alcance y la eliminación de código repetitivo pero necesario para manejar la seguridad básica y la escala dentro de un entorno de contenedores. Una malla de servicios tiene una amplia variedad de capacidades interesantes, pero sus beneficios siguen siendo en gran medida operativos: observabilidad, responsabilidad y escala. El valor más significativo para un desarrollador está en la eliminación de código (y, por lo tanto, en la reducción de la deuda técnica y arquitectónica).
El uso de una malla de servicios para escalar, proteger y observar aplicaciones implementadas en entornos de contenedores alivia la carga de escribir código que debería ser manejado por la infraestructura, pero que hasta hace poco se había delegado a los desarrolladores. Una malla de servicios es una forma de aliviar la responsabilidad de los desarrolladores y devolverles un tiempo precioso que podrían utilizar para desarrollar servicios y aplicaciones que a su vez aportan valor al negocio.