Dropbox transforma su back-end con la plataforma sin servidor Atlas

En un proyecto de desarrollo, es esencial comenzar con una composición de código bien pensada lo antes posible. Esto es lo que Dropbox señala al final de una publicación de blog donde describe la arquitectura de software que sustenta su servicio de intercambio de archivos colaborativo en la nube. Esto evoluciona, en la parte de back-end, de un producto monolítico del lado del servidor llamado Metaserver y escrito en Python (que comprende más de 3 millones de líneas de código), a una plataforma de orquestación de servicios administrada. Este último, denominado Atlas, está diseñado para administrar pequeñas funciones independientes al proporcionar al equipo de desarrolladores de Dropbox una experiencia sin servidor al estilo de AWS Fargate.

Este proyecto a largo plazo fue lanzado el año pasado por el editor con el objetivo de reducir los enredos de código y liberar a los departamentos y sus equipos de ingeniería de estos enredos. Los intentos anteriores de mejorar Metaserver no tuvieron éxito debido al tamaño del código base y su complejidad. Por lo tanto, el proyecto implicó innovar tanto en la arquitectura, por ejemplo, al estandarizar en gRPC y usar la transcodificación gPRC TTP de Envoy, como en las operaciones, por ejemplo, mediante la introducción de autoescalado y pruebas canarias, explican los ingenieros de software de Dropbox en su publicación que extrae varias lecciones de la proyecto hasta la fecha.

El intento de una SOA

Inicialmente, el equipo de ingeniería intentó una arquitectura orientada a servicios (SOA) para evolucionar Metaserver. El objetivo era facilitar la gestión operativa de los servicios independientes en producción antes de construir servicios fuera del monolito y, en última instancia, dividir este último en pequeños servicios operados por diferentes equipos. El intento resultó arduo y largo y puso de relieve las dificultades que surgirían en la siguiente etapa. Por tanto, se volvió a evaluar el problema. "Descubrimos que las funciones del producto en Dropbox se pueden dividir en dos categorías amplias: sistemas grandes y complejos como la lógica para compartir un archivo y pequeñas funciones independientes como la página de inicio", dijeron los autores del ticket, Naphat Sanguansin y Utsav Shah. “Esto nos llevó a una conclusión importante: las pequeñas funciones independientes no requieren servicios administrados de forma independiente. Por eso construimos Atlas ”.

Para funciones pequeñas, no es necesario sobrecargar al equipo de productos con la planificación de la capacidad y la configuración de alertas, explican los ingenieros de Dropbox. Lo que estos equipos buscan principalmente es tener un lugar para escribir la lógica y ejecutarla automáticamente cuando un usuario llega a una ubicación determinada, y tener alertas automáticas básicas en caso de errores. “El código que envían al repositorio debe implementarse de manera consistente, rápida y continua. La mayor parte de la funcionalidad del producto entra en esta categoría, por lo que Atlas podría optimizarla ”. Por otro lado, los componentes grandes deben seguir siendo sus propios servicios, operados por equipos más grandes que gestionan de forma sostenible la salud de sus sistemas. Componentes con los que Atlas convive armoniosamente.

Un enfoque híbrido

Atlas es, por tanto, un enfoque híbrido. Proporciona la interfaz de usuario y la experiencia de un sistema sin servidor a los desarrolladores de productos de Dropbox, aprovechando los servicios de aprovisionamiento automático. “El objetivo de Atlas es brindar la mayoría de los beneficios de una arquitectura orientada a servicios, al tiempo que se minimizan los costos operativos asociados con la ejecución de un servicio”, resumen los autores del artículo. Dado que Atlas está administrado, los desarrolladores que escriben código simplemente definen la interfaz y la implementación de los puntos finales. Atlas luego se encarga de crear un clúster de producción para dar servicio a estos terminales. Es el equipo de la plataforma gestionada el que se encarga del seguimiento.

Resumen en 5 puntos, los beneficios esperados de Atlas son mejoras en la estructura del código, entrega de código independiente y consistente, reducción de tareas operativas, unificación de la infraestructura en componentes como gRPC (sin necesidad de reinventar la rueda) y, finalmente, la capacidad de aislar ciertas características, como la página de inicio. El post luego detalla el diseño técnico del proyecto: desglose de funcionalidades en componentes, orquestación, implementación operativa con la configuración automática de un pipeline de implementación para la producción de cada componente. En comparación con la magnitud de la tarea de reemplazar completamente Metaserver con Atlas, este proyecto se está completando en pasos más pequeños. Actualmente, Atlas sirve a más del 25% del tráfico del Metaserver anterior. “Hemos validado la migración restante en pruebas. Estamos en el camino correcto para abandonar Metaserver en un futuro próximo ”, concluye el equipo de ingenieros de software en su puesto.