Por qué es importante un enfoque por aplicación para los servicios de aplicação
No puedo leer la mente (mis hijos no estarían de acuerdo, pero eso no viene al caso), pero puedo leer las respuestas a nuestra encuesta sobre el estado de la entrega de aplicação . Y cuando los leo a través de la lente de quienes se identifican como desarrolladores de aplicaciones, veo surgir una imagen muy interesante.
A los desarrolladores les importa la velocidad. Y seguridad. Y escala. No necesariamente en ese orden, pero se preocupan por los tres. No sólo se preocupan, sino que reconocen el valor de los servicios de aplicação para ayudarlos a lograr los tres objetivos.
Es decir, los desarrolladores no sólo quieren servicios de aplicação de 'aceleración' vagos, sino que también quieren servicios específicos que proporcionen optimizaciones de TCP y almacenamiento en caché. Quieren un firewall de aplicação web y, además, algún equilibrio de carga.
El problema es que la mayoría de estos servicios de aplicação se entregan en un modelo de infraestructura compartida. Cada aplicação obtiene su propia “representación virtual”, pero ésta reside físicamente en una pieza de software o hardware compartida.
Esto puede causar problemas reales y es en parte una fuente de la fricción que persiste entre TI y el desarrollo de aplicaciones. Es esta naturaleza compartida de los sistemas lo que nos trajo ventanas de cambio, juntas de revisión e implementaciones los sábados por la noche (con pizza, para mantenernos tranquilos), los procesos que ralentizan el desarrollo y hacen que la implementación sea una experiencia frustrante para todos los involucrados.
Ya no implementamos aplicaciones monstruosas y monolíticas. Incluso si no hemos recurrido a microservicios frenéticos ni hemos descompuesto las aplicaciones en cientos de pequeños servicios, aún tenemos más aplicaciones con cronogramas de implementación más frecuentes. Aplicaciones que se desarrollan en sprints de una semana de duración en lugar de proyectos de un año y que necesitan enviar actualizaciones con mayor rapidez y frecuencia.
En última instancia, esa es una de las razones por las que la nube (pública) ha tenido tanto éxito. Porque es mi aplicación y mi infraestructura y no tengo que esperar a Bob, Alice o John antes de enviar una actualización. Porque es todo mío y es mi responsabilidad si algo sale mal.
Ese mismo enfoque también es posible (y preferible, creo yo) en las instalaciones. Lo que se necesita es que todas las piezas y partes que componen la cadena de entrega de una aplicação admitan el mismo tipo de enfoque por aplicación que la nube ha hecho deseable.
Básicamente, un enfoque por aplicación para entregar los servicios de red y de aplicação necesarios es similar a dedicar una subred a la aplicação; una VLAN de entrega de aplicaciones, por así decirlo. Se trata de una única aplicación, con servicios dedicados.
Ese tipo de aislamiento no sólo es bueno para los cronogramas de implementación, sino también para todos los demás. Los fallos ocurren, y cuando ocurren, es conveniente restringir el radio de explosión tanto como sea posible. Las arquitecturas por aplicación implican un impacto de falla muy limitado, lo que hace que todas esas personas de guardia "por si acaso" estén felices porque no recibieron esa llamada. Puedo lanzar e implementar cada semana sin entrar en conflicto con las aplicaciones que lanzan e implementan una vez al mes. Mi aplicación, mis servicios, mi cronograma de implementación.
Una arquitectura por aplicación también facilita la solución de problemas que surgen en la producción. Y a menudo lo hacen. De hecho, el 50% de los desarrolladores informaron problemas en la producción después del lanzamiento del código en una encuesta de Atlassian de 2017 . No hay posibilidad de que alguien más haya realizado un cambio que pueda afectar la aplicação. Puede acceder directamente a los sistemas involucrados en lugar de perder tiempo valioso averiguando qué sistemas podrían estar involucrados.
Una arquitectura por aplicación naturalmente se adapta mejor a la nube, ya sea pública o privada, porque esa es la suposición del modelo. Cada aplicación tiene un conjunto dedicado de servicios de aplicação para escalarla, acelerarla y protegerla.
La realidad es que una arquitectura por aplicación era inevitable. No es la primera vez que digo esto . La gravedad de las aplicações es demasiado fuerte como para ignorarla, y la seguridad cada vez más específica de cada aplicación, necesaria para mantener una aplicação segura, significaba que tarde o temprano se adoptaría un enfoque por aplicación.
Y eso es bueno, porque los servicios de aplicação que desean los desarrolladores son, en la mayoría de los casos, específicos de la aplicación. Lo que funciona para uno no necesariamente funcionará para el otro; de hecho, puede ser negativo. Al adoptar un enfoque arquitectónico por aplicación para la entrega de aplicação, puede garantizar que los desarrolladores no solo obtengan lo que quieren y necesitan para escalar, proteger y acelerar las aplicaciones, sino que también pueden respaldar mejor el modelo de autoservicio que esperan de la nube, ya sea local o fuera de ella.