Archivo de la categoría: SOA

La Ingeniería detrás de Uber (PARTE I)

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

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 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.

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.

Fuentes de información:

  1. https://eng.uber.com/soa/
  2. http://highscalability.com/
Anuncios

2 comentarios

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, SOA

Distinguiendo entre SaaS y SOA

Surge una gran confusión al momento de hacer la distinción entre el software como servicio (SaaS) y la arquitectura orientada a servicios (SOA). El Marco de Referencia de Zachman puede ayudar a tratar de dar sentido a la sopa de letras de los Web Services y los servicios públicos que constituyen la base tanto para SOA y SaaS.

Varios profesionales de TI tienden en algún momento, a utilizar erróneamente el término software como servicio (SaaS) y arquitectura orientada a servicios (SOA) de manera intercambiable. A lo mejor, esta práctica defectuosa crea confusión, en el peor de los casos, puede conducir a diseños pobres.  Nuestro objetivo, por lo tanto, es de aclarar el significado de estos dos términos a menudo utilizados y abusados​​.

En pocas palabras, la diferencia entre SaaS y SOA es que el primero es un modelo de entrega de software mientras que el segundo es un modelo para la construcción de software. Una mejor manera de iluminar las diferencias entre estos dos conceptos es el uso del conocido modelo arquitectónico Zachman [1].

En este artículo, examinaremos brevemente los conceptos de SaaS y SOA, seguido de una breve historia de los modelos de arquitectura de software. Utilizamos el modelo Zachman para diferenciar los dos enfoques arquitectónicos para la construcción de software. Dado que el modelo Zachman es bastante intuitivo, el enfoque que tomamos para describir las diferencias entre SaaS y SOA funciona bien incluso con los profesionales que no son de TI.

Definiendo los términos

A veces se conoce como software de suscripción, [2] el modelo de entrega SaaS separa esencialmente la propiedad del software por parte del usuario, el propietario es un vendedor que aloja el software y permite al usuario ejecutarlo bajo demanda a través de alguna forma de arquitectura del lado del cliente a través de Internet o un Intranet. Este nuevo modelo ofrece software como los servicios públicos y los cargos sobre una base por uso, similar a la forma en que cobra una empresa de servicios públicos de electricidad. Tal vez el producto SaaS más célebre es la herramienta para la gestión de Salesforce.com Customerrelationship. Sin embargo, los productos SaaS están disponibles para una amplia gama de funciones de negocios, incluyendo servicio al cliente, gestión de recursos humanos, la funcionalidad de escritorio, correo electrónico, nóminas, aplicaciones financieras, y la cadena de suministro y control de inventario. [3]

En un modelo SOA, los componentes constitutivos del sistema de software son servicios reutilizables. [4] Una colección de servicios que interactúan entre sí a través de interfaces estándares y protocolos de comunicación. SOA promete cambiar radicalmente la forma en que construimos sistemas internos, así como la forma en que los sistemas internos y externos interactúan. Esta estrategia arquitectónica va de la mano con las aplicaciones de software que están cerca de los objetos de negocio que ayudan a crear una capa de abstracción (porque SOA le permite seleccionar “piezas” de software personalizadas que puede alinear estrechamente con su funcionalidad comercial correspondiente). SOA es también un marco coherente para conectar el software adecuado estática y dinámicamente.

Algunos de los principales actores de SOA y sus últimos productos incluyen a: BEA AquaLogic, Sonic SOA Suite 6.1, Oracle Web Services Manager, HP Systinet Registry 6.0, Iona Artix 5.0, Cape Clear 7.5, Microsoft .NET, Sun Java Composite Application Platform Suite, & IBM WebSphere.  En esta lista, se termina con una arquitectura tecnológica, una arquitectura de procesos, la arquitectura de la aplicación, y así sucesivamente. SOA ayuda a reunirlos, aunque no siempre es fácil de moverse en esa dirección teniendo muchas y diversas aplicaciones involucradas.

A pesar de sus diferencias, SaaS y SOA están estrechamente relacionados con los modelos arquitectónicos para los sistemas de información a gran escala. Con SaaS, un proveedor puede ofrecer un sistema de software como un servicio. Usando SOA permite que el servicio publicado pueda ser descubierto y adoptado como un componente de servicio para la construcción de nuevos sistemas de software, que también pueden ser publicados y entregados como nuevos servicios. En otras palabras, los dos modelos se complementan entre sí: ​​SaaS ayuda a ofrecer componentes para que SOA los pueda usar, y SOA ayuda a implementar SaaS de forma  más rápida.

Aunque ambos proporcionan características prometedoras para la industria del software moderno, son sólo modelos de nivel conceptual y requieren una tecnología detallada para apoyarlos. En la actualidad, el mejor habilitador conocido que apoya tanto SaaS y SOA son las tecnologías de aplicaciones programables de servicios Web con descripciones de interfaz estándar que proveen acceso universal a través de protocolos de comunicación estándar. [5] Los servicios web proporcionan un conjunto holístico basado en XML, ad hoc, además la industria de lenguajes Web  y protocolos estándar apoya a las descripciones de servicios web (Web Services Desription Language [WSDL] [6]), publicación y descubrimiento (utilizando UDDI [7]), el transporte (mediante SOAP [8]), y así sucesivamente.

Ni tampoco SaaS requiere la tecnología de servicios Web para SOA, pero es, con mucho, la mejor opción actual para apoyarlos.

En otras palabras, las tecnologías de servicios Web, con toda su pila asociada de normas, permiten y facilitan la adopción de SaaS y SOA. Vale la pena señalar que ni SaaS ni SOA requiere de tecnología de servicios Web, pero es lejos la mejor opción actual para apoyarlos. Ante este hecho, se utilizan los términos de servicios y servicios Web indistintamente en este artículo.

Texto completo (inglés) en: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1140&context=silicon_valley

Referencias

[1] J.A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems J., 1987, vol. 26, no. 3, pp. 276–292.

[2] M. Turner, D. Budgen, and P. Brereton, “Turning Software into a Service,” Computer, vol. 36, no. 10, 2003, pp. 38–44.

[3] M.H. Weier and L. Smith, “Businesses Get Serious about Software as a Service,” Information Week, 16 Apr. 2007, pp. 46–48.

[4] L.-J. Zhang, J. Zhang, and H. Cai, Services Computing, Springer, 2007.

[5] C. Ferris and J. Farrell, “What Are Web Services?” Comm. ACM, vol. 46, no. 6, 2003, p. 31.

[6]. “Web Services Description Language (WSDL) 1.1,” W3C note, E. Christensen et al., eds., 15 Mar. 2001; www.w3.org/TR/wsdl.

[7] Universal Description, Discovery, and Integration (UDDI), version 3, Organization for the Advancement of Structured Information Standards (Oasis), 2004; http://www.uddi.org/pubs/uddi_v3.htm.

[8] SOAP Version 1.2, Part 1: Messaging Framework (second edition), W3C recommendation, M. Gudgin et al., eds., 27 Apr. 2007; http://www.w3.org/TR/soap12-part1/

7 comentarios

Archivado bajo Arquitectura de Software, SaaS, SOA