Comparación de la entrega de aplicación : 2005 frente a 2015

James Ward, quien escribe código (su descripción), recientemente escribió un excelente artículo en el que comparó la implementación de aplicación hoy en día con la de hace diez años. Uno de los secretos mejor guardados de la industria de TI en general es que los cambios en las arquitecturas y la implementación de aplicación tienen un impacto directo en la entrega de aplicación (el proceso real de garantizar que las aplicaciones sean rápidas, seguras y estén disponibles para sus consumidores). Los cambios que hoy están produciendo los microservicios, por ejemplo, son significativos en cuanto a cómo van a cambiar la arquitectura de la red así como su modelo de implementación.

Lo sé, lo sé. Estás pensando que los avances hacia los microservicios, la contenerización y la nube abstraen la red, haciendo que las aplicaciones dependan menos de ellos. Y eso es cierto, desde la perspectiva de los desarrolladores y quizás incluso de los operadores. Pero aún se necesita una red; los datos intercambiados aún necesitan fluir por esas tuberías y los servicios que residen en la red aún son responsables de muchas funciones que hacen que las aplicaciones funcionen rápidamente, las mantienen seguras y aseguran la disponibilidad . Los cambios en dónde y cómo se componen e implementan las aplicaciones necesariamente impactan esos servicios incluso si la aplicación no es consciente de su existencia (y, honestamente, nunca debería saberlo). Son como ángeles guardianes en ese sentido.)

Entonces, dada la relación, incluso si no es correspondida por la aplicación, el artículo de James inspiró una mirada paralela a los cambios en cómo presentamos aplicaciones en los últimos diez años.

Arquitectura de implementación

2005	2015
Línea de conga	Plataforma

En 2005, los equipos de red (NetOps) implementaron los diversos servicios de aplicación necesarios para entregar aplicaciones en lo que nos gusta llamar una “línea de conga”. Éstas fueron soluciones puntuales individuales. Si necesitabas algo para que esa aplicación fuera más rápida, implementabas un producto de optimización del rendimiento de la web en su propia caja personal y privada. Otra caja para equilibrar la carga, otra para la seguridad de la aplicación, y así sucesivamente. Al final se formaron largas filas con muchas cajas, cada una de las cuales debía recorrerse en ambas direcciones. 

En 2004 surgieron los controladores de entrega de aplicación (pero eran muy inmaduros en 2005) y comenzaron a evolucionar hacia lo que tenemos hoy, que es una plataforma . Estas plataformas proporcionan una funcionalidad y un procesamiento comunes y pueden ampliarse con módulos (o complementos o extensiones o como quiera llamarlos). El enfoque de plataforma reduce en gran medida el tiempo transcurrido “en el cable”, de la misma forma que la contenerización y la virtualización reducen la cantidad de tiempo empleado en viajar entre aplicaciones y servicios. También ofrece la capacidad de reducir los costos operativos al compartir una base común (la plataforma) que normaliza la gestión de los diversos servicios de aplicación necesarios para entregar una aplicación hoy.

La evolución de producto a plataforma es ventajosa a medida que la implementación de aplicación avanza hacia arquitecturas más desechables y descompuestas que aprovechan tecnologías emergentes como contenedores y microservicios e implementación en entornos de nube porque se pueden usar para implementar una variedad de servicios de aplicación , o solo uno, utilizando el mismo núcleo estandarizado. Esto significa menos gastos administrativos a medida que se expande la superficie de los servicios de aplicación implementados y la capacidad de agregar servicios según sea necesario a medida que crecen las aplicaciones .

Métodos de implementación

2005	2015
Implementación manual	Despliegue programable

En 2005, las GUI basadas en web apenas se estaban generalizando y el método principal para aprovisionar y configurar servicios de aplicación era mediante la CLI. Este proceso, como todos los procesos manuales, requería tiempo y, a medida que los servicios de aplicación se volvían más complejos, requería aún más tiempo. La introducción de problemas debido a errores humanos y el impacto resultante (estar en la red aumenta exponencialmente el radio de explosión de una configuración incorrecta) significó que la supervisión se prolongó aún más en ese momento. Copiar y pegar era algo común, pero no infalible, y los costos administrativos de gestionar servicios eran lo suficientemente significativos como para garantizar que sólo las aplicaciones más importantes obtuvieran los beneficios de esos servicios.

Avanzamos rápidamente hasta 2015 y la revolución de DevOps. La programabilidad, tanto en API como en configuraciones basadas en plantillas, está cambiando todo, incluso en la red. Los servicios de aplicación ahora se pueden automatizar a través de API que utilizan marcos populares como Puppet y Chef, preintegrados con soluciones de orquestación como Cisco APIC y VMware NSX, y personalizados con Python, Perl, bash y curl. Las plantillas de servicio de aplicación permiten la estandarización, la reutilización y fomentan el tratamiento de la infraestructura “como código” para permitir que las prácticas de entrega continua se extiendan a la red.

Si bien no es tan omnipresente como la entrega continua dentro del desarrollo de aplicación , la entrega de aplicación ha evolucionado (y continúa evolucionando) para soportar opciones de implementación programables que reducen el tiempo de comercialización mediante un aprovisionamiento de servicios más rápido, además de reducir los costos operativos mediante la automatización y la reutilización.

Factores de forma de implementación

2005	2015
Gran hierro	Virtualizado

En 2005, hubo una prisa por construir hardware de red más grande, mejor, más rápido y con mayor capacidad. El aumento de la velocidad de Ethernet y una explosión de aplicaciones basadas en la web significaron una expansión complementaria del gran hardware implementado en la red para satisfacer los requisitos de servicios de aplicación .

Hoy en día la atención se centra en la densidad y la utilización óptima de los recursos. Esto significa virtualización y computación en la nube, ambas respaldadas por la virtualización de las plataformas de distribución de aplicación . Las plataformas de distribución de aplicación ahora pueden implementarse en entornos de nube como AWS, Microsoft Azure y Rackspace, así como en un dispositivo virtual que puede implementarse en hardware especialmente diseñado o estándar. Esta capacidad es un requisito, no sólo para soportar entornos de nube, sino para adaptarse a arquitecturas emergentes como los microservicios. Hoy en día, los microservicios y los servidores son, como señala James Ward, “desechables, inmutables y efímeros…”.

Esto significa que muchos de los servicios de aplicación que se trasladan al dominio de DevOps (equilibrio de carga, seguridad de aplicación y optimización) deben cumplir los criterios de un centro de datos definido por software . Como mínimo, deben poder encajar en un modelo inmutable y desechable a escala. Hoy en día existen muchas plataformas de distribución de aplicación que, combinadas con opciones de implementación programables, están listas para enfrentar el desafío.

Responsabilidad de implementación

En 2005 –y en muchas organizaciones todavía hoy– el equipo de red es totalmente responsable de la implementación y la gestión de la entrega de aplicación . Cada aspecto de la entrega, desde la adquisición hasta el aprovisionamiento y la configuración, fue y a menudo todavía es manejado por operaciones de red. Este modelo inconexo significó demoras mientras se resolvían los requisitos, se creaban los tickets y los ingenieros aprovisionaban y configuraban manualmente los servicios de aplicación 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 combinados con la adopción de DevOps está cambiando eso. El deseo de TI como servicio es fuerte, con un cambio en la responsabilidad de la configuración de los servicios de aplicación hacia los equipos de operaciones o incluso de desarrollo. Es necesario que los servicios afines a la aplicación estén ubicados más cerca de ella, tanto física como topológicamente. Esto coloca a DevOps al mando y a la responsabilidad de aprovisionar y configurar dichos servicios.

Eso no significa que el equipo de red se esté lavando las manos en lo que respecta a la entrega de aplicación . Existe un segmento importante de aplicaciones y preocupaciones corporativas que requieren servicios de aplicación entregados de una manera más tradicional enfocada en lograr confiabilidad en lugar de agilidad. Esos servicios todavía están, y probablemente seguirán estando, en el dominio del equipo de red. Pero otros son y seguirán siendo responsabilidad de DevOps.

La entrega de aplicación ha avanzado mucho en los últimos diez años. Ha evolucionado desde un conjunto de productos a una plataforma unificada, ha ganado capacidad de programación y se ha transformado desde un gran dispositivo hasta un sistema compatible con hipervisores e implementación en la nube. A medida que las aplicaciones móviles, los microservicios y DevOps continúan cambiando radicalmente la forma en que se crean, implementan y entregan las aplicaciones , se espera ver una evolución continua de los servicios que, en última instancia, entregan esas aplicaciones y las mantienen rápidas, seguras y disponibles.