Cómo Airbnb creció al alejarse de un monolito

Engineer’s Codex es un boletín informativo sobre lecciones de ingeniería del mundo real. Cada semana, analizo ideas técnicas interesantes de empresas en una lectura de 5 minutos.

La semana pasada escribí sobre cómo Google escribe código limpio y mantenible.

Airbnb comenzó como un simple monolito de Ruby on Rails en 2008.

En 2018, Airbnb comenzó su migración a una arquitectura orientada a servicios, cuando el “monorriel” de Ruby on Rails comenzó a volverse difícil de mantener y se convirtió en un único punto de falla.

La principal diferencia entre SOA y microservicios tiene que ver con el alcance de la arquitectura.

En un modelo SOA, los servicios o módulos se comparten y reutilizan en toda la empresa, mientras que una arquitectura de microservicio se basa en servicios individuales que funcionan de forma independiente. (Fuente)

Si bien Airbnb no necesariamente necesitaba migrar a una SOA, lo eligió porque tenía sentido para sus necesidades organizativas.

En una reciente charla 2023esbozaron cuatro lecciones:

• Invierta temprano en infraestructura compartida

• Simplifique las dependencias del servicio

• Centralizar la hidratación de datos (obtención y transformación)

• Separe la lógica de la interfaz de usuario de la lógica del backend

En este artículo, resumo la charla y hago comparaciones de arquitectura con otras grandes empresas de tecnología, como Meta, Google y Uber.

Airbnb construyó una infraestructura común compartida por equipos de todos los servicios.

1. Marco API interno construido en Apache Ahorro

   1. Permitió que todos los servicios de Airbnb definieran API limpias y se comunicaran entre sí.

   2. El marco manejaba la comunicación entre servicios, la propagación de errores, las métricas de observabilidad y la validación del esquema.

   3. Los ingenieros podrían centrarse en implementar la lógica empresarial central.

   4. Facebook/Meta utiliza una versión interna personalizada de Apache Thrift llamada fbthrift, que tienen de código abierto.

   5. Google, Netflix, Square y otras empresas utilizan gRPC.

2. red eléctrica: Una biblioteca interna para ejecutar tareas en paralelo

   1. Ayudó a organizar el código en un gráfico acíclico dirigido (DAG), lo que permitió que las tareas se ejecutaran simultáneamente.

   2. Útil para tareas como validación y agregación de datos.

3. Un toque: Un marco construido sobre Kubernetes para gestionar servicios e implementarlos de manera eficiente.

   1. Se aseguró de que todas las configuraciones de servicio se administraran en un solo lugar.

   2. Proporcionó una herramienta de línea de comandos para implementar servicios en diferentes entornos.

   3. Google utiliza Borg como administrador de clústeres. Era un predecesor de Kubernetes. Google y Google Cloud se ejecuta en Borg.

   4. Facebook/Meta utiliza Twine para la gestión de clústeres.

4. Espinaquer: una plataforma de entrega continua de código abierto que facilitó flujos de trabajo seguros y repetibles para implementar cambios en la producción.

   1. Análisis canary automatizado destacado para garantizar implementaciones fluidas a escala.

   2. Análisis canario automatizado le permite implementar parcialmente un cambio y luego evaluarlo con respecto a la implementación actual para evaluar su rendimiento.

   3. Spinnaker fue creado en Netflix.

   4. Uber tiene una charla fantástica sobre Implementaciones seguras y rápidas a escala planetaria..

Al invertir en esta infraestructura común, Airbnb pudo acelerar su migración a SOA y cosechar los beneficios de una mayor confiabilidad y agilidad empresarial.

A medida que Airbnb siguió ampliando su arquitectura, el equipo separó los servicios en capas según las prioridades técnicas. Este enfoque ayudó a reducir la complejidad y garantizar que los servicios estables no dependieran de otros más volátiles.

Un servicio de nivel superior podría llamar a un servicio de nivel inferior, pero no al revés. Para hacer cumplir esta arquitectura de capas basada en topología, Airbnb introdujo bloques de servicio en la capa de plataformacada uno de los cuales contiene funcionalidades comerciales relacionadas.

Estos bloques encapsularon datos y lógica empresarial, ofreciendo una API simple y consistente a los clientes ascendentes. Este enfoque simplificó las dependencias de los servicios, lo que facilitó a los ingenieros descubrir y aprovechar la funcionalidad principal.

Hidratación de datos es el proceso de importar datos a un objeto.

Es una tarea común en los servicios de presentación, que implica buscar y fusionar datos de múltiples servicios posteriores.

Para agilizar este proceso y evitar la duplicación (¡que es costosa a escala!), Airbnb introdujo un capa de acceso a datos centralizada. Esta capa proporcionó un esquema GraphQL consolidado que unió diferentes entidades, como listados, usuarios y reservas, de varias fuentes de datos.

Al centralizar la lógica de hidratación y la obtención de datos, los ingenieros podrían centrarse en la innovación de productos en lugar de escribir el mismo código de hidratación de datos repetidamente.

La capa de acceso a datos también introdujo un enfoque declarativo para la recuperación de datos, lo que permitió a los ingenieros escribir consultas basadas en los datos que necesitaban, reduciendo posibles errores y mejorando la eficiencia.

Para garantizar una experiencia de usuario consistente y agilizar el desarrollo, Airbnb introdujo la App Framework, un sistema de interfaz de usuario unificado y basado en servicios. Este marco permitió a Airbnb presentar una API estandarizada a los clientes e impidió que los ingenieros reinventaran constantemente la rueda con sus propias API personalizadas.

El backend controlaba el contenido y el estilo de la interfaz de usuario dentro de cada sección de una página frontal renderizada. La interfaz era la principal responsable de renderizar cada sección.

El equipo dividió la interfaz de usuario en secciones estandarizadas, cada una con su modelo de datos y tipo de componente de la interfaz de usuario. Este enfoque proporcionó patrones claros de reutilización y personalización, lo que permitió a los equipos de productos lanzar nuevas funciones en todos los clientes sin versiones de aplicaciones móviles ni implementaciones de front-end.

Los datos de la interfaz de usuario se enviaron desde el backend.

Estandarizar la API orientada al cliente es una medida común para las empresas a medida que escalan. DoorDash también tuvo una excelente publicación sobre sus experiencias con la separación..

• Deshacer el trabajo es normal. Durante todo el proceso, Airbnb normalmente tuvo que deshacer el trabajo anterior. Si bien puede resultar doloroso eliminar el código, es importante mantenerse alejado de ello.

• Dividir los servicios permite a los equipos moverse a diferentes velocidades. En Airbnb, los equipos de frontend normalmente se movían más rápido que en otras áreas. El movimiento anterior permitió a cada equipo avanzar a su propio ritmo en lugar de ser retenido o impulsado por otro equipo.

• Haz el movimiento sólo cuando sea necesario. ¡Airbnb funcionó bien en un solo monolito Rails durante una década! Solo hicieron la migración a SOA después de que se volvió realmente doloroso continuar con el desarrollo en el monolito.

• Los microservicios son más para escalar organizaciones que para aplicaciones.

Compartir el códice del ingeniero