No puedo leer la mente (mis hijos no estarían de acuerdo, pero eso no viene al caso), aunque sí puedo leer las respuestas a nuestra encuesta sobre el estado de la entrega de aplicaciones. Y cuando las analizo desde la perspectiva de quienes se identifican como desarrolladores de aplicaciones, veo surgir una imagen muy interesante.
A los desarrolladores les importan la velocidad, la seguridad y la escalabilidad. No necesariamente en ese orden, pero las tres son importantes para ellos. Y no solo eso, sino que también reconocen el valor de los servicios de aplicaciones para ayudarles a conseguirlas.
En concreto, los desarrolladores no solo quieren servicios de aplicaciones de «aceleración» poco definidos, sino servicios específicos que ofrezcan optimizaciones de TCP y almacenamiento en caché. También quieren un cortafuegos de aplicaciones web y, además, algo de balanceo de carga.
El problema es que la mayoría de estos servicios de aplicaciones se prestan mediante un modelo de infraestructura compartida. Cada aplicación tiene su propia «representación virtual», pero esta reside físicamente en un componente de software o hardware compartido.
Esto puede causar verdaderos problemas y es, en parte, una de las causas de la fricción que sigue existiendo entre TI y los desarrolladores de aplicaciones. Es precisamente esta naturaleza compartida de los sistemas la que dio lugar a las ventanas de cambio, los comités de revisión y los despliegues de los sábados por la noche (con pizza para mantenernos contentos): procesos que ralentizan el desarrollo y hacen que el despliegue sea una experiencia frustrante para todos los implicados.
Ya no desplegamos aplicaciones monolíticas gigantescas. Aunque no nos hayamos lanzado de lleno a los microservicios ni hayamos descompuesto las aplicaciones en cientos de pequeños servicios, seguimos teniendo más aplicaciones con ciclos de despliegue más frecuentes. Aplicaciones que se desarrollan en sprints de una semana, en lugar de proyectos de un año, y que necesitan publicar actualizaciones con mayor rapidez y frecuencia.
En última instancia, esa es en gran medida la razón por la 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 para publicar una actualización. Porque todo es mío y, si algo sale mal, la responsabilidad es enteramente mía.
Ese mismo enfoque también es posible en las instalaciones propias (y, en mi opinión, preferible). Para ello, es necesario que todos los elementos que componen la cadena de entrega de una aplicación admitan el mismo tipo de enfoque específico para cada aplicación que la nube ha hecho deseable.
Básicamente, un enfoque por aplicación para proporcionar los servicios de red y de aplicaciones necesarios equivale a dedicar una subred a la aplicación; una VLAN de entrega de aplicaciones, por así decirlo. Todo gira en torno a esa única aplicación, con servicios dedicados.
Ese tipo de aislamiento no solo es beneficioso para los calendarios de despliegue, sino también para todos los demás. Los fallos ocurren y, cuando suceden, conviene limitar al máximo su alcance. Las arquitecturas independientes para cada aplicación permiten contener estrictamente el impacto de los fallos, lo que alegra a todas esas personas que están de guardia «por si acaso», porque no reciben esa llamada. Puedo publicar y desplegar cada semana sin interferir con las aplicaciones que se publican y despliegan una vez al mes. Mi aplicación, mis servicios, mi calendario de despliegue.
Una arquitectura por aplicación también facilita la resolución de los problemas que surgen en producción. Y suelen surgir con frecuencia. De hecho, el 50 % de los desarrolladores afirmó haber tenido problemas en producción tras publicar el código en una encuesta de Atlassian de 2017. No hay posibilidad de que otra persona haya realizado un cambio que pueda afectar a la aplicación. Puedes centrarte directamente en los sistemas implicados, en lugar de perder un tiempo valioso intentando averiguar qué sistemas podrían estar implicados.
Una arquitectura por aplicación se adapta de forma natural mejor a la nube, ya sea pública o privada, porque ese es el supuesto en el que se basa el modelo. Cada aplicación cuenta con un conjunto específico de servicios de aplicación para escalarla, acelerarla y protegerla.
La realidad es que una arquitectura por aplicación era inevitable. No es la primera vez que lo digo. La fuerza de atracción de las aplicaciones es demasiado intensa como para ignorarla, y la seguridad cada vez más específica que se necesita para proteger cada aplicación hacía que, tarde o temprano, se acabara adoptando un enfoque por aplicación.
Y eso es algo positivo, porque los servicios de aplicaciones que quieren los desarrolladores suelen ser específicos para cada aplicación. Lo que funciona para una no tiene por qué funcionar para otra y, de hecho, puede resultar contraproducente. Al adoptar un enfoque arquitectónico por aplicación para la entrega de aplicaciones, no solo puede garantizar que los desarrolladores obtengan lo que quieren y necesitan para escalar, proteger y acelerar las aplicaciones, sino también ofrecer un mejor soporte para el modelo de autoservicio que esperan de la nube, tanto en entornos locales como externos.
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.