Por qué la entrega de aplicação debería parecerse más a una fábrica (y menos al taller de un artesano)

En aquel entonces…

En la lejana era anterior a la nube, la entrega de aplicação era muy diferente a como es hoy. Esto se debe a que nada se movía más rápido que la velocidad a la que TI podía adquirir y aprovisionar los servidores en los que se ejecutaban las aplicações . La planificación de nuevas aplicações o actualizaciones importantes de aplicação llevó muchos meses o años. Al mismo tiempo, las aplicações empresariales se volvieron cada vez más complejas, con listas crecientes de interdependencias que eran difíciles de rastrear y gestionar. Surgieron amenazas de seguridad que podrían paralizar sistemas enteros durante días o provocar filtraciones de datos que pusieran fin a carreras. Incluso sin actores externos maliciosos, el riesgo de implementar un cambio que pusiera a la red (y a las aplicações que ésta soportaba) en peligro continuó aumentando junto con el índice de complejidad.

Para gestionar estos riesgos y garantizar la seguridad y confiabilidad de cada aplicação bajo su cuidado, los equipos de red y seguridad desarrollaron procesos y políticas que requerían una gran revisión manual y generalmente implicaban políticas diseñadas a medida para satisfacer las necesidades únicas de cada aplicação. Si bien estos procedimientos eran engorrosos, no eran necesariamente cuellos de botella. A menudo marcaban el ritmo del proceso de adquisiciones.

De un cielo azul claro…

Entonces apareció la Nube. De repente, los procesos de implementación comenzaron a parecer un lastre para un sistema que de otro modo avanzaría rápidamente. Casi al mismo tiempo, GitHub y otras plataformas de codificación social facilitaron la colaboración entre los desarrolladores en el código, ya sea dentro del mismo equipo o en proyectos de código abierto. Las nuevas arquitecturas de aplicação aumentaron drásticamente la eficiencia de los desarrolladores al reducir las oportunidades de que el trabajo realizado en una parte de la aplicação entre en conflicto con otras partes, lo que representa una fuente importante de trabajo, repetición del trabajo y demoras. Las arquitecturas de microservicios y Service Mesh reducen las dependencias entre partes de la propia aplicação , mientras que los contenedores y sin servidor reducen las dependencias de la infraestructura subyacente, lo que libera a los desarrolladores individuales y a los equipos de aplicação para que avancen a su propio ritmo. Los desarrolladores ahora pueden implementar aplicações en minutos en lugar de meses. Inicialmente, estas implementaciones estaban restringidas a proyectos de desarrollo y prueba, pero la demanda de un acceso más rápido a los sistemas de producción creció rápidamente.

Transformación digital: Un trabajo en progreso

Los administradores de red y los ingenieros de seguridad tuvieron dificultades para mantenerse al día en parte porque, a diferencia de los desarrolladores, su experiencia profesional se centraba en mantener la seguridad del negocio en lugar de optimizar los flujos de trabajo. Para los desarrolladores, muchos de los conceptos centrales detrás de lo que llegó a conocerse como el movimiento DevOps ya eran algo natural: automatizar procesos, optimizar sistemas, reducir las dependencias entre sistemas y aprovechar procesos y códigos reutilizables siempre que fuera posible. Los administradores de red y los ingenieros de seguridad, por el contrario, fueron formados como artesanos. La naturaleza crítica de su trabajo exigía que cada aplicação fuera tratada con revisiones manuales, mantenida con juntas de revisión de cambios y gestionada a través de políticas diseñadas manualmente que pudieran actualizarse (manualmente) en respuesta a condiciones cambiantes.

La buena noticia es que, a pesar de comenzar la carrera muy por detrás de los desarrolladores en términos de comprensión de los procesos de implementación automatizada , los equipos de red y seguridad se están poniendo al día .

La fábrica de aplicação : Aplicación de una mentalidad de sistemas a la entrega de aplicação

Una buena manera de pensar en la transición es imaginar una fábrica de aplicação . En lugar de políticas diseñadas a mano y procesos de revisión manuales, los expertos en redes y seguridad necesitan definir políticas reutilizables y luego enviarlas a los desarrolladores para que las implementen con sus aplicações como parte de un proceso de implementación automatizada .

Es cierto que es más fácil decirlo que hacerlo. Así como la transición de los productos artesanales a los productos producidos en fábricas no fue simplemente una cuestión de comprar equipos pesados y reasignar a los trabajadores a nuevos roles, el cambio a un enfoque de sistemas tiene tanto que ver con la mentalidad y la cultura como con las herramientas y los procesos. En lugar de juntas de revisión de cambios y equipos de seguridad que investigan laboriosamente cada posible vector de amenaza de seguridad y riesgo de rendimiento, un sistema de distribución de aplicação automatizado bien diseñado mantiene pequeños los dominios de falla para minimizar el impacto y crea bucles de retroalimentación efectivos para permitir la detección y respuesta tempranas. Las decisiones sobre herramientas y canalizaciones deben equilibrar la libertad del desarrollador con el valor de la eficiencia de los servicios consistentes. El sistema ideal ofrece a los desarrolladores la máxima libertad para tomar decisiones sobre herramientas que inciden en el desarrollo de funciones, pero proporciona un conjunto consistente de servicios de seguridad e infraestructura con capacidad para múltiples nubes. La incorporación de servicios consistentes en el núcleo del proceso de distribución de aplicação reduce la deuda técnica y mejora la eficiencia operativa y de cumplimiento. Eso, a su vez, libera a los desarrolladores para que se concentren en ofrecer más valor de innovación al negocio.

(Vea la infografía completa de F5 Aplicação Factory haciendo clic en la imagen a continuación).