DevOps no est\u00e1 muerto, ni siquiera est\u00e1 \u201cde parranda\u201c como dice la canci\u00f3n. DevOps evoluciona, eso s\u00ed, y las afirmaciones exageradas sobre su muerte (como le pasara a Mark Twain) suelen provenir de personas u organizaciones que tienen una visi\u00f3n sesgada o parcial de lo que significa DevOps. A veces, simplemente quieren \u201cvender\u201c algo.<\/p>\n\n\n\n
El origen de DevOps est\u00e1 en la b\u00fasqueda de la estrecha colaboraci\u00f3n entre las personas que realizan funciones de desarrollo y de operaciones. Esto no \u201cest\u00e1 superado\u201d. No podemos decir que hacemos DevOps de forma mayoritaria y por eso ahora estamos en la b\u00fasqueda de algo m\u00e1s. DevOps no est\u00e1 muerto, pero s\u00ed se ha aplicado con gran frecuencia de forma imperfecta y<\/strong>, sobre todo, parcial<\/strong>.<\/p>\n\n\n\n DevOps pone el foco en la colaboraci\u00f3n y los objetivos compartidos para reducir el tiempo a mercado sin comprometer la calidad de las soluciones<\/strong>. Para conseguir ese noble objetivo se precisa cambiar y evolucionar nuestra forma de trabajar en tres dimensiones principales:<\/p>\n\n\n\n DevOps tiene un componente tecnol\u00f3gico muy importante, pero no \u00fanicamente va de herramientas y automatizaci\u00f3n. Este es el anti-patr\u00f3n que con mayor frecuencia me he encontrado: organizaciones, equipos o personas individuales con una concepci\u00f3n err\u00f3nea de que DevOps es \u00fanicamente para la automatizaci\u00f3n de tareas, o \u201ctoil reduction\u201d como se expresa en ingl\u00e9s com\u00fanmente. Cuando esto suced\u00eda lo que he visto es que DevOps se convert\u00eda en otro silo m\u00e1s en el que se hab\u00edan \u201carrojado\u201d todas las tareas de automatizaci\u00f3n del ciclo de vida del software y las infraestructuras, oculto tras el \u201cmuro de la confusi\u00f3n\u201d que supone una herramienta de ticketing<\/em>.<\/p>\n\n\n\n Afortunadamente, el foco en la mejora continua<\/strong> que acompa\u00f1a a los principios de DevOps ha conseguido destilar nuestro conocimiento y experiencia acumulados todos estos a\u00f1os en un mejor entendimiento de lo que funciona y lo que no, y, en particular, que no se puede dejar de lado la transformaci\u00f3n de personas y procesos, al igual que no podemos dejar de lado la muy necesaria reducci\u00f3n del trabajo manual y repetitivo.<\/p>\n\n\n\n No podemos decir por tanto que DevOps \u201chaya fallado\u201d. Han existido y seguir\u00e1n existiendo transformaciones incompletas fruto de visiones imperfectas, pero tambi\u00e9n hay much\u00edsimas con un gran \u00e9xito lo que est\u00e1 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\u00f1as empresas de nicho o startups, sino de grandes corporaciones y multinacionales que han comprendido y aplicado DevOps en todas sus dimensiones transformacionales.<\/p>\n\n\n\n El futuro de DevOps es, por tanto, DevOps. Mejor comprendido, mejor aplicado, pero sigue siendo el mismo DevOps que naci\u00f3 espont\u00e1neamente en 2009.<\/p>\n\n\n\n Son m\u00faltiples las formas en que DevOps ha evolucionado desde aquel primer evento DevOpsDays en Ghent, con el subt\u00edtulo entonces novedoso que rezaba \u201cDev se encuentra con Ops, Ops se encuentra con Dev\u201d.<\/p>\n\n\n\n A continuaci\u00f3n, comparto una lista, no exhaustiva, de los temas y conceptos que en mi experiencia m\u00e1s han impactado positivamente a nuestra forma de entender DevOps:<\/p>\n\n\n\n En este art\u00edculo exploraremos en detalle el primero de estos puntos. En futuros art\u00edculos de esta serie profundizar\u00e9 en el resto de los aspectos y sus aportaciones a la evoluci\u00f3n de nuestro entendimiento de DevOps.<\/p>\n\n\n\n En los \u00faltimos a\u00f1os todos hemos visto la proliferaci\u00f3n de t\u00e9rminos del tipo DevXOps. P.ej. DevSecOps, DevQAOps, DevInfraOps, BizDevOps\u2026 Las motivaciones para esto pueden ser m\u00faltiples, pero en mi experiencia cuando alguien ha empleado ese t\u00e9rmino en una conversaci\u00f3n, presentaci\u00f3n o documentaci\u00f3n, ha sido para expresar que la \u201cX\u201d representa alg\u00fan elemento adicional, complementario, a la visi\u00f3n de DevOps.<\/p>\n\n\n\n En mi opini\u00f3n esto es innecesario ya que el termino DevOps, adem\u00e1s de sencillo y elegante, ya es completo de por s\u00ed.<\/p>\n\n\n\n Volvamos unos minutos al pasado, a la fundaci\u00f3n de DevOps. \u00bfC\u00f3mo? Exploremos el programa de la primera edici\u00f3n de la conferencia DevOpsDays [1]<\/a>. Metodolog\u00edas \u00e1giles en operaciones, behavior-driven development (BDD), pipelines de integraci\u00f3n continua, infraestructura como c\u00f3digo\u2026 Podemos ver c\u00f3mo el movimiento de acercamiento de Dev y Ops va m\u00e1s all\u00e1 de las funciones de programadores y operadores.<\/p>\n\n\n\n Unos a\u00f1os m\u00e1s tarde el libro \u201cThe DevOps Handbook\u201d, de los autores Gene Kim, Jez Humble, Patrick Dubois y John Willis, nos permit\u00eda profundizar en los principios fundacionales de DevOps. Ya desde la portada los autores nos lo dejan claro: \u201cc\u00f3mo crear agilidad, fiabilidad y seguridad de primera clase en organizaciones tecnol\u00f3gicas.\u201d<\/p>\n\n\n\n En definitiva: agilidad, calidad, seguridad y la ingenier\u00eda de las infraestructuras han estado presentes desde su fundaci\u00f3n en los principios de DevOps. No han surgido como un pensamiento posterior. \u00bfPor qu\u00e9 entonces existe esa necesidad de buscar un mejor DevOps con los, en mi opini\u00f3n superfluos, t\u00e9rminos DevXOps?<\/p>\n\n\n\n Podr\u00eda decirse que cuando alguien escribe DevSecOps es porque tiene la impresi\u00f3n equivocada de que DevOps no incluye la seguridad de manera impl\u00edcita, o que de forma an\u00e1loga cuando alguien escribe DevQAOps es porque piensa que la calidad no forma parte de DevOps de manera impl\u00edcita. Y s\u00ed, BizDevOps es un t\u00e9rmino que de forma redundante pretende indicar que \u201c\u00a1eh!, nosotros s\u00ed que contamos con el negocio\u201d. 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.<\/p>\n\n\n\n Dev representa al cambio<\/strong>: todas las funciones dentro de una organizaci\u00f3n que son necesarias para trasladar las ideas a software que funciona y est\u00e1 en manos de los usuarios finales.<\/p>\n\n\n\n Ops representa la estabilidad<\/strong>: todas las funciones dentro de una organizaci\u00f3n que son necesarias para asegurar que el software en producci\u00f3n es estable, fiable, operable y responde a las necesidades de los usuarios.<\/p>\n\n\n Dev quiere cambio \u2013 Ops quiere estabilidad<\/em><\/p>\n\n\n\n Para una organizaci\u00f3n que adopta los principios de DevOps esos objetivos no son contradictorios, ya que a ambos lados del imaginario \u201cmuro de la confusi\u00f3n\u201d 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\u00f3n que los sustentan.<\/p>\n\n\n Todos quieren soluciones y sistemas fiables y f\u00e1cilmente operables Siguiendo este razonamiento, Dev<\/strong> como abstracci\u00f3n debe incluir a las personas del negocio que trasladan ideas y requerimientos a especificaciones accionables y con criterios de aceptaci\u00f3n claros y concretos; ingenieros de software que desarrollan las aplicaciones; ingenieros de plataformas e infraestructuras que preparan la base s\u00f3lida sobre la que se ejecutar\u00e1n las aplicaciones; ingenieros de calidad que ayudar\u00e1n a que el software cumpla con la funci\u00f3n deseada y lo haga siguiendo buenas pr\u00e1cticas y est\u00e1ndares; 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\u00e1n los modelos de riesgos y posibles vulnerabilidades de las aplicaciones mientras se est\u00e1n creando.<\/p>\n\n\n\n Ops<\/strong> como abstracci\u00f3n entonces incluye a los ingenieros y operadores que mantienen las aplicaciones, plataformas e infraestructuras al d\u00eda (todas ellas actualizadas, escalables, observables) y respondiendo a situaciones an\u00f3malas antes de que produzcan impacto a los usuarios finales; ingenieros de plataformas e infraestructuras que analizan y mejoran el dise\u00f1o resiliente de los sistemas y que aplican pr\u00e1cticas como la ingenier\u00eda del caos para ir m\u00e1s all\u00e1 en la detecci\u00f3n de problemas de forma proactiva; ingenieros del centro de operaci\u00f3n de seguridad y redes (SOC, NOC, por sus siglas en ingl\u00e9s) que identifican posibles vulnerabilidades y detectan los intentos de intrusi\u00f3n, aplicando formas de remediarlo siguiendo estrategias claras definidas previamente; los desarrolladores que resuelven f\u00e1cil y r\u00e1pidamente problemas en el c\u00f3digo; as\u00ed como personas del negocio que miden, analizan y calibran el impacto que cambios espec\u00edficos o productos completos tienen sobre los usuarios finales y el negocio que desarrollan.<\/p>\n\n\n\n \u00a1Pues vaya! Al final resulta que en Dev y Ops no hay perfiles tan diferen\u2026\u2026 \u00a1Eso es! \u00a1Es porque est\u00e1n cerca unos de otros en todo momento!<\/p>\n\n\n\n Uno de los principios fundacionales de DevOps nos habla sobre derribar los silos organizativos<\/strong> y dar autonom\u00eda a los equipos de forma que sean multidisciplinares y con tanta independencia con el resto de la organizaci\u00f3n como sea posible. Se reduce la fricci\u00f3n entre roles porque todos los roles necesarios en el ciclo de vida de una soluci\u00f3n tecnol\u00f3gica colaboran de forma continua con objetivos compartidos<\/strong>: negocio, software, hardware, datos, calidad, seguridad\u2026 Sin silos, solo responsabilidades que cambian y se adaptan al momento del ciclo de vida.<\/p>\n\n\n\n Una manera genial de visualizar ese \u201cdramatis personae\u201d es el Extended DevOps Reality<\/em> ideado por Burr Sutter [2]<\/a>. Muy recomendable por su estilo y por su punto de atenci\u00f3n de que DevOps no es una funci\u00f3n separada; no es un silo adicional dentro de la organizaci\u00f3n. DevOps o lo somos todos o no lo somos ninguno. Y todos somos \u201ch\u00e9roes\u201d.<\/p>\n\n\n DevOps \u201cdramatis personae\u201d<\/em><\/p>\n\n\n\n Como conclusi\u00f3n de esta primera parte resaltar\u00eda 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\u00eda 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 \u00fanicamente en momentos puntuales del ciclo de vida (y normalmente demasiado tarde).<\/p>\n\n\n\n En futuros art\u00edculos de la serie continuar\u00e9 profundizando en otras ideas y conceptos que han llegado para mejorar nuestra visi\u00f3n de c\u00f3mo adoptar DevOps a escala y de forma efectiva en organizaciones tecnol\u00f3gicas de todos los tama\u00f1os e industrias.<\/p>\n\n\n\n Mientras tanto\u2026 sigamos la conversaci\u00f3n en redes.<\/p>\n\n\n\n Jorge Hidalgo es director de ingenier\u00eda 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\u00e9n responsable en Accenture globalmente de la comunidad de pr\u00e1ctica Java y Java Champion desde 2023.<\/p>\n\n\n\n Jorge cuenta con m\u00e1s de 25 a\u00f1os de experiencia en la industria, principalmente con tecnolog\u00edas Java, web, cloud, DevOps, agilidad y ciberseguridad. Adem\u00e1s de desarrollar su actividad profesional con clientes, es una figura activa en las comunidades tecnol\u00f3gicas, tanto como ponente en numerosos eventos locales e internacionales, como liderando la actividad de comunidades como M\u00e1laga JUG, M\u00e1laga Scala Developers y Boquer\u00f3nSec, as\u00ed como colaborando en la organizaci\u00f3n de eventos como OpenSouthCode o Codemotion.<\/p>\n\n\n\n https:\/\/deors.wordpress.com<\/a><\/p>\n\n\n\n https:\/\/x.com\/deors314<\/a><\/p>\n\n\n\n https:\/\/www.linkedin.com\/in\/deors<\/a><\/p>\n\n\n\n [1]<\/a> Devopsdays Ghent 2009<\/a><\/p>\n\n\n\n [2]<\/a> Extended DevOps Reality Images \u2013 Burr’s Developer Blog (burrsutter.com)<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"\n
\u00bfC\u00f3mo ha evolucionado, entonces, DevOps?<\/h2>\n\n\n\n
\n
DevOps y variantes DevXOps<\/h1>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/04\/devops-1-img-1-1-1024x292.png\")
<\/figure>\n<\/div>\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/04\/devops-1-img-2-1024x582.png\")
<\/figure>\n<\/div>\n\n\n
que resuelven las necesidades del negocio y de los usuarios finales<\/em><\/p>\n\n\n\n![\"devops\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/04\/devops-1-img-3.png\")
<\/figure>\n<\/div>\n\n\nConclusi\u00f3n de la primera parte<\/h2>\n\n\n\n
Sobre el autor<\/h3>\n\n\n\n
\n\n\n\n