Todos conocemos el adagio: “Los malos trabajadores culpan a sus herramientas”. Pero aquí hay cinco razones por las que las herramientas de software program involucradas en DevOps en normal, y la canalización de CI/CD en specific, se han convertido en parte del problema en lugar de la solución.
1. Tardan demasiado en desplegarse
Esto, hay que decirlo, es una gran ironía. Cuando el desarrollo de software program comenzó por el camino ágil en el último milenio, fue para romper con los modelos en cascada, no porque fueran incorrectos per se, sino porque eran demasiado lentos. Así como un ciclo de desarrollo de dos a tres años es demasiado largo ya que el mundo (tecnológico) habrá cambiado, también lo es un período related para implementar una herramienta en una empresa.
Además de las escalas de tiempo fundamentales, la capacidad de atención de la toma de decisiones simplemente no se extiende tanto. El resultado es que las herramientas a menudo se implementan a medias antes de que llegue la próxima ola de herramientas, lo que aumenta la complejidad en lugar de reducirla.
2 . Todavía se venden como balas mágicas.
En casi todos los seminarios net orientados a soluciones en los que he estado, se usa la línea “pero no es una varita mágica” (es justo, si nadie más lo cube, lo haré yo). No obstante, todavía nos dicen que las herramientas de software program son la respuesta: pueden transformar la forma en que entrega el software program, tienen todo lo que necesita, and many others.
Realmente sería maravilloso si estas declaraciones de advertising fueran ciertas, pero solo son parcialmente correctas. Sin embargo, a diferencia de los instrumentos financieros, los proveedores de herramientas no están obligados a incluir renuncias de responsabilidad en sus portadas, por ejemplo, “El éxito requiere la debida diligencia del cliente y la gestión del cambio”.
3. Aparecen nuevos todo el tiempo
Esto es tan irónico como 1. Un camino razonablemente estándar es cuando los ingenieros inteligentes que trabajan para una empresa más grande expresan su frustración con sus propias canalizaciones y terminan creando una solución genial. Igualmente inteligentes, se dan cuenta de que están en lo cierto, forman una startup, encuentran un par de clientes y consiguen alguna inversión, gastando sumas razonables en advertising y, de hecho, en asesoría de analistas.
En el espacio DevOps, que inevitablemente está lleno de desarrolladores, esta situación es más común que (digamos) la infraestructura de redes: la gente generalmente no inicia empresas de telecomunicaciones como proyectos paralelos. El problema es que esto cae en la trampa de asumir que nadie más ha resuelto el mismo problema, creando lados adicionales en la misma montaña para trabajar.
4. Se venden sin controles
En mi experiencia de implementar herramientas de desarrollo de software program (que no está mal), tienden a dividirse en dos campos. Algunos son tácticos: un pequeño widget de prueba de rendimiento, panel o capacidad de integración. El resto, casi en exceso, tiene algún tipo de expectativa estratégica sobre cómo se hacen las cosas. Los administradores de entornos de desarrollo necesitan equipos para trabajar con la noción de entornos. Las herramientas de prueba necesitan una metodología de prueba.
Si bien muchas herramientas pueden tener un marco asociado, una forma de pensar o un enfoque, a menudo no conducen a esto. Sin embargo, seamos claros, todo requerirá cambios a nivel de gestión en la forma en que se hacen las cosas, o incluso más alto. Existen excepciones: algunos proveedores venden a nivel de directorio, pero consulte también 5.
5 . Son vendidos y comprados por ingenieros.
Esto se superpone con 4, pero se trata más del lanzamiento al mercado, que a menudo es un modelo freemium o de código abierto plus. Esencialmente, las herramientas se presentan como tácticas, con el conocimiento directo de que, tarde o temprano, tendrán que ser percibidas como estratégicas.
En la industria, este modelo de ventas se llama “aterrizar y expandirse”: simplemente entre de cualquier manera y crezca a partir de ahí. Sin embargo, la realidad es más “aterrizar, expandirse y luego comenzar a tener problemas”: las organizaciones terminan con bolsas de herramientas implementadas de diferentes maneras y un entorno muy fragmentado. Los proveedores también pueden reclamar los logotipos de los clientes, pero luego tienen dificultades para convertir las implementaciones tácticas en clientes más estratégicos.
Todos estos problemas se pueden resumir como “herramientas estratégicas, vendidas y compradas tácticamente”. No voy a señalar con el dedo exclusivamente a los vendedores (aunque recuerdo una conversación que tuve sobre tácticas de venta, en un dominio diferente. Yo: “¿Por qué lo haces de esa manera? No es agradable”. Ellos: ” Porque funciona”).
Y luego, las capacidades más nuevas, como los indicadores de características, se presentan para mejorar aún más las cosas, cuando en realidad son todo lo contrario. Creo que las banderas de características son excelentes para el registro, pero vendidas/compradas sin controles, son una ruta hacia una fragmentación y desesperación aún mayores.
¿Hay una respuesta? Dado que los proveedores de herramientas de software program difícilmente van a adoptar un enfoque de “vendamos menos y califiquemos a cualquier organización que no esté lo suficientemente organizada para usar nuestro materials”, la responsabilidad tiene que detenerse en las organizaciones de usuarios finales, específicamente en sus equipos de ingeniería y cómo se gestionan. Si bien los proveedores deben rendir cuentas, se necesitan dos para bailar tango.
La clave está en la palabra “herramientas” en sí. Tenemos que dejar de pensar en herramientas como destornilladores y mazos, y empezar a verlas como sistemas de fabricación: estamos construyendo una fábrica de software program, no un taller estilo hipster.
Las organizaciones necesitan ver sus cadenas internas de suministro de software program de la misma manera que verían una planta de fabricación (tercera ironía de alerta: ese es exactamente el punto señalado en el Proyecto Phoenix, escrito hace 15 años).
Esto también significa directamente restringir que los desarrolladores tomen decisiones de herramientas incuestionables. Lo siento, pero no compro completamente la frase “los desarrolladores son los nuevos hacedores de reyes”, ya que hablo con demasiadas personas de operaciones e infraestructura que tienen que palear las pilas de estiércol que crean si no se controlan.
Todos necesitamos estar protegidos contra nosotros mismos, y la consecuencia de una cultura de todo vale en nombre de la innovación es una serie de feudos fragmentados, no grandes imperios. El problema del “prototipo/PoC se convierte en la plataforma” es tan cierto para las herramientas como para el software program a medida si el tiempo es limitado, lo que inevitablemente es así.
Desde la perspectiva del proveedor, esto significa centrarse en una lista más pequeña de proveedores, dándoles potencialmente más dinero y trabajando con ellos para comprender los cambios culturales necesarios para adoptar sus capacidades por completo.
Y los líderes empresariales, siempre que permitan que la situación domine, están alentando la ineficiencia y el despilfarro. Las cosas buenas solo salen del caos por excepción. Por el lado positivo, particularmente relevante en estos tiempos recesivos, esta fragmentación crea grandes oportunidades para reducir el desperdicio y aumentar la eficiencia, liberando fondos para la innovación.
Sobre todo, hemos creado una jungla al no prestar atención al frente. Nunca es demasiado tarde para comenzar a abordar esto, pero sin rodeos, si todas las empresas son empresas de software program, deben comenzar a actuar como tal.
