¿Pros / contras de descontinuar un flujo de trabajo de DevOps?

Estoy tratando de evaluar si es una buena idea alejarse de un flujo de trabajo de estilo devops a los tradicionales dev-then-ops (no estoy seguro de cómo se llama).

Somos un pequeño departamento de 5 personas escondido dentro de una compañía de medios tradicionales de 4000 empleados (por ejemplo, que no es de software). Hace dos años comenzamos a crear software para permitir que nuestro departamento escale significativamente nuestra producción. Hemos tenido bastante éxito y la gran empresa está comenzando a darse cuenta. Hasta la fecha, hemos sido los únicos responsables del diseño, desarrollo e implementación de lo que se ha convertido en una plataforma de microservicio AWS de ~ 10 servicios. Nuestro equipo no se identifica como DevOps, pero sin duda estamos viviendo la vida de DevOps, con cada desarrollador íntimamente familiarizado con el código y el sistema en el que se ejecuta.

Una de las preguntas que enfrentaremos en breve es qué "eficiencias" compartimos entre nosotros y el departamento de TI de nuestra empresa matriz. El propietario de nuestro proyecto generalmente prefiere la subcontratación en lugar del aprendizaje interno, por lo que en nuestro caso, estas eficiencias probablemente significan obtener la mayor cantidad de trabajo de TI "fuera de nuestro plato" como sea posible. Actualmente, diría que nuestro equipo tiene una división del 70/30% entre la experiencia en codificación y la infraestructura. El departamento de TI está sólidamente en el ámbito de TI, sin un cruce visible en el desarrollo de software.

El propietario de nuestro proyecto (un individuo no técnico) espera que al entregar la mayor cantidad de trabajo posible al equipo de TI veremos un aumento de ~ 1: 1 en la productividad por cada hora de trabajo de operaciones que eliminamos. Aunque soy escéptico sobre esto. Nuestro producto todavía es pre-beta (a pesar de que ya es un activo comercial significativo) y en nuestra experiencia limitada con el departamento de TI, generalmente hay retrasos significativos para cosas tan simples como los cambios de permisos del sistema de archivos.

En este momento, mi solución ideal sería que el departamento de TI nos "adoptara" y nos permitiera continuar implementando nuestro propio trabajo, a la vez que nos aseguramos de cumplir con los estándares y requisitos de la oficina de TI. Sin embargo, no estoy seguro de lo realista que es eso. Además, es casi el enfoque opuesto que defiende nuestro propietario del proyecto, ya que agregaría trabajo de operaciones adicionales a corto plazo.

En nuestra situación, ¿cuáles son las ventajas y desventajas probables de permanecer con el enfoque DevOps en lugar de entregar TI?

No es una buena idea.

En mi experiencia, obtendrá las desventajas de ambos, mientras que cualquier ventaja proyectada de alguna manera no se materializará.

Detallado:

1. Perderás velocidad.
   TI cumplirá con su propio estándar. La nueva tarea (para ellos) seguirá la misma plantilla 'lenta' que todo su trabajo tiene ahora. Esté preparado, lo encontrarán desafiante, por lo que incluso menos velocidad que las acciones simples estándar.
2. No podrás descargar.
   Se apoyará en ustedes para cada anomalía. Te esforzarás por poner a un tipo al día, y lo siguiente que harás ahora es que te repetirás porque la siguiente tarea / problema / día habrá un nuevo tipo, nuevamente.
3. Se requerirá documentación, pero no ayudará.
   Una vez más, el comportamiento de la plantilla será que los manuales cortos no podrán detectar todas las anomalías, y los textos completos no se leerán por ser demasiado largos. Por lo tanto, cualquier inversión aquí será una pérdida, del mismo modo que el enorme esfuerzo necesario para implementar mejoras para que sus herramientas alcancen una calidad "reducida".

Por último, pero no menos importante, cualquier problema se reflejará en ustedes. Alquitrán, principio del alquitrán.

Si lo anterior suena cínico, bueno, me temo que he estado allí. Repetidamente.

¿Qué hacer en su lugar?

Vaya de compras al departamento de TI, búsquese un candidato útil y mantenga a este tipo "prestado" para aliviar su carga de trabajo.

Puede encontrar muchas de las respuestas en el resultado de la encuesta DevOps que debe pedirle al propietario del producto que lea. Este es un documento escrito específicamente para gente de negocios con poco conocimiento técnico que habla en los términos que debe entender.

En promedio, necesitará 1 desarrollador adicional por cada 4 personas para mantener el mismo nivel de desarrollo de funciones (38% frente al 49% del tiempo dedicado al nuevo trabajo). Su tiempo medio para recuperarse del fracaso disminuirá hasta 25 veces. Su trabajo será un 20% menos agradable y tendrá un 40% más de probabilidades de recomendar su trabajo a un amigo. Solo esos tres hechos deberían ser suficientes.

Lo que perderá al integrarse en la organización de TI es la parte "Dev" de su pequeño equipo DevOps. Cuando los equipos se segmentan en roles artificiales de NetOps, SysOps y Dev, se presentan los siguientes problemas:

1. Burocracia y aislamiento innecesarios : para hacer cualquier cosa, los desarrolladores deberán enviar un ticket a TI y esperar a que lo implementen. Ya no podrán implementar e interactuar con ellos mismos, hasta sus instancias de desarrollo y control de calidad, lo que limitará la infraestructura que pueden codificar. Están atrapados en la barrera de VM en lugar de poder codificar en la pila completa. Si lo que envían a TI parece código DevOps, estarán mal equipados para manejarlo y podrían volver a implementaciones manuales.
2. Descuido : alternativamente, pueden implementarlo tal cual y luego descuidar a la bestia porque no saben cómo interactuar con él, y no son desarrolladores, por lo que el código no es su problema.
3. Interrupciones : uno de los beneficios a menudo ignorados de DevOps es su naturaleza programática. Claro, puede llevar más tiempo implementar ese servidor tratándolo como código, pero esto automatiza los errores humanos. La forma en que se convirtió en dev es la forma en que entrará en QA / Test es la forma en que entrará en producción, reduciendo así las interrupciones. Cuando los desarrolladores pierden el acceso al equipo de red, necesitan implementar su servicio o la infraestructura de cómputo no solo toma más tiempo, sino que introduce más humanos falibles que causarán más interrupciones.
4. Documentación : en algunos sentidos, el código DevOps es autodocumentado. Sabes cómo se creó y desplegó el servidor porque el código te lo dice. En 5 años, cuando sea el momento de una actualización a CentOS 8 o lo que sea, ya nadie sabrá cómo implementar su aplicación, incluso en las capas de red, almacenamiento, monitoreo y respaldo.

En resumen, debe sugerir que el propietario de su proyecto se tome el tiempo de leer The Mythical Man-Month para desengañarlo de la noción de que verá una relación 1: 1 en productividad y The Phoenix Project, que es una buena novela (y entretenido) ilustración de lo que se gana y se pierde al usar DevOps en lenguaje no técnico para personas no técnicas. Si el propietario del proyecto tiene algún tipo de viaje, está disponible un audiolibro audible de The Phoenix Project.

Le sugiero que adopte parte del equipo de TI y les brinde capacitación exhaustiva en el nuevo sistema.

Una vez que entienden el sistema completamente, entonces tiene sentido descargarlo.

De lo contrario, se convertirá en un Centro de soporte para TI, y pasará mucho tiempo en la lucha contra incendios a medida que aprenden las complejidades del nuevo sistema.