Hemos escuchado muchas veces muchas historias relacionadas con migraciones a mejor con sistemas como Scala, Elixir, Erlang, Rust o Go por citar algunos, en muchos casos estas experiencias son fructíferas. Por ejemplo, en la página web de Erlang Solutions, bajo sus casos de estudio podemos encontrar la historia de Bleacher Report.
También puedes echarle un vistazo a esta conferencia (en inglés) de Peter Hastie, Levelling up at Bleacher Report.
No obstante, veremos también más adelante cómo la empresa fue obligada a transicionar a otra tecnología completamente diferente. No es un final feliz, me temo.
Ante todo y antes de lanzarte a leer la historia, te recomiendo que si quieres adentrarte y aprender más sobre Elixir o Elixir y OTP, aproveches la oportunidad y adquieras alguno de nuestros libros. Están escritos desde la experiencia, con muchos ejemplos y de forma clara y concisa.
El Camino hacia Elixir
La compañía Bleacher Report comenzó su andadura como una empresa que permite diseñar las noticias deportivas que cada usuario quiere recibir tan pronto como estén disponibles. De todo tipo de deportes, en EEUU, el desafío era muy alto y teniendo en cuenta que cada usuario podía definir su lista de noticias a su gusto el sistema debían filtrar las noticias para cada usuario antes de publicarlas o enviarles notificaciones.
El desafío era alto y su desarrollo comenzó en Ruby on Rails tal y como comentan en algunas conferencias. Tras esta etapa de lucha intentando escalar el sistema llegaron a Elixir. Todo son luces, no hay sombras e incluso con el soporte de consultores externos consiguen adaptarse y aprender a emplear esta nueva tecnología (algo diferente en verdad de Ruby y Rails) y pasan de tener cientos de servidores a tan solo unos 5 servidores.
La típica historia con final feliz que nos deja con una sonrisa justo antes de ir a dormir. Pero, esto solo fue el comienzo.
El cambio tras la pandemia
La pandemia de 2019 y que se convirtió en una parada completa de las actividades físicas y conjuntas entre 2020 y 2021 supuso una parada crítica en el sector de los deportes. Sin deportes, Bleacher Report no tenía información para hacer llegar a sus usuarios. La empresa Warner Media de la que formaban parte no obstante los tranquilizó, mientras fuesen parte de Warner Media no habría problema, no habría despidos.
De momento todo bien. Los programadores aprovecharon para programar nuevas características, publicar algunas bibliotecas como software libre y mejoras para Phoenix y Ecto. El sitio fue uno de los más confiables de Warner Media.
Sin embargo, llegó el drama.
Todo el Elixir debe morir
Warner Media apostó por Max, otra plataforma creada en Node.JS y se comenzaron a orquestar los despidos. El 50% de los ingenieros y el 100% de la gente de producto fueron despedidos. Los que quedaron tuvieron la tarea de convertir el código de Elixir a Node.JS.
La integración fue tan bien como se esperaba, es decir, mal. Cada intento de ir migrando cada parte de Elixir a Node.JS fracasaba y debían echar marcha atrás porque mientras los servicios estaban en Node.JS se degradaron muchas partes del sitio web. La gente de Warner Media no estaba dispuesta a aprender y por eso su ímpetu de reemplazar el lenguaje fue más allá y donde se consiguió convertir debían reemplazarlo con Node.JS y algunas partes con Rust.
La sentencia de Warner Media en aquel momento era: todo el Elixir debe morir.
La gran mayoría de ingenieros dedicados a la parte de Elixir lo vieron como una señal y comenzaron a abandonar la compañía. No había esperanza de futuro.
Tras varios años, Elixir aún no está muerto y las partes que sí cambiaron necesitaron de muchas herramientas y complejidad. Podemos decir que nadie pasó de Elixir y OTP felizmente.
Conclusiones
Keathly nos cuenta todo esto en Reddit en un hilo donde se pregunta si Bleacher Report está abandonando OTP. Es interesante ver este tipo de historias porque muchas veces, las historias de éxito no son lo suficientemente motivadoras como las historias de fracasos. En este caso, el sistema de Elixir y OTP funcionaba tan bien que fue y está siendo muy difícil suplantarlo manteniendo todas las características que este tiene con otras tecnologías. De hecho, varias personas atestiguan que la complejidad del sistema cambiado es peor.
¿Por qué se insiste entonces en cambiar algo que funciona? El problema radica en la sensación que crean los lenguajes que no están en el top 5 o top 10 del índice TiOBE. Si se emplean lenguajes pequeños o no tan conocidos se tienen la sensación de estar condenados a no encontrar personal para cubrir puestos, a tener gente irremplazable en algunas posiciones de la compañía y tener que pagar sueldos muy altos.
En realidad, esto puede suceder con cualquier tecnología, cualquier lenguaje y cualquier desarrollo. Si un programador oscurece su desarrollo hasta el punto de que sus compañeros no sepan qué es lo que realmente hay ahí, tendrás exactamente el mismo problema.
Además, Keathly reseña un hecho muy preocupante y común. En muchas grandes corporaciones los empleados que entran y se van quedando no resultan ser los mejores, sino los empleados a los que no les gusta el cambio, no les gusta aprender y por ese en Warner Media los empleados que tuvieron que hacerse cargo de Bleacher Report no consentían en aprender Elixir sino en cambiar ese código a su dominio, a sus lenguajes, incluso si eso no funciona.
Como solemos decir, si no está roto, ¡no lo toques!
