Los constructores expertos (DevOps) también necesitan colaboración
Si eres padre (e incluso si no lo eres, no te juzgamos), probablemente hayas visto alguna vez la película Lego. Más de una vez.
Soy de la opinión de que probablemente debería ser un requisito obligatorio para cualquier empresa que esté considerando adoptar DevOps.
En serio.
Esto se debe a que una de las (muchas) lecciones aprendidas es que incluso los maestros constructores, expertos en su dominio específico, necesitan colaborar con otros para salvar el mundo y mover una aplicação a su estado de implementación deseado. Es decir, uno que no esté estancado en la producción con el aterrador Kragle tecnológico que son los procesos manuales.
Individualmente, los maestros constructores pueden visualizar no sólo lo que quieren construir sino también todos los componentes que necesitan para construirlo. Y lo hacen, a menudo y de manera admirable, en la película, creando creaciones completas que pueden destruir, volar, correr y disparar para salvar el día. Pero cuando llegó el momento de actuar en el panorama "más amplio"; no solo de construir creaciones individuales y luego orquestar (¿ven lo que hice allí?) una serie de eventos para frustrar el plan del Malvado, no pudieron hacerlo. Necesitaban a un tipo al que le gustara consultar instrucciones y llevar una lista con los procedimientos necesarios para que todos avanzaran en la misma dirección.
En nuestro caso esa dirección es la producción.
A medida que la implementación continua se convierte en una posibilidad real y el objetivo final de DevOps al superar el muro entre el desarrollo y el "resto de TI", existe una necesidad muy real de coordinación entre los cuatro dominios operativos (es decir, seguridad, almacenamiento, computación y red) para garantizar que los maestros constructores de cada conjunto individual de servicios y sistemas no trabajen en el vacío.
Incluso los desarrolladores que adoptan microservicios, con su “código local e independiente de otros servicios”, saben que esa mentalidad y ese enfoque solo funcionan si hay interfaces (API) claramente definidas y documentadas con las que otros servicios puedan comunicarse. Esas interfaces no se desarrollan (o no deberían desarrollarse) en el vacío, sin una comprensión de cómo otros servicios las invocarán.
Lo mismo ocurre en el lado de producción del muro, donde los cuatro dominios operativos deben comunicarse en algún momento para permitir que el despliegue continuo realmente se lleve a cabo. Hay un plan maestro, un conjunto de instrucciones que deben seguirse, aunque no se detalle cómo se construirá cada servicio individual o conjunto de servicios. En algún momento, deben orquestarse en un proceso general que impulse la implementación desde un extremo al otro del proceso de producción.
Los maestros constructores de cada dominio no pueden trabajar de forma totalmente independiente unos de otros. Necesitan coordinarse, cooperar y considerar cómo su pieza del rompecabezas encaja en el gran plan para salvar el mundo (de las aplicaciones) sobre el que se basa el negocio hoy.
Una de las formas de comenzar a hacerlo es graficar los conjuntos de impacto. Me acordé de esto después de leer un artículo reciente sobre el acoplamiento de código, La regla del 80% del acoplamiento de programas , con la vista puesta en la seguridad. El artículo está muy centrado en el código y en la creación de lo que equivale a gráficos de dependencia específicos para personas con mentalidad de desarrollo, pero si lo llevas a un nivel superior (lo abstraes) y consideras las funciones/procedimientos/métodos como sistemas en producción, puedes comenzar a ver cómo esto podría ser útil. Comprender el nivel de dependencia que tiene la implementación de una aplicação en servicios específicos (o incluso en el nivel de dominio, para empezar) puede brindar información valiosa para entender cuánta coordinación se requerirá entre los grupos para realizar el trabajo y poder diseñar un plan para lograr ese objetivo.
Uno de los mejores ejemplos es que casi todo depende de que se implementen primero los servicios de red principal . Esto se aplica no solo a la aplicação y sus componentes dependientes, sino también a la seguridad y los servicios de orden superior que la entregan. El equilibrio de carga, la seguridad de las aplicação web e incluso el firewall dependen de los atributos de red para funcionar. Comprender esas dependencias (el factor de acoplamiento) entre los sistemas y servicios administrados por diferentes grupos (silos) dentro de TI puede ser de gran ayuda para avanzar en la necesidad de comunicarse y colaborar para lograr incluso algo similar a una implementación continua.
Incluso los maestros constructores tienen que entender cómo su creación encaja en el panorama general. La aplicación de técnicas y herramientas de desarrollo al mundo de operaciones cada vez más automatizado y basado en código en TI les ayudará a construir mejor las interfaces necesarias para integrar su pieza del rompecabezas en el gran esfuerzo de construcción que es la implementación continua.