El software sigue consumiendo TI: su próximo curso son los servicios de aplicaciones
En 2015, me di cuenta de que el software se estaba comiendo a la TI . Esto se basó en datos extraídos de una variedad de fuentes de la industria, incluidas RightScale, HBR, PWC y otras. Desde el desarrollo hasta la implementación y la entrega, el software estaba tomando el control en todas partes.
Pero incluso entonces, la infiltración de software en la red (del lado de producción de la casa) era todavía mínima. Oh, las señales estaban allí e incluso muchas de las herramientas y API que necesitábamos. Pero si la amplitud del oleoducto era un plato sofisticado, entonces el desarrollo era el plato principal y el despliegue y la entrega meramente el postre.
Eso fue entonces, esto es ahora. Y lo que estamos viendo que sucede es que la implementación y la entrega son ahora uno de los tres platos principales en el menú del proceso de desarrollo de aplicação .
¿Los datos? Extraído de la investigación de F5 realizada durante los últimos dos años. Se señala a la transformación digital como el impulsor de toda esta automatización y cambio, pero no hay que pasar por alto el impacto disruptivo de la nube pública en general.
Independientemente de quién reciba el crédito (¿o la culpa?) por el giro de la balanza a favor del software, es casi indiscutible que el software todavía está devorando a la TI.
Desarrollo
El segmento de desarrollo del pipeline de aplicação siempre ha estado impulsado por el software. Usamos software para construir las distintas bibliotecas y ejecutables. Usamos software para alojar versiones del código mucho antes de que Git existiera o CI/CD se convirtiera en un término común*.
Lo que no siempre se automatizó fue toda la amplitud del segmento de desarrollo. Las pruebas automatizadas, la gestión de la configuración y los sistemas de compilación basados en eventos no eran tan comunes como lo son hoy.
Gracias a la nube y a DevOps, el segmento de desarrollo del flujo de trabajo de aplicação se ha convertido, en gran medida, en una tarea de “software que crea el software”.
Implementación
La nube y DevOps vuelven a recibir el reconocimiento por impulsar la necesidad de una mayor automatización en el segmento de implementación. Este segmento del “otro lado del muro de producción” está dominado por operaciones que automatizan la implementación de la infraestructura de las aplicaciones, así como los procesos de compilación y prueba. Éste nunca fue realmente el problema. La cuestión era el “resto del oleoducto”. La parte del pipeline que comprendía la infraestructura de red que proporcionaba las plataformas para los servicios de aplicação necesarios para escalar, proteger y acelerar las aplicaciones.
Es este segmento de la cadena de aplicação el que ahora está experimentando un crecimiento explosivo en automatización por parte de un grupo cada vez mayor de ingenieros de redes expertos a los que llamamos NetOps, como un guiño al movimiento DevOps que ha influenciado (y continúa influyendo) las herramientas, técnicas y metodologías utilizadas para automatizar "la red".
Observamos enormes avances en los últimos tres años en términos del uso y la importancia de la automatización en las operaciones de red. El segmento de implementación del proceso de aplicação está camino de convertirse en el esfuerzo del “software que implementa el software”.
Delivery
El segmento de entrega del proceso de aplicação será el más disruptivo de todos. Esto se debe en parte a que durante veinte años nuestro recurso principal en la red ha sido una brillante caja de hierro. Son escalables, tienen la capacidad y, en general, son más rápidos que el software. Pero con la inevitabilidad de las organizaciones multi-nube y la adopción de la nube pública como una opción incluso para las aplicações empresariales más críticas, las reglas del juego han cambiado.
El hardware no migra a la nube. El hardware no es realmente la plataforma adecuada para soportar las arquitecturas por aplicación necesarias para adoptar enfoques de infraestructura inmutable como código para la entrega. El software migra a la nube. El software admite aplicaciones individuales, inmutabilidad e infraestructura como código.
La pregunta no es realmente hardware o software (para las arquitecturas de nube por aplicación, la respuesta obviamente es software), sino ¿contenedores o software virtual? A medida que los contenedores avanzan rápidamente para consumir centros de datos y nubes por igual, hemos visto una duplicación de la demanda de servicios de aplicação entregados en contenedores. Ahora bien, para ser justos, esa duplicación fue de aproximadamente el 4% en 2017 al 9% en 2018, pero aun así es un salto significativamente grande, independientemente de que la adopción sea de un solo dígito o no.
También ha habido una demanda significativamente mayor de software virtual, y las preferencias de hardware han disminuido año tras año. Ahora bien, si crees que algún día llegará a cero, entonces no entiendes realmente por qué pasamos del software al hardware en primer lugar (sí, ya hemos pasado por eso antes) y por qué una parte del segmento de distribución (la red central, compartida) probablemente siempre será en gran medida hardware en la empresa.
Sin embargo, la mayor parte del segmento de distribución será software. Ya lo es. Ya hace tiempo que lo es. Es la única forma de aliviar la fricción de la migración hacia y desde la nube pública y abordar la creciente fricción de los cronogramas de implementación tradicionales con los cronogramas de entrega de aplicaciones impulsados por la demanda. Los contenedores y el software virtual consumirán al menos dos tercios del segmento de distribución de aplicação , tanto locales como en la nube pública.
El segmento de distribución se está convirtiendo en una iniciativa de “software que entrega el software que entrega y protege el software”.
Esto se debe a que el software sigue devorando a las TI y continuará haciéndolo en el futuro previsible.
*Si su hogar está compuesto principalmente por desarrolladores (como es el caso del mío), entonces CI/CD es un término familiar. Depende.