Sip, ese soy yo hace 20 años en la CampusMac 2004 – Madrid.

Desde hace unos meses he leído a figuras de la industria como David Hernimer Hanson (@dhh), Charity Majors (@mipsytipsy) o incluso Kelsey Hightower (@kelseyhightower) hablar sobre la explosión de complejidad y coste que han tenido soluciones basadas en nube y microservicios, y la necesidad de re-aprender sistemas más sencillos.

Pensando en sistemas más sencillos, recordé dos artículos, por una parte el de Serverless de hace unos meses y por otra parte el de mi servidor HTTP de hace más de 10 años, y pensé que sería interesante volver atrás y recordar cómo se hacía, probaba y distribuía software antes, basándome en mi experiencia personal y en lo que recuerdo de lo que fueron mis inicios por las redes. Acompáñame mi querido lector en esta pequeña máquina del tiempo.

Disclaimer: Este es un artículo de recuerdos, y la memoria tiene la mala manía de reconstruirse cada vez que recordamos, así que hay detalles que puedo haber confundido, pido perdón al lector de antemano.

2000 – 2007: Informática a nivel usuario

A lo largo de los 2000 mi experiencia fue más utilizando que creando, y mis días se iban copiando ficheros, escribiendo configuraciones, y equivocándome una y otra vez. Mi primer contacto con el desarrollo fue una web en GeoCities y lo siguiente que recuerdo es estar instalando y configurando PHPNuke y PostNuke, aprendiendo poco acerca de PHP, MySQL, o FTP usando Transmission, FileZilla, CuteFTP y otros. Como nota interesante, descubrí Mac, Linux con Mandrake y posteriormente con Ubuntu, llevandome por delante varios discos duros por mis pruebas.

Nuevas skills de personaje: FTP, copiar ficheros y cambiar permisos.

2008 – 2012: WordPress, Azure y Heroku

En 2008 tuve mi primer proyecto real, la oportunidad de convertir una web estática a una dinámica usando WordPress. Eso me permitió aprender algo de JavaScript, frameworks como Mootools y jQuery, maquetación con CSS con sistemas de grid, plugins y ficheros PHP. Mi aprendizaje fue mediante el mecanismo de prueba y error, hacer tests era algo que aún me quedaba por descubrir.

Por aquel entonces poner cosas en producción seguía siendo subir cambios vía FTP, encontrarme con una página en blanco cuando mi código de PHP fallaba (y fallaba mucho), y lo más parecido a control de versiones era el historial que, ya por aquella época, Dropbox daba a sus usuarios y que me salvó de más de un susto. El control de versiones llegaría a mi vida en verano de 2010, primero con SVN y luego con git.

A mediados de 2010 como parte de los programas de estudiantes de Microsoft tuve mi primer contacto con la nube. Azure era un portal hecho en Silverlight en el cual se subían las aplicaciones empaquetadas con Visual Studio a un entorno de pre-producción y que luego se cambiaba a producción haciendo click en un botón. Era la época de los despliegues vía interfaces de usuario y la consola no se veía por todo aquello. Para mis 20 años esto era pura magia y me faltaban muchas bases para comprender la importancia de lo que hoy es conocido como blue-green deployment.

Fuera del ecosistema Microsoft existía otro mundo, y crucé ese portal en 2011 cuando descubrí, a la vez, la combinación de un lenguaje de programación (Ruby), dos frameworks (Rails y Sinatra) control de versiones (Git) y el concepto de desplegar en «la nube» desde línea de comandos (Heroku). Esto suponía una diferencia abismal con C#, Visual Studio y las interfaces a las que estaba acostumbrado y me impactó mucho. Aunque seguí vinculado al mundo Microsoft, este descubrimiento me permitió ver más allá, aprendí que era posible publicar aplicaciones sin tener que usar FTP, y todo lo que aprendí de control de versiones hizo que entrar en PlasticSCM fuera un reto aún más entretenido.

Nuevas skills de personaje: PHP, Ruby, Git, Svn, blue-green deployments.

2012: El Mundo Real™

El 20 de agosto de 2012 entré en las oficinas de Boecillo de Codice Software, la pastilla roja me hizo abrir los ojos y descubrir cómo funcionaba el software que generaba dinero y pagaba nóminas, más allá de las demos, o como lo definía Pablo Santos, «tecnología para hacer hola-mundos».

PlasticSCM era por aquel entonces una máquina muy bien engrasada y por lo que me cuenta Pablo, siguió mejorando tras mi partida. Por aquel entonces el equipo trabajaba con el patrón «Rama por Tarea», y como parte de la definición de la tarea había que hacer tests (hacer código que ejecutaba el código que yo había creado y que validaba que el código que yo había hecho funcionaba como yo creía que lo había hecho. Piensa que es la primera vez que te lo dicen en tu vida…).

La magia continuaba cuando terminabas la tarea, la mandabas a revisar, lo que significa que otro miembro del equipo podía ver tus cambios (y darte algun que otro comentario, o muchos comentarios en mi caso), pero es que mientras tanto esos tests se ejecutaban automáticamente (wait, what?) en un servidor que teníamos al lado de la máquina de café. Hoy es obvio, pero hace 12 años había muy poca gente haciendo esto desde España con clientes como Samsung y la NASA.

Estas tareas se combinaban en un proceso manual que llevaba a cargo nuestro release manager Luis, (de ahí que le llamaramos cariñosamente las Reluises), que tras combinar las tareas existentes lanzaba un conjunto de tests (también automatizadas) que en este caso incluian tests de interfaz, para dar como resultado un binario que se subía a la web de PlasticSCM.

Nuevas skills de personaje: C#, Testing, revisiones de código.

2014: Entornos de integración

Mi siguiente parada en el proceso de aprendizaje fue haciendo una red social para científicos como parte de Frontiers y Loop. El desarollo se hacía en una copia local de la plataforma, y un entorno de integración por equipo.

La magia de estos entornos de integración es que, si teníamos 10 equipos, cada equipo tenía el suyo que desplegaba cambios constantemente, pero una vez por semana, nuestro equipo desplegaba los cambios en todos los otros entornos, si un equipo de Madrid estaba haciendo algo que rompiera un componente que se hacía en Laussanne, nos enterábamos a la hora de desplegar en el entorno de integración en vez de produción.

Estos despliegues tenían tests de integración y de interfaz de usuario con Selenium que se ejecutaban continuamente, y además teníamos un monitor (sí, una pantalla física) que nos decía en tiempo real cómo iban los tests y cuanto habían tardado.

Por esa época aún teníamos una división más visible entre desarrollo y operaciones, lo que hacía que personalmente tuviera poca visibilidad a cómo se desplegaban cambios y especialmente cómo se ponían las cosas en producción.

Nuevas skills de personaje: Integración continua, entornos de pre-producción.

2015 – Hoy: The age of DevOps

En un giro de los acontecimientos que nadie esperaba, en 2015 vi un Tweet de Nacho Robles que decía: First 10 digit palindrome in pi.com. Éra la época del Tuenti Challenge y pensé que sería divertido. Sin darme cuenta acabé, tras varios días, horas de entrevistas y varias llamadas por teléfono, con la posibilidad de entrar en Amazon, cambiar completamente de entorno y descubrir qué había al otro lado del espejo.

Lo que había al otro lado del espejo era… mucho. El código estaba distribuido a lo largo de miles de paquetes usando un sistema llamado Brazil, que actuaba a la vez como gestor de paquetes (npm, nuget) y como sistema de build (ant, gradle). De manera local, tanto en Mac como en Linux (y más tarde, en Windows) podíamos ejecutar el código y los tests y enviar nuestro código a revisar.

Una vez que el código estaba revisado, se combinaba a la rama principal (merge) y empezaba la magia, el código se volvía a compilar, se desplegaba en diferentes máquinas en diferentes regiones donde se ejecutaban tests de integración, de interfaz e incluso de carga, y finalmente poner el código en producción de manera automática y vigilar que los sistemas siguieran funcionando mediante alarmas.

Este sistema, llamado pipelines, era equivalente a sistemas comerciales como AWS CodePipelines o Github Actions. Como la automatización sin control no sirve de nada una de las características de este sistema era que permitía el uso de ventanas de tiempo, para poder desplegar en producción en horario de oficina, para permitir que el equipo pudiera estar disponible en caso de que hubiera problemas, y no desplegar fines de semana o festivos.

Todo esto ya estaba en funcionamiento hace 9 años. Desde entonces los sistemas se han ido mejorando y a su vez agregando complejidad. Leer más

Construir software a esta escala implica miles de piezas de código, cientos de personas y diferentes regiones del mundo, y aunque el proceso es complejo, a lo largo de estos años he visto varias iniciativas donde se busca mantener un balance entre complejidad y velocidad de ejecución, ya que la complejidad por si misma no agrega valor ni al equipo ni al usuario final.

Epílogo: Apreciar la belleza

Some people choose to see the ugliness in this world, the disarray. I choose to see the beauty.

Dolores Abernathy, WestWorld.

A lo largo de estos 20 años he visto como, paradójicamente, hacer software es cada vez más complicado y más seguro a la vez, he pasado de tirar abajo una web porque subí el fichero erróneo o incompleto via FTP a tener que revisar un despliegue en producción porque una alarma decía que el uso de CPU era demasiado alto tras un despliegue sin que hubiera un impacto visible para los usuarios.

He trabajado con software de diferentes escalas, he hecho aplicaciones de escritorio y móviles que dan para otro artículo, y me he equivocado constantemente. He visto lo difícil que resulta des-aprender y re-aprender algo y salir de tu zona de confort, y especialmente quitarte prejuicios de encima tras irlos acumulando a lo largo del tiempo, pero esto nos permite apreciar la belleza de lo diferente y nos hace mejores profesionales.

He tenido la suerte que mis años formativos han coincidido con un período de innovación increíble que me ha permitido ver el mundo como era entonces y como es ahora. Sin embargo me permite apreciar la belleza de aquellos tiempos donde todo era más simple y peligroso.

Por ello, querido lector, te animo a usar un cliente FTP y subir una web estática a un dominio, a instalar de manera local una copia antigua de un CMS o una instancia de mysql (sin Docker, a lo loco!), a crear tu propio servidor HTTP y en general a explorar los orígenes de lo que hoy es el desarrollo web y la integración continua.

Te garantizo que, después de equivocarte unas cuantas veces, aprenderás algo que no esperabas, que puede ser o sacarte una sonrisa, o, a la larga, convertirte en algo diferente, cruzar un espejo o tomar la pastilla roja.