Tema 1.4 - Tipologías y Anti-tipologías de equipos DevOps

Esta es la clásica división de 'tíralo por encima del muro' entre Dev y Ops. Significa que los puntos de la historia se pueden reclamar temprano (DONE significa 'característica completa', pero no funciona en producción), y la operatividad del software se ve afectada porque los desarrolladores no tienen suficiente contexto para las características operativas y la gente de operaciones no tiene tiempo ni ganas de participar. Devs para solucionar los problemas antes de que el software entre en funcionamiento. Probablemente, todos sabemos que esta topología es mala, pero creo que en realidad hay peores topologías; al menos con Anti-Tipo A (Dev y Ops Silos), sabemos que hay un problema.

El silo del equipo DevOps (Anti-Tipo B) generalmente resulta de un gerente o ejecutivo que decide que "necesita un poco de esto de DevOps" y comienza un 'equipo DevOps' (probablemente lleno de personas conocidas como 'un DevOp'). Los miembros del equipo de DevOps rápidamente forman otro silo, manteniendo a Dev y Ops más separados que nunca mientras defienden su rincón, sus habilidades y su conjunto de herramientas de los "desarrolladores despistados" y las personas "dinosaurio Ops". La única situación en la que un silo de DevOps separado realmente tiene sentido es cuando el equipo es temporal, dura menos de (digamos) 12 o 18 meses, con el propósito expreso de acercar Dev y Ops, y con un mandato claro para hacer que DevOps equipo superfluo después de ese tiempo; esto se convierte en lo que he llamado una topología DevOps de tipo 5.

Esta topología nace de una combinación de ingenuidad y arrogancia de los desarrolladores y gerentes de desarrollo, particularmente cuando se inician nuevos proyectos o sistemas. Asumiendo que Ops ahora es cosa del pasado ("tenemos la nube ahora, ¿verdad?"), Los desarrolladores subestiman enormemente la complejidad y la importancia de las habilidades y actividades operativas, y creen que pueden prescindir de ellas, o simplemente cubrirla en horas libres. El Anti-Tipo C probablemente terminará necesitando de una topología  de Tipo 3 (Ops como IaaS) o Tipo 4 (DevOps-as-a-Service) cuando su software se involucre más persona y las actividades operativas comiencen a inundar el desarrollo. Si estos equipos reconocieran la importancia de las operaciones como una disciplina tan importante y valiosa como el desarrollo de software, podrían evitar muchos dolores de cabeza y errores operativos innecesarios (y bastante básicos).

Para "convertirse en DevOps" sin perder la velocidad actual de los equipos de desarrollo (entrega de lectura de historias funcionales), se configura un equipo de DevOps para trabajar en las herramientas necesarias para las canalizaciones de implementación, la gestión de la configuración, la gestión del entorno, entre otros. Mientras tanto, la gente de Ops continúa trabajando de forma aislada y los equipos de desarrollo continúan arrojándoles aplicaciones "sobre la pared". Aunque los resultados de este equipo dedicado pueden ser beneficiosos en términos de una cadena de herramientas mejorada, su impacto es limitado. El problema fundamental de la falta de participación y colaboración temprana de Ops en el ciclo de vida del desarrollo de aplicaciones permanece sin cambios.

Este antitipo es típico en organizaciones con poca madurez de ingeniería. Quieren mejorar sus prácticas y reducir costos, pero no ven a la TI como un motor central del negocio. Debido a que los éxitos de la industria con DevOps ahora son evidentes, también quieren "hacer DevOps". Desafortunadamente, en lugar de reflexionar sobre las brechas en la estructura y las relaciones actuales, toman el difícil camino de contratar "ingenieros de DevOps" para sus equipos de operaciones. DevOps se convierte simplemente en un cambio de marca del rol anteriormente conocido como SysAdmin, sin que se produzca ningún cambio cultural u organizativo real. Este antitipo se está generalizando cada vez más a medida que los reclutadores sin escrúpulos se suben al carro en busca de candidatos con habilidades de automatización y herramientas. Desafortunadamente, son las habilidades de comunicación humana las que pueden hacer que DevOps prospere en una organización.

La organización no quiere mantener un equipo de operaciones separado, por lo que los equipos de desarrollo asumen la responsabilidad de la infraestructura, la gestión de entornos, la supervisión, etc. priorizaciones que conducen a enfoques mediocres y soluciones a medias. 

En este antitipo, la organización muestra falta de apreciación por la importancia y las habilidades requeridas para operaciones de TI efectivas. En particular, el valor de Ops disminuye porque se trata como una molestia para Devs (ya que Ops es administrado por un solo administrador de equipo de Dev con otras prioridades

Esta es una forma de antitipo A (Dev and Ops Silos) que es prominente en empresas medianas y grandes donde múltiples sistemas heredados dependen del mismo conjunto central de datos. Debido a que estas bases de datos son tan vitales para el negocio, un equipo de DBA dedicado, a menudo bajo el paraguas de Ops, es responsable de su mantenimiento, ajuste del rendimiento y recuperación ante desastres. Eso es comprensible. El problema es cuando este equipo se convierte en el guardián de todos y cada uno de los cambios en la base de datos, convirtiéndose efectivamente en un obstáculo para implementaciones pequeñas y frecuentes (un principio fundamental de DevOps y Continuous Delivery).

Además, al igual que Ops en el antitipo A, el equipo de DBA no participa en las primeras etapas del desarrollo de la aplicación, por lo que los problemas de datos (migraciones, rendimiento, etc.) se encuentran al final del ciclo de entrega. Junto con la sobrecarga de admitir múltiples bases de datos de aplicaciones, el resultado final es una constante lucha contra incendios y una creciente presión para cumplir.

Esta es una forma de Anti-tipo A (Dev and Ops Silos) pero 10 años después. Los ingenieros de operaciones ahora se llaman a sí mismos SRE, pero poco más ha cambiado. Los desarrolladores aún arrojan software que solo tiene 'características completas' sobre la pared a los SRE. La operatividad del software aún se ve afectada porque los desarrolladores no están más cerca de ejecutar el software que crean, y los SRE aún no tienen tiempo para interactuar con los desarrolladores para solucionar los problemas cuando surgen.

Esta es la 'tierra prometida' de DevOps: colaboración fluida entre los equipos de desarrollo y los equipos de operaciones, cada uno de los cuales se especializa donde sea necesario, pero también comparte donde sea necesario. Es probable que haya muchos equipos de desarrollo separados, cada uno trabajando en una pila de productos separada o semi-separada. 

Mi sensación es que este modelo Tipo 1 necesita un cambio organizativo bastante sustancial para establecerlo, y un buen grado de competencia en los puestos superiores del equipo de gestión técnica. Dev y Ops deben tener un objetivo compartido claramente expresado y demostrablemente efectivo ("Entregar cambios confiables y frecuentes", o lo que sea). La gente de operaciones debe sentirse cómoda al emparejarse con desarrolladores y familiarizarse con la codificación basada en pruebas y Git, y los desarrolladores deben tomar en serio las características operativas y buscar personas de operaciones para obtener información sobre las implementaciones de registro, y así sucesivamente, todo lo cual necesita un gran cambio de cultura. del pasado reciente.

Donde la gente de operaciones se ha integrado en los equipos de desarrollo de productos, vemos una topología de Tipo 2. Hay tan poca separación entre Dev y Ops que todas las personas están muy enfocadas en un propósito compartido; esta es discutible una forma de Tipo 1 (Colaboración de desarrollo y operaciones) , pero tiene algunas características especiales. 

Organizaciones como Netflix y Facebook con efectivamente un solo producto basado en la web han logrado esta topología de Tipo 2, pero creo que probablemente no sea muy aplicable fuera de un enfoque de producto limitado, porque las restricciones presupuestarias y el cambio de contexto suelen estar presentes en una organización con múltiples los flujos de productos probablemente obligarán a Dev y Ops a separarse más (digamos, volver a un modelo Tipo 1). Esta topología también podría llamarse 'NoOps', ya que no hay un equipo de Operaciones distinto o visible (aunque Netflix NoOps también podría ser Tipo 3 (Ops como IaaS) ).

Para las organizaciones con un departamento de operaciones de TI bastante tradicional que no puede o no cambiará (lo suficientemente rápido), y para las organizaciones que ejecutan todas sus aplicaciones en la nube pública (Amazon EC2, Rackspace, Azure, etc.), probablemente ayude tratar las operaciones como un equipo que simplemente proporciona la infraestructura elástica en la que se implementan y ejecutan las aplicaciones; el equipo operativo interno es, por lo tanto, directamente equivalente a Amazon EC2 o infraestructura como servicio. 

Un equipo (quizás un equipo virtual) dentro de Dev luego actúa como una fuente de experiencia sobre características operativas, métricas, monitoreo, aprovisionamiento de servidores, etc., y probablemente realiza la mayor parte de la comunicación con el equipo de IaaS. Este equipo sigue siendo un equipo de desarrollo, sin embargo, sigue prácticas estándar como TDD, CI, desarrollo iterativo, entrenamiento, etc. 

La topología de IaaS intercambia alguna efectividad potencial (perdiendo la colaboración directa con la gente de Ops) para una implementación más sencilla, a lo mejor obteniendo valor más rápidamente que intentando el Tipo 1 (Colaboración de Dev y Ops) que podría intentarse en una fecha posterior.

Algunas organizaciones, particularmente las más pequeñas, pueden no tener las finanzas, la experiencia o el personal para liderar los aspectos operativos del software que producen. Luego, el equipo de desarrollo podría comunicarse con un proveedor de servicios como Rackspace para ayudarlos a crear entornos de prueba y automatizar su infraestructura y monitoreo, y asesorarlos sobre los tipos de características operativas para implementar durante los ciclos de desarrollo de software. 

Lo que podría llamarse DevOps-as-a-Service podría ser una forma útil y pragmática para que una pequeña organización o equipo aprenda sobre automatización, monitoreo y administración de configuración, y luego tal vez avance hacia un Tipo 3 (Ops como IaaS) o incluso Modelo Tipo 1 (Colaboración de desarrollo y operaciones) a medida que crecen y contratan más personal con enfoque operativo.

El equipo de DevOps con una fecha de caducidad (tipo 5) se parece sustancialmente al antitipo B (silo del equipo de DevOps), pero su intención y longevidad son bastante diferentes. Este equipo temporal tiene la misión de acercar Dev y Ops, idealmente hacia un modelo Tipo 1 (Colaboración de desarrollo y operaciones) o Tipo 2 (Responsabilidades de operaciones totalmente compartidas), y eventualmente volverse obsoleto. 

Los miembros del equipo temporal 'traducirán' entre Dev-speak y Ops-speak, presentando ideas locas como stand-ups y Kanban para equipos de Operaciones, y pensando en detalles sucios como balanceadores de carga, NIC de administración y descarga de SSL para Dev. equipos Si suficientes personas comienzan a ver el valor de unir Dev y Ops, entonces el equipo temporal tiene una posibilidad real de lograr su objetivo; Lo más importante es que la responsabilidad a largo plazo de las implementaciones y los diagnósticos de producción no debe asignarse al equipo temporal, de lo contrario, es probable que se convierta en un silo de equipo DevOps (Anti-Tipo B).

Dentro de las organizaciones que tienen una gran brecha entre Dev y Ops (o la tendencia hacia una gran brecha), puede ser efectivo tener un equipo de DevOps 'facilitador' que mantenga a los lados de Dev y Ops hablando. Esta es una versión del Tipo 5 (Equipo DevOps con fecha de caducidad), pero donde el equipo DevOps existe de forma continua con el cometido específico de facilitar la colaboración y la cooperación entre los equipos Dev y Ops. A los miembros de este equipo a veces se les llama 'Defensores de DevOps', porque ayudan a difundir el conocimiento de las prácticas de DevOps.

DevOps a menudo recomienda que los equipos de desarrollo se unan a la rotación de guardia, pero no es esencial. De hecho, algunas organizaciones (incluida Google) ejecutan un modelo diferente, con una 'transferencia' explícita de Desarrollo al equipo que ejecuta el software, el equipo de Ingeniería de confiabilidad del sitio (SRE). En este modelo, los equipos de desarrollo deben proporcionar pruebas de prueba (registros, métricas, etc.) al equipo de SRE que demuestren que su software tiene un estándar lo suficientemente bueno como para recibir asistencia del equipo de SRE. 

Fundamentalmente, el equipo de SRE puede rechazar el software que es deficiente desde el punto de vista operativo y pedir a los desarrolladores que mejoren el código antes de ponerlo en producción. La colaboración entre Dev y SRE ocurre en torno a criterios operativos, pero una vez que el equipo de SRE está satisfecho con el código, ellos (y no el equipo de desarrollo) lo admiten en producción.

Los contenedores eliminan la necesidad de algunos tipos de colaboración entre Dev y Ops al encapsular los requisitos de implementación y tiempo de ejecución de una aplicación en un contenedor. De esta forma, el contenedor actúa como un límite entre las responsabilidades de Dev y Ops. Con una cultura de ingeniería sólida, el modelo de colaboración impulsada por contenedores funciona bien, pero si Dev comienza a ignorar las consideraciones operativas, este modelo puede convertirse en un 'nosotros y ellos' contradictorio.

Para cerrar el abismo Dev-DBA, algunas organizaciones han experimentado con algo como el Tipo 9, donde una capacidad de base de datos del equipo DBA se complementa con una capacidad de base de datos (o especialidad) del equipo Dev. Esto parece ayudar a traducir entre la vista centrada en Dev de las bases de datos (como tiendas de persistencia esencialmente tontas para aplicaciones) y la vista centrada en DBA de las bases de datos (fuentes inteligentes y ricas de valor comercial).