DevOps derriba ese muro

Quiero que imagines un muro. El muro se extiende completamente a la derecha y a la izquierda. Es más alto que tú, no puedes ver por encima de él y sabes que hay personas al otro lado, muchas. Pero no sabes si se parecen a ti. ¿Son enemigos o amigos?

Los desarrolladores creaban código y lo arrojaban por encima del muro a operaciones, y se convertía en el problema de operaciones.

Hacían simplemente lo que les parecía, sin preocuparse de verdad por la calidad del servicio.

Esos dos lados tienen trabajos casi opuestos, uno es hacer cambios y el otro oponerse a esos cambios tanto como sea posible.

Pero no hablan sobre lo que realmente están tratando de lograr.

Esto es Command Line Heroes en español, un podcast original de Red Hat. Episodio 4, DevOps derriba el muro.

Sí, durante décadas el mundo de TI estuvo definido por esa división de roles. Había desarrolladores por un lado. A ellos se los incentivaba a crear la mayor cantidad de cambios lo más rápido posible. Y luego estaba el equipo de operaciones por otro lado. A ellos se los incentivaba a evitar que hubiera demasiados cambios. Mientras tanto, el código se arrojaba a ciegas por encima de ese muro, sin empatía o comunicación real entre estos dos mundos. ¿Qué se necesitaría para derribar un muro como ese? Se necesitaría un cambio radical.

En el último episodio, vimos cómo las nuevas metodologías ágiles dieron preponderancia a las mejoras iterativas constantes, y esa necesidad de velocidad nos obligaría a cambiar la forma en que trabajamos entre nosotros. Hay un límite en cuanto a cuán rápido puede funcionar un grupo de personas aisladas y ese límite se volvió un problema porque…

Todo está en un tiempo de comercialización más rápido, mayor agilidad, más iteración y no en grandes obras a largo plazo.

Richard Henshall es líder de Red Hat Ansible Automation.

Recuerdo los días en los que ordenabas un servidor y aparecía cuatro meses después. Todo coincidía, así que la pila era todo una sola cosa y llevaba años que se diseñara y construyera. Eso ya no se usa y simplemente desapareció, hasta el punto de que simplemente es... “está activado, pruébalo y vuelve a desactivarlo”, para muchas organizaciones.

En la actualidad, una compañía como Amazon implementa un código nuevo varias veces por minuto. Imagínate intentar hacer eso utilizando un flujo de trabajo de desarrollo en cascada paso a paso. Es simplemente imposible. Pronto, las preocupaciones de operaciones sobre estabilidad, seguridad y confiabilidad se harían a un lado en favor de la velocidad.

Mientras tanto, los desarrolladores no percibían como su responsabilidad la de producir códigos que funcionaran en el mundo real. Los desarrolladores tenían poco interés en los temas de estabilidad y seguridad, pero esos son problemas muy reales que debemos abordar. Entonces, terminamos con muchas revisiones innecesarias a lo largo del proceso, un ida y vuelta a un lado y otro de esa división.

Piensa en cuánto puede ralentizar una compañía esa división. Piensa en cuán ineficiente podría llegar a ser. Pero rara vez se alentó a los desarrolladores a mirar más allá de su propia línea de comandos.

El tamaño de los directorios crecía y crecía, y nunca los limpiaban, a menos que les impidiera hacer cualquier trabajo.

Sandra Henry-Stocker es una sysadmin jubilada que escribe para las revistas IDG.

Con frecuencia discutía y decía: “Mira, estás usando todo este espacio en el disco. ¿No hay algo de lo que puedas deshacerte para que tengamos más espacio para trabajar? porque nos estamos quedando sin espacio en este servidor”. Y sí, pasamos por eso muchas veces.

En definitiva, es un problema de mentalidad. Esta actitud divisiva entre desarrolladores y operaciones, donde uno no tenía que entender las preocupaciones del otro. Bueno, en el pasado había estado bien, pero a medida que la velocidad ganaba importancia, esa cultura se volvió cada vez más inestable. Estar aislado en tu burbuja de trabajo era demasiado ineficiente.

Jonah Horowitz trabaja para el equipo de Fiabilidad de Sistemas en Stripe. Describe cómo, incluso si los desarrolladores y operaciones hubieran querido trabajar juntos, no hubiesen podido porque en un sentido los habían puesto en equipos contrarios.

Con frecuencia se evalúa al equipo de operaciones por tiempo de productividad y confiabilidad, y una de las mejores maneras de aumentar el tiempo de productividad es disminuir la cantidad de cambios en el sistema. Pero el lanzamiento de nuevas funciones está cambiando el sistema, y se incentiva a los ingenieros de software que trabajan en productos a que generen muchas funciones lo más rápido posible. Entonces se instaura este conflicto entre Dev y Ops cuando los roles están separados.

Desarrolladores comprometidos a crear funciones. Operaciones comprometidos a mantener el sitio funcionando. Dos objetivos en conflicto. Pero como dije, con la creciente necesidad de velocidad, de lanzamientos iterativos rápidos, esta desconexión entre desarrollo y operaciones estaba llegando a un punto crítico y algo tenía que ceder.

Alrededor de 2009, el muro que dividía Dev y Ops parecía más el muro de una prisión que otra cosa. Lo que necesitábamos era una nueva metodología que pudiera allanar la transición de desarrollo a operaciones, permitiendo que ambos trabajaran de manera más rápida y holística.

Patrick Debois, CTO de la plataforma Small Town Heroes, lanzó una conferencia para personas que querían derribar ese muro. Llamó a su ocurrencia DevOps Days. Lo acortó a DevOps para el hashtag y, así, el movimiento recibió un nombre.

Pero un nombre no es un proceso, estaba claro por qué se necesitaba DevOps, pero, ¿cómo funcionaría? ¿Cómo se supone que debemos integrar Dev y Ops sin iniciar una guerra? Afortunadamente, tengo a Scott Hanselman para que me lo explique. Scott es el gerente principal de programas de .NET y ASP.NET en Microsoft.

Entonces, Scott,

Quiero hablar contigo sobre la relación entre ser un desarrollador y cómo ha sido DevOps a lo largo de los años. ¿Cómo suena eso?

Me parece un buen plan.

Bueno. Creo que un buen punto de partida es simplemente definir qué es DevOps. ¿Cómo lo describirías?

La entrada de Wikipedia de 2008 que define a DevOps de hecho es muy buena. Es un conjunto de prácticas destinadas a reducir el tiempo entre hacer un cambio y que ese cambio pase a producción, garantizando la calidad. Entonces, si sucede que cargaste un código, y es martes y se implementará en el lanzamiento de junio, eso no está nada bien. No sería una integración continua. Sería una integración de un par de veces al año.

Si tienes un sistema DevOps bueno y saludable, si has realizado las prácticas de organización, estarás haciendo una integración continua con producción. Entonces, ¿qué puedes hacer? ¿Qué mejores prácticas puedes definir, puedes crear, que te permitan obtenerla? Digamos, cargué un código el martes y estará en producción el jueves. Ahora esta es la parte importante, pausa de suspenso, mientras se garantiza una alta calidad.

Lo que es realmente interesante acerca de esa definición es que es un conjunto de prácticas, pero cuando las personas hablan de DevOps, hablan como si fuera una labor, un puesto, un título. ¿Eso entra en conflicto con la idea de que es un conjunto de prácticas?

Cuando surge un nuevo conjunto de prácticas o nueva palabra de moda, a la gente le gusta ponerla en su tarjeta de presentación. Sin ánimo de ofender a los que están escuchando este podcast y ahora miran su tarjeta de presentación y dicen: “¡Qué mal!”. Y ahora van a, no sé, cerrar su computadora portátil, llenos de furia y abandonar este podcast.

Hubo un excelente hilo de Brian Guthrie, un trabajador muy esforzado, que se desempeñaba en SoundCloud. Una persona muy inteligente. Habló sobre DevOps y en este hilo de Twitter hace un tiempo dijo que DevOps es un conjunto de prácticas, punto. No es un puesto laboral. No es una herramienta de software. No es algo que uno instala. No es el nombre de un equipo.

La forma en que lo formuló fue: “No es un polvo mágico empresarial”. Si no tienes mejores prácticas, si no tienes buenas prácticas, no tienes DevOps. Así que, se trata más de una mentalidad que de crear un puesto laboral y decir: “Vamos a contratar ingenieros de DevOps y a esparcir estos ingenieros mágicos de DevOps por la organización, sin que la organización tenga voluntad organizativa ni que adopte la mentalidad que es DevOps”. Así que, si crees que es un kit de herramientas o algo que se instala, no has entendido.

Retrocedamos en el tiempo, antes de que DevOps fuera un término, de que tuviéramos DevOps en nuestras tarjetas de presentación o habláramos de ello como un conjunto de prácticas. Hace 10 años, ¿cómo describirías la relación entre los desarrolladores y la gente de operaciones?

Era una relación bastante combativa. La gente de operaciones controlaba la producción, y los desarrolladores nunca se acercaban a la producción. Estábamos en diferentes lados de un muroque no nos dejaba ver al otro lado. Nosotros, los de desarrollo, intentamos todo lo que pudimos hacer algo que se pareciera a producción, pero nunca... nunca se parece a producción.

Tuvimos algunos problemas. Teníamos entornos de desarrollo que no se veían ni se parecían a producción, entonces, inevitablemente sucedía esto de: “Oye, funciona diferente en producción que en desarrollo”. Y luego, la distancia entre que algo se aprobaba y que ingresaba a producción era de semanas y semanas, entonces ni siquiera podías pensarlo desde el lugar correcto. Porque trabajé en esa función en enero y recién se está implementando ahora en abril, entonces, cuando inevitablemente surja un error, no se solucionará hasta junio y ni siquiera recuerdo de qué estábamos hablando.

Así que le gente de operaciones, su trabajo era… Su trabajo era casi desacelerarnos intencionalmente. Prácticamente existían para que los desarrolladores fuesen más lentos y, por supuesto, sentían que queríamos interrumpir la producción todo el tiempo.

Entonces, ¿a qué se debía esto? ¿Era solo un gran malentendido de lo que los desarrolladores querían y estaban tratando de hacer? ¿Era un problema de confianza? ¿Por qué era tan combativo?

Creo que tú misma respondiste, diste en el clavo. Respondiste todo correctamente. Había un problema de confianza. Había una sensación, creo, de que los desarrolladores se creían especiales, o mejores que los de TI, y los de TI pensaban que los desarrolladores no tenían respeto por producción.

Creo que esa cultura venía de arriba, la idea de que éramos organizaciones diferentes y que de algún modo teníamos metas diferentes. Creo que se dio cierta madurez en el área de software, y todos nos dimos cuenta de que escribimos software para hacer progresar el negocio, sea cual sea el negocio.

Es decir, esa sensación de “Todos estamos avanzando en la dirección correcta”, como dicen, “todos tiramos para el mismo lado”. Pero definitivamente era un tema de confianza, porque los ingenieros de DevOps no confían en los ingenieros de productos para implementar, ¿verdad?

Y los ingenieros de DevOps tradicionalmente no escribían código, así que no entendían qué había cambiado. Por lo tanto, había una falta de confianza en todos los niveles. Y nadie comprendía el proceso de implementación y las personas confiaban solo en ellas mismas.

Entonces, si nadie comprendía realmente el sistema, la idea de un ingeniero full stack era como un mito. Pero ahora, comenzamos a pensar en el stack completo como una organización. Teníamos términos como propiedad completa del producto, y llegó la metodología ágil y dijo que todos debían apropiarse del producto, y el sentido de propiedad comunitario y la comunidad en torno al código lentamente cambiaron las cosas para generar un entorno de confianza.

Estás escuchando Command Line Heroes en español, un podcast original de Red Hat. Entonces, para que DevOps alcanzara su potencial, íbamos a necesitar mucha confianza en ambos lados, y eso significa mucha más comunicación. Volvemos con Richard Henshall. Él considera la empatía en ambas direcciones como la pieza fundamental de DevOps.

Algunos de los profesionales de DevOps, algunos de los que son realmente buenos, han desempeñado ambos roles. Creo que ahí es donde llega el verdadero poder, cuando las personas realmente pueden desempeñar ambos roles, en lugar de solo ver el otro lado. Entonces, no prolongas la separación… vas y ocupas el lugar del otro durante un período de tiempo. Creo que eso es lo que restituye la empatía.

Ahora, no se trata de comunicarse solo para hacer recuerdos agradables. Lo que Richard Henshall describe es que la industria gire hacia ese enfoque que mencionó Scott.

Un enfoque en la integración continua. El software no solo iba a escribirse y lanzarse en pequeños lotes rápidos, sino también a probarse en pequeños lotes rápidos. Y eso significaba que los desarrolladores necesitaban retroalimentación instantánea sobre el código que estaban escribiendo y cómo funcionaría en el mundo real.

A medida que el tiempo de lanzamiento al mercado se redujo de meses a días a horas, buscamos un nuevo conjunto de herramientas para automatizar cualquier elemento que pudiera automatizarse.

Hay muchas herramientas de monitoreo. Prometheus es una común. El token de seguridad STO para la orquestación de servicio está comenzando a interesarles a muchos, también está eso.

GitHub te permite realizar un seguimiento de los cambios. PagerDuty gestiona las operaciones digitales. El sistema de archivos de red (NFS) instala sistemas de archivos en una red. Jenkins te permite automatizar las pruebas en tu generación. Realmente necesitas un ecosistema completamente nuevo de herramientas para implementar DevOps con más eficacia.

Gordon Haff es un evangelista de la tecnología en Red Hat.

Lo que vemos es esta enorme colección de nuevos tipos de herramientas y plataformas que DevOps puede usar. Realmente todas salen del código abierto.

Gordon tiene razón. La colección de herramientas nuevas es enorme y también tiene razón sobre la perspectiva del código abierto. El crecimiento de las herramientas de automatización nunca habría sido posible en un sistema estrictamente exclusivo.

Tantas herramientas, tanta automatización. Como resultado, los desarrolladores pueden implementar cambios en el momento, la generación se hace automáticamente, se gestiona la compilación y se ejecutan pruebas automatizadas. Sandra Henry-Stocker describe el cambio que generó esto.

Podía tomar algo en lo que estaba trabajando e implementarlo rápidamente, y podía controlar muchos sistemas desde la línea de comandos de uno, en lugar de tener que trabajar en muchos lugares diferentes o preguntarme cómo haría para enviarlo a una red e implementarlo en muchas máquinas diferentes.

Básicamente, se volvió más fácil quedarse en un solo lugar, pero poder hacer cambios en una amplia variedad de sistemas informáticos.

Las herramientas de automatización habían resuelto el problema de la velocidad. Pero no elogiemos solo las herramientas olvidando la metodología.

Esas herramientas son casi como símbolos de nuestro cambio cultural. Nos animan a ampliar nuestros roles. Los desarrolladores han estado forzados a mirar, al menos ocasionalmente, desde la línea de comandos. De esa manera, las prioridades de Dev y Ops se alinean. De hecho, lo que ha dejado en claro el surgimiento de DevOps es que en un mundo cada vez más rápido, nadie puede permitirse permanecer aislado.

Jonah Horowitz ha trabajado para varias empresas del área de la Bahía de San Francisco, en Estados Unidos, entre ellas Quantcast y Netflix. Explica cómo incluso algunas de las compañías más grandes del mundo han reinventado su cultura a la luz de esto.

Hubo una especie de adopción cultural de parte de toda la compañía, fue como “Así es como implementaremos software. Lo haremos en pequeños lotes. Lo haremos utilizando estos procedimientos de implementación”. No creo que DevOps pueda... No creo que pueda ser exitoso si solo es impulsado por el equipo de operaciones.

Debe ser algo que la gerencia y el liderazgo de la compañía apoyen. Es en gran medida un cambio cultural.

Cuando MacKenzie encuestó a 800 directores de informática y ejecutivos de TI, el 80 % dijo que implementaban DevOps en alguna parte de su organización, y más de la mitad planeaba implementarlo en toda la compañía para 2020. Los ejecutivos están viendo que las herramientas de automatización aumentan la velocidad de entrega.

Son los mismos a los que no les molestaba que llegara un palé a un centro de datos y quedara allí por un mes entero antes de que se pusiera en marcha una máquina nueva. En la actualidad, si esperas más de 10 minutos para aprovisionar algo, estás haciendo algo mal. Con competidores que alcanzan velocidades como esa, nadie puede permitirse quedarse atrás.

Los equipos de operaciones se deben haber puesto nerviosos, entregando todas esas herramientas a los desarrolladores. En operaciones estaban acostumbrados a ser los adultos, ¿y ahora se suponía que tenían que entregar las llaves al auto? Uf… Los desarrolladores están aprendiendo a moverse rápido sin romper nada. Pero a medida que los ánimos se aquietan en la revolución de DevOps, los mayores cambios pueden ser para el equipo de operaciones.

¿DevOps realmente amenaza el rol de operaciones? ¿Dev está utilizando sus nuevas herramientas para devorarse a Ops? Cindy Sridharan es desarrolladora y escribió un extenso artículo de investigación sobre todo esto. En tu artículo y en tu publicación en el blog, mencionas que la gente de operaciones no estaba necesariamente satisfecha de cómo iban las cosas. ¿Qué estaba sucediendo? ¿Qué dirías?

Digámoslo así, el ideal de DevOps era que las responsabilidades se compartieran. Que hubiera un reparto más equitativo entre desarrolladores y operaciones para garantizar realmente la entrega holística del software.

Creo gran parte del descontento de los ingenieros, de los ingenieros de operaciones, surge del hecho de que esa no es realmente la realidad que se vive, les sigue tocando a ellos la parte más pesada. Siguen siendo ellos los que siempre hacen el trabajo rutinario. Siguen siendo los que asumen la responsabilidad de ejecutar las aplicaciones, y los desarrolladores no están precisamente haciendo lo suficiente.

La pregunta será crucial en los próximos años. ¿Cómo va a ser la operación DevOps? A medida que automatizamos, la función de operaciones ¿disminuye o se transforma?

Pero debemos recordar que DevOps no se trata solo de las herramientas y la aplicación de nuevas tecnologías. Esta metodología de hecho está moldeando la tecnología y, a su vez, la tecnología está moldeando la metodología. Es un increíble bucle de retroalimentación. La cultura hace las herramientas y las herramientas refuerzan la cultura.

Al final, ese muro que describimos al comienzo, el que divide Dev de Ops, quizás no tenga sentido para los desarrolladores en cinco años, y eso es genial.

El líder de automatización, Richard Henshall.

Creo que está comenzando a hacer que las personas entiendan mejor qué les preocupaba a los que están al otro lado de la ecuación. He visto mucha más comprensión.

Sysadmin, Jonah Horowitz.

Creo que escribir un software realmente bueno es un arte, y algo que veo en los mejores desarrolladores con los que trabajo es que verdaderamente impulsan hacia adelante el arte de la ingeniería de software o desarrollo de software.

Sysadmin, Sandra Henry-Stocker.

Creo que los desarrolladores se están volviendo mucho más astutos y mucho más cuidadosos. Tienen que mejorar sus habilidades constantemente, y sé que eso lleva mucho trabajo.

Resulta que sí había amigos al otro lado de ese muro. Encantada de conocerlos. Muchos desarrolladores podrían pensar que DevOps es aburrido, solo un montón de scripts de automatización rígidos y escalamiento de problemas. Pero después de escuchar estas historias, esperamos que veas que DevOps es más que sus herramientas. Es cómo podemos trabajar juntos para crear mejores productos más rápido.

Aquí está la buena noticia: a medida que desarrollamos nuevas plataformas para desarrolladores, el trabajo mejora, se vuelve más rápido y más adaptable a diferentes entornos. El círculo de interés también puede seguir ampliándose. Ves a personas ampliando DevOps para incluir seguridad, y obtenemos SecDevOps, o incluyendo negocios, y obtenemos BizDevOps. El debate que tendremos ahora es: ¿cuán importante es que los desarrolladores entiendan no solo cómo usar estas herramientas sino también cómo funciona DevOps, y cuán realista es esperar que comprendan ese nuevo mundo?

La forma en que entablemos ese debate definirá el trabajo de los próximos héroes de la línea de comandos.

Quizás hayas notado que en todo lo que hablamos sobre herramientas y automatización, dejamos afuera algo importante. Bueno, lo estamos guardando para la próxima vez, cuando toda esta automatización de DevOps alcance la velocidad de la luz y rastreemos el surgimiento de los contenedores.

Está todo en el episodio 5.

Command Line Heroes en español es un podcast original de Red Hat. Para suscribirte al programa, simplemente busca Command Line Heroes en español en Spotify, Apple Podcasts, Google Podcasts o donde sea que obtengas tus podcasts. Luego, haz clic en suscribirte para ser el primero en saber cuando hay disponibles nuevos episodios. Gracias por escucharnos y sigan programando.