Comparación de la entrega de aplicação : 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 aplicação 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 aplicação tienen un impacto directo en la entrega de aplicação (el proceso real de garantizar que las aplicações 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 aplicações 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 aplicações necesariamente impactan esos servicios incluso si la aplicação 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 aplicação, el artículo de James inspiró una mirada paralela a los cambios en cómo presentamos aplicações 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 aplicação necesarios para entregar aplicações 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 aplicação (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 aplicações 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 aplicação necesarios para entregar una aplicação hoy.

La evolución de producto a plataforma es ventajosa a medida que la implementación de aplicação 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 aplicação , 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 aplicação implementados y la capacidad de agregar servicios según sea necesario a medida que crecen las aplicações .

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 aplicação era mediante la CLI. Este proceso, como todos los procesos manuales, requería tiempo y, a medida que los servicios de aplicação 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 aplicações 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 aplicação 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 aplicação 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 aplicação , la entrega de aplicação 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 aplicações basadas en la web significaron una expansión complementaria del gran hardware implementado en la red para satisfacer los requisitos de servicios de aplicação .

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 aplicação . Las plataformas de distribución de aplicação 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 aplicação que se trasladan al dominio de DevOps (equilibrio de carga, seguridad de aplicação 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 aplicação 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 aplicação . 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 aplicação 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 aplicação hacia los equipos de operaciones o incluso de desarrollo. Es necesario que los servicios afines a la aplicação 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 aplicação . Existe un segmento importante de aplicações y preocupaciones corporativas que requieren servicios de aplicação 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 aplicação 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 aplicações móviles, los microservicios y DevOps continúan cambiando radicalmente la forma en que se crean, implementan y entregan las aplicações , se espera ver una evolución continua de los servicios que, en última instancia, entregan esas aplicações y las mantienen rápidas, seguras y disponibles.