¿Es difícil captar la esencia hablando de DevOps? Hemos reunido para ti analogías llamativas, frases impactantes y consejos de expertos que te ayudarán a llegar al fondo de la cuestión, incluso si no eres un especialista. Al final, un bono: el propio DevOps de los empleados de Red Hat.
El término DevOps surgió hace 10 años y ha recorrido el camino desde un hashtag en Twitter hasta convertirse en un poderoso movimiento cultural en el mundo de la TI, una verdadera filosofía que alienta a los desarrolladores a lograr resultados más rápido, experimentar y avanzar mediante iteraciones. DevOps se ha vuelto irreversiblemente asociado con el concepto de transformación digital. Pero como suele suceder con la terminología de TI, en una década DevOps ha acumulado numerosas definiciones, interpretaciones y malentendidos.
Por lo tanto, a menudo se pueden escuchar preguntas sobre DevOps como, ¿es lo mismo que Agile? ¿O es una metodología especial? ¿O simplemente es un sinónimo de ‘colaboración’?
DevOps abarca muchos conceptos diferentes (entrega continua, integración continua, automatización, etc.), por lo que puede ser difícil extraer lo principal, especialmente si te importa el tema. Sin embargo, esta habilidad es muy útil, no importa si intentas transmitir tus ideas a tu jefe o simplemente hablas sobre tu trabajo con familiares o amigos. Así que por ahora dejemos de lado los matices terminológicos de DevOps y enfoquémonos en el panorama general.
Qué es DevOps: 6 definiciones y analogías
Hemos pedido a expertos que expliquen la esencia de DevOps de la manera más simple y breve posible, para que su valor sea claro para lectores de cualquier nivel técnico. Como resultado de estas conversaciones, seleccionamos las analogías más destacadas y las frases impactantes que te ayudarán a construir tu relato sobre DevOps.
1. DevOps es un movimiento cultural
«DevOps es un movimiento cultural en el que ambas partes (desarrolladores de software y especialistas en operaciones de sistemas TI) reconocen que el software no aporta un valor real hasta que alguien comienza a usarlo: clientes, usuarios, empleados, no importa – considera Eveline Oehrlich, analista senior del Instituto DevOps. – Por lo tanto, ambas partes trabajan juntas para asegurar una entrega rápida y de calidad del software».
2. DevOps es lo que empodera a los desarrolladores
«DevOps empodera a los desarrolladores para que tengan control sobre las aplicaciones, su implementación y la gestión de la entrega de principio a fin»
«Normalmente se habla de DevOps como una forma de acelerar la entrega de aplicaciones en producción mediante la construcción y aplicación de procesos automatizados», dice Jai Schniepp, director de plataformas DevOps en la compañía de seguros Liberty Mutual. «Pero para mí, es algo mucho más fundamental. DevOps empodera a los desarrolladores para que tengan control sobre las aplicaciones o determinadas partes del software, su implementación y la gestión de la entrega de principio a fin. DevOps elimina la confusión sobre responsabilidades y guía a todos los participantes del proceso hacia la creación de una infraestructura automatizada y gestionada por el desarrollador».
3. DevOps es la colaboración en la creación y entrega de aplicaciones
«En términos simples, DevOps es un enfoque para la producción y entrega de software en el que todos trabajan juntos», señala Gur Staff, presidente y líder en la automatización de negocios digitales de BMC.
4. DevOps es una línea de producción
«La construcción en línea solo es posible si todas las piezas encajan entre sí».
«Compararía DevOps con una línea de ensamblaje de automóviles», continúa Gur Staff. «La idea es diseñar y fabricar todas las piezas de antemano para que luego puedan ensamblarse sin ajustes individuales. La construcción en línea solo es posible si todas las piezas encajan entre sí. Aquellos que diseñan y fabrican el motor deben considerar cómo fijarlo al chasis o bastidor. Los que fabrican los frenos deben pensar en las ruedas, y así sucesivamente. De la misma manera, debe ser con el software.»
Un desarrollador que crea la lógica del negocio o la interfaz de usuario debe considerar la base de datos que almacena la información de los clientes, las medidas de seguridad para proteger los datos del usuario, así como cómo funcionará todo cuando el servicio comience a atender a una audiencia tal vez incluso de millones de usuarios».
«Hacer que las personas colaboren y piensen en las partes del trabajo que realizan otros, en lugar de concentrarse exclusivamente en sus propias tareas, es el mayor obstáculo que hay que superar. Si se logra, tendrás excelentes oportunidades para la transformación digital», añade Gur Staff.
5. DevOps es la combinación adecuada de personas, procesos y automatización.
Jayne Groll, directora ejecutiva del Instituto DevOps, ofreció una analogía excelente para explicar DevOps. Según ella, «DevOps es como una receta de cocina, que tiene tres categorías principales de ingredientes: personas, procesos y automatización. La mayoría de estos ingredientes pueden ser tomados de otras áreas y fuentes: Lean, Agile, SRE, CI/CD, ITIL, liderazgo, cultura, herramientas. El secreto de DevOps, al igual que cualquier buena receta, radica en cómo se equilibran y combinan correctamente estos ingredientes para aumentar la velocidad y efectividad en la creación y lanzamiento de aplicaciones».
6. DevOps es cuando los programadores trabajan como un equipo de Fórmula 1.
«La carrera se planifica no de inicio a fin, sino al revés, de fin a inicio».
«Al hablar sobre lo que esperar de la iniciativa DevOps, cito el ejemplo de un equipo de carreras de NASCAR o de Fórmula 1», dice Chris Short, director de marketing de plataformas en la nube de Red Hat y editor del boletín DevOps’ish. «El líder de dicho equipo tiene un único objetivo: alcanzar la mejor posición posible al final de la carrera, teniendo en cuenta los recursos disponibles y los desafíos que se le presenten. Al mismo tiempo, la carrera se planifica no de inicio a fin, sino al revés, de fin a inicio. Primero se establece un objetivo ambicioso y luego se determinan las formas de alcanzarlo. Después, se desglosan en subtareas y se delegan a los miembros del equipo».
«Durante toda la semana antes de la carrera, el equipo perfecciona sus paradas en boxes. Se ocupa de entrenamientos de fuerza y cardiovasculares para estar en forma en el agotador día de la carrera. Practica la cohesión en la resolución de cualquier problema que pueda surgir en la carrera. De manera similar, el equipo de desarrollo debe entrenar las habilidades para realizar lanzamientos frecuentes de nuevas versiones. Con esas habilidades y un sistema de seguridad bien afinado, el lanzamiento de nuevas versiones a producción también ocurre con más frecuencia. Dentro de esta mentalidad, el aumento de la velocidad implica un aumento en la seguridad», dice Short.
«No se trata de hacer las “cosas correctas”, añade Short, sino de eliminar la mayor cantidad posible de obstáculos que se interponen en el camino hacia el resultado deseado. Colabora y adáptate según los comentarios que recibas en tiempo real. Esté preparado para las anomalías y trabaja para mejorar la calidad y minimizar su impacto en el avance hacia la meta. Eso es lo que nos espera en el mundo de DevOps».
Cómo escalar DevOps: 10 consejos de expertos
DevOps simple y DevOps a gran escala son cosas completamente diferentes. Te contaremos cómo superar las barreras del primero al segundo.
Para muchas organizaciones, el camino hacia DevOps comienza de manera fácil y placentera. Se crean pequeños equipos apasionados, los viejos procesos se sustituyen por nuevos y los primeros éxitos no tardan en llegar.
Lamentablemente, esto es solo un brillo falso, una ilusión de progreso, como dice Ben Grinnell, director gerente y líder del área de tecnologías digitales de la firma consultora North Highland. Las victorias iniciales, por supuesto, son prometedoras, pero no ayudan a alcanzar el objetivo final, que es la adopción masiva de DevOps en la organización.
Es fácil ver que, como resultado, se forma una cultura de separación entre “nosotros” y “ellos”.
«A menudo, las organizaciones inician proyectos pioneros, creyendo que abrirán el camino hacia un DevOps masivo, sin considerar si los demás querrán o podrán seguir este camino», explica Ben Grinnell. «Los equipos encargados de llevar a cabo estos proyectos suelen reclutar a “vikingos” auto-confiados que han realizado algo similar en otros lugares, pero que son novatos en su organización. A su vez, se les anima a romper y destruir reglas que siguen siendo obligatorias para los demás. Es fácil ver que, como resultado, se forma una cultura de división entre “nosotros” y “ellos”, lo que dificulta la transferencia de conocimientos y habilidades».
«Y este problema cultural es solo una de las razones por las que es difícil escalar DevOps. Los equipos de DevOps se enfrentan a un aumento de complejidades técnicas que son típicas de las empresas en rápido crecimiento que han apostado por la tecnología de la información», dice Steve Newman, fundador y presidente de Scalyr.
«En el mundo actual, los servicios cambian en cuanto surge la necesidad. Implementar y lanzar nuevas funciones constantemente es, por supuesto, excelente, pero coordinar este proceso y resolver los problemas que surgen es un verdadero dolor de cabeza», añade Steve Newman. «En organizaciones que crecen muy rápidamente, los ingenieros en equipos multidisciplinarios luchan por mantener la capacidad de rastrear cambios y sus efectos en cascada a nivel de dependencias. Además, a los ingenieros no les agrada perder esta capacidad, lo que hace que les resulte más difícil comprender la naturaleza de los problemas que surgen».
¿Cómo superar las dificultades descritas y avanzar hacia la adopción masiva de DevOps en una gran organización? Los expertos aconsejan tener paciencia, incluso si su objetivo final es acelerar el ciclo de desarrollo de software y los procesos comerciales.
1. Recuerde que los cambios culturales requieren tiempo
Jayne Groll, directora ejecutiva del Instituto DevOps: «En mi opinión, la expansión de DevOps debe ser tan gradual e iterativa como lo es el desarrollo ágil (y debe impactar de igual manera la cultura). En Agile y DevOps, se hace hincapié en equipos pequeños. Pero a medida que crece el número de estas integraciones, hay más personas aplicando nuevos métodos de trabajo, lo que resulta en una transformación cultural a gran escala».
2. Dedique suficiente tiempo a la planificación y selección de la plataforma
Eran Kinsbruner, evangelista técnico principal de Perfecto: «Para que la escalabilidad funcione, los equipos de DevOps deben comenzar aprendiendo a combinar procesos tradicionales, herramientas y habilidades, y luego cultivar lentamente cada fase de DevOps y estabilizarla. Todo comienza con una planificación cuidadosa de las historias de usuario y los flujos de creación de valor, tras lo cual llega la etapa de escritura de software y control de versiones utilizando desarrollo basado en trunk u otros enfoques más adecuados para la ramificación y fusión de código».
«Luego sigue la etapa de integración y pruebas, donde se requiere una plataforma escalable para la automatización. Aquí es crucial que los equipos de DevOps elijan la plataforma adecuada que se alinee con su nivel de habilidades y los objetivos finales del proyecto.
La siguiente fase es la implementación en el entorno de producción, y debe ser completamente automatizada utilizando herramientas de orquestación y contenedores. Es importante tener entornos virtualizados en todas las etapas de DevOps (simulador del entorno de producción, entorno de control de calidad y, propiamente dicho, el entorno de producción) y siempre utilizar los datos más recientes para las pruebas, de modo que se obtengan conclusiones actuales. La analítica debe ser inteligente y capaz de manejar grandes volúmenes de datos con retroalimentación rápida y efectiva».
3. Liberar la responsabilidad del sabor de la culpa
Gordon Haff, evangelista de RedHat: «La creación de un sistema y una atmósfera que permitan y fomenten los experimentos facilita la realización de lo que se llaman fracasos exitosos en el desarrollo ágil de software. Esto no significa que ya no haya responsabilidad por los fracasos. De hecho, identificar al responsable se vuelve incluso más sencillo, ya que 'ser responsable' ya no significa 'ser el culpable del accidente'. Es decir, la esencia de la responsabilidad cambia cualitativamente. En este sentido, hay cuatro factores que se vuelven cruciales: la magnitud del fallo, los enfoques, los procesos de producción y los incentivos». (Para más detalles sobre estos factores, se puede leer el artículo de Gordon Haff «Lecciones de DevOps: 4 aspectos de experimentos saludables».)
4. Limpia el camino adelante
Ben Grinnell, director general y líder del área de tecnologías digitales de la consultora North Highland: «Para lograr la escalabilidad, recomiendo lanzar junto con los proyectos pioneros un programa de 'limpieza del camino'. El objetivo de este programa es eliminar el desorden que queda tras los pioneros de DevOps, como normas obsoletas y otras cosas similares, para que el camino hacia adelante permanezca despejado».
«Brinda a las personas apoyo organizativo y genera impulso a través de una comunicación que va mucho más allá del grupo de pioneros, celebrando ampliamente los éxitos de los nuevos métodos de trabajo. Capacita a las personas que participan en la siguiente ola de proyectos de DevOps y que están nerviosas porque están utilizando DevOps por primera vez. Y recuerda que estas personas son muy diferentes a los pioneros».
5. Haz que las herramientas sean más democráticas
Steve Newman, fundador y presidente de Scalyr: «Las herramientas no deben ser ocultadas y deben ser relativamente fáciles de dominar para cualquiera que esté dispuesto a invertir tiempo en ello. Si la capacidad de solicitar registros se le otorga solo a tres personas 'certificadas' para trabajar con alguna herramienta, siempre tendrás un máximo de tres personas capaces de resolver el problema correspondiente, incluso si dispones de un entorno computacional muy grande. En otras palabras, se genera un cuello de botella que puede tener graves consecuencias para el negocio».
6. Crea las condiciones ideales para que el equipo trabaje
Tom Clark, líder del área de Common Platform en la televisión ITV: «Puedes hacer lo que quieras, pero no todo a la vez. Por lo tanto, establece grandes objetivos, comienza con pequeños pasos y avanza rápidamente en iteraciones. Con el tiempo, ganarás la reputación de ser un equipo que lo logra todo, lo que hará que otros también deseen adoptar tus métodos. Y no persigas la construcción de un equipo altamente efectivo. En su lugar, proporciona a las personas las condiciones ideales para trabajar y la efectividad llegará por sí sola».
7. No olvides la Ley de Conway y los tableros Kanban
Logan Daigle, Director de Entrega de Software y Estrategia DevOps en CollabNetVersionOne: «Es importante ser consciente de las implicaciones de la Ley de Conway. En mi interpretación libre, esta ley establece que los productos que creamos y los procesos que utilizamos, incluidos DevOps, están organizados de la misma manera que nuestra organización».
«Si en la organización hay un alto grado de fragmentación y durante la planificación, creación y entrega de software el control cambia de manos varias veces, el efecto de la escalabilidad será nulo o efímero. Por el contrario, si la organización forma equipos multifuncionales en torno a productos financiados con orientación al mercado, las posibilidades de éxito aumentan drásticamente».
«Otro aspecto importante de la escalabilidad es mostrar en los tableros Kanban todo el trabajo que está en proceso (WIP, trabajo en progreso). Cuando en la organización hay un lugar donde las personas pueden ver estas cosas, esto estimula enormemente la colaboración, lo que tiene un efecto positivo en la escalabilidad».
8. Busca cicatrices antiguas
Manuel Pais, Consultor DevOps y coautor del libro ‘Team Topologies’: «Llevar las prácticas DevOps más allá de Dev y Ops e intentar aplicarlas a otras funciones no se puede considerar un enfoque óptimo. Sin duda, generará ciertos efectos (por ejemplo, mediante la automatización de la gestión manual), pero se puede lograr mucho más si se comienza entendiendo los procesos de entrega y retroalimentación».
«Si en el sistema de TI de la organización hay cicatrices antiguas, es decir, procedimientos y mecanismos de gestión que fueron implementados a raíz de incidentes pasados pero que han perdido actualidad (debido a cambios en productos, tecnologías o procesos), ciertamente deben ser eliminados o suavizados, y no automatizar procesos ineficaces o innecesarios».
9. No generen variantes de DevOps
Antony Edwards, director de producción de Eggplant: «DevOps es un término muy ambiguo, por lo que cada equipo termina teniendo su propia versión de DevOps. Y no hay nada peor que tener 20 variantes de DevOps en una organización que no coexisten bien. No se puede permitir que cada uno de los tres equipos de desarrollo tenga su propia interfaz especial entre el desarrollo y la gestión del producto. Así como tampoco se puede permitir que los productos tengan sus propias expectativas únicas en cuanto al manejo de retroalimentación al trasladarse al simulador del entorno de producción. De lo contrario, nunca podrán escalar DevOps».
10. Prediquen el valor de DevOps para el negocio
Steve Newman, fundador y presidente de Scalyr: «Trabajen en el reconocimiento del valor de DevOps. Aprendan y no duden en hablar sobre los beneficios de lo que hacen. DevOps ahorra increíblemente tiempo y dinero (solo piensen: menos tiempos de inactividad, menor tiempo promedio de recuperación), y los equipos de DevOps deben enfatizar (y predicar) constantemente la importancia de estas iniciativas para el éxito del negocio. Así podrán expandir su base de seguidores y aumentar la influencia de DevOps en la organización».
BONUS
En El 13 de septiembre llegará nuestro propio DevOps; sí, en Red Hat, como fabricante de software, tenemos nuestros propios equipos y prácticas de DevOps.
Nuestro ingeniero, Mark Birger, quien trabaja en el desarrollo de servicios de automatización interna para otros grupos en toda la organización, contará su propia historia en un ruso claro: cómo el equipo de DevOps de Red Hat migró aplicaciones de entornos virtuales de Hat Virtualization, gestionados por Ansible, a un formato completamente contenedor en la plataforma OpenShift.
Pero esto no es todo:
Después de que las organizaciones trasladaron sus cargas de trabajo a contenedores, los métodos tradicionales de monitoreo de aplicaciones pueden no funcionar. En el segundo informe, explicaremos nuestra motivación para cambiar la forma de registrar y mostraremos la continuación del camino que nos llevó a los métodos modernos de registro y monitoreo.
Fuente: habr.com
