Tres factores que te impiden adoptar DevOps
No, tú no. Tú. Los ejecutivos no están tan entusiasmados con DevOps como aquellos que están en las trincheras, y la respuesta puede encontrarse en una de estas tres preocupaciones clave.
Las organizaciones de alto rendimiento no solo han adoptado, sino que han adoptado, DevOps. El informe fundamental sobre el estado de DevOps de Puppet Labs nos ha demostrado esto durante los últimos dos años, y me imagino que volverá a reforzar esa relación el año que viene. Según una serie de encuestas y estudios de la industria, las organizaciones están adoptando DevOps. Pero, así como en el pasado se adoptaron metodologías de desarrollo de aplicaciones ágiles y eficientes, adoptar no siempre significa lo que creemos que significa. Resultó que lo que las organizaciones realmente quieren decir cuando hablan de “adoptar métodos ágiles” para el desarrollo de aplicaciones es que un porcentaje relativamente pequeño de sus proyectos utilizaban métodos ágiles. Eso no significaba que se hubieran lanzado a lo grande y hubieran dado el salto radical aceptándolo para cada proyecto.
Lo mismo parece ser cierto para DevOps, donde los encuestados lo están adoptando con entusiasmo y obteniendo resultados, pero los ejecutivos en general todavía parecen ser tibios con el enfoque, aumentando solo dos puntos porcentuales en "impacto estratégico" año tras año, del 15% en 2016 al 17% en 2017, según nuestra encuesta sobre el estado de la entrega de aplicação . Si bien los arquitectos de la nube y los roles autoidentificados como “DevOps” pueden estar plenamente comprometidos con su iniciativa DevOps, e incluso haber superado el muro en producción, los ejecutivos aún están rezagados en la adopción de este enfoque. Lo que realmente significa que las “organizaciones” no necesariamente adoptan DevOps por completo.
Hay tres preocupaciones clave que probablemente sean responsables de impedir que los líderes de TI y de negocios le den a DevOps la cálida bienvenida que merece.
- Tiempo . Los proyectos de TI internos de cualquier tipo que requieren una mentalidad de migración (ya sea de tradicional a la nube, de monolito a microservicios, de manual a automatizado) a veces se consideran poco más que una propuesta que hace perder el tiempo. No contribuyen directamente al crecimiento del negocio y, por lo tanto, el tiempo dedicado a dichos proyectos puede resultar oneroso para las partes interesadas del negocio. Es necesario que quienes apoyan DevOps ilustren a los líderes empresariales un conjunto claro de objetivos y beneficios esperados que surgirán al embarcarse en tales proyectos. Ya sea que se trate de ahorros de costos o de una TI más receptiva, es importante que las empresas comprendan la recuperación prevista de la inversión para lograr que acepten y respalden el esfuerzo. Un centavo ahorrado puede ser un centavo ganado, pero un centavo invertido es a menudo diez centavos ganados. Invierta en DevOps ahora y las organizaciones cosecharán los beneficios más adelante.
- Interrupción. Ningún líder de TI quiere ser la causa de interrupciones en el negocio. Invertir ahora en una iniciativa de DevOps puede ser disruptivo, en particular si provoca una desaceleración en el proceso de producción cuando todos saben que es necesario acelerarlo. Debido a que habilitar la producción para la automatización y la orquestación a menudo significa alterar los sistemas responsables de las actividades diarias del negocio, cualquier iniciativa que lo requiera puede causar una interrupción indeseable. La realidad es que confiar en métodos manuales obsoletos para aprovisionar, escalar y gestionar sistemas puede ser la verdadera disrupción, si no hoy, mañana. Una de las características distintivas de un entorno de producción sin fricciones es la capacidad de responder según demanda a las necesidades de capacidad y servicios. Esto es algo que se vuelve cada vez más difícil de lograr a medida que la TI se hunde bajo el peso de la creciente demanda causada por los esfuerzos de transformación digital . Sin riesgo no hay recompensa. Asumir el riesgo ahora probablemente implique menos riesgos que cuando su cartera de aplicação haya crecido el doble o más.
- Bloquear . Un temor común de los líderes de TI es el de quedar “atados” a decisiones. La buena noticia es que la mayoría de los dispositivos y sistemas de red que respaldan la automatización y la orquestación se basan en protocolos y conceptos de estándares abiertos como HTTP, REST y JSON. Aquí es donde el tiempo invertido inicialmente en diseñar y diseñar un sistema que aproveche las API y las plantillas tanto como sea posible dará sus frutos más adelante. La integración con dispositivos o sistemas que requieren la recreación paso a paso de comandos emitidos por la CLI a través de una API casi con certeza provocará un bloqueo. Este es uno de los mayores beneficios de las plantillas: reducir la dependencia de las API específicas del dispositivo y del sistema y, por lo tanto, limitar su exposición a solo unos pocos comandos que se pueden migrar fácilmente a un nuevo sistema o aplicación en el futuro. Asegúrese de que la infraestructura admita una API basada en REST y, cuando sea posible, utilice plantillas para permitir una fácil extracción de los sistemas y entornos más adelante.
Existen otras preocupaciones, por supuesto, pero principalmente estas tres preocupaciones clave resuenan en todos los centros de datos y a lo largo del tiempo cuando se trata de la adopción de tecnología y metodología. Toma tiempo, puede ser disruptivo y hay grandes posibilidades de que haya un estancamiento. La debida diligencia y un enfoque reflexivo de la implementación, junto con una actitud de invertir ahora y beneficiarse después, pueden aliviar esas preocupaciones y generar una mejor posibilidad de sentar con éxito una base firme pero flexible que no solo permita sino que acelere la transformación digital necesaria para que el negocio crezca ahora y en el futuro.