Cómo Uber migró miles de microservicios a una plataforma multicloud

• "Up: Microservicios portables listos para la nube"
• Uber despliega más de 4,000 veces por semana 4,500 microservicios stateless mediante 4,500 ingenieros y numerosos sistemas automatizados
• Estos servicios son desarrollados, desplegados y operados por cientos de equipos individuales que trabajan de forma independiente en todo el mundo
• Los servicios varían en tamaño, forma y función: algunos son pequeños y se usan para tareas internas, mientras que otros son grandes y se usan para cálculos en tiempo real a gran escala

Historia de los servicios stateless de Uber

• En 2014, Uber tenía un monolito escrito en Python que almacenaba datos en una sola base de datos PostgreSQL
• A medida que creció, contrató más ingenieros y migró a una arquitectura de microservicios
• A medida que aumentó la cantidad de servicios, Uber creó una herramienta llamada µDeploy para desplegar código de forma centralizada y a gran escala
  • Containerizó todos los servicios stateless y abstrajo la administración y colocación de hosts
  • Permitió que el grupo de infraestructura administrara la flota de hosts de manera independiente a los microservicios de las unidades de negocio
  • Pero la administración y colocación de servicios seguían siendo manuales
• La infraestructura de Uber sigue un modelo en el que grupos de zonas forman una región
• La latencia entre zonas dentro de una región es lo suficientemente baja como para que la comunicación síncrona entre servicios dentro de la misma región sea eficiente
• Cada zona puede ser un clúster de máquinas propiedad de Uber o de un proveedor de nube pública, pero una zona específica siempre pertenece a un solo proveedor
• En general, cualquier microservicio debería poder llamar a otros servicios sin problemas de latencia, siempre que estén dentro de la misma región
• µDeploy no centralizaba en el sistema la colocación geográfica de las cargas de trabajo, porque los ingenieros aún tenían que gestionar la colocación física a nivel de zona de disponibilidad
• Es decir, los ingenieros de servicio seguían teniendo que decidir no solo si ejecutar un servicio en una zona on-premise, sino también en qué zona específica ejecutarlo
• Al operar centros de datos on-premise, la escasez de chips y los problemas en la cadena de suministro alargaron los tiempos de entrega
• El 13 de febrero de 2023, Uber se asoció con Oracle y Google para reducir su exposición a los problemas de la cadena de suministro y diversificar
• Con miles de ingenieros de Uber desarrollando cientos de servicios distintos que respaldan el negocio, habría sido imposible ejecutar esta estrategia sin "un sistema que pudiera abstraer la infraestructura subyacente"

Prepararse para mover Uber a la nube

• Migrar 4,500 servicios stateless a la nube mientras el negocio seguía operando requería una enorme cantidad de coordinación y esfuerzo
• Desde el inicio quedó claro que esta tarea era propensa a errores y casi imposible de gestionar mediante esfuerzos manuales coordinados
• Para mantener y administrar microservicios stateless a gran escala, era necesario transformarlos para que un sistema centralizado de despliegue pudiera gestionarlos automáticamente sin intervención humana
• Más allá de Stateless: hacia la Portability
  • Con base en el modelo de regiones y zonas, idearon el concepto de "portabilidad"
  • La portabilidad se refiere a servicios que pueden ejecutarse en cualquier zona dentro de una región y que pueden ser movidos automáticamente a nuevas zonas por la plataforma de infraestructura sin intervención humana
  • Esto incluye moverse entre proveedores de nube pública, así como entrar y salir de zonas on-premise
  • Algunos servicios, por su dependencia de la configuración de zonas y de las preferencias de recursos por zona, normalmente no eran portables
  • Para realizar una migración automática a la nube, era necesario que todos los servicios fueran portables

Hacer portable a Uber

• A lo largo de 2021 y 2022, llevaron adelante un programa en toda la organización de ingeniería para asegurarse de que todos los servicios fueran portables
• En muchos casos, bastaba con inspeccionar el código para detectar violaciones a la portabilidad, por ejemplo revisando el uso de constantes de cadena y nombres de archivo
• Para los casos simples, escribieron reglas de linter que resaltaban código aparentemente hardcodeado para ejecutarse en ubicaciones físicas específicas
• Para probar si un servicio realmente era portable, tuvieron que moverlo efectivamente entre varias zonas sin intervención humana
• Construyeron un conjunto de herramientas de prueba para que los owners de servicio pudieran iniciar la primera migración de su servicio
  • Como se basaba en herramientas ya existentes para hacer rollouts de código seguros y graduales, los owners podían revertir el despliegue a la zona original en cualquier momento y corregir problemas si aparecían
  • Una vez que la migración se completaba con éxito, ese servicio quedaba marcado para moverse automáticamente en adelante
• En los años siguientes repitieron este proceso para todos los servicios de Uber y finalmente lo completaron por completo
• Tras terminar el trabajo, pudieron cambiar la topología de zonas sin intervención de los ingenieros de servicio
• Para garantizar que los servicios siguieran siendo portables con el tiempo, migran continuamente todos los servicios entre zonas cada pocas semanas y así prueban regularmente la capacidad de movimiento
• Esto permite detectar fácilmente regresiones, y con el tiempo los ingenieros se acostumbraron a no asumir una colocación específica por zona para sus servicios

Up: plano de control federado multicloud y multi-tenant

• Definieron los siguientes objetivos iniciales del sistema
  • Proveer un único punto de entrada para que los ingenieros interactúen con los sistemas de infraestructura
  • Administrar y aplicar mejores prácticas a los servicios desplegados directamente en el sistema, ofreciendo un alto nivel de seguridad durante los rollouts de código
  • Automatizar la colocación de servicios en zonas de disponibilidad; esto incluye cambiar los despliegues hacia nuevas zonas cuando estén disponibles y coordinar centralmente la colocación para respaldar la alta disponibilidad de Uber
  • Automatizar migraciones engorrosas a nivel de infraestructura para que los ingenieros de servicio no tengan que involucrarse en ellas
• Arquitectura de alto nivel
  • Experience Layer:
    • Implementa las distintas formas en que los ingenieros interactúan con el sistema
    • UI, Continuous Delivery, robots que mantienen el sistema en buen estado, etc.
    • Balancer, que mueve continuamente cargas de trabajo hacia clústeres y zonas con menor utilización
    • Auto Scaler, que optimiza continuamente la asignación de capacidad para cada carga de trabajo
  • Platform Layer:
    • Implementa las abstracciones que usa la capa Experience para interactuar con los servicios
    • Incluye las abstracciones de servicio y entorno de servicio que forman el modelo conceptual de operación del servicio, así como la propia API a nivel de servicio
    • En la capa de plataforma, las restricciones de servicio se expresan como un estado objetivo de alto nivel que describe las propiedades deseadas del despliegue real del servicio
    • Puede incluir restricciones sobre el rendimiento de las máquinas donde se ejecutará y sobre la capacidad total de cómputo por servicio y por región
  • Federation Layer:
    • Implementa la integración con los clústeres de cómputo
    • Organiza todos los clústeres según sus capacidades y ubicación física para implementar las abstracciones de región y zona usadas por las capas superiores
    • Toma el estado objetivo de alto nivel de los servicios desde la plataforma y lo traduce en colocación por zonas y clústeres; esta traducción se basa en las restricciones del estado objetivo y en el estado real de los clústeres, incluyendo la capacidad disponible en ese momento y los clústeres que pueden cumplir restricciones primarias y secundarias
    • El resultado de esta traducción puede cambiar con el tiempo, y más adelante puede resultar preferible otra colocación en zonas y clústeres
    • Todas las invocaciones del balancer y otras acciones iniciadas desde la capa Experience también pueden hacer que esta colocación se recalcule y cambie
    • Para mantener el sistema seguro y los servicios en buen estado, el componente de gestión de cambios implementa un flujo de rollout que modifica gradualmente el estado global mediante integración con todos los sistemas que monitorean la salud del servicio
    • El proceso de rollout incluye canarying a nivel de todo el sistema y monitoreo de señales de salud; si se detectan problemas, el sistema hace rollback rápidamente a la configuración y colocación previas al cambio
  • Regions
    • Las regiones contienen instancias reales de clústeres
    • Incluyen clústeres de Peloton y Kubernetes®
    • Estos están fuera de Up como tal, pero son los destinos de la colocación real de capacidad y administran la colocación de contenedores en hosts físicos

Efecto

• Comenzaron el trabajo en Up en 2018, entregaron un prototipo funcional a inicios de 2019 y lanzaron oficialmente la plataforma a mediados de 2020
• Desde entonces migraron más de 4,000 servicios de todas las líneas de negocio de Uber desde la plataforma de despliegue anterior hacia Up
• Como la mayor parte de esta migración fue automatizada, el equipo pudo concentrarse en los casos de uso más avanzados y también apoyar la migración de otros equipos
• Durante este período, la estabilidad de la plataforma fue la máxima prioridad, lo que permitió operar el negocio de forma estable en un contexto en el que millones de usuarios usan los sistemas de Uber cada día
• La migración completa de aproximadamente 2,000,000 de núcleos de cómputo hacia la nueva plataforma tomó cerca de 2 años y se completó con éxito en 2022
• Gracias a esta migración, devolvieron al negocio capacidad adicional valuada en decenas de millones de dólares mediante esfuerzos de autoescalado y eficiencia
• También lograron un ahorro significativo al evitar decenas de miles de horas de ingeniería antes dedicadas a actualizaciones manuales de servicios, configuración y llenado de nuevas zonas, y aprendizaje para navegar el complejo entorno de infraestructura de Uber

Qué sigue

• Tras completar la migración de µDeploy a Up, el equipo ahora puede enfocarse en construir soluciones que puedan aplicarse a toda la flota de servicios de manera centralizada y automatizada, así como en la experiencia de usuario alrededor de estas capacidades
• Migración a la nube
  • Uber está trasladando una parte importante de su flota a la nube
  • Gracias a la automatización a gran escala y a la capa de abstracción que ofrece Up, los equipos de servicio pueden alejarse en gran medida de los detalles de infraestructura requeridos para esta transición
• Continuous Delivery automatizado
  • Apuntan a automatizar por completo el despliegue de código hasta producción usando pipelines automatizados que ejecuten diversas verificaciones y pruebas antes de que el código llegue a producción
  • Un área específica en la que el equipo planeaba enfocarse en 2023 es mantener los servicios "actualizados", de modo que todo el código en ejecución en producción se mantenga al día con las últimas actualizaciones de seguridad y bibliotecas
• Seguridad del despliegue (Safety)
  • Los datos existentes muestran que una parte significativa de los incidentes observados está relacionada con cambios de código y configuración
  • Apuntan a reducir de forma importante la proporción de defectos que realmente llegan a producción automatizando aspectos manuales del ciclo de vida del servicio, como ejecutar pruebas previas a producción o definir políticas de rollout gradual
• Plataforma
  • Organizar toda la flota de servicios stateless de Uber bajo una sola plataforma paraguas permite modelar con mayor claridad las dependencias e interacciones entre productos de plataforma de infraestructura
  • Esto no solo permite ofrecer un modelo unificado en el código, sino también una experiencia de usuario completamente integrada para el resto de la organización de ingeniería
  • El siguiente gran objetivo del equipo es poder observar y operar toda la infraestructura desde un solo lugar

Conclusión

• El esfuerzo por construir la plataforma Up representa ahora un cambio cultural significativo, ya que todos los servicios stateless se despliegan gradualmente usando las mismas mejores prácticas y automatización
• Cambiar políticas de rollout o construir automatización para rollouts masivos de bibliotecas, tareas que antes requerían meses de trabajo, ahora es posible de forma centralizada
• Esperan seguir colaborando con los stakeholders de Up y los owners de servicio para alcanzar la visión de que los ingenieros de Uber puedan concentrarse únicamente en el código sin preocuparse por la infraestructura