Comparativa de la entrega de aplicaciones: 2005 frente a 2015

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

James Ward, que escribe código (así se describe él), recientemente publicó un excelente artículo en el que comparaba el despliegue de aplicaciones actual con el de hace diez años. Uno de los secretos mejor guardados del sector de las TI en general es que los cambios en las arquitecturas y el despliegue de aplicaciones tienen un impacto directo en la entrega de aplicaciones (el proceso de garantizar que las aplicaciones sean rápidas, seguras y estén disponibles para sus usuarios). Los cambios que están provocando actualmente los microservicios, por ejemplo, son importantes por la forma en que van a cambiar la arquitectura de red y su modelo de despliegue.

Lo sé, lo sé. Estás pensando que la transición hacia los microservicios, la contenerización y la nube abstrae la red, haciendo que las aplicaciones sean menos dependientes de ella. Y es cierto, desde la perspectiva de los desarrolladores y quizá incluso de operaciones. Pero sigue siendo necesaria una red; los datos intercambiados aún tienen que circular por esas vías y los servicios que residen en la red siguen siendo responsables de muchas funciones que hacen que las aplicaciones sean rápidas, las mantienen seguras y garantizan su disponibilidad. Por tanto, los cambios en dónde y cómo se componen y despliegan las aplicaciones afectan necesariamente a esos servicios, aunque la aplicación no sea consciente de su existencia (y, sinceramente, nunca debería llegar a saberlo. En ese sentido, son como ángeles de la guarda).

Así pues, dada esta relación, aunque la aplicación no la corresponda, el artículo de James inspiró un análisis paralelo de los cambios que se han producido en la forma de entregar aplicaciones durante los últimos diez años.

Arquitectura de despliegue

2005	2015
Línea de conga	Plataforma

En 2005, los equipos de redes (NetOps) implementaban los distintos servicios de aplicaciones necesarios para entregar aplicaciones siguiendo lo que nos gusta llamar una «fila de conga». Se trataba de soluciones puntuales independientes. Si necesitabas algo para acelerar una aplicación, implementabas un producto de optimización del rendimiento web en su propio dispositivo dedicado. Otro dispositivo para el balanceo de carga, otro para la seguridad de las aplicaciones, y así sucesivamente. Al final, se formaban largas filas de numerosos dispositivos, cada uno de los cuales debía atravesarse en ambos sentidos.

En 2004 surgieron los controladores de entrega de aplicaciones (aunque en 2005 aún eran muy inmaduros) y comenzaron a evolucionar hacia lo que tenemos hoy en día: una plataforma. Estas plataformas proporcionan funciones y capacidades de procesamiento comunes, y pueden ampliarse mediante módulos (o complementos, extensiones o como prefiera llamarlos). El enfoque basado en plataformas reduce considerablemente el tiempo que se pasa «en la red», de forma muy similar a cómo la contenerización y la virtualización reducen el tiempo dedicado a desplazarse entre aplicaciones y servicios. También permite reducir los costes operativos al compartir una base común —la plataforma— que unifica la gestión de los distintos servicios de aplicaciones necesarios para ofrecer una aplicación hoy en día.

La evolución de producto a plataforma resulta ventajosa a medida que el despliegue de aplicaciones avanza hacia arquitecturas más desechables y desacopladas que aprovechan tecnologías emergentes como los contenedores y los microservicios, así como el despliegue en entornos de nube, ya que permiten implementar diversos servicios de aplicaciones, o uno solo, utilizando el mismo núcleo estandarizado. Esto supone una menor carga administrativa a medida que aumenta el número de servicios de aplicaciones desplegados, además de la posibilidad de añadir servicios según sea necesario conforme crecen las aplicaciones.

Métodos de implementación

2005	2015
Implementación manual	Implementación programable

En 2005, las interfaces gráficas de usuario basadas en web apenas empezaban a generalizarse, y el principal método para aprovisionar y configurar servicios de aplicaciones era la interfaz de línea de comandos (CLI). Este proceso, como todos los procesos manuales, requería tiempo y, a medida que los servicios de aplicaciones se volvían más complejos, aún más. Los problemas derivados de errores humanos y su consiguiente impacto (al estar en la red, el alcance de una configuración incorrecta aumenta exponencialmente) hacían necesaria una supervisión que alargaba todavía más el proceso. Copiar y pegar era una práctica habitual, pero no infalible, y la carga administrativa que suponía gestionar los servicios era tan considerable que solo las aplicaciones más importantes podían beneficiarse de ellos.

Avancemos hasta 2015 y la revolución de DevOps. La programabilidad —tanto mediante API como mediante configuraciones basadas en plantillas— lo está cambiando todo, incluso en la red. Ahora, los servicios de aplicaciones pueden automatizarse mediante API utilizando marcos de trabajo populares como Puppet y Chef, integrados previamente con soluciones de orquestación como Cisco APIC y VMware NSX, y personalizarse con Python, Perl, bash y curl. Las plantillas de servicios de aplicaciones permiten la estandarización y la reutilización, y fomentan que la infraestructura se trate «como código» para extender las prácticas de entrega continua a la red.

Aunque no está tan extendida como la entrega continua en el desarrollo de aplicaciones, la entrega de aplicaciones ha evolucionado (y sigue evolucionando) para admitir opciones de despliegue programables que reducen el tiempo de comercialización mediante un aprovisionamiento de servicios más rápido, además de disminuir los costes operativos gracias a la automatización y la reutilización.

Modalidades de implementación

2005	2015
Grandes sistemas	Virtualizado

En 2005, se desató una carrera por desarrollar hardware de red más grande, mejor, más rápido y con mayores prestaciones. El aumento de las velocidades de Ethernet y la proliferación de aplicaciones web hicieron necesario ampliar en consonancia los grandes sistemas desplegados en la red para satisfacer los requisitos de los servicios de aplicaciones.

Hoy en día, la atención se centra en la densidad y el aprovechamiento óptimo de los recursos. Esto implica virtualización y computación en la nube, ambas respaldadas por la virtualización de las plataformas de entrega de aplicaciones. Actualmente, estas plataformas pueden implementarse en entornos de nube como AWS, Microsoft Azure y Rackspace, así como mediante un dispositivo virtual que puede desplegarse tanto en hardware específico como en hardware estándar. Esta capacidad es un requisito no solo para admitir entornos de nube, sino también para adaptarse a arquitecturas emergentes como los microservicios. Hoy en día, tanto los microservicios como los propios servidores son, como señala James Ward, «desechables, inmutables y efímeros…».

Esto significa que muchos de los servicios de aplicaciones que están pasando al ámbito de DevOps —equilibrio de carga, seguridad de las aplicaciones y optimización— deben cumplir los criterios de un centro de datos definido por software. Como mínimo, deben poder adaptarse a gran escala a un modelo inmutable y desechable. Muchas plataformas de entrega de aplicaciones ya han alcanzado ese punto y, combinadas con opciones de implementación programables, están preparadas para afrontar el reto.

Responsabilidad del despliegue

En 2005 —y todavía hoy en muchas organizaciones—, el equipo de redes era el único responsable de implementar y gestionar la entrega de aplicaciones. Todos los aspectos de la entrega, desde la adquisición hasta el aprovisionamiento y la configuración, estaban —y a menudo siguen estando— en manos del equipo de operaciones de red. Este modelo fragmentado provocaba retrasos mientras se concretaban los requisitos, se creaban incidencias y los ingenieros aprovisionaban y configuraban manualmente los servicios necesarios para entregar una aplicación.

Hoy en día, esto sigue siendo así en muchas organizaciones, pero el impacto de la nube y los microservicios, junto con la adopción de DevOps, está cambiando esta situación. Existe un gran interés por las TI como servicio, y la responsabilidad de configurar los servicios de aplicaciones se está trasladando a los equipos de operaciones o incluso de desarrollo. Es necesario que los servicios vinculados a las aplicaciones estén más cerca de estas, tanto física como topológicamente. Esto sitúa a DevOps firmemente al mando y le atribuye la responsabilidad de aprovisionar y configurar dichos servicios.

Eso no significa que el equipo de redes se desentienda de la entrega de aplicaciones. Hay un importante segmento de aplicaciones y necesidades empresariales que requieren que los servicios de aplicaciones se presten de una forma más tradicional centrada en lograr fiabilidad en lugar de agilidad. Esos servicios siguen perteneciendo, y probablemente seguirán perteneciendo, al ámbito del equipo de redes. Sin embargo, otros están pasando y seguirán pasando a ser responsabilidad de DevOps.

La entrega de aplicaciones ha avanzado mucho en los últimos diez años. Ha pasado de ser un conjunto de productos a convertirse en una plataforma unificada, ha incorporado capacidades de programación y ha evolucionado desde grandes sistemas de hardware hasta ofrecer compatibilidad con hipervisores y despliegues en la nube. A medida que las aplicaciones móviles, los microservicios y DevOps siguen transformando radicalmente la forma en que se crean, despliegan y entregan las aplicaciones, cabe esperar que continúen evolucionando los servicios que, en última instancia, permiten entregar dichas aplicaciones y mantenerlas rápidas, seguras y disponibles.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

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 Vittie