Tres lecciones DevOps
Tres lecciones DevOps
30 años de experiencia resumidas en tres momentos de mi vida
A fines del año pasado fui invitado por mi amigo Juan Manuel Barrios (puedes escuchar una entrevista a él en este podcast) a dar una charla sobre DevOps.
La titulé “tres cosas que he aprendido en 30 años sobre DevOps”.
Este artículo es la versión en prosa de esa presentación.
Nota: este post se ve mejor en el navegador y es probable que tengas problemas al verlo en tu correo electrónico.
Lección 1: Más sabe el diablo por viejo…
A fines de 1994 estaba trabajando en un proyecto SCADA, subcontratado por Sonda para Cementos Bio Bio, este proyecto requirió mi visita por dos semanas a la planta automatizada en Talcahuano, para poder reproducir y reparar un fallo en el software.
La historia ya lo conté en mi blog, si les interesa está en este enlace. Lo importante para el contexto de esta charla es que en esa época programábamos este sistema en Microsoft Visual C++
Cuando programabas para Windows, Windows NT en nuestro caso, te encontrabas con un problema que se conocía como DLL Hell.
Eso significaba que probablemente en tu PC de desarrollo todo funcionaba, pero cuando instalabas tu programa en otro computador las cosas fallaban, porque alguna dependencia en alguna DLL específica ya no funcionaba como se esperaba, y tu programa dejaba de funcionar.
En la práctica este meme era cierto, y no todo era culpa tuya. Pero no podías decirle eso al cliente. El problema es que si arreglabas tu sistema, instalando las versiones de las DLL que tu programa requería, era casi seguro que otro programa dejaba de funcionar en esa máquina.
Ahora bien, en nuestra pequeña empresa preferíamos usar Borland Delphi:
Una característica que tenían lo programas en Delphi es que empaquetaban todo lo que necesitaban en un sólo gran archivo .exe, que era gigantesco, comparado con los generados por Visual C++, podía pesar varios megabytes, lo que en ese tiempo era mucho. Pero la gracia es que tu programa era autónomo y no dependía de que estuviera instalada determinada versión de alguna DLL específica.
Ahora un paréntesis. En ese tiempo nos volvimos distribuidores de los productos de Borland, junto con EXE, la empresa de mi amigo Ubaldo Taladriz.
En 1998 viajamos a Scott Valley, California para el lanzamiento de lo que serían Delphi 4 y Jbuilder 2
De hecho, todos los días nos pasaban un CD Rom con un build de estos productos, y durante la semana que estuvimos allá podíamos buscar bugs en el software, si encontrabas uno crítico te recompensaban con algunos cientos de dólares.
Los cuarteles generales de Borland eran hermosos, acá hay algunas imágenes del Campus Borland en Scott Valley:
Era un lugar pensado para quedarse allí todo el día, había de todo, casinos, oficinas de trabajo espectaculares, gimnasios, canchas de tenis, y para jugar basquetbol o futbol salón, lo que quisieran. Jaulas de oro para encerrar a jóvenes e incautos desarrolladores.
Allá en ese campus es que conocí el trabajo de Tara Hernández.
El fotograma es parte de la película Project Code Rush, que narra parte de la historia de Netscape y el nacimiento del proyecto Mozilla. Antes de trabajar en Netscape, Tara Hernández era ingeniero de integración continua en Borland y responsable de esas pantallas con cuadros rojos, amarillos y verdes que uno podía ver el algunas pantallas en los pasillo del Campus. Todas las noches se compilaba y se ejecutaban tests automatizados para probar la integridad del producto.
En el documental Code Rush se puede ver un servidor de integración continua usado por Netscape.
Pero volvamos a Delphi.
Delphi tenía esta ventanita:
Acá configurabas los paquetes de tiempo de ejecución que irían integrados a tu programa. Acá está en más detalle:
Esto era vital, así evitabas el DLL Hell, y podías entregar software de forma confiada. Esto lo aprendieron después los ingenieros de Microsoft por el simple expediente de que contrataron a los cerebros detrás de Delphi para que se fueran a trabajar en lo que años después se llamó .Net.
¿Qué cosas aprendí en los 90?
La importancia de entregar ambientes inmutables y autónomos.
Integración Continua
Lección 2: Granito a granito un zorzal se comió una vid
Este señor es Alistair Cockburn, creador de la arquitectura hexagonal, de la metodología Crystal Clear, y uno de los firmantes originales del manifesto ágil.
Lo importante es lo que dice esta lámina. Antes de lograr el éxito tendremos varios fracasos.
En 2011, mientras trabajaba en Previred, viajé a Boston a un Summit de RedHat. Acá me pueden ver visitando el bar Cheers, una referencia que nadie de la gen-z va a entender.
En esa conferencia tuve acceso a Openshift 1.0
Fue ahí que volví con la idea de lograr implantar los principios DevOps con mi equipo de desarrollo en Previred. Eso llevó con el tiempo a lo que documenté en mi tesis de magister
Y que se tradujo en un proceso de entrega continua
En 2011, cuando viajé a Boston éramos capaces de realizar unos 60 cambios en producción al año (un poco más de uno por semana). Para el 2018, tras un proceso de mejora continua, y paso a paso, llegamos a los 640 cambios al año.
¿Qué cosas aprendí en ese periodo?
La importancia de la entrega continua
Cómo implantar correctamente procesos ágiles
Lección 3: Lo que no te mata evoluciona y lo intenta de nuevo
Mucha gente cree que adoptar una tecnología es todo lo que se necesita para que las cosas funcionen. Pero quien haya trabajado de implantar DevOps sabe que no es fácil, y abordar el cambio cultural es vital. Pero no todos los entienden.
Llegó el Corona Virus en 2020 y todo combió.
Fue ahí cuando empecé a trabajar remoto, y cambió mi percepción del trabajo remoto. También ayudó que mis hijos mayores ya no estaban con nosotros y de repente nuestra casa tenía espacio para poder implementar una oficina.
Esta foto fue tomada en esa época. Así partió mi espacio propio donde trabajo, creo y a veces toco la batería. Yo lo llamo “La Rocinante”, ahora está mucho más producida y seguro les mostraré su evolución en algún futuro post.
La pandemia es uno de esos eventos que le encantan a Nicholas Taleb, un punto que pone a prueba a las personas y a las organizaciones. Es donde las más resistentes sobreviven, pero las anti frágiles innovan, prosperan y ganan.
En esa época, por razones que no viene al caso mencionar, me sentías así:
Así que adivinen que hice cuando vi este tweet:
Bueno, la respuesta está en mi respuesta. Me fui a Cornershop.
Y me convertí en arquitecto
Y ahí (re)descubrí que la entropía es el enemigo.
Consideren estas cifras, corresponden los cambios en trunk (main) de la base de código al día:
Previred: entre 0.4 a 2 🥵
Cornershop: 600 😎
Uber: 2.400 😳
Amazon: 54.000 🤯
Me enfrenté a una nueva realidad.
En esta parte de la presentación, cuando hablo de esto, inserto esta imagen:
Ya ni me acuerdo que quiero decir, pero tiene que ver con que estuve pensando en ese tiempo con que hay una suerte de secuencia principal por donde se mueven la mayoría de las empresas, porque la envergadura del problema que están solucionando se mueve dentro de ciertos parámetros típicos, tal como ocurre con las estrellas en el diagrama Hertzsprung-Russell. Pero hay otras empresas, como Uber, Google, o Amazon, las Big Tech en general que son como las gigantes rojas. Esto pensando en el tamaño de sus bases de código.
Es por este tiempo que elaboré lo que yo llamo Conjetura del tamaño del equipo:
Lo que dice estas expresiones es que el tamaño de tu equipo de desarrollo es proporcional a las lineas de código contenidas en tu base de código, de acuerdo a un factor que depende del lenguaje de programación. Estos datos están basados en bases de código a las que he tenido acceso en diversas empresas.
Esto es importante considerando que cada programador que agregas a tu equipo puede introducir entropía en esa base de código
Hay una ley, la Ley de Lehman de la entropía de software, de la que escribí en mi blog, que dice:
"Un programa que es usado sufrirá cambios continuos
o se volverá progresivamente menos útil."
— Ley de la Entropía de Lehman
Entonces los desarrolladores son esenciales, y a la vez la fuente de toda esa entropía.
Así que debes tener cuidado en cómo haces crecer y evolucionar tu equipo de tecnología. Para eso pueden ver una aproximación en esta charla dictada por Osvaldo Mena:
¿Qué aprendimos?
Las personas y su organización son relevantes
Bonus
Para cerrar la charla dejenme compartir algo más importante, que todo lo técnico.
Los 50 son los nuevos 30
Les voy a mostrar algunos cincuentones
"Like what you do, and then you will do your best" –– Katherine Johnson
En la película Hidden Figures aparece representada como más joven, ella tenía 34 años cuando empezó a trabajar en la NASA, en 1969, a los 51 años ayudó a calcular la trayectoria a la luna del Apolo 11.
"Programming is understanding" –– Joe Armstrong
Creador del lenguaje Erlang, a los 50 años documentó todo lo que hizo en Ericsson desarrollando sistemas distribuidos confiables y de alto desempeño, gracias a Erlang, y lo presentó como tesis doctoral, obteniéndola a los 53 años.
"It's one thing to fail with something you utterly believe in, but to fail with something you don't believe in? You just feel so sordid" –– Steven Wilson
Dijo que no se casaría nunca, porque su vida estaba dedicada totalmente a la música, uno de los más grandes y menos conocidos artistas contemporáneos, recién después de los cincuenta ha podido disfrutar de estadios llenos con su banda Porcupine Tree y está felizmente casado y criando dos hermosas niñas y componiendo cada vez mejor música.
Y yo qué he hecho estos últimos dos años
- 📚 he leído más de 80 libros (~1 x semana )
- 🤓 he dictado 8 cursos universitarios (3 en pregrado)
- ⌨️ he escrito más que nunca en mis blogs y newsletter
- 🎤 inicié un podcast capítulos hasta el momento
- 👨🏻💻 cerca de 1.500 commits ( ~ 15 x semana )
- 🏡 Y construí una casa en el campo (bueno...)
Y recorrido nuevos caminos
Así que les dejo con la última lección, que viene de uno de mis filósofos favoritos:
"La vida sólo puede ser comprendida mirando hacia atrás,
pero ha de ser vivida mirando hacia adelante."
— Soren Kierkegaard
Te falto a lo que has hecho la barba candado, "Mx style" jejeje.
Muy interesante la lección 2, justo estoy con mi equipo en una etapa de nuevos desarrollos y me sirve lo que comentaste para transmitirles a ellos, gracias !.