Tres cosas que te impiden adoptar DevOps

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

No, tú no. Tú. Los directivos no están ni de lejos tan entusiasmados con DevOps como quienes trabajan sobre el terreno, y el motivo podría estar en una de estas tres preocupaciones clave.

Las organizaciones de alto rendimiento no solo han adoptado DevOps, sino que lo han integrado plenamente. El informe de referencia State of DevOps de Puppet Labs nos lo ha demostrado durante los dos últimos años, y me imagino que el próximo año volverá a confirmar esa relación. Según diversos estudios y encuestas del sector, las organizaciones están adoptando DevOps. Sin embargo, al igual que ocurrió en el pasado con la adopción de metodologías ágiles y lean para el desarrollo de aplicaciones, «adoptar» no siempre significa lo que creemos. Resultó que, cuando las organizaciones hablaban de «adoptar metodologías ágiles» para el desarrollo de aplicaciones, en realidad querían decir que solo un porcentaje relativamente pequeño de sus proyectos las utilizaba. No significaba que se hubieran lanzado de lleno a aplicarlas en todos sus proyectos.

Lo mismo parece ocurrir con DevOps: los encuestados lo están adoptando con entusiasmo —y obteniendo resultados—, pero, en general, los directivos todavía parecen mostrarse poco receptivos a este enfoque, ya que su «impacto estratégico» solo aumentó dos puntos porcentuales interanuales —del 15 % en 2016 al 17 % en 2017—, según nuestra encuesta Estado de la entrega de aplicaciones. Aunque los arquitectos de la nube y quienes se identifican como profesionales de «DevOps» pueden estar plenamente volcados en su iniciativa de DevOps e incluso haberla llevado ya a producción, los directivos siguen rezagados a la hora de adoptar este enfoque. Esto significa, en realidad, que las «organizaciones» no necesariamente han adoptado DevOps por completo.

Hay tres preocupaciones clave que probablemente estén impidiendo que los responsables de TI y de negocio den a DevOps la cálida bienvenida que realmente merece.

1. Tiempo. Los proyectos internos de TI de cualquier tipo que requieren un enfoque de migración —ya sea de sistemas tradicionales a la nube, de una arquitectura monolítica a microservicios o de procesos manuales a automatizados— se consideran a veces poco más que una pérdida de tiempo. No contribuyen directamente al crecimiento empresarial y, por tanto, puede resultar difícil que las partes interesadas de la empresa respalden el tiempo dedicado a estos proyectos. Quienes apoyan DevOps deben presentar a los responsables empresariales un conjunto claro de objetivos y beneficios previstos derivados de la puesta en marcha de dichos proyectos. Ya se trate de ahorrar costes o de lograr una TI con mayor capacidad de respuesta, es importante que la empresa comprenda el retorno previsto de la inversión para conseguir su aceptación y apoyo. Puede que un céntimo ahorrado sea un céntimo ganado, pero un céntimo invertido suele generar diez. Las organizaciones que inviertan ahora en DevOps cosecharán los frutos más adelante.
   
2. Disrupción. Ningún responsable de TI quiere ser la causa de interrupciones en el negocio. Invertir ahora en una iniciativa de DevOps puede generar disrupciones, especialmente si ralentiza el flujo de producción cuando todo el mundo sabe que es necesario acelerarlo. Dado que preparar la producción para la automatización y la orquestación suele implicar modificar los sistemas responsables de las operaciones diarias, cualquier iniciativa que lo requiera puede provocar una interrupción no deseada. La realidad es que depender de métodos manuales obsoletos para aprovisionar, escalar y gestionar sistemas puede ser la verdadera causa de 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 bajo demanda a las necesidades de capacidad y servicios. Esto resulta cada vez más difícil de conseguir a medida que el área de TI se ve desbordada por el aumento de la demanda provocado por las iniciativas de transformación digital. Quien no arriesga, no gana. Asumir el riesgo ahora probablemente conlleve menos riesgos que hacerlo cuando la cartera de aplicaciones se haya duplicado o haya crecido aún más.
   
3. Dependencia de un proveedor. Un temor habitual entre los responsables de TI es quedar «atados» por sus decisiones. La buena noticia es que la mayoría de los dispositivos y sistemas de red compatibles con la automatización y la orquestación se basan en protocolos de estándares abiertos y conceptos como HTTP, REST y JSON. Aquí es donde el tiempo dedicado desde el principio a diseñar y definir la arquitectura de un sistema que aproveche al máximo las API y las plantillas dará sus frutos más adelante. La integración con dispositivos o sistemas que requieran reproducir paso a paso, mediante una API, los comandos ejecutados desde la CLI conducirá casi con toda seguridad a una dependencia de un proveedor. Esta es una de las mayores ventajas de las plantillas: reducen la dependencia de API específicas de dispositivos y sistemas y, por tanto, limitan la exposición a unos pocos comandos que pueden migrarse fácilmente a un nuevo sistema o aplicación en el futuro. Asegúrese de que la infraestructura sea compatible con una API basada en REST y, siempre que sea posible, utilice plantillas para facilitar la extracción posterior de sistemas y entornos.

Por supuesto, existen otras preocupaciones, pero estas tres son las principales y se repiten en los centros de datos a lo largo del tiempo cuando se trata de adoptar tecnologías y metodologías. Requiere tiempo, puede causar interrupciones y existe una probabilidad muy alta de quedar atado a un proveedor. La diligencia debida, un enfoque meditado de la implementación y una mentalidad de invertir ahora para obtener beneficios más adelante pueden mitigar estas preocupaciones y aumentar las probabilidades de establecer con éxito unos cimientos sólidos pero flexibles que no solo permitan, sino que aceleren, la transformación digital necesaria para que la empresa crezca tanto ahora como en el futuro.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie