El otro día estaba en modo curiosidad y me dió por investigar sobre micro-servicios. Estuve un rato leyendo sobre diseño de sistemas hasta que caí en el blog de Twitch.

Gracias a eso, hoy tenemos de que hablar 😂.

Voy a contarte como fue que Twitch pasó de una arquitectura monolítica a una arquitectura de micro-servicios.

Resulta que Twitch salió en Junio del 2011 y todo fue construido con Ruby on Rails. Tener un solo código fuente (un monolito) para el backend fue la decisión correcta porque les permitía iterar rápidamente sobre el producto.

Cuando la organización fue creciendo, habían muchas razones para dividir el código. Mario, Full Stack Engineer de Twitch, dice que estas son las principales:

Coordinación: Prevenir tener "muchos cocineros" dentro de la misma cocina.
Resiliencia: Reducir los daños cuando algo vaya mal.
Escalabilidad: Superar los cuellos de botella en el rendimiento.

Y justamente esta última razón fue la más importante.

En Twitch uno de los principales atractivos que hay es que puedes hablar en tiempo real con la persona que está en directo.

Para el 2010, cuando se comenzaron a hacer eventos de videojuegos, podían haber más de 20mil usuarios conectados al mismo tiempo (que para ese entonces era una locura) y entonces como todas las partes del sistema estaban en la misma aplicación todo colapsaba al mismo tiempo (La API, los videos, base de datos, chat, búsqueda, tienda, etc).

Aquí fue cuando comenzaron a hacer pruebas de concepto con diferentes lenguajes y herramientas.

Primero probaron mejorar la arquitectura usando Sidekiq y RabbitMQ, pero eso solo hacía el proyecto en Rails mucho más grande.

También intentaron extraer el sistema de chat e implementarlo en Node.js, pero esta tecnología aún estaba muy joven y tenía muchos bugs.

Finalmente seleccionaron Python con Tornado y entonces esa fue su primera implementación de un "micro-servicio" que en realidad aún no calificaba del todo como uno.

En 2012 el lenguaje de Go estaba ganando mucha popularidad y entonces crearon una herramienta interna que saturaba al navegador con mensajes para testear e identificar bugs en el sistema de chat. Aquí validaron que efectivamente Go estaba listo para ser usado en producción.

Y nace su primer micro-servicio. Utilizaron Go para reemplazar el servidor de intercambio de mensajes que tenían implementado hasta el momento.

A partir de aquí es que se vino la migración masiva a micro-servicios.

De Monolito a Micro-servicio

En el 2015 comenzaron toda una campaña interna para migrar el backend de Rails a Go. El nombre de la campaña fue "Wexit" 😂.

Todo se veía muy bonito en la teoría, pero muchas cosas salieron mal al dejar atrás el monolito:

Usar un único canal de despliegue para todos.
Uso de hojas de cálculo para coordinar los entornos.
Ejecutar Puppet en uno de los ambientes de producción para probar los cambios de infraestructura.
Esperar a compilaciones cada vez más lentas.
Luchando para rastrear errores hasta sus propietarios.
Enrutamiento lento debido a demasiados endpoints de API.
Consultas lentas a la base de datos.
Constantemente lidiando con merge conflicts.

¿Y cómo mantuvieron viva la plataforma mientras duraba la migración?

Hicieron una proxy con NGINX que se encargaba de dirigir el tráfico entre los controladores del viejo proyecto en Ruby y los controladores del nuevo proyecto en Go.

Entonces cada vez que necesitaban migrar algo, configuraban un nuevo proxy hasta acabar con el monolito.

Spoiler, les tomó años terminar la migración por completo.

Para finalizar

Lo que yo saco como conclusión de todo esto es que no hace falta comenzar con una arquitectura de micro-servicios si apenas estás comenzando una startup.

Pienso que la mejor forma de iniciar es tal cual como lo hizo Twitch. Comenzar con un único código base (un monolito) y entonces a medida que vaya creciendo la aplicación, vamos optimizando procesos.

Esa es la mejor forma de construir software. No hace falta hacer una arquitectura mega compleja desde el principio.

Recursos para ti

Voy a hacer un cambió para esta y las siguientes ediciones y es que voy a compartir los recursos diariamente vía Twitter y LinkedIn 😏.

3 Noticias para ti

Nos vemos en la edición #10

Espero que hayas aprendido con la experiencia de Twitch con los monolitos y los micro-servicios.

Recuerda que si quieres hablar de algo en particular puedes sugerir el tema respondiendo este correo.

Hasta pronto 👊🏼

Nicolás Leal.

#9 Rompiendo el Monolito con Twitch