¿Qué es Uber?
Uber es un servicio de transporte que emplea la web para todas las operaciones de
gestión, es también una aplicación con soporte para las grandes plataformas móviles como
iOS, Android y Windows Phone.
Su servicio provee de varios de modelos de negocio siendo la opción más económica el
UberX que destaca por su flota de Toyota Prius, además, está el Uber Black que es el
servicio original de la compañía, Uber LUX que es la opción más cara con automóviles
como el BMW 7 o el Porsche Panameras y el Uber SUV para viajar en vehículos de mayor
tamaño.
Cómo funciona Uber
MAHATHIR MOHD YASIN / [Link]
La aplicación es muy sencilla de usar, solo tienes que instalarla, darle los datos de tu tarjeta
de crédito, que es totalmente seguro, y seguir las siguientes instrucciones:
Gracias al GPS de tu Smartphone, la aplicación conoce tu localización y podrás verlo bien
claro en el mapa que te muestra junto con las localizaciones de los autos Uber más
cercanos a ti.
Tienes que entrar tu destino y luego solicitar un conductor que debe ser el más cercano a
ti.
Puedes ver en tiempo real el trayecto de tu chofer designado y el tiempo estimado de
llegada.
El chofer te lleva a tu destino sin tener que pagar en metálico, el costo del viaje te lo
descuentan de tu tarjeta de crédito junto con la propina.
Ventajas de Uber ante los taxis comunes
Prathan Chorruangsak / [Link]
Este tipo de servicio de transporte presenta grandes ventajas ante los taxis tradicionales
como:
Está reconocido por la excelencia de sus conductores, no ponen música alta en el vehículo,
no te cuentan su vida a través de la ventanilla ni discuten con el pasajero.
No tienes que gastarte los pulmones silbando para parar un taxi en la calle, con solo un
click lo puedes tener en la puerta de tu casa.
El chofer no pregunta a donde vas, solo te lleva.
Es mucho más económico que un taxi común, los vehículos son más limpios y el conductor
está certificado y registrado.
COMO FUNCIONA UBER
Nuestro servicio principal son los viajes a pedido, y la app posibilita que se le asignen
Socios Conductores a los usuarios para que lleguen a sus destinos. Conoce cómo funciona,
paso a paso:
PASO 1
El usuario abre la app
El usuario ingresa el destino en la casilla ¿A dónde vas? que se encuentra en la parte
superior de la pantalla, toca cada opción de viaje para ver el tiempo de espera, los tamaños
de los autos y los precios. Luego, confirma su punto de partida y toca Pedir.
PASO 2
Se le asigna un Socio Conductor al usuario.
Un Socio Conductor cercano ve el pedido de viaje y decide aceptarlo. Cuando está a un
minuto de distancia, el usuario recibe una notificación automática.
PASO 3
El Socio Conductor llega por el usuario
El Socio Conductor y el usuario verifican sus nombres y el destino. Luego, el Socio
Conductor inicia el viaje.
PASO 4
El Socio Conductor lleva al usuario a su destino
La app brinda al Socio Conductor la opción de acceder a indicaciones calle por calle para
que pueda concentrarse en llegar al destino, y el usuario, disfrutar de un viaje cómodo.
PASO 5
El Socio Conductor y el usuario califican el viaje y hacen comentarios
Al final de cada viaje, los Socios Conductores y los usuarios pueden calificarse
mutuamente con 1-5 estrellas. Los usuarios también pueden dar reconocimientos a los
Socios Conductores y agregar propina para expresar su gratitud.
Regístrate hoy
¿Estás listo para probar Uber? Pide un viaje como usuario o ponte al volante para generar
ganancias.
La app de usuario
Llega a donde quieres ir de manera fácil y confiable con solo tocar un botón. Elige la
opción de viaje que mejor se adapte a tus necesidades.
La app para Socios Conductores
Con Uber tú tienes el control. La app para Socios Conductores se diseñó con funciones que
te permiten decidir cómo, dónde y cuándo generas ganancias.
La Ingeniería detrás de Uber
Publicado el 28/11/2016 por excelencemanagement
El principio detrás de la compleja ingeniería de Uber se basa en algo que ya he comentado
en otras oportunidades en este mismo blog: ¿Cómo escalar a partir de una arquitectura
monolítica simple? ¿Cómo romper este esquema de trabajo para formar una arquitectura que
soporte grandes cantidades de datos y tráfico y además nos provea de seguridad?.
La respuestas a estas preguntas las abordé en detalle en mi tesis de Magister en la cuál realicé
un trabajo de investigación de las que en ese tiempo eran las principales plataformas de redes
sociales: Facebook, Twitter, Instagram, Flirck. Y aunque Uber no entra directamente en la
categoría de “red social”, usa los principios sociales y por supuestos los de ingeniería del
software para hacer que su plataforma tecnológica vaya creciendo de la mano de su modelo
de negocios.
La Arquitectura inicial monolítica de Uber:
Fuente: [Link]
Inicialmente Uber partió en la ciudad de San Francisco, California, teniendo todo su código
base y los repositorios diseñados para trabajar en esta parte geográfica del mundo, lo cuál les
permitía resolver los problemas de negocio de manera “sencilla”, lo que incluía: conectar a
los pasajeros con los transportistas, el sistema de pagos y facturación. Para cumplir con estos
requerimientos era razonable contar con toda esa lógica de negocios en un solo lugar, pero
en la medida en que comenzaron a expandirse a otras ciudades y agregar nuevas
funcionalidades, esto ya no era tan razonable.
En la medida en que los “domain models” comenzaron a crecer en conjunto con la adición
de nuevas características, los componentes se comenzaron a tornar ALTAMENTE
ACOPLADOS (recordemos que uno de los principios fundamentales de ingeniería de
software es mantener los componentes lo menos acoplados posible), y esto logró que la
encapsulación y la separación de intereses se tornara un trabajo difícil. Por lo tanto la tarea
primordial del equipo de ingeniería de Uber era encontrar una forma en que rápidamente se
pudieran integrar piezas de código al modelo de negocio; y acá es donde entra la integración
continúa.
¿Cómo lograr un buen escalamiento cuando tenemos diseñada nuestra plataforma para un
solo repositorio?
El cambio a SOA:
Uber decidió seguir el ejemplo de empresas como: Amazon, Twitter, Netflix, SoundCloud y
romper el esquema monolítico base para formar una arquitectura orientada a servicios
(SOA). En concreto, SOA puede significar una variedad de cosas distintas (como término,
algo que abordé en el artículo Distinguiendo entre SaaS y SOA), sin embargo Uber decidió
abordar SOA a partir del uso del patrón de microservicios. Para no inventar la rueda, voy a
recurrir a la genial explicación de Martín Fowler:
Una arquitectura monolítica pone toda su funcionalidad en un único proceso, y la forma en
que tiene de escalar (crecer) es agregando múltiples servidores.
Una arquitectura de microservicios pone cada funcionalidad (lo más atómica posible) en un
servicio separado, y la forma que tiene de crecer es distribuyendo estos servicios a través de
los servidores, replicando de acuerdo a las necesidades del negocio.
Cada servicio puede ser escrito en su propio lenguaje y puede o no tener su propia base de
datos.
Esto resuelve varios problemas, pero también aparecen algunos nuevos, los cuales están
clasificados en las siguientes áreas:
1. Obviousness
2. Safety
3. Resilience
PD: uso los términos en inglés porque a veces es difícil encontrar una correcta traducción al
texto sin que esto vaya en desmedro del contexto.
Obviousness:
Con más de 500 servicios, encontrar el servicio adecuado puede tornarse en una ardua
tarea. Toda vez identificado el servicio, la forma en que se utilizará este servicio no es tan
obvia, ya que cada microservicio tiene estructurado su propio camino. Los servicios que
ofrecen REST o RPC (donde es posible acceder a su funcionalidad dentro de su propio
dominio -lo que se conoce como stateless-), se caracterizan por ofrecer contratos débiles, y
en el caso de Uber, los contratos varían mucho entre microservicios. La adición de un
esquema JSON a una API REST puede mejorar la seguridad y el proceso de desarrollo contra
el servicio, pero no es trivial de escribir o mantener. Por último, estas soluciones no ofrecen
ninguna garantía con respecto a la tolerancia a fallos o la latencia. No hay manera estándar
para manejar los tiempos de espera del lado del cliente y las interrupciones, o garantizar que
una interrupción de un servicio no cause interrupciones en cascada. La capacidad de
recuperación global del sistema se vería afectada negativamente por estas debilidades. Como
un desarrollador escribió, “convertimos nuestra API monolítica en una API monolítica
distribuida”.
Se ha hecho evidente que necesitamos una forma estándar de comunicación que ofrezca la
seguridad de tipos, la validación y la tolerancia a fallos. Otros objetivos incluyen:
Formas sencillas para proporcionar bibliotecas de cliente
Soporte “Cross Language”
Tiempos de espera sintonizables con políticas de reintento
Desarrollo y Testing Eficiente
En esta etapa de nuestro hiper-crecimiento, los ingenieros de Uber continúan evaluando
tecnologías y herramientas para adaptarse a nuestras metas. Una cosa que sí sabemos es que
el uso del ya existente Lenguaje de definición de interfaz (IDL) que proporciona una gran
cantidad de herramientas pre-construidas desde el primer día es ideal.
Se evaluaron las herramientas existentes y encontramos que Apache Thrift (popularizada por
Facebook y Twitter) cumplió con nuestras necesidades. Thrift es un conjunto de bibliotecas
y herramientas para la construcción de servicios de lenguajes cruzados altamente escalables.
Para lograr esto, los tipos de datos y las interfaces de servicios se definen en un archivo es
agnóstico del lenguaje de programación. A continuación, el código se genera para abstraer el
transporte y la codificación de mensajes RPC entre los servicios escritos en todos los
lenguajes que usamos (Python, Node, Go, etc.)
Safety:
El argumento más convincente para Thrift es su seguridad. Thrift garantiza la seguridad de
la unión (binfing) de los servicios al utilizar contratos estrictos. El contrato describe cómo
interactuar con ese servicio incluyendo como llamar a los procedimientos de ese servicio, lo
que proporcionan entradas y salida de lo que se espera al momento de ejecutarlo.
La adhesión a un estricto contrato significa menos tiempo que se dedica a encontrar la manera
de comunicarse con un servicio y hacer frente a la serialización. Además, como microService
evoluciona no tenemos que preocuparnos acerca de las interfaces que cambian
repentinamente, y somos capaces de desplegar servicios de forma independiente de los
consumidores. Esta es una muy buena noticia para los ingenieros de Uber. Estamos en
condiciones de pasar a otros proyectos y herramientas desde Thrift resolviendo el problema
de la seguridad fuera de la caja.
Resilience:
Por último, nos inspiramos en la tolerancia a fallos y las bibliotecas de latencia en otras
empresas que se enfrentan a problemas similares, tales como Netflix que usa la biblioteca
Hystrix y de Twitter la biblioteca Finagle , para abordar el problema de la resistencia. Con
esas bibliotecas en mente, escribimos bibliotecas que aseguran los clientes son capaces de
hacer frente a situaciones de fallo con éxito (que se discutirá con más detalle en un próximo
post).
¿Hacia dónde se dirige Uber?
Claramente a mejorar la escalabilidad organizacional y proveer mayor resistencia y tolerancia
a fallos usando la arquitectura de microServicios. Ellos entienden que hasta este punto la
solución no es perfecta y requiere de cambios, desafortunadamente existen pocas
herramientas alternativas para Python y Node que son parte del stack de desarrollo de Uber
y se requiere de buena inversión de tiempo para construirlas. Lo interesante, es ver que si es
posible migrar un modelo monolítico a uno de mayor escalabilidad como SOA
(implementado a través de micro servicios) considerando la evolución de nuestro modelo de
negocios, ya lo ha hecho Facebook y Twitter en el pasado, y los chicos de Uber no quisieron
quedar fuera.
La misión de Uber es ser tan fiables como el transporte de agua corriente, en todas partes,
para todo el mundo. Para hacer esto posible, creamos y trabajamos con datos complejos.
Luego agrupamos muy ordenadamente la plataforma que permite a los conductores poder
conseguir que las empresas y los pilotos se desplacen.
Si bien queremos que la interfaz de usuario de Uber sea simple, diseñamos sistemas
complejos detrás de él para mantenerse, manejamos interacciones difíciles, y
servimos grandes cantidades de tráfico de datos. (Principio KISS)
Hemos roto la arquitectura monolítica original en muchas partes a escala con el crecimiento.
Con cientos de microservicios que dependen el uno del otro, dibujando un diagrama de cómo
funciona Uber en este momento es tremendamente complicado, y todo cambia rápidamente.
Lo que se puede cubrir en un artículo de dos partes es la pila que se utilizó para la primavera
de 2016.
Desafíos de la Ingeniería de Uber: No hay usuarios
gratuitos, Hyper crecimiento:
Tenemos los mismos problemas de escala global como algunas de las compañías de software
más exitosas, pero 1) estamos a sólo seis años de edad, por lo que no las hemos resuelto
todavía, y 2) Nuestro negocio está basado en el mundo físico en tiempo real.
A diferencia de los servicios freemium, Uber tiene solo los usuarios transaccionales: pilotos,
controladores y ahora los comedores y los mensajeros. La gente confía en nuestra tecnología
para poder hacer dinero, ir a donde tienen que ir, así que no hay tiempo para hacer una pausa.
Damos prioridad a la disponibilidad y escalabilidad.
A medida que nos ampliamos en las carreteras, nuestro servicio debe escalar. La flexibilidad
de nuestra pila fomenta la competencia por lo que las mejores ideas pueden ganar. Estas ideas
no son necesariamente únicas. Si existe una herramienta fuerte, la usamos hasta que nuestras
necesidades exceden sus capacidades. Cuando necesitamos algo más, construimos soluciones
internas. La Ingeniería de Uber ha respondido al crecimiento con gran capacidad de
adaptación, la creatividad y la disciplina en el último año. Para el 2016, tenemos planes aún
más grandes. En el momento en que usted lea esto, mucho habrá cambiado, pero esto es una
instantánea de lo que estamos usando ahora. A través de nuestras descripciones, esperamos
demostrar nuestra filosofía entorno al uso de herramientas y tecnologías.
El Stack Tecnológico de Uber:
En lugar de una torre de restricciones, como la imagen de un árbol. En cuanto a las
tecnologías en Uber, se ve una pila común (como un tronco de árbol) con énfasis diferentes
para cada equipo o en la oficina de ingeniería (sus ramas). Es todo hecho de la misma materia,
pero las herramientas y servicios florecen de manera diferente en diferentes áreas.
En pocas palabras: La plataforma:
Este primer artículo se centra en la plataforma de Uber, es decir, todo lo que le da el poder
más grande a la organización de la ingeniería de Uber, equipos de plataforma crean y
mantienen las cosas que permiten a los ingenieros para posteriormente construir otros
programas, funciones, y las aplicaciones que se utilizan.
Infraestructura y almacenamiento:
Nuestro negocio se ejecuta en un modelo de nube híbrida, usando una mezcla de proveedores
de la nube y múltiples centros de datos activos. Si un centro de datos falla, viajes (y todos los
servicios asociados con viajes) conmutación por error a otro. Asignamos ciudades para el
centro de datos más cercano geográficamente, pero cada ciudad se copian en un centro de
datos diferente en otra ubicación. Esto significa que todos nuestros centros de datos son los
viajes en todos los tiempos de funcionamiento; no tenemos noción de un centro de datos
como “copia de seguridad”. Para la provisión de esta infraestructura, se utiliza una mezcla
de herramientas internas y Terraform.
Las nubes híbridas combinan los modelos de nubes públicas y privadas. Un usuario es
propietario de unas partes y comparte otras, aunque de una manera controlada. Las nubes
híbridas ofrecen la promesa del escalado, aprovisionada externamente, a demanda, pero
añaden la complejidad de determinar cómo distribuir las aplicaciones a través de estos
ambientes diferentes. Las empresas pueden sentir cierta atracción por la promesa de una nube
híbrida, pero esta opción, al menos inicialmente, estará probablemente reservada a
aplicaciones simples sin condicionantes, que no requieran de ninguna sincronización o
necesiten bases de datos complejas. Se unen mediante la tecnología, pues permiten enviar
datos o aplicaciones entre ellas. Un ejemplo son los sistemas de correo electrónico
empresarial. [Link]
Nuestras necesidades de almacenamiento han cambiado con el crecimiento. Un ejemplo
sencillo de Postgres nos llevó a través de nuestra infancia, pero a medida que fue
creciendo tan rápidamente, fue necesario aumentar el tiempo de almacenamiento en disco y
la disminución de respuesta del sistema disponibles.
Actualmente usamos un modelo sin esquema (construido in-house en la parte superior del
stack de MySQL), Riak, y Cassandra. Sin esquema es para el almacenamiento de datos a
largo plazo; Riak y Cassandra se reúnen como plataforma de alta disponibilidad, y las
demandas de baja latencia. Con el tiempo, las instancias sin esquema reemplazaron instancias
individuales de MySQL y Postgres, y Cassandra reemplazó a Riak debido a la velocidad y el
rendimiento. Para el almacenamiento y análisis de datos complejos distribuidos, utilizamos
un almacén Hadoop. Más allá de estas bases de datos, nuestros ingenieros de Seattle se
centran en la construcción de una nueva plataforma de datos en tiempo real.
Utilizamos Redis tanto para el almacenamiento en caché y la puesta en cola. Twemproxy
ofrece escalabilidad de la capa de almacenamiento en caché sin sacrificar la tasa de aciertos
de caché a través de su algoritmo de hash coherente.
Logging:
Nuestros servicios interactúan entre sí y con los dispositivos móviles, y esas interacciones
son valiosas para usos internos como la depuración, así como los casos de negocios como
precios dinámicos. Para el registro, utilizamos varios clústeres Kafka, y los datos se archivan
en Hadoop y/o en un servicio web de almacenamiento de archivos antes de que caduque
Kafka. Estos datos también se ingiere en tiempo real por los diversos servicios e indexados
en una pila ELK para la búsqueda y visualización (ELK significa Elasticsearch, Logstash, y
Kibana).
App Provisioning:
Utilizamos contenedores Docker sobre Mesos para hacer funcionar nuestros microservicios
con configuraciones consistentes de manera evolutiva, con la ayuda de Aurora para los
servicios de larga duración y los trabajos de cron. Uno de nuestros equipos de infraestructura,
la plataforma de aplicaciones, produjo una biblioteca de plantillas que se basa en los servicios
de imágenes fáciles de enviar y acoplables.
Routing and Service Discovery:
Nuestra arquitectura orientada al servicio (SOA) hace que el descubrimiento de servicios de
enrutamiento sea crucial para el éxito de Uber. Los servicios deben ser capaces de
comunicarse entre sí en nuestra compleja red. Hemos utilizado una combinación de HAProxy
y Hyperbahn para resolver este problema. Hyperbahn es parte de una colección de software
de código abierto desarrollado en Uber: Ringpop, TChannel, y Hyperbahn todos comparten
una misión común para agregar la automatización, la inteligencia, y el rendimiento de una
red de servicios.
Los servicios legados utilizan instancias locales HAProxy para encaminar JSON sobre
peticiones HTTP a otros servicios, con el servidor front-end web Nginx a los servidores en
el extremo posterior. De esta forma bien establecida de la transferencia de datos hace que la
solución de problemas sea fácil, que era crucial a lo largo de varias migraciones a sistemas
recientemente desarrollados en el último año.
Sin embargo, estamos dando prioridad a la fiabilidad a largo plazo sobre la capacidad de
depuración (debuggability). Usando protocolos alternativos para HTTP (como spdy,
HTTP/2, y TChannel) junto con los lenguajes de definición de interfaz como Thrift y
Protobuf que ayudarán a evolucionar nuestro sistema en términos de velocidad y fiabilidad.
Ringpop, una capa de hash coherente, trae la cooperación y la auto-sanación (self-healing) a
nivel de aplicación. Hyperbahn permite que los servicios puedan encontrarse y comunicarse
con los demás de forma sencilla y fiable, así como los servicios se programan de forma
dinámica con Mesos.
En lugar del arcaico pooling para ver si algo ha cambiado, nos estamos moviendo a un patrón
de pub-sub (publicación de actualizaciones a los suscriptores). HTTP/2 y spdy permiten más
fácilmente este modelo de inserción. Varias características basadas en este “pooling” dentro
de la aplicación de Uber verán una tremenda aceleración de mover para empujar usando pub-
sub.
Development and Deploy:
Phabricator provee una gran cantidad de poder para poder manejar nuestra gran cantidad de
operaciones internas, a partir de la revisión de código hasta el proceso de la documentación
automatizado. Buscamos a través de nuestro código en OpenGrok. Para proyectos de código
abierto de Uber, desarrollamos utilizando GitHub para proyectos de código abierto y para el
seguimiento de problemas y revisiones de código.
Los ingenieros de Uber se esfuerzan por hacer que el desarrollo pueda simular el ambiente
de producción lo más cerca posible, por lo que desarrollan principalmente en máquinas
virtuales que se ejecutan en un proveedor de la nube o en el portátil de un desarrollador.
Construimos nuestro propio sistema de despliegue interno para gestionar las construcciones.
Jenkins hace la integración continua. Se combinaron Packer, Vagrant, Boto, y Unison para
crear herramientas para la construcción, gestión y desarrollo de las máquinas virtuales.
Utilizamos Clusto para la gestión de inventarios en el desarrollo. Puppet gestiona la
configuración del sistema.
Trabajamos constantemente para construir y mantener canales de comunicación estables, no
sólo para nuestros servicios, sino también para nuestros ingenieros. Para el descubrimiento
de información, construimos uBlame (un guiño a git-blame) para realizar un seguimiento de
qué equipo es propietario de un determinado servicio, y Whober para buscar nombres, caras,
información de contacto, y la estructura organizativa. Utilizamos un sitio de documentación
interna que auto construye documentos contactándose con repositorios utilizando Sphinx. Un
servicio empresarial de alerta a nuestros ingenieros de guardia para mantener los sistemas en
funcionamiento. La mayoría de los desarrolladores ejecutar OS X en sus computadoras
portátiles, y Linux la mayoría de nuestros casos de producción se ejecutan con Debian Jessie.
Languages:
En los niveles más bajos, los ingenieros de Uber escriben principalmente en Python, [Link]:
Go, y Java. Comenzamos con dos lenguas principales: [Link] para el equipo del mercado,
y Python para todos los demás. Estas primeras lenguas todavía alimentan la mayoría de los
servicios que se ejecutan en Uber hoy.
Adoptamos Go y Java por razones de alto rendimiento. Proporcionamos soporte de primera
clase para los lenguajes. Java se aprovecha del ecosistema de código abierto y se integra con
las tecnologías externas, como Hadoop y otras herramientas de análisis. Go nos da eficiencia,
simplicidad y velocidad de ejecución.
Nosotros sustituimos el viejo código Python mayor dado que el objetivo es romper el código
base original en microservicios. Un modelo de programación asíncrona nos da un mejor
rendimiento. Utilizamos Tornado con Python, pero el soporte nativo de Go, para la
concurrencia es ideal para la mayoría de los nuevos servicios de rendimiento crítico.
Escribimos herramientas en C y C ++ cuando es necesario (como por alta eficiencia, código
de alta velocidad a nivel del sistema). Utilizamos software que está escrito en los lenguajes
de HAProxy, por ejemplo-, pero en su mayor parte, no trabajamos en ellos.
Y, por supuesto, los que trabajan en la parte superior de la pila de escritura en las
lenguajes más allá de Java, Go, Python, y Node.
Testing:
Para asegurarnos de que nuestros servicios pueden manejar las demandas de nuestro entorno
de producción, hemos desarrollado dos herramientas internas: Tormenta de granizo y
uDestroy. Tormenta de granizo impulsa las pruebas de integración y simula la carga máxima
fuera de las horas pico, mientras que uDestroy rompe intencionadamente cosas por lo que
podemos mejorar en el manejo de fallos inesperados.
Nuestros empleados utilizan una versión beta de la aplicación para poner a prueba
continuamente nuevos desarrollos antes de que lleguen a los usuarios. Hicimos un reportero
de comentarios sobre la aplicación de atrapar cualquier error antes de que llegue a los
usuarios. Cada vez que se toma una captura de pantalla de las aplicaciones Uber, esta
característica nos lleva a presentar una tarea de corrección de errores en Phabricator.
Fin…
No pude traducir el artículo completo por cuestiones de tiempo, pero eso si, traté de
centrarme en las cosas importantes (una parte en realidad) y en el stack tecnológico, que creo
podrá darnos algunas buenas pautas para que aprendamos como escalar a partir de una
arquitectura monolítica. Estos temas son relevantes para quienes desean formarse como
arquitectos de software. Conocer de tecnología es de hecho una habilidad dura que debiese
correr por las venas de quienes deseen formarse en este interesante (y hermoso) mundo. En
la siguiente parte espero poder hablar más acerca de los asuntos relacionados con las app
móviles y como interactuar en tiempo real cuando nos enfrentamos al problema geográfico,
como distribuir la arquitectura lógica del software en capas que ayuden en parte a ir
resolviendo estos problemas. Espero les sea de utilidad… Nos vemos!
El principio detrás de la compleja ingeniería de Uber se basa en algo que ya he comentado
en otras oportunidades en este mismo blog: ¿Cómo escalar a partir de una arquitectura
monolítica simple? ¿Cómo romper este esquema de trabajo para formar una arquitectura
que soporte grandes cantidades de datos y tráfico y además nos provea de seguridad?. La
respuestas a estas preguntas las abordé en detalle en mi tesis de Magister en la cuál realicé
un trabajo de investigación de las que en ese tiempo eran las principales plataformas de
redes sociales: Facebook, Twitter, Instagram, Flirck. Y aunque Uber no entra directamente
en la categoría de “red social”, usa los principios sociales y por supuestos los de ingeniería
del software para hacer que su plataforma tecnológica vaya creciendo de la mano de su
modelo de negocios.
La Arquitectura inicial monolítica de Uber
Fuente: [Link]
Inicialmente Uber partió en la ciudad de San Francisco, California, teniendo todo su código
base y los repositorios diseñados para trabajar en esta parte geográfica del mundo, lo cuál
les permitía resolver los problemas de negocio de manera “sencilla”, lo que incluía:
conectar a los pasajeros con los transportistas, el sistema de pagos y facturación. Para
cumplir con estos requerimientos era razonable contar con toda esa lógica de negocios en
un solo lugar, pero en la medida en que comenzaron a expandirse a otras ciudades y agregar
nuevas funcionalidades, esto ya no era tan razonable.
En la medida en que los “domain models” comenzaron a crecer en conjunto con la adición
de nuevas características, los componentes se comenzaron a tornar ALTAMENTE
ACOPLADOS (recordemos que uno de los principios fundamentales de ingeniería de
software es mantener los componentes lo menos acoplados posible), y esto logró que la
encapsulación y la separación de intereses se tornara un trabajo difícil. Por lo tanto la tarea
primordial del equipo de ingeniería de Uber era encontrar una forma en que rápidamente se
pudieran integrar piezas de código al modelo de negocio; y acá es donde entra la
integración continúa.
¿Cómo lograr un buen escalamiento cuando tenemos diseñada nuestra plataforma para un
solo repositorio?
El cambio a SOA
Uber decidió seguir el ejemplo de empresas como: Amazon, Twitter, Netflix, SoundCloud
y romper el esquema monolítico base para formar una arquitectura orientada a servicios
(SOA). En concreto, SOA puede significar una variedad de cosas distintas (como término,
algo que abordé en el artículo Distinguiendo entre SaaS y SOA), sin embargo Uber decidió
abordar SOA a partir del uso del patrón de microservicios. Para no inventar la rueda, voy a
recurrir a la genial explicación de Martín Fowler:
Una arquitectura monolítica pone toda su funcionalidad en un único proceso, y la forma en
que tiene de escalar (crecer) es agregando múltiples servidores.
Una arquitectura de microservicios pone cada funcionalidad (lo más atómica posible) en un
servicio separado, y la forma que tiene de crecer es distribuyendo estos servicios a través de
los servidores, replicando de acuerdo a las necesidades del negocio.
Fuente: [Link]
Cada servicio puede ser escrito en su propio lenguaje y puede o no tener su propia base de
datos.
Esto resuelve varios problemas, pero también aparecen algunos nuevos, los cuales están
clasificados en las siguientes áreas:
1. Obviousness
2. Safety
3. Resilience
PD: uso los términos en inglés porque a veces es difícil encontrar una correcta traducción al
texto sin que esto vaya en desmedro del contexto.
Obviousness
Con más de 500 servicios, encontrar el servicio adecuado puede tornarse en una ardua
tarea. Toda vez identificado el servicio, la forma en que se utilizará este servicio no es tan
obvia, ya que cada microservicio tiene estructurado su propio camino. Los servicios que
ofrecen REST o RPC (donde es posible acceder a su funcionalidad dentro de su propio
dominio -lo que se conoce como stateless-), se caracterizan por ofrecer contratos débiles, y
en el caso de Uber, los contratos varían mucho entre microservicios. La adición de un
esquema JSON a una API REST puede mejorar la seguridad y el proceso de desarrollo
contra el servicio, pero no es trivial de escribir o mantener. Por último, estas soluciones no
ofrecen ninguna garantía con respecto a la tolerancia a fallos o la latencia. No hay manera
estándar para manejar los tiempos de espera del lado del cliente y las interrupciones, o
garantizar que una interrupción de un servicio no cause interrupciones en cascada. La
capacidad de recuperación global del sistema se vería afectada negativamente por estas
debilidades. Como un desarrollador escribió, “convertimos nuestra API monolítica en una
API monolítica distribuida”.
Se ha hecho evidente que necesitamos una forma estándar de comunicación que ofrezca la
seguridad de tipos, la validación y la tolerancia a fallos. Otros objetivos incluyen:
Formas sencillas para proporcionar bibliotecas de cliente
Soporte “Cross Language”
Tiempos de espera sintonizables con políticas de reintento
Desarrollo y Testing Eficiente
En esta etapa de nuestro hiper-crecimiento, los ingenieros de Uber continúan evaluando
tecnologías y herramientas para adaptarse a nuestras metas. Una cosa que sí sabemos es que
el uso del ya existente Lenguaje de definición de interfaz (IDL) que proporciona una gran
cantidad de herramientas pre-construidas desde el primer día es ideal.
Se evaluaron las herramientas existentes y encontramos que Apache Thrift (popularizada
por Facebook y Twitter) cumplió con nuestras necesidades. Thrift es un conjunto de
bibliotecas y herramientas para la construcción de servicios de lenguajes cruzados
altamente escalables. Para lograr esto, los tipos de datos y las interfaces de servicios se
definen en un archivo que es agnóstico del lenguaje de programación. A continuación, el
código se genera para abstraer el transporte y la codificación de mensajes RPC entre los
servicios escritos en todos los lenguajes que usamos (Python, Node, Go, etc.)
Safety
El argumento más convincente para Thrift es su seguridad. Thrift garantiza la seguridad de
la unión (binfing) de los servicios al utilizar contratos estrictos. El contrato describe cómo
interactuar con ese servicio incluyendo como llamar a los procedimientos de ese servicio, lo
que proporcionan entradas y salida de lo que se espera al momento de ejecutarlo.
Fuente: [Link]
La adhesión a un estricto contrato significa menos tiempo que se dedica a encontrar la
manera de comunicarse con un servicio y hacer frente a la serialización. Además, como
microService evoluciona no tenemos que preocuparnos acerca de las interfaces que
cambian repentinamente, y somos capaces de desplegar servicios de forma independiente
de los consumidores. Esta es una muy buena noticia para los ingenieros de Uber. Estamos
en condiciones de pasar a otros proyectos y herramientas desde Thrift resolviendo el
problema de la seguridad fuera de la caja.
Resilience
Por último, nos inspiramos en la tolerancia a fallos y las bibliotecas de latencia en otras
empresas que se enfrentan a problemas similares, tales como Netflix que usa la biblioteca
Hystrix y de Twitter la biblioteca Finagle , para abordar el problema de la resistencia. Con
esas bibliotecas en mente, escribimos bibliotecas que aseguran los clientes son capaces de
hacer frente a situaciones de fallo con éxito (que se discutirá con más detalle en un próximo
post).
¿Hacia dónde se dirige Uber?
Claramente a mejorar la escalabilidad organizacional y proveer mayor resistencia y
tolerancia a fallos usando la arquitectura de microServicios. Ellos entienden que hasta este
punto la solución no es perfecta y requiere de cambios, desafortunadamente existen pocas
herramientas alternativas para Python y Node que son parte del stack de desarrollo de Uber
y se requiere de buena inversión de tiempo para construirlas. Lo interesante, es ver que si
es posible migrar un modelo monolítico a uno de mayor escalabilidad como SOA
(implementado a través de micro servicios) considerando la evolución de nuestro modelo
de negocios, ya lo ha hecho Facebook y Twitter en el pasado, y los chicos de Uber no
quisieron quedar fuera.
Lo que se viene en la Parte II:
Ya nos adentraremos completamente en el stack de Uber, hablaremos tanto de su backend
como de casi todo su stack tecnológico pasando por la arquitectura lógica y física,
plataformas, lenguajes de programación, entre otros. Créanme que lo que estos chicos
realizan a nivel de Frontend y Backend es muy interesante.
