bluebay2014 - stock.adobe.com
Por qué es hora de repensar el debate DevOps vs. ITIL
A medida que las organizaciones busquen alinear más estrechamente sus objetivos comerciales y de TI, deben combinar las prácticas de DevOps e ITIL, en lugar de comprometerse exclusivamente con una metodología sobre la otra.
Históricamente, ITIL y DevOps han sido malos compañeros de cama. DevOps se trata de velocidad y habilitación, mientras que ITIL, al menos tradicionalmente, es un marco mucho más proscriptivo que genera retrasos considerables en un flujo de trabajo de DevOps.
Esto no quiere decir que DevOps sea perfecto; muchas organizaciones han descubierto –con su respectivo costo– que un enfoque abierto de DevOps ha llevado a problemas importantes, como un código relativamente descontrolado que pasa del desarrollo a la producción.
Sin embargo, DevOps ha madurado, al igual que el marco de gestión de servicios de TI de ITIL. Y si bien las dos tecnologías aún no son una combinación perfecta, es hora de dejar de pensar en términos de DevOps frente a ITIL y, en su lugar, considerar DevOps e ITIL.
Donde DevOps e ITIL se cruzan
Los talleres de DevOps deben contar con los controles y equilibrios correctos. Deben codificar procesos que permitan auditorías; retroalimentar los errores a los desarrolladores para que los corrijan; y crear un circuito de retroalimentación de los usuarios finales a los equipos de desarrollo y operaciones.
La última versión del marco ITIL –ITIL 4– se centra en el valor, lo que proporciona una base sólida para estos procesos. Y a medida que DevOps continúa evolucionando, las prácticas de ITIL podrían ayudar a los equipos de TI a crear entornos idempotentes.
La idempotencia es el medio por el cual una entidad –como un usuario final, un desarrollador, un profesional de operaciones de TI o incluso una IA o un motor de aprendizaje automático– define el resultado deseado de cualquier cambio dado. Las herramientas subyacentes luego usan scripts para crear y aprovisionar paquetes en un entorno operativo que logrará el resultado deseado. Este enfoque requiere un monitoreo continuo y ciclos de retroalimentación para garantizar que el resultado no solo se logre, sino que también se mantenga a medida que cambia la plataforma.
ITIL 4 abarca estos conceptos. La cadena de valor del servicio del marco promueve un conjunto interconectado de actividades que se ocupan de la creación, entrega y mejora continua del servicio. Es complementario a las prácticas de desarrollo continúo y entrega continúa en DevOps. Sin embargo, hay una diferencia clave entre DevOps e ITIL aquí: el primero enfatiza las formas técnicas y ocultas de realizar estas tareas, mediante el uso de herramientas de desarrollo y procesos duros, mientras que el segundo se enfoca más en garantizar que las tareas ocurran. de forma controlada y auditable.
El sistema de valor del servicio de ITIL se superpone a su cadena de valor del servicio. Este amplio sistema representa cómo funciona una organización desde la oportunidad o la demanda del usuario final hasta la entrega de valor.
DevOps vs. ITIL para la empresa
En el momento de la publicación, el sistema de valor del servicio de ITIL supera con creces el estado actual de DevOps; específicamente, el estado de BizDevOps. En este modelo DevOps, los impulsores comerciales dan forma a cómo trabajan los desarrolladores, con el objetivo de satisfacer las necesidades de los usuarios que afectan directamente los resultados de la organización. Ha habido algún progreso en torno a BizDevOps, pero no lo suficiente como para que sea una realidad en todos los departamentos de TI de las empresas. El sistema de valor del servicio de ITIL podría proporcionar una capa sobre los entornos DevOps existentes para habilitar esta capacidad tan necesaria.
La mayoría de las herramientas DevOps de código abierto abordan las necesidades tecnológicas incompletas de los desarrolladores y el personal de operaciones, aunque algunos sistemas comerciales también intentan apuntar a la empresa. Pero estos sistemas, hasta la fecha, han tenido un éxito limitado, en parte porque los departamentos de TI, no la empresa, obtienen en gran medida las herramientas DevOps. Además, los equipos de TI aún sufren la percepción de estar algo alejados del resto de la organización, por lo que se muestran reacios a implementar y respaldar la interfaz comercial de tales herramientas.
ITIL, por otro lado, es nominalmente una herramienta de procesos de negocios, particularmente bajo ITIL 4. Corresponde a Axelos, la organización detrás del marco de trabajo de ITIL, hacer un esfuerzo para llevar ITIL a la empresa, como un medio para proporcionar los controles necesarios sobre la cadena de valor de principio a fin en toda la organización.
¿Qué hay de nuevo con ITIL?
Después de casi una década de silencio, Axelos finalmente presentó la versión 4 de ITIL a mediados de 2019. La actualización del marco de ITSM se basa en las pautas y mejores prácticas existentes, y se ajusta al cambio de paradigma de las operaciones en la nube, las aplicaciones distribuidas y DevOps. Pero también ofrece aclaraciones y correcciones sobre detalles en versiones anteriores. Además, ITIL se hizo menos prescriptivo y más flexible, lo que hace posible que más organizaciones adopten y se adhieran a estas mejores prácticas.
Será interesante ver si los proveedores de herramientas y los desarrolladores de código abierto comienzan a centrarse menos en las comparaciones de DevOps frente a ITIL y, en cambio, ven a este último como un marco no competitivo que crea una plataforma estandarizada en la que pueden trabajar. Si los equipos y proveedores de DevOps pueden integrar los conceptos y prácticas de ITIL en sus entornos, todos podrían ganar.
