Servicios de aplicação y canalización de CD
Como sucede con todas las tecnologías que llegan a dominar las conversaciones sobre centros de datos, DevOps actualmente sufre una fatiga de definiciones. En realidad en este punto creo que es agotamiento, pero la línea entre ambos es difícil de determinar. Basta decir que DevOps está tan lejos de tener una definición aceptada universalmente como la nube y SDN.
Pero DevOps es único en el sentido de que sus conceptos compuestos también suelen confundirse y combinarse. Por ejemplo, CD puede interpretarse como “entrega continua” o “implementación continua”. Estos dos no son lo mismo y tampoco deben confundirse ni combinarse. Puppet Labs hizo un gran trabajo al ilustrar la diferencia en una publicación de blog :
Notarás que la diferencia definitoria es si la implementación en producción es “manual” (entrega continua) o “automatizada” (implementación continua).
El problema es que hay una cantidad importante de trabajo en ese pequeño cuadro naranja denominado “implementar en producción” que debe automatizarse. No se trata simplemente de implementar la aplicación y sus dependencias (bases de datos, otros servicios, infraestructura, etc.). También se trata de implementar todos los servicios de red y aplicação necesarios para entregar esa aplicação al consumidor final. Aquí es donde entran en juego los servicios de aplicação y donde la entrega de aplicação (en el sentido de producción, no en el de desarrollo) entra en el proceso de implementación continua.
Para automatizar el paso de “implementación en producción” dentro del proceso de implementación continua, es necesario aprovisionar, configurar y probar muchas partes móviles. Esto significa todo, desde redes básicas hasta seguridad (como firewalls), disponibilidad (equilibrio de carga) y servicios de rendimiento (aceleración, almacenamiento en caché, etc.). En promedio, las organizaciones utilizan 11 servicios de entrega de aplicação diferentes para satisfacer su necesidad de aplicações rápidas, seguras y disponibles. Cada uno debe implementarse (aprovisionarse y configurarse) y algunos dependen de la implementación de otros.
Cada uno de esos servicios (esto es como aquel acertijo de St. Ives, para los que estén jugando) tiene un número variable de características que deben configurarse, opciones establecidas como verdaderas o falsas, algoritmos seleccionados, rutas establecidas, etc.
En otras palabras, cambiar de “manual” a “automático” no es tan fácil como parece.
¿Qué está frenando la red?
Un obstáculo importante a la hora de automatizar estos procesos se encuentra en las diferencias entre los componentes compartidos y los componentes por aplicación. La infraestructura como código es posible en el ámbito de la infraestructura de aplicaciones precisamente porque podemos dedicar infraestructura (como un servidor web o un balanceador de carga) a una aplicação. Esto significa que su archivo de configuración es algo así como un microservicio: está localizado y enfocado en proporcionar servicios para una aplicação.
Cuando nos adentramos en el mundo de las redes y los servicios de aplicaciones, este no siempre es el caso. Un enrutador o conmutador, por ejemplo, está diseñado específicamente para proporcionar conectividad y servicios de reenvío para múltiples aplicações. Esto significa que los archivos de configuración necesariamente abarcan múltiples aplicações. Si bien el control de versiones puede ser útil en este caso, la realidad es que las configuraciones están muy ligadas a un dispositivo, no a una aplicación. Lo mismo ocurre con los servicios y la seguridad de las aplicaciones.
Si bien es bueno que todos estemos avanzando hacia un mundo donde la API es la CLI, también tenemos que abordar la necesidad de respaldar un paradigma por aplicación (o centrado en la aplicación, si lo prefiere) donde las configuraciones se puedan administrar por aplicación .
Esto significa avanzar hacia una arquitectura de red de estilo microservicios en la que los servicios se implementan y configuran aplicación por aplicación. Esto puede tomar la forma de “dispositivos” dedicados (virtuales o hardware, el factor de forma es irrelevante para los propósitos de esta discusión) o configuraciones específicas de la aplicación, como plantillas .
¿Ya llegamos?
Nos estamos acercando, con modelos declarativos de aprovisionamiento y gestión que utilizan API para implementar plantillas (es decir, infraestructura como código) por aplicación, pero aún no hemos llegado allí. Todavía queda mucho trabajo por hacer en el ámbito de descubrir cómo orquestar la automatización necesaria para permitir una implementación continua exitosa.
La red, la infraestructura, los servicios de aplicaciones y los silos de seguridad deben incluirse si vamos a realizar la transición de "manual" a "automático" para ese paso de "implementación a producción" que es fundamental para completar la transición de la entrega continua a la implementación continua. Y eso significa más trabajo en la capa de automatización, así como en la orquestación general necesaria para automatizar por completo los procesos que, en última instancia, impulsan la implementación continua en producción.