Supere estos cinco desafíos DevOps

1. Falta de comunicación y prioridades dispersas

La mayoría de los desafíos de DevOps son problemas de personas. Los rencores, conceptos erróneos y estereotipos entre departamentos son profundos.

Conversaciones que reflejan que la negatividad puede descarrilar DevOps. Por ejemplo, preguntamos cómo evitar que la seguridad ralentice a los desarrolladores, en lugar de cómo el equipo de seguridad puede fortalecer el desarrollo de una aplicación, dijo Lyman. "La seguridad del software es un tipo de calidad del software, y eso es algo que los desarrolladores aprecian". Para hablar su idioma, dijo, encuadre la seguridad como un aspecto vital de la calidad del software.

DevOps es una forma de conectar los objetivos de equipos de TI dispares, así como su trabajo. Cuando el equipo de seguridad puede influir en el diseño de la aplicación o la infraestructura, el producto es más fuerte, porque esas medidas de seguridad no son complicaciones tardías. El producto de software funciona mejor y requiere menos resolución de problemas y mediación porque el trabajo se realizó por adelantado para contrarrestar los problemas potenciales.

2. Equipos de DevOps en silos

John Allspaw.

Quizás el problema de DevOps más sutil es cuando una organización de TI crea un equipo de DevOps nuevo y distinto. "Algunos practicantes creían que (...) hay algún tipo de influencia social o política que se obtiene al nombrar a su equipo 'DevOps'", dijo Allspaw.

En realidad, DevOps no está destinado a erradicar la experiencia del dominio, ni a convertir a los especialistas en generalistas. Es beneficioso tanto para los profesionales de TI a nivel individual, como para el departamento de TI en general redistribuir algunas responsabilidades, aunque sea temporalmente. Por ejemplo, cuando los desarrolladores de aplicaciones, que conocen el resultado previsto de su código desde el principio, se hacen cargo de la implementación, el cambio puede fomentar una comprensión de la perspectiva de las operaciones de TI. Este trabajo interdisciplinario puede potencialmente curar parte de la brecha entre estos dos grupos, provocada por las tensiones de objetivos no coincidentes. También significa que los desarrolladores deben asumir una mayor responsabilidad por la calidad del código que producen.

Para fomentar la colaboración en lugar de un equipo de DevOps aislado, el liderazgo de TI debe vincular los incentivos a varias etapas del desarrollo de un proyecto, pero basar esos incentivos en el desempeño de otro equipo, dijo Lyman. Por ejemplo, si el incentivo de los desarrolladores depende de qué tan bien lo haga el equipo de operaciones de TI, los desarrolladores se esforzarán por proporcionar a las operaciones de TI la mejor versión de sus entregables. Esos incentivos pueden cruzar muchas categorías, desde oportunidades de mejora personal hasta proyectos nuevos e innovadores.

3. Pensamiento estrecho

En sus inicios, los defensores de DevOps sugirieron que DevOps debería ser sinónimo, y reemplazable en cualquier oración, con las tres C: colaboración, cooperación y coordinación.

"La colaboración, la cooperación y la coordinación fue la perspectiva que los desarrolladores [podrían] anticipar, comprender y empatizar con la posición en la que se encuentran los ingenieros de operaciones, y los ingenieros de operaciones [podrían] empatizar, comprender y potencialmente construir, de manera colaborativa, los roles y responsabilidades que tienen los desarrolladores", dijo Allspaw. Para "hacer DevOps", los diferentes equipos de TI deben perseguir un objetivo común con compasión por las posiciones de los demás y un impulso para hacer que las cosas funcionen. Crear un equipo de DevOps es simplemente dividir dos equipos de TI y crear un tercero.

Pero este hito solo marca un fracaso si el viaje termina aquí.

Por el contrario, uno de los mayores desafíos en DevOps es reunir a todas las partes interesadas al mismo tiempo. Y es aquí donde la pregunta de DevOps se convierte en la pregunta de DevSecOps y, a veces, BizDevOps.

Jay Lyman.

DevOps tiene partes interesadas clave fuera de los equipos de desarrollo y operaciones de TI, es decir, en seguridad y redes, pero también en la administración y en el lado comercial. El equipo de DevOps debe incluir profesionales de redes, seguridad y control de calidad, junto con líderes empresariales, gerentes de proyectos y científicos de datos, para tener las mejores posibilidades de éxito. Descuidar estas áreas es un gran obstáculo para el éxito de DevOps. Cuando una organización de TI crea software con DevOps, necesita todos los demás equipos y departamentos de TI que no pertenecen a DevOps para completar sus objetivos y ayudarlos a alcanzar los suyos. "[Las organizaciones de TI] necesitan este esfuerzo para la tormenta... para difundir esto más allá del equipo", dijo Lyman.

Específicamente, lleve DevOps a la gestión. Las iniciativas y los logros de un equipo de DevOps son limitados si el liderazgo no los impulsa hacia el resto de la organización.

4. Demasiadas herramientas

Una organización puede tener una secuencia de CI/CD sin DevOps, pero no puede tener DevOps sin una canalización de CI/CD. Así como uno no puede aprender a conducir sin un automóvil, una organización de TI no puede aprender a automatizar la implementación de aplicaciones si no tiene las herramientas en su lugar. No permita que la selección de herramientas de DevOps se salga de control.

Históricamente, muchas organizaciones se inclinaron hacia conjuntos de herramientas de un solo proveedor, totalmente integrados, listos para usar, con soporte. Sin embargo, la complejidad de la TI ha llevado a la proliferación de herramientas de nicho, lo que conduce a una colección fragmentada de herramientas que las organizaciones deben integrar. También hay una gama cada vez mayor de servicios basados ​​en la nube para desarrollo, prueba, implementación, CI/CD y más. Y con las herramientas de código abierto, cualquiera puede elegir el producto que mejor se adapte a sus habilidades y trabajo.

"No sé si alguna organización, ya sabes, una gran empresa, puede obtener todo lo que necesitan, técnicamente, de un proveedor para una implementación de DevOps", dijo Lyman.

Sin supervisión, una organización puede terminar con docenas de herramientas innecesarias en uso. Intente estandarizar la menor cantidad posible de herramientas DevOps. Para hacerlo, el personal y la administración deben unirse para determinar las características y funciones importantes y la mejor manera de adaptarse a las necesidades especializadas más allá de ellas.

5. Demasiados cambios demasiado pronto

Es tentador adoptar DevOps de una sola vez: reemplazar las arquitecturas monolíticas en máquinas virtuales y servidores con nuevas y brillantes plataformas en la nube y aplicaciones SaaS y FaaS, secuencias automatizadas, contenedores y paneles de monitoreo. Hay demasiadas piezas de un entorno de TI para cambiar todas a la vez; y las dependencias entre aplicaciones plantean un gran desafío. La implementación y el escalado de DevOps dentro de una organización deben incluir una planificación cuidadosa y la colaboración entre grupos. Evalúe los riesgos de seguridad y los posibles errores, así como la complejidad innecesaria que creará problemas en el futuro.

Para superar este desafío de DevOps, cree un centro de excelencia donde los miembros del equipo de múltiples disciplinas puedan crear una lista de proyectos, herramientas o tecnologías para actualizar, priorizados por mayor impacto y facilidad de transición. Un centro de excelencia a menudo puede comenzar con los campeones iniciales de DevOps, para ayudar a establecer políticas y estructuras internas para la organización y medir qué tan bien está funcionando DevOps. Vincule estos esfuerzos a un programa de capacitación interno, documentación clara y centros de recursos.