Introducción
¡Qué cosas tiene el mundo de la tecnología! Tan joven, y en continua evolución, tan cambiante, que para muchas voces se hace necesario, casi compulsivo, el estar “matando” lenguajes, plataformas o metodologías cada pocos años.
Seguro que lo habéis escuchado antes: Cobol está “muerto”, Java está “muerto”, el Waterfall está “muerto”, incluso Agile está “muerto”. Y desde no hace mucho, para seguir con esta tendencia, he podido leer en varios lugares que DevOps está “muerto”.
DevOps no está muerto, ni siquiera está “de parranda“ como dice la canción. DevOps evoluciona, eso sí, y las afirmaciones exageradas sobre su muerte (como le pasara a Mark Twain) suelen provenir de personas u organizaciones que tienen una visión sesgada o parcial de lo que significa DevOps. A veces, simplemente quieren “vender“ algo.
El origen de DevOps está en la búsqueda de la estrecha colaboración entre las personas que realizan funciones de desarrollo y de operaciones. Esto no “está superado”. No podemos decir que hacemos DevOps de forma mayoritaria y por eso ahora estamos en la búsqueda de algo más. DevOps no está muerto, pero sí se ha aplicado con gran frecuencia de forma imperfecta y, sobre todo, parcial.
DevOps pone el foco en la colaboración y los objetivos compartidos para reducir el tiempo a mercado sin comprometer la calidad de las soluciones. Para conseguir ese noble objetivo se precisa cambiar y evolucionar nuestra forma de trabajar en tres dimensiones principales:
- Personas: estructura de equipos, roles y responsabilidades…
- Procesos: optimización de flujos de trabajo (lean), reducción de dependencias…
- Tecnología: automatización de tareas, re-arquitectura de soluciones…
DevOps tiene un componente tecnológico muy importante, pero no únicamente va de herramientas y automatización. Este es el anti-patrón que con mayor frecuencia me he encontrado: organizaciones, equipos o personas individuales con una concepción errónea de que DevOps es únicamente para la automatización de tareas, o “toil reduction” como se expresa en inglés comúnmente. Cuando esto sucedía lo que he visto es que DevOps se convertía en otro silo más en el que se habían “arrojado” todas las tareas de automatización del ciclo de vida del software y las infraestructuras, oculto tras el “muro de la confusión” que supone una herramienta de ticketing.
Afortunadamente, el foco en la mejora continua que acompaña a los principios de DevOps ha conseguido destilar nuestro conocimiento y experiencia acumulados todos estos años en un mejor entendimiento de lo que funciona y lo que no, y, en particular, que no se puede dejar de lado la transformación de personas y procesos, al igual que no podemos dejar de lado la muy necesaria reducción del trabajo manual y repetitivo.
No podemos decir por tanto que DevOps “haya fallado”. Han existido y seguirán existiendo transformaciones incompletas fruto de visiones imperfectas, pero también hay muchísimas con un gran éxito lo que está permitiendo a sus organizaciones avanzar en sus aspiraciones hacia un mejor tiempo a mercado y calidad en las soluciones. No hablamos tan solo de pequeñas empresas de nicho o startups, sino de grandes corporaciones y multinacionales que han comprendido y aplicado DevOps en todas sus dimensiones transformacionales.
El futuro de DevOps es, por tanto, DevOps. Mejor comprendido, mejor aplicado, pero sigue siendo el mismo DevOps que nació espontáneamente en 2009.
¿Cómo ha evolucionado, entonces, DevOps?
Son múltiples las formas en que DevOps ha evolucionado desde aquel primer evento DevOpsDays en Ghent, con el subtítulo entonces novedoso que rezaba “Dev se encuentra con Ops, Ops se encuentra con Dev”.
A continuación, comparto una lista, no exhaustiva, de los temas y conceptos que en mi experiencia más han impactado positivamente a nuestra forma de entender DevOps:
- DevOps y variantes DevXOps
- Continuous Delivery vs. Site Reliability Engineering
- La experiencia del desarrollador (Developer Experience, DevEx, o DevX)
- Plataformas internas para desarrolladores (Internal Developer Platforms)
- La ingeniería de plataformas (Platform Engineering)
- El ingeniero ‘E-shaped’ y qué significa ser Full-stack
En este artículo exploraremos en detalle el primero de estos puntos. En futuros artículos de esta serie profundizaré en el resto de los aspectos y sus aportaciones a la evolución de nuestro entendimiento de DevOps.
DevOps y variantes DevXOps
En los últimos años todos hemos visto la proliferación de términos del tipo DevXOps. P.ej. DevSecOps, DevQAOps, DevInfraOps, BizDevOps… Las motivaciones para esto pueden ser múltiples, pero en mi experiencia cuando alguien ha empleado ese término en una conversación, presentación o documentación, ha sido para expresar que la “X” representa algún elemento adicional, complementario, a la visión de DevOps.
En mi opinión esto es innecesario ya que el termino DevOps, además de sencillo y elegante, ya es completo de por sí.
Volvamos unos minutos al pasado, a la fundación de DevOps. ¿Cómo? Exploremos el programa de la primera edición de la conferencia DevOpsDays [1]. Metodologías ágiles en operaciones, behavior-driven development (BDD), pipelines de integración continua, infraestructura como código… Podemos ver cómo el movimiento de acercamiento de Dev y Ops va más allá de las funciones de programadores y operadores.
Unos años más tarde el libro “The DevOps Handbook”, de los autores Gene Kim, Jez Humble, Patrick Dubois y John Willis, nos permitía profundizar en los principios fundacionales de DevOps. Ya desde la portada los autores nos lo dejan claro: “cómo crear agilidad, fiabilidad y seguridad de primera clase en organizaciones tecnológicas.”
En definitiva: agilidad, calidad, seguridad y la ingeniería de las infraestructuras han estado presentes desde su fundación en los principios de DevOps. No han surgido como un pensamiento posterior. ¿Por qué entonces existe esa necesidad de buscar un mejor DevOps con los, en mi opinión superfluos, términos DevXOps?
Podría decirse que cuando alguien escribe DevSecOps es porque tiene la impresión equivocada de que DevOps no incluye la seguridad de manera implícita, o que de forma análoga cuando alguien escribe DevQAOps es porque piensa que la calidad no forma parte de DevOps de manera implícita. Y sí, BizDevOps es un término que de forma redundante pretende indicar que “¡eh!, nosotros sí que contamos con el negocio”. Debemos desterrar esas ideas preconcebidas y centrarnos en la manera simple y elegante en la que DevOps nos reta a hacer las cosas de forma diferente.
Dev representa al cambio: todas las funciones dentro de una organización que son necesarias para trasladar las ideas a software que funciona y está en manos de los usuarios finales.
Ops representa la estabilidad: todas las funciones dentro de una organización que son necesarias para asegurar que el software en producción es estable, fiable, operable y responde a las necesidades de los usuarios.
Dev quiere cambio – Ops quiere estabilidad
Para una organización que adopta los principios de DevOps esos objetivos no son contradictorios, ya que a ambos lados del imaginario “muro de la confusión” se persigue el mismo objetivo: sistemas que generan valor al negocio y a los usuarios finales; sistemas seguros, fiables, y que en definitiva pagan las facturas de toda la organización que los sustentan.
Todos quieren soluciones y sistemas fiables y fácilmente operables
que resuelven las necesidades del negocio y de los usuarios finales
Siguiendo este razonamiento, Dev como abstracción debe incluir a las personas del negocio que trasladan ideas y requerimientos a especificaciones accionables y con criterios de aceptación claros y concretos; ingenieros de software que desarrollan las aplicaciones; ingenieros de plataformas e infraestructuras que preparan la base sólida sobre la que se ejecutarán las aplicaciones; ingenieros de calidad que ayudarán a que el software cumpla con la función deseada y lo haga siguiendo buenas prácticas y estándares; expertos en datos que definan modelos adecuados para trasladar el dominio de negocio a las estructuras de datos adecuadas; o los analistas de seguridad que determinarán los modelos de riesgos y posibles vulnerabilidades de las aplicaciones mientras se están creando.
Ops como abstracción entonces incluye a los ingenieros y operadores que mantienen las aplicaciones, plataformas e infraestructuras al día (todas ellas actualizadas, escalables, observables) y respondiendo a situaciones anómalas antes de que produzcan impacto a los usuarios finales; ingenieros de plataformas e infraestructuras que analizan y mejoran el diseño resiliente de los sistemas y que aplican prácticas como la ingeniería del caos para ir más allá en la detección de problemas de forma proactiva; ingenieros del centro de operación de seguridad y redes (SOC, NOC, por sus siglas en inglés) que identifican posibles vulnerabilidades y detectan los intentos de intrusión, aplicando formas de remediarlo siguiendo estrategias claras definidas previamente; los desarrolladores que resuelven fácil y rápidamente problemas en el código; así como personas del negocio que miden, analizan y calibran el impacto que cambios específicos o productos completos tienen sobre los usuarios finales y el negocio que desarrollan.
¡Pues vaya! Al final resulta que en Dev y Ops no hay perfiles tan diferen…… ¡Eso es! ¡Es porque están cerca unos de otros en todo momento!
Uno de los principios fundacionales de DevOps nos habla sobre derribar los silos organizativos y dar autonomía a los equipos de forma que sean multidisciplinares y con tanta independencia con el resto de la organización como sea posible. Se reduce la fricción entre roles porque todos los roles necesarios en el ciclo de vida de una solución tecnológica colaboran de forma continua con objetivos compartidos: negocio, software, hardware, datos, calidad, seguridad… Sin silos, solo responsabilidades que cambian y se adaptan al momento del ciclo de vida.
Una manera genial de visualizar ese “dramatis personae” es el Extended DevOps Reality ideado por Burr Sutter [2]. Muy recomendable por su estilo y por su punto de atención de que DevOps no es una función separada; no es un silo adicional dentro de la organización. DevOps o lo somos todos o no lo somos ninguno. Y todos somos “héroes”.
DevOps “dramatis personae”
Conclusión de la primera parte
Como conclusión de esta primera parte resaltaría el mensaje de que es inconcebible pensar en DevOps sin que roles clave como negocio, calidad o seguridad formen parte fundamental del enfoque de productos y soluciones durante todo su ciclo de vida. Y resaltaría el contraste que eso supone con el modelo predominantes en organizaciones que no practican DevOps donde nos encontramos equipos de calidad o seguridad independientes y que participan únicamente en momentos puntuales del ciclo de vida (y normalmente demasiado tarde).
En futuros artículos de la serie continuaré profundizando en otras ideas y conceptos que han llegado para mejorar nuestra visión de cómo adoptar DevOps a escala y de forma efectiva en organizaciones tecnológicas de todos los tamaños e industrias.
Mientras tanto… sigamos la conversación en redes.
Sobre el autor
Jorge Hidalgo es director de ingeniería de software en Accenture, responsable de DevOps en Accenture Iberia y de la unidad de Arquitectura y plataformas cloud y DevOps en Accenture EMEA South Technology Center. Es también responsable en Accenture globalmente de la comunidad de práctica Java y Java Champion desde 2023.
Jorge cuenta con más de 25 años de experiencia en la industria, principalmente con tecnologías Java, web, cloud, DevOps, agilidad y ciberseguridad. Además de desarrollar su actividad profesional con clientes, es una figura activa en las comunidades tecnológicas, tanto como ponente en numerosos eventos locales e internacionales, como liderando la actividad de comunidades como Málaga JUG, Málaga Scala Developers y BoquerónSec, así como colaborando en la organización de eventos como OpenSouthCode o Codemotion.
https://www.linkedin.com/in/deors
[2] Extended DevOps Reality Images – Burr’s Developer Blog (burrsutter.com)
