análisis de elasticidad y tolerancia a fallos en

UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERÍA

Departamento de Sistemas y ComputaciónGrupo de Comunicaciones y Tecnología de Informaciónde - COMIT

Análisis de elasticidad y tolerancia a fallosen Arquitecturas de Aplicaciones Web:Arquitecturas Reactiva y Microservicios

Oscar Kiyoshige Garcés Aparicio

Trabajo de grado presentado para optarpor el título de Magíster en Ingeniería de Sistemas y Computación

en la Universidad de los Andes

Diciembre, 2015

Asesor: Prof. PhD. Harold Enrique Castro Barrera

Tabla de Contenido

Tabla de Contenidos i

Índice de ilustraciones iii

Índice de Tablas iv

1 Introducción 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Descripción del Problema . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contribución de la Tesis . . . . . . . . . . . . . . . . . . . . . . . 31.4 Organización del documento . . . . . . . . . . . . . . . . . . . . . 3

2 Contexto 52.1 Arquitecturas Monolíticas . . . . . . . . . . . . . . . . . . . . . . 62.2 Sistemas Distribuidos . . . . . . . . . . . . . . . . . . . . . . . . 72.3 SOC, SOA y Microservicios . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Service Oriented Computing . . . . . . . . . . . . . . . . . 92.3.2 Service Oriented Architecture . . . . . . . . . . . . . . . . 92.3.3 Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.4 Arquitectura Reactiva . . . . . . . . . . . . . . . . . . . . 11

3 Estado del Arte 153.1 Elasticidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Benchmarks de Tolerancia a Fallos . . . . . . . . . . . . . 203.2.3 Benchmarks en Arquitecturas de microservicios y en

Arquitecturas Reactivas . . . . . . . . . . . . . . . . . . . 21

4 Estrategia de Solución 224.1 Prueba de Elasticidad . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.2 Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Prueba de Tolerancia a Fallos . . . . . . . . . . . . . . . . . . . . 254.2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.3 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

i

ii Tabla de Contenido

5 Validación 295.1 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Arquitectura Reactiva . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.1 Play! Framework usando akka-clúster . . . . . . . . . . . 315.3 Arquitectura basada en microservicios . . . . . . . . . . . . . . . 31

5.3.1 Patrones de descubrimiento . . . . . . . . . . . . . . . . . 315.3.2 Tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . 32

5.4 Selección del IaaS (Infrastructure as a Service) . . . . . . . . . . 335.5 Ejecución de las pruebas . . . . . . . . . . . . . . . . . . . . . . . 33

5.5.1 Prueba de elasticidad . . . . . . . . . . . . . . . . . . . . 335.5.2 Prueba de tolerancia a fallos . . . . . . . . . . . . . . . . 36

6 Conclusiones y trabajo futuro 40

Bibliografía 42

Índice de Ilustraciones

2.1 Imagen obtenida de [10] . . . . . . . . . . . . . . . . . . . . . . . 62.2 Relación entre SOC, SOA y Microservicios . . . . . . . . . . . . . 13

4.1 Proceso de pruebas de Software ISO-29119 . . . . . . . . . . . . . 224.2 Cambio de Carga en el tiempo: Número de solicitudes por unidad

de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Cambio de Carga y de recursos en el tiempo: Número de

solicitudes por unidad de tiempo . . . . . . . . . . . . . . . . . . 254.4 Cambio de Carga e inyección de fallos en el tiempo . . . . . . . . 27

5.1 Prototipo desarrollado con Cluster de Actores . . . . . . . . . . 325.2 Prototipo desarrollado con microservicios . . . . . . . . . . . . . 335.3 Resultados elasticidad - Arquitectura Reactiva . . . . . . . . . . 345.4 Resultados elasticidad - Arquitectura basada en Microservicios . 355.5 Resultados Tolerancia a Fallos - Arquitectura Reactiva . . . . . . 375.6 Resultados Tolerancia a Fallos - Arquitectura Reactiva . . . . . . 375.7 Resultados Tolerancia a Fallos - Arquitectura basada en

microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.8 Resultados Tolerancia a Fallos - Arquitectura basada en

microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

iii

Índice de Tablas

2.1 Diferencias entre SOA y Microservicios . . . . . . . . . . . . . . . 12

4.1 Configuración de prueba de carga para evaluar Elasticidad yTolerancia y Fallos . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 Requerimiento Funcional: R1 - Simular uso intensivo de CPU . . 305.2 Requerimiento Funcional: R2 - Retornar cuotas del proceso de

liquidación de un Crédito . . . . . . . . . . . . . . . . . . . . . . 305.3 Resultados elasticidad - Arquitectura Reactiva . . . . . . . . . . 345.4 Resultados elasticidad - Arquitectura basada en Microservicios . 355.5 Resultados Tolerancia a Fallas - Arquitectura reactiva . . . . . . 365.6 Resultados Tolerancia a Fallas - Arquitectura basada en

microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

iv

1Introducción

1.1 Contexto

En veinte años, la WorldWideWeb (web) se ha transformado en dos dimensiones.La primera, desde el tipo de servicios ofrecidos que consistían en la creacióny acceso a contenido de tipo estático, sin cambios en el tiempo y creadospor un grupo de usuarios. Ahora, el contenido es dinámico, ya que semodifica constantemente, en tiempo real y desarrollado por diversas fuentescomo usuarios, dispositivos y sensores. Asimismo, han surgido aplicacionesque crean nuevos servicios y formas de comunicación entre los seres humanos.Estos servicios han traído como consecuencia nuevos modelos de negocios ynuevas metodologías de acceso e interacción con la información. Entre estos,se encuentran las plataformas de transacciones bancarias, pasarelas de pagos yplataformas para el comercio electrónico; plataformas de aprendizaje virtual yredes de colaboración (e.g., Foros, Redes sociales); y demás sistemas críticos ysensibles a fallos e.g., Sistemas críticos empresariales, telemedicina.

La segunda dimensión está relacionada con la población de usuarios capacesde acceder a la web. En el 2014, se estimaba que existía una penetración del 40%de la población global [1], lo que trae consigo aumento en la demanda de nuevosservicios, y cambios en las aplicaciones para satisfacer la demanda de acceso degrandes cantidades de usuarios de forma concurrente.

Estas transformaciones han causado que las aplicaciones web consideren dosrequerimientos: la tolerancia a fallos, para así tener la capacidad de ofreceraplicaciones sensibles a fallos y sistemas críticos; y la elasticidad, para soportarla demanda de los usuarios concurrentes. De esta manera, se han planteadosoluciones desde la arquitectura computacional y la arquitectura de solución.Desde la arquitectura de infraestructura computacional se han desarrolladoparadigmas como es el caso del Cloud Computing, el cual permite la consolidaciónde sistemas elásticos y tolerante a fallos; los nuevos paradigmas generan nuevosretos y consideraciones al ser sistemas distribuidos. Desde el punto de vistade arquitectura de solución, se han elaborado propuestas con característicasadaptadas a este nuevo paradigma de infraestructura computacional. Ahora

1

2 1.2. Descripción del Problema

bien, para aplicaciones web han surgido dos arquitecturas de solución con estascualidades y que además argumentan que son soluciones, en especial, de losrequerimientos de tolerancia a fallos y elasticidad; estas son: Arquitecturasbasadas en microservicios (en el desarrollo del documento se le denominanmicroservicios) y arquitecturas reactivas.

1.2 Descripción del ProblemaLas arquitecturas reactivas y microservicios, han sido diseñadas para adaptarsea las transformaciones de la web. La primera como una solución a necesidadesespecíficas de la web, en especial la tolerancia a fallos, cambios en tiemporeal y la elasticidad. Por su parte, microservicios ha sido una adopción degrandes empresas e importantes aplicaciones web, e.g., Netflix, LinkedIn, conlos propósitos específicos de generar ventajas en el desarrollo, cambios de lasaplicaciones y elasticidad. Sin embargo, los autores presentan que se cuenta conlos mecanismos y el diseño para la tolerancia a fallos.

En este sentido, los autores y defensores de las arquitecturas reactiva[2],[3] y microservicios [4] sostienen que se encuentran diseñadas para suplircon los requerimientos destacados en este trabajo, i.e. la tolerancia a fallosy la elasticidad; no obstante, no se cuentan con evidencias cuantificables quelo demuestren. Asimismo, no se encuentran herramientas para la toma dedecisiones, como el caso de la elección de la arquitectura para los nuevosdesarrollos de aplicaciones web que deban cumplir con estos requerimientos.

Existen múltiples definiciones, métricas y cálculos mediante los cuales sepueden cuantificar la elasticidad y la tolerancia a fallos, temas discutidos enprofundidad en el capítulo 2. Las herramientas y técnicas existentes para laelaboración de pruebas de elasticidad y tolerancia a fallos, como Yahoo CloudServing Benchmark (YCSB) [5], Standard Performance Evaluation Corporation(SPEC) [6], Transactional Processing Performance Council (TPC) [7], que sonespecificaciones de las pruebas y los datos para sistemas de bases de datostransaccionales. Por otra parte, AUToCLES [8] y JMeter [9] son herramientaspara la automatización de pruebas, con la limitante de no estar orientada amétricas de elasticidad y tolerancia a fallos. A pesar de su importancia, estassoluciones no proponen pruebas para aplicaciones web, ni estrategias para lavalidación de la tolerancia a fallos y elasticidad.

Lo anterior permite evidenciar que en la literatura no está presente unaevaluación cuantificable de las arquitecturas relacionadas con los requerimientosresaltados; así como tampoco, un conjunto de pruebas de elasticidad y toleranciaa fallos sobre aplicaciones web, que permitan la toma de decisiones sobre laelección de una arquitectura para nuevos proyectos web.

Por consiguiente, esta investigación desarrolla los siguientes objetivos:

1.2.1 Objetivo General

Comparar las arquitecturas de aplicaciones web, reactiva y microservicios, paraasí evidenciar la más adecuada en los requerimientos de Tolerancia a fallos yelasticidad.

Introducción 3

1.2.2 Objetivos específicos

1. Construir un prototipo de aplicación web que represente cada una de lasarquitecturas estudiadas.

2. Seleccionar una definición y métricas para el cálculo de tolerancia a fallosy elasticidad.

3. Diseñar e implementar un conjunto de pruebas que permitan calcular laelasticidad y el porcentaje de tolerancia a fallos.

4. Analizar los resultados la elasticidad y el porcentaje de tolerancia a fallosen cada uno de los prototipos de las arquitecturas desarrolladas.

1.3 Contribución de la Tesis

• Contribución 1: Definir los conceptos de elasticidad,tolerancia a fallos y microserviciosLa revisión de la literatura manifiesta que los conceptos de elasticidad,tolerancia a fallos y microservicios tienen múltiples definiciones. Deesta manera, este trabajo tiene como contribución realizar una revisiónde los conceptos para elaborar una definición propia de cada uno delos anteriores conceptos.

• Contribución 2: Crear herramientas para medición deelasticidad y tolerancia a fallosEste trabajo exhibe un conjunto herramientas, definición eimplementación de pruebas y herramientas de automatización, para lacuantificación de los requerimientos de elasticidad y tolerancia a fallos.

• Contribución 3: Comparar dos arquitecturas de aplicacioneswebLas actuales aplicaciones web pueden estar diseñadas con base endiferentes arquitecturas, entre las que se encuentran las arquitecturasreactiva y microservicios. Este trabajo consiste en la comparación delas arquitecturas con respecto a la efectividad en los requerimientos detolerancia a fallos y elasticidad.

1.4 Organización del documentoCon el propósito de cumplir con los objetivos y contribuciones planteadas, estedocumento se divide de la siguiente forma: primero, en el contexto (capítulo 2)se construye una definición de los conceptos que aborda la tesis, arquitecturasreactivas y microservicios, así como también conceptualizaciones importantes

4 1.4. Organización del documento

para la elaboración de las definiciones, como lo son arquitecturas orientadas aservicios (SOA), arquitecturas monolíticas y sistemas distribuidos. Segundo, enla sección del estado del arte (capítulo 3) se abordan trabajos relacionados conlas pruebas de tolerancia a fallos y de escalabilidad que se encuentran en laliteratura, así como también trabajos relacionados con mediciones de desempeñode las dos arquitecturas seleccionadas. A continuación, en el capítulo 4 sedescribe la estrategia de solución plateada para el desarrollo del trabajo y suposterior validación e implementación en el capítulo 5. Por último, el capítulo 6desarrolla las conclusiones y el trabajo futuro establecido para dar continuidada la propuesta actual.

2Contexto

En esta sección se describe el contexto relacionado con la web y las arquitecturasa estudiar. Esto incluye el desarrollo de los conceptos esenciales para la definiciónde las arquitecturas que se emplean en el desarrollo del documento. Primero,se debe conocer la diferencia entre los conceptos de arquitectura, modelo dereferencia y arquitectura de referencia; luego dar una visión general de lasarquitecturas utilizadas, en un principio, en aplicaciones web y sus problemasadyacentes. Luego, se describen las nuevas arquitecturas y metodologías pararesponder dos interrogantes, los problemas encontrados en las arquitecturaspropuestas en un principio y los requerimientos definidos para este documento.

Para comprender el contexto del problema, es necesario agregar algunasdefiniciones. Bass et al. en [10] definen y describen las relaciones entre losdiferentes conceptos, a saber, patrón de arquitectura, modelo de referenciay arquitectura de referencia. El primer concepto es una descripción de loselementos y sus relaciones, ambos conforman una familia de arquitecturascapaces de satisfacer unas restricciones dadas, en otras palabras, se solucionanen un problema específico. En [11] se cita “Cada patrón describe un problemael cual ocurre, una y otra vez en nuestro entorno, y luego describe la solucióna ese problema, de la manera que se pueda usar esta solución un millón deveces [. . . ]" e.g., Un patrón arquitectural como Model-View-Controller (MVC)define tres componentes y desacopla la funcionalidad de la Vista, los datos y lalógica del negocio. Un modelo de referencia es definido como una descomposiciónestándar de un problema conocido en partes que cooperan para resolverlo e.g.,El modelo de referencia TCP/IP describe las capas por las que deben pasar losdatos en las comunicaciones entre dispositivos. Por último, una arquitectura dereferencia es un modelo de referencia implementado en elementos de softwarey en el intercambio de datos e.g., implementación del modelo de referencia deTCP/IP.

En la Figura 2.1 se muestra las relaciones entre los diferentes conceptos desdelo general; sin embargo, es partir de las relaciones dirigidas que se evidenciamayor especificidad de elementos en el diseño, desde un diseño abstracto hastauna implementación determinada.

5

6 2.1. Arquitecturas Monolíticas

Modelo Referencial

Patrón Arquitectural

Arquitectura de Referencia

Arquitectura de Software

Figure 2.1 Imagen obtenida de [10]

Las anteriores definiciones permiten dar una mirada general al problema,para continuar con la explicación de las propuestas de arquitecturas de solución.En principio, las arquitecturas de solución se consideran monolíticas, fácilesde implementar y desplegar por los pequeños equipos de desarrollo, pero condesventajas en la escalabilidad, en la tolerancia a fallos y en equipos de desarrollocon diferentes especialidades y habilidades.

2.1 Arquitecturas Monolíticas

Las aplicaciones web se encuentran desarrolladas bajo una arquitecturadistribuida denominada cliente-servidor. Normalmente, el cliente es unWeb Browser (navegador) (e.g., Safari, Google Chrome, Opera e InternetExplorer) encargado de presentar información al usuario; mientras el servidorejecuta una aplicación y retorna la información almacenada a los navegadores.Inicialmente, las aplicaciones web se encontraban desplegadas y diseñadas paraser almacenadas o desplegadas en un solo servidor. Al cual se le adicionabala responsabilidad de responder a todas las solicitudes realizadas por losnavegadores.

Precisamente, las arquitecturas descritas en este trabajo brindan solucionesen las aplicaciones alojadas del lado del servidor. La evolución de la web trajoconsigo la transformación de diferentes conceptos, entre esos el de monolítico.Anteriormente, monolítica se denominaba a una aplicación standalone diseñadapara contener todas las funciones en un solo despliegue (e.g., SistemasOperativos, desarrollos empresariales en sistemas como AS/400); mientras quesoluciones distribuidas basadas en cliente-servidor no eran clasificados como tal.Hoy en día, los defensores de microservicios en [12] han extendido la definiciónde las aplicaciones monolíticas, para incluir las que pueden ser distribuidas e.g.,cliente-servidor, pero que en un solo servidor se encuentran todos los serviciosdisponibles. En ese sentido, Cockcorft et al. en [13] establecen que una aplicaciónmonolítica es aquella en que los componentes se encuentran desplegados enun mismo proceso y se comunican mediante métodos regulares i.e. llamadoal sistema, comunicaciones entre procesos, entre otros. Por su parte, TammerSaleh en [14] describe que los sistemas monolíticos se encuentran conformadospor grandes cantidades de líneas de códigos y funcionalidades acopladas; ambos

Contexto 7

factores podrían presentar mayor cantidad de problemas, en especial, relacionadocon la elasticidad y la tolerancia a fallos, debido a que existe un alto acoplamientode la solución o a la generación de latencias y errores en sistemas dependientesde un Middleware [15].

No obstante, los sistemas monolíticos presentan ventajas como se describe en[16] y que los autores logran listar:

1. La facilidad de desarrollo de un proyecto, se construyen componentesacoplados y dependientes, además los IDE’s (Integrated DevelopmentEnvironment) actuales están diseñados para la implementación de solucionesmonolíticas. 2. Construcción de pruebas generales de las funcionalidades. 3. Eldespliegue, dado que solo se debe realizar el de una sola aplicación y en unúnico servidor. 4. Escalabiliad de las aplicaciones, la demanda de más recursoscomputaciones se puede solucionar asignándolos en una sola instancia (escalarverticalmente), o a través de clúster de despliegues de una sola aplicación usandoalgún reverse proxy o balanceador de cargas). 5. No existen problemas ni lacomplejidad de los sistemas distribuidos.

La implementación de soluciones monolíticas presentan ciertas desventajasrelacionadas con los altos costos de escalar aplicaciones y cumplir con elrequerimiento de elasticidad. Estas generalmente están conformadas por unaaplicación desplegada en un servidor robusto, responsable de toda la aplicacióny de la información almacenada. Esto implica, si un fragmento de códigoo funcionalidad necesita una mayor cantidad de recursos computacionales noes posible asignárselos de forma exclusiva y controlada, sino a la aplicacióncompleta.

Sin embargo, se incrementa la dificultad de desarrollo en equiposdada la cantidad de funcionalidades acopladas en un solo despliegue.Adicionalmente, los requerimientos destacados, la tolerancia a fallos y laelasticidad, recaerían en la capacidad del servidor. De esta manera, elsistema colapsaría frente a cualquier fallo en el servidor. Para esto se debeimplementar mecanismos de tolerancia a fallos como Active/Standby failover,Active/Active failover y redundancy, los cuales se hace una ampliaciónconceptual en Sección 3, que no garantizan la continuidad del servicio.

Una vez identificadas estas desventajas en arquitecturas monolíticas, surgenarquitecturas desacopladas y pensadas para escalar, que en esencia se encuentranadaptadas a la elasticidad, como lo son los sistemas distribuidos y arquitecturasde microservicios.

2.2 Sistemas Distribuidos

Como se ha mencionado, las arquitecturas web en esencia son solucionesdistribuidas, sin embargo para cumplir con los requerimientos de elasticidad ytolerancia a fallas, deben estar diseñadas e implementadas bajo arquitecturas desistemas distribuidos más complejos y robustos.

Un sistema distribuido es un conjunto de computadores independientes,que tienen una determinada configuración e interacción con el fin de brindarun servicio (Tanenbaum en [17]); sin embargo, para el usuario final, estainteracción es transparente, lo que genera la apariencia de la existencia de unúnico recurso computacional. Una aplicación web puede estar diseñada bajo una

8 2.3. SOC, SOA y Microservicios

arquitectura distribuida, robusta y con mayor complejidad, bajo las restriccionesy consideraciones generadas por este tipo de soluciones. Rotem-Ga-Oz en [18]recopila los planteamientos de autores como Peter Deutsch y James Gosling,sobre ocho consideraciones que se deben tener al diseñar sistemas distribuidos,como lo son:

1. La red es confiable.

2. La latencia es cero.

3. El ancho de banda es infinito.

4. La red es segura.

5. La topología no cambia.

6. Solo hay un administrador.

7. El costo del transporte es cero.

8. La red es homogénea.

Estas se deben considerar como restricciones en el diseño de las soluciones.

Como se ha enfatizado, los sistemas distribuidos fueron planteados con elpropósito de satisfacer las transformaciones y los constantes cambios en laweb [19]. Así pues, han surgido múltiples soluciones a partir de: los avancesen arquitectura de infraestructura y telecomunicaciones; las arquitecturas desolución con nuevos patrones de diseño, modelos de referencia y arquitecturasde referencia, tales como SOA (Service Oriented Architecture), SOC (ServiceOriented Computing) y Component-based Programming.

En la actualidad, gracias a la difusión por parte de empresas como Netflix,LinkedIn [20, 21] existe una tendencia de soluciones en la que se utiliza un patrónarquitectural orientado por servicios. Así como también, exponen las ventajassobre las arquitecturas monolíticas y como una propuesta para el requerimientola elasticidad. La comunidad ha denominado este tipo arquitecturas bajo unnombre específico, microservicios. Por lo que ha generado gran controversia lasdifusas diferencias con la bien conocida SOA (Services Oriented Architecture).

Este trabajo presenta como contribución, la diferenciación entre los conceptosSOA y microservicios, y la definición de este último para tener un concepto únicoen el documento.

2.3 SOC, SOA y Microservicios

En esta sección, se hace una distinción entre los conceptos de arquitecturasorientadas por servicios (SOA) y microservicios. Con base en una investigacióny tipificación a nivel conceptual, se tiene como resultado de la tesis definicionespropias a microservicios y sus respectivas características.

Contexto 9

2.3.1 Service Oriented Computing

Tsai et al. [22] y Thomas Erl en [23] definen Service Oriented Computing (SOC)como un paradigma de desarrollo de sistemas distribuidos en el que se definenconceptos bases de SOA. Sin embargo, se puede ampliar el alcance e incluir a lasarquitecturas de microservicios como parte de SOC, gracias a la naturaleza dela creación de servicios como unidad funcional.

Como conclusión, en esta sección se muestra la relación entre SOC, SOA ymicroservicios. Así pues, primero se deben definir conceptos los cuales sirvencomo insumos para las conclusiones.

2.3.2 Service Oriented Architecture

SOA ha sido bastante estudiada, sin embargo se encuentran dos grandesdefiniciones divergentes:

• Como Patrón o estilo Arquitectural: Autores como Erl [24, 23], Barryet al. [25], entienden a SOA como un patrón arquitectural, en el cual sediseña, se implementan y se coordinan servicios con el fin de soportar oautomatizar los procesos de negocio. Esto con objetivos entre los que sedestacan: Bajo acoplamiento, contrato de servicios, autonomía de cadaservicio, reusabilidad y no guardar estados dentro de las aplicaciones [26].Para Tsai et al. [22] no existe diferencia entre SOC y SOA, pues define aSOA como un paradigma que abstrae este tipo de sistemas distribuidos.Por otra parte, surgieron soluciones arquitecturales e implementacionesintermedias para realizar la orquestación de los servicios y necesarias paradesacoplar las funcionalidades. Así, patrones como SAGA [27] y ESB(Enterprise Service Bus) son elementos que todos los autores proponencomo parte de la construcción de una solución SOA. SOA se encuentradiseñada para cumplir con unas restricciones, entre los cuales se recalca elbajo acoplamiento y el uso contratos de los servicios pues se menciona quelos proveedores y consumidores de servicios, deben ser capaces de solicitar,interpretar y responder mensajes, de forma que el sistema sea estable y eldesarrollo del mismo se encuentre estandarizado.

• Como Modelo de referencia: Con el fin de estandarizar y realizaruna unificación a las tantas definiciones de patrones existentes, OASIS(Advancing Open Standards for the Information Society) decide publicarun modelo de referencia [28] en el que se plantean los elementos esencialespara SOA. El primero es la entidad, responable de crear las funcionalidades(capabilities) encargadas de solucionar los problemas de la empresa. bajoesta premisa, el modelo de referencia describe siete conceptos:

1. Servicio: Mecanismo para acceder a las funcionalidades de lasentidades.

2. Descripción del servicio: A grandes rasgos, el modelo de referenciaindica que debe existir una descripción de un servicio, el cual constade información relevante para el consumo y respuestas ofrecidas porlos servicios, entre los que se encuentra la estructura de la informacióna solicitar o responder, la semántica de la información y los métodosde interacción.


3. Visibilidad: Capacidad de identificar el consumidor y proveedor delos servicios y los permisos entre los mismos.

4. Contexto de ejecución: El contexto abarca todo lo relacionado conla infraestructura, i.e. componentes de Hardware, computadores,elementos de telecomunicaciones, en la que se ejecutan los servicios, lasentidades que procesan (consumen o proveen servicios) y los contratos.

5. Efecto en el mundo real: Es la capacidad de ver persistir cambios enun sistema distribuido que tiene elementos compartidos. Es deseadoque los cambios que suceden a una variable compartida debe serconsistente en todo el sistema.

6. Contrato: Es la generación de un acuerdo entre el proveedor y elconsumidor de los servicios, con el fin de registrar lo que se desea(y como) solicitar y lo que se acuerda a responder. Esto incluye,establecer acuerdos de calidad de servicio, tiempos de respuesta, entreotros.

7. Interacción: Mecanismos para realizar la interacción y ejecutaracciones entre los servicios, este concepto se encuentra relacionado conel contrato y las políticas establecidas por los servicios, el contexto enel que se encuentra ejecutándose, hasta con el visibilidad entre losmismos.

Como se observa, SOA tiene varios tópicos transversales, debido a que seencuentra diseñado para proveer soluciones a entornos empresariales, que tengannecesidades complejas y capacidad de soportar aplicaciones sensibles y críticaspara el negocio. En el momento que las empresas decidieron adoptar estetipo de arquitecturas, varios proveedores presentaron sus productos: IBM conWebSpehere [29], Oracle [30] y productos open source como Mule ESB (Ahoraintegrado en la plataforma Anypoint). Esta proliferación de productos dio aconocer a SOA como un sistema de integración de aplicaciones empresarialesque utilizaba un Middleware, esto acarreó a la generación de grandes obstáculos,tales como el diseño de la arquitectura de solución y despliegue de ESB, diseñoe implementación de interfaces para la integración con las aplicaciones nuevasy legadas, así como también se difundió una errónea concepción de SOA, susprincipios y motivaciones.

SOA se puede definir desde dos perspectivas, como patrón arquitectural, enel que muchos autores enfatizan en el uso de middlewares como: Elemento deintegración (lo que ha generado dificultades en las implementaciones); y como unmodelo de referencia, en el que solo se hace descripción a alto nivel de elementosque componen y la comunicación entre los mismos. Autores, la comunidad yempresas emergentes (start-ups) han intentado mejorar las soluciones orientadaspor servicios a través de la eliminación de las desventajas documentadas de lasarquitecturas tradicionales y las orientadas por servicios, como lo son problemasasociados a la elasticidad y tolerancia a fallos. Las nuevas aproximaciones se hanconcentrado en un nuevo patrón llamado microservicios.

2.3.3 Microservicios

El concepto de microservicios se ha propagado en los últimos años gracias aempresas como Netflix, Amazon, Twitter y start-ups como se evidencia en [14,

Contexto 11

20, 21, 31, 32] y a los autores que han trabajado en las iniciativas que intentandefinir el concepto y los objetivos, como Fowler en [4], Richardson [13] y lacomunidad [12].

A pesar de los grandes aportes y su divulgación, no se tiene una definiciónclara que permita suprimir la dicotomía con el concepto de SOA [33].Concretamente, para Richardson y Fowler en [13, 4] respectivamente, definena una arquitectura de microservicios como un patrón centrado en la divisiónde las funcionalidades en pequeños servicios. Cada servicio debe ser autónomo,desplegado en único proceso y utilizar mecanismos ligeros de comunicación entrelos mismos. Esta definición es bastante difusa, lo que implica que autores comoLittle y Steve Jones en [33] no logren diferenciar los dos conceptos y concluyenque las arquitecturas de microservicios es una versión simplificada de SOA.

En el siguiente cuadro se puede precisar las diferencias entre microserviciosy SOA (Cuadro. 2.1). La comparación se realiza con las característicasque se describen en [4, 12]: ventajas y desventajas; objetivo de los patrones;granuralidad de los servicios, ya que se comparan arquitecturas orientadas aservicios y es necesario analizar el grado de granularidad de los mismos y porúltimo si se considera un patrón arquitectural, por definición, debe satisfacerunas restricciones o solucionar un problema recurrente.

Desde el punto de vista conceptual existe una diferencia entre el modelo dereferencia y el patrón arquitectural de SOA, puesto que sus alcances y objetivosson diferentes. Como se muestra en la Tabla 2.1; los microservicios tienenprincipios diferentes a SOA, pero en la praxis no están totalmente aislados,dado que comparten conceptos tales como: los mecanismos de descubrimientoy registro de servicios; mecanismos de intercambio de solicitudes; hasta elconcepto de división de capabilities en servicios independientes. La diferenciaque se encuentra es en el conjunto de objetivos a alcanzar y en como dividirlas funcionalidades para cumplir con las restricciones. Por otra parte, en [31]presentan una metodología para adoptar microservicios y de como se deberíaorientar el desarrollo. La metodología incluye un estilo para el diseño, DomainDriven Development (DDD), que cuenta con la ventaja de desacoplar losmicroservicios y no generar alto acoplamiento por las dependencias.

De esta manera, extendemos la definición a; una arquitectura de microservicioes un patrón arquitectural que se encuentra bajo ciertas restricciones de diseño:Bajo acoplamiento, escalabilidad y elasticidad, tolerancia a fallos, división deresponsabilidades (datos, lógica, despliegue). De acuerdo con la necesidad, unservicio debe ser atómico, la granularidad está dada por los requerimientos ypor decisiones de diseño si tenemos en cuenta que la comunicación entre losmicroservicios es liviana y no debe haber alto procesamiento ni consumo derecursos en los elementos intermedios.

En la figura 2.2 se puede ver la relación entre SOC, SOA (comopatrón arquitectural) y microservicios: SOA y microservicios son patronesarquitecturales que se encuentran dentro de un paradigma de desarrolloorientados por servicios (SOC).

2.3.4 Arquitectura Reactiva

La programación reactiva, es un término bastante estudiado para definir a unparadigma de programación y por lo tanto se tiene bastante información. Laprogramación reactiva se centra en dos grandes conceptos mencionados en [35]:


SOA Patrón SOA RM Arquitectura deMicroservicios

División enEquipos deDesarrollo

Por aplicación No aplica Por microservicio

Tipo deaplicaciones

Empresarial Empresarial General

Objetivo Desacoplar, Integraraplicacionesempresariales

Desacoplar e integraraplicaciones

Desacoplar, endpointsrobustos pipelinesligeros

Granularidadde losservicios

Dependiendo de laaplicación y del diseñode la solución

No Aplica Servicios pequeños(Autores establecenque entre 10 y 100LoC [31, 32] o SRP(Single ResponsibilityPrinciple) [34]) )

Restriccionesa satisfacer

Bajo acoplamiento,contrato de servicios,autonomía de cadaservicio, reusabilidad,sin estado.

No aplica Facilidad de desplieguey automatización,Escalabilidady resiliencia,Computacióndistribuida:Descentralizarprocesamiento, datos,diferentes stacktecnológicos, Orientadoal desarrollador.Distribuirresponsabilidades de unsistema monolítico.

Table 2.1 Diferencias entre SOA y Microservicios

• Comportamientos: Son valores variables en el tiempo, es decir que sonlos valores reactivos.

• Eventos: Secuencias de ocurrencias ordenadas en el tiempo.

Adicionalmente, las aplicaciones reactivas son soluciones orientadas poreventos donde lo más importante es la notificación e intercambio de ocurrenciasde estos dentro del sistema. Por esto, se plantearon Functional ReactiveProgramming (FRP) y lenguajes como Haskell [36], (Functional ReactiveAnimation) FRAN [37], que permiten la creación de comportamientos quereaccionen a eventos y desarrollo aplicaciones reactivas, en especial en las áreas deanimación, robótica, interfaces gráfica, usando lenguajes funcionales declarativosy bajo el paradigma de programación reactiva.

Odersky et al. en [38] plantea Scala como un lenguaje que puede construircomponentes alternativos a la implementación del patrón Observer. El patrónObserver es la solución predominante para capturar los cambios en los estadosdentro de un sistema. En [11] se describe un escenario en el cual se puede usar.

Contexto 13

SOC

SOA Microservicios

Figure 2.2 Relación entre SOC, SOA y Microservicios

El caso es que el cambio de un objeto debe actualizar el estado de otros (propagarel cambio) y no se sabe cuantos objetos necesitan ser modificados. Odersky etal. en [38] hacen una crítica a este patrón con la justificación que se quebrantanprincipios como: Encapsulación, al tener que compartir el estado con otras clases;distancia semántica, difícil entender la intención del desarrollador y el código;Abstracción, el patrón promueve el uso de interfaces robustas, y no se puedeabstraer sobre la fuente del evento de forma individual. Para contrarrestar esto,se propone la programación reactiva a través de un lenguaje de programación(Scala) y de un framework Scala.React con el fin de permitir la propagación delcambio.

Teniendo ya un paradigma de programación, algunos años después, se escribióun manifiesto [3] sobre una arquitectura centrada en cuatro requerimientos y quetoda solución web actual debería soportar:

• Responsividad: Todo sistema debe responder a las solicitudes por partedel usuario, esto quiere decir que debe existir una continuidad en laprestación de las funcionalidades del sistema, i.e. el sistema siempre debereaccionar a las solicitudes por parte de los usuarios.

• Elasticidad: La capacidad del sistema de escalar para atender unacantidad de usuarios bajo demanda, es decir el sistema debe reaccionara los cambios del número de solicitudes.

• Orientados por eventos: Un sistema debe responder a los eventos, porlo tanto los eventos son el elemento esencial de intercambio dentro delsistema, es decir el sistema debe reaccionar a los eventos generados.

• Resiliencia: Un sistema debe ser capaz de reaccionar a los puntos de fallasy recuperarse para mantener la responsividad.

En el caso de las arquitecturas reactivas, esta extiende la programaciónreactiva solo como paradigma de desarrollo, sino más bien a la arquitecturade una solución que reacciona a los eventos, cambios de volúmenes de peticiones,a los fallos dentro del sistema, en general un sistema que siempre sea capaz dereaccionar.


La empresa TypeSafe ha sido la encargada de desarrollar una plataforma, lacual la denominan como reactiva, Play [39], y consta de varios elementos quepermiten clasificarla como una plataforma reactiva.

En el tutorial [40] se describen varias formas en que las aplicaciones puedenser reactivas:

1. Reactive Push: Es la capacidad de enviar datos desde el lado del servidoral cliente, en el caso de la plataforma se utilizan WebSockets para el envíode información entre las partes.

2. Reactive Pull: Es la capacidad de comunicación desde el lado del clientehacia el servidor para obtener los datos necesarios y pasarlos a la interfazgráfica.

3. Reactive UI: Un sistema debe mostrar datos en tiempo real al usuario final,lo cual la interfaz gráfica también debe ser reactiva. Para esto, se utilizanframeworks orientados por eventos, como lo son Javascript y JQuery.

4. Reactive Request: Algunas llamadas pueden ser asincrónicas, esto con elfin, de no ocupar procesos en esperar las llamadas (una ventaja de PlayNon-Blocking IOs). Play está soportado por Akka [2], una implementacióndel modelo de Actores propuestos por Agha [41] para la ejecución deprocesos de forma concurrente, permite tener una gran cantidad deprocesos (actores) capaces de responder de forma asincrónica solicitudes, enla teoría esto se refleja en ventajas como lo son: Resiliencia, Escalabilidady Non-blocking IOs

5. Reactive Composition: Es el conjunto de solicitudes.

6. 2-way Reactive: Es la comunicación bidireccional entre el cliente y elservidor, esto quiere decir que el sistema es tanto Reactive Push comoReactive Pull.

3Estado del Arte

Las arquitecturas reactiva y microservicios, son descritas como solucionespara dos requerimientos específicos, la tolerancia a fallos y la elasticidad.Como se muestra en el capítulo 1 estas son necesidades que surgen graciasa las transformaciones de la web. Este documento desea comparar las dosarquitecturas teniendo en cuenta los dos requerimientos, para esto es necesarioseleccionar, primero, la definición de los conceptos de elasticidad y tolerancia afallos. Además, la elección de métricas y herramientas para hacer la mediciónadecuada para elaborar la comparación.

3.1 ElasticidadEn otras áreas del conocimiento definen la elasticidad como una capacidadmensurable e.g., Economía es la medición de dependencia entre variables, enFísica la capacidad de un material en retornar al estado original luego de unadeformación, que ha sido adaptada al contexto de la computación como unatributo del paradigma Cloud Computing bajo ciertas definiciones ambiguas ycontradictorias; Herbst en [42] recopila cinco de estas contradicciones, las cualesconsidera ambiguas e incapaces de definir adecuadamente el concepto, así comotampoco, de capturar los aspectos más importantes:

1. La Open Data Center Alliance (ODCA) define elasticidad como unacapacidad para escalar teniendo en cuenta la carga dentro del sistema.

2. La National Institute of Standards and Technology (NIST) plantea laelasticidad como un atributo de Cloud Computing que permite asignarmayor capacidad a los recursos para responder rápidamente a unademanda.

3. Edwin Schouten autor de Author at Thoughts On Cloud encuentra queelasticidad es otro nombre que se atribuyó a la escalabilidad.

4. Rich Wolski (CTO de la Empresa dedicada a Cloud Computing,Eucalyptus) plantea que la elasticidad mide la habilidad de Cloud para

15

16 3.2. Tolerancia a fallos

distribuir una solicitud a diferentes recursos.

5. Reuven Cohen, por su parte, establece que la elasticidad cuantifica lacapacidad de gestionar, medir, predecir y adaptar la habilidad de responderde una aplicación, basada en las demandas.

Las principales críticas a los anteriores aspectos son la falta de inclusión devarios conceptos: a) Medición, ya que es un concepto necesario dada la naturalezadel concepto y las aproximaciones de otras áreas. b) El marco de Tiempo en elcual se realiza dicha medición. c) Automatización, la elasticidad responde acambios dinámicos bajo demanda, la respuesta debe ser automática.

Así pues, frente a las críticas el aporte en [42] es una definición concisa deelasticidad, la cual la define como: “El grado en el cuál un sistema es capaz deadaptarse a los cambios de carga de trabajo, aprovisionando y desabasteciendorecursos de una forma automática, lo cual en cada punto en el tiempo los recursosdisponibles corresponden a la actual demanda tan cerca como sea posible". Bajoeste concepto de elasticidad se trabajará durante el desarrollo de la tesis, debidoa que es una definición que logra unificar varias definiciones de entidades comola ODCA y la NIST; además es relevante pues el concepto es generalizado, nosolo se le atribuye al paradigma de Cloud Computing, sino a cualquier sistema.

Como se ha mencionado, la elasticidad es atribuida al paradigma de CloudComputing, sin embargo, existen arquitecturas de solución las cuales no sonfáciles de adaptarse a los cambios de recursos de infraestructura de formadinámica, e.g., Clústers de servidores. Por ende, la elasticidad no solo se centraríaen la medición de la infraestructura, sino también en la capacidad en la que lasarquitecturas de solución tienen para adaptarse a los cambios de carga de trabajoaprovisionando o desabasteciendo recursos en un marco de tiempo.

3.2 Tolerancia a fallos

Como se mencionó en el capítulo 2 la tolerancia a fallos en los sistemasdistribuidos es un término bastante estudiado. Esto se justifica a través de lasocho falacias de los sistemas distribuidos, la red no es confiable y los recursos noestán exentos de eventualidades que generen no disponibilidad de los sistemas.En este caso, diferentes paradigmas como Cloud Computing solucionan losinconvenientes, dado que se cuentan con grandes niveles de alta disponibilidad(e.g., AWS tiene un nivel del 99,95% es decir 44 minutos al mes1). Sin embargo,otros inconvenientes de la aplicación, el sistema debería ser capaz de ofrecer unservicio continuo y tolerar los fallos.

Bajo esta idea, se debe definir lo qué es un fallo. Fernandez et al. en [43]explica el concepto de defecto como un evento generado en algún componentedel sistema y que compromete el correcto funcionamiento del mismo, estos sepueden propagar por el sistema y en el peor de los casos colapsarlo, es decirque el sistema produzca comportamiento deseado. Por otra parte, [44] explicatres conceptos: Defecto (Fault en Inglés), el cual genera un Error. Error es laconfiguración de un estado incorrecto dentro del sistema y al ocurrir genera unafalla. La falla (Failure en Inglés), representa la condición en que el sistema no

1Información obtenida de: http://aws.amazon.com/es/ec2/

Estado del Arte 17

presenta el comportamiento esperado. A partir de las anteriores definiciones, seentiende por falla, al estado en el que se encuentra un sistema al no presentarel comportamiento deseado, e.g., suponga que un servidor web se encuentraconectado a otro de Bases de datos, con el propósito de persistir todas lastransacciones de los usuarios. En un instante de tiempo, hay un problema con laMemoria RAM del servidor de Bases de datos, este es un defecto que causa unerror, el reinicio del proceso del DBMS (Database Management System). Luego,esta secuencia de eventos ocasionan una falla en todo el sistema, pues el servidorWeb no se puede conectar a la base de datos y no podrá atender a las nuevassolicitudes. Si el sistemaNo es Tolerante a Fallos, colapsará y se deberán realizarun proceso de recuperación, generalmente volver a inicializarlo completamente.En el caso opuesto, el sistema será capaz de gestionar el fallo sin comprometerel servicio a los usuarios.

Por su parte Jhawar et al. [44] formalmente define Tolerancia a Fallos comola capacidad de un sistema de continuar con su funcionamiento en presencia defallas.

Los defectos se pueden clasificar en dos:

1. [43, 45, 46] lo denotan como Defectos de Hardware, en el caso de [44] lonombra Defecto de choque (Crash Fault). Los autores, describen estedefecto como problemas físicos que pueden ocurrir y que el recurso quedacompletamente fuera de servicio. e.g., Problemas de Red o energía.

2. En [43, 45, 46] son defectos en Software y en el caso de [44] es unDefecto Byzantino (Byzantine Fault). Este tipo de defectos son losque en un momento de falla el sistema continúa en funcionamiento perocon un comportamiento no predecible. e.g., Códigos fuentes con errores,entradas inesperadas a los módulos del software.

Es cierto que existen fallos, también se encuentran técnicas para mitigarlas.Se debe contar con un sistema Tolerante a Fallos e implementar estrategias, queentre las cuales se encuentran:

1. Replicación: Es la técnica más común para mantener alta disponibilidadde recursos críticos. Consiste en replicar tanto el Hardware, Softwarey componentes de red. Así, una vez exista una falla, el componentereplicado es el encargado de continuar con el funcionamiento. Se puedededucir, la existencia de dos tipos de configuraciones: Activo-Activo,en el cuál los dos componentes replicados se encuentran funcionandomediante un balanceador de carga encargado de distribuir las peticiones, yActivo-Pasivo, una vez falle el componente activo el pasivo es el encargadode continuar con el sistema. Esta estrategia se puede extender a Defectosde Software, Agha et al. [41] y Fernandez et al. [43] plantean mecanismosen los cuales Agentes y Actores replicados y distribuidos pueden colaboraren la Tolerancia a Fallos.

2. Monitoreo y Supervisión: Fernandez et al. citeFernandez-Diaz2015centran su propuesta en esta estrategia, pues su aproximación es de unlenguaje de programación basado en Sistemas Multi-agentes (MAS) ycuyo objetivo es un sistema Tolerante a Fallos mediante la supervisiónde los agentes que componen el sistema y reaccionando a las fallas que sepresenten. Por su parte [44], hace una breve descripción de la estrategia y


se resalta que aunque es muy sencilla, es muy importante en la detecciónfallas y la posterior reacción.

3. Checkpoint y reinicio: Consiste en capturar y almacenar todo el estadodel sistema teniendo en cuenta ciertos parámetros configurados e.g., Cadax segundos o después de n líneas de código, y detectado el fallo se reiniciadesde el último estado almacenado [44].

Ya se cuenta con la definición propia para elasticidad y tolerancia a fallos.Ahora, se hace una revisión de las soluciones y herramientas actuales para elcálculo de elasticidad y posteriormente de tolerancia a fallos.

3.2.1 Benchmarks

Los Benchmarks se definen como un conjunto de pruebas con el objetivo demedir una determinada variable. Esta propuesta se centra en la medición dedos grandes características de las arquitecturas web: Elasticidad y Tolerancia aFallos.

Benchmarks de elasticidad

De acuerdo con [47] un Benchmark de Elasticidad mide el rendimiento de unsistema dentro de un marco temporal y de cambios en las cargas de trabajo; porlo que se deben proponer medidas que permitan concluir el grado de elasticidadde un sistema.

Variables de medición Elasticidad para Klems [47] es el grado de eficienciaen el que un sistema escala el número de recursos en tiempo de ejecución bajotérminos de velocidad. Así, se contempla el impacto en el rendimiento teniendoen cuenta la carga actual al sistema. Para cuantificar ese grado, se propone medirlatencias en los tiempos de respuesta, en tres diferentes instantes de tiempo,antes, durante y después de escalar el recurso. El autor sostiene que estas facultana la medición y concluir sobre el impacto en el rendimiento del sistema y sobreel tiempo que toma configurar las nuevas asignaciones de recursos (escalado).

Autores como Almeida et al. en [48] miden la elasticidad basándose enpenalidades: sobre-provisionado e infra-provisionado, de esta manera se midegrado en el que el sistema reacciona a la demanda de carga de trabajo. Paraobtener los resultados, Almeida propone las siguientes mediciones y fórmulas:

1. Penalidad por sobre-aprovisionamiento (Over-provisioningpenaly): El sistema sobre-aprovisionado cumple con los cambios de lascargas de trabajo, sin embargo se estarían utilizando más recursos de losnecesarios. Para el cálculo de sobre-aprovisionamiento se tiene:

overprovp =

∑ni=1

expectedrt(i)executiontime(i)

n

Debido a que el tiempo de ejecución en un entorno sobre-aprovisionado vaa ser menor que el tiempo esperado. Así, mayor el valor de overprovp,quiere decir que el tiempo de ejecución es menor al tiempo esperado y estaes una característica de un sistema que está sobre-aprovisionado.

Estado del Arte 19

Los autores proponen otra ecuación de sobre-aprovisionamiento. Comoel promedio de las tazones entre el tiempo de respuesta esperado y eltiempo total del grupo de consultas, i.e. el tiempo gastado por ungrupo de consultas i que se incluye en la ecuación si satisface la ecuaciónexpectedrt − δ > querygrouprt. El autor incluye δ para obtener un rangode tiempos de respuestas esperados por las consultas.

overprovp =

∑ni=1

expectedet(i)querygrouprt(i)

n

2. Penalidad por infra-aprovisionamiento (Under-provisioningpenalty): Se encuentra relacionado con una mala elasticidad, dado que nocubre con lo mínimo demandado por los cambios en las cargas de trabajo.En el otro contexto, donde existiese elasticidad, escalaría los recursos pararesponder a los cambios y evitar esta penalidad. En la siguiente ecuación,se hace un cálculo del nivel de infra-aprovisionamineto, del cuál se puedeinducir que es el promedio de las razones entre tiempos de ejecución que nocumplen con un límite establecido y los tiempos de respuestas que cumplencon dicho límite.

underprovp =

∑ni=1

violatedet(i)expectedrt(i)

n

Ahora bien, existe una relación inversamente proporcional entreunderprovp y elasticidad; Mayor underprovp menor elasticidad, dado queconcluiría que los tiempos de ejecución en los que no estarían dentro dellímite establecido son mayores a los tiempos de respuesta esperados.

La elasticidad, entonces, se obtiene de la suma de las penalidades, los autoresdecidieron agregar dos pesos a la ecuación para diferenciar la importancia entrelos valores de las penalidades.

elasticity = x ∗ underprovp + y ∗ overprovp

x+ y

Existen otras aproximaciones para encontrar la elasticidad, Weber et al. [49]y Herbest et al.Herbst2013 proponen hacer mediciones básicas que dan unanoción de elasticidad y a partir de estas mediciones se encuentran métricasrelevantes para el concepto de elasticidad.

• A es el tiempo promedio que toma cambiar de un estadoinfra-aprovisionado a un óptimo sobre-aprovisionado.

•∑A es el tiempo acumulado en el estado infra-aprovisionado

• U es la cantidad de recursos infra-aprovisionados.

•∑U es la cantidad acumulada de recursos infra-aprovisionados.

• B,∑B,O,

∑O son análogos a las anteriores mediciones, en un contexto

sobre-aprovisionado.


• T duración total del tiempo de evaluación

A partir de estas mediciones básicas, se calculan las métricas relevantes deelasticidad:

• Velocidad para escalar:∑A

• Precisión (periodos de sobre-aprovisionamiento): Pd =∑

O

T

• Elasticidad: Eu = 1A∗U

Estas mediciones en conjunto constituyen la percepción de un sistema concaracterísticas de elasticidad.

Herramientas de Medición En las diferentes referencias bibliográficas, sehan encontrado que se han creado herramientas para automatizar las medicionesde cargas de trabajo, algunas se orientan a las pruebas en sistemas de bases dedatos.

1. Yahoo Cloud Serving Benchmark (YCSB) [5]: Esta solución tiene comoobjetivo desarrollar un Framework y un conjunto de pruebas que permitanevaluar el rendimiento de bases de datos en la nube.

2. Transactional Processing Performance Council (TPC) [7]: Organizaciónencargada de desarrollar conjuntos de pruebas para evaluar el rendimientoen sistemas de bases de datos. Las pruebas de TPC son bien conocidas ydifundidas en la literatura de benchmarking, sin embargo solo se orienta ala creación de pruebas en sistemas de bases de datos.

3. Standard Performance Evaluation Corporation (SPEC) [6]: Es unaorganización que crea, mantiene y estandariza benchmarks. SPEC hadesarrollado un SPECweb para evaluar servidores Web, incluyendo pruebasde cargas, no obstante, este proyecto no continúa en desarrollo.

4. AUToCLES [8]: Es una herramienta de automática para la generación depruebas en sistemas elásticos. Es posible el análisis de los eventos queocurren durante las pruebas no genera métricas que evalúen y permitancuantificar la elasticidad.

5. JMeter [9]: Es una herramienta para realizar pruebas de carga y estrés,bastante fácil de extender, por lo que se podría extender para obtener lasmétricas para elasticidad.

3.2.2 Benchmarks de Tolerancia a Fallos

Tsai et al. en [50], propone que el Benchmark de Tolerancia a Fallos se compone,de una medida que caracteriza la tolerancia a los fallos por parte de un sistemay la especificación del proceso para obtener la métrica. Esto sugiere la creaciónde un mecanismo encargado de realizar las pruebas y de obtener las métricasnecesarias. En el mismo artículo, se propone esta capaz de inyectar defectosen el sistema, posteriormente obtener el comportamiento del sistema y porúltimo analizar las métricas de la tolerancia a fallos: El número de incidentescatastróficos (El sistema no se recuperó) y la degradación del sistema.

Estado del Arte 21

Aunque la Tolerancia a Fallos ha sido estudiada existen múltiples problemasque aún se están haciendo propuestas e investigación en el tema, no es elcaso de los Benchmarks que logren cuantificar la Tolerancia a Fallos paraarquitecturas Web. Como se puede evidenciar en [44] las pruebas se hacenutilizando herramientas que a la fecha se encuentran obsoletas, causando dudasal validar arquitecturas emergentes.

3.2.3 Benchmarks en Arquitecturas de microservicios y enArquitecturas Reactivas

Hasta la fecha, no se encuentran mediciones de ningún tipo de las diferentestipos de arquitecturas. Cada uno de los defensores de las arquitecturas ofrecenargumentos sobre la capacidad de ser elásticos y tolerantes a fallos, no obstante,no existen pruebas que comprueben dichas características de cada una de lasarquitecturas.

4Estrategia de Solución

El propósito de este trabajo es la evaluación de dos requerimientos, elasticidady tolerancia a fallos en dos arquitecturas de aplicaciones Web, arquitecturasreactivas y microservicios. Para esto, se proponen tres pasos, los cuales seencuentran basados en el estándar de pruebas de software de la ISO-29119, comose evidencia en la figura 4.1.

Diseño e Implementación

de Pruebas

Configuración y Mantenimiento del entorno de

pruebas

Ejecución de pruebas

Especificación de pruebas

Requerimientos del entorno de

pruebas

Reporte del entorno de

pruebas

Resultado de las pruebas

Figure 4.1 Proceso de pruebas de Software ISO-29119

El primer paso consiste el diseño e implementación de las dos pruebas, enel cual se mencionan, el objetivo, la estrategia, las métricas y las conclusionesdeseadas por parte de la ejecución de las pruebas.

Posterior a la definición de las pruebas, se ejecuta el proceso deimplementación del entorno de pruebas. Para esto, se construye un prototipopara cada arquitectura. Además, se selecciona el IaaS (Infrastructure as aService) de AmazonWeb Services como el entorno de despliegue para las pruebas,dado que brinda servicios de Computo virtualizado, Balanceador de Carga, deautoescalado, y al fácil acceso a la consola de administración de las máquinasvirtuales; los cuales son necesarios para la ejecución, obtención de las pruebasde elasticidad y tolerancia a fallos.

Por último se ejecutan las pruebas, se recopilan las métricas y se procedea construir el análisis de los resultados. Este proceso de análisis incluye las

22

Estrategia de Solución 23

consideraciones para mejorar cada uno de los requerimientos en las arquitecturasy se exponen a partir de la observación y experimentación de todo el proceso.

A continuación, se presentan las herramientas y la especificación de laspruebas utilizadas como mecanismos para la construcción del análisis entre lasdos arquitecturas, reactiva y microservicios. Cada especificación de las pruebasse realiza con base en los conceptos básicos descritos por el estándar ISO-29119[51], por lo tanto se incluyen: una descripción de la estrategia de la prueba, lasmétricas a analizar y las herramientas usadas.

4.1 Prueba de ElasticidadComo se menciona en el capítulo 3, se cuenta con un concepto y una metodologíaanalítica para la observación de la elasticidad de un sistema. Klems en [47]propone una técnica y un concepto para cuantificar la elasticidad de un sistemade bases de datos relacionales. Con el fin de construir un análisis similar peroen arquitecturas de Aplicaciones Web. Primero se cambia el objetivo y elalcance de las pruebas. Luego, se abstraen los conceptos más importantes, quepermitan elaborar el análisis de elasticidad. Estos son explicados como parte dela estrategia y de las métricas a recopilar de las pruebas. Por último, se mencionael nuevo objetivo de la prueba, la estrategia y técnica de la prueba.

4.1.1 Objetivo

El objetivo de la prueba es dimensionar la capacidad de elasticidad de lasarquitecturas seleccionadas, para que así, se pueda concluir que arquitecturacumple de forma más efectiva con el requerimiento de elasticidad.

4.1.2 Estrategia

Para cumplir con el objetivo, se debe explicar el alcance y clasificar el tipo deprueba requerida para cuantificar la elasticidad. En ese orden de ideas, se deberealizar una prueba de carga (Cantidad de solicitudes) variable e incremental enun marco de tiempo. Esto permite obtener métricas suficientes para el análisis aposteriori. Estas habilitan la cuantificación de los cambios de recursos necesariosen el tiempo. Para el desarrollo de las pruebas, los recursos son el númerode instancias con la capacidad para atender solicitudes. En el prototipo de laarquitectura reactiva, los recursos equivalen al número de actores dentro delsistema, distribuidos en las diferentes máquinas virtuales. En la prueba, cadamáquina virtual cuenta con dos actores. Caso contrario, en microservicios, losrecursos se encuentran definidos por el número de máquinas virtuales o instanciasdel microservicio.

Primero se realiza el proceso de elección y definición de las métricas paraluego realizar la explicación del conjunto sucesivo de pasos a realizar durante laprueba.

Métricas

El proceso de abstracción de las métricas se realiza con base en las pruebasejecutas en la propuesta de Klems. Las seleccionadas y su justificación semencionan a continuación.

24 4.1. Prueba de Elasticidad

• Carga por unidad de tiempo: Esta prueba de elasticidad, es enesencia, una prueba de carga variable en el tiempo, por lo tanto esimperativo obtener los datos del número de solicitudes a someter en laprueba.

• Cantidad de recursos por unidad de tiempo: La prueba deelasticidad busca encontrar la relación entre la cantidad de recursosnecesarios, los cambios en la carga y el tiempo. Esta métrica permite hacerel diagnóstico si el sistema es capaz de adaptarse a los cambios durante eltiempo de ejecución de la prueba.

• Tiempo requerido por nodo para el inicio de procesamientode solicitudes: Esta métrica es una variación para calcular lamétrica de sobre-aprovisionamiento e infra-aprovisionamiento planteadapor Klems. La propuesta inicial considera los tiempos de respuesta decada solicitud, sin embargo para realizar una mejor comparación entre lasdos arquitecturas que permitan obtener las características y causas de lasdiferencias entre las arquitecturas, se obtienen los tiempos en que el sistemaes capaz de abastecerse de nuevos recursos.

Luego de la definición de las métricas, se propone un algoritmo para generarlos datos necesarios para el diseño de las pruebas. Además de los pasos descritosa continuación, también se muestran los datos a utilizar y por ende, el diseño delas pruebas.

1. Definir una carga base: En el contexto de este proyecto, la carga base seadopta como el número de solicitudes que el sistema es capaz de respondercon un mínimo de recursos en una unidad de tiempo. Se hizo una prueba deconcepto y se determinó que la carga base es de 12 solicitudes por recursoen un minuto.

2. Cálculo teórico de carga variable e incremental: Conforme a losresultados demostrados en [52] y con la carga base definida, se proyecta deforma lineal la carga en relación con el número de recursos. En la Figura4.2 se muestra el resultado de la proyección, obteniendo los datos pararealizar la prueba de carga.

0

12

24

36

48

60

72

84

0 60 120 180 240 300 360

Figure 4.2 Cambio de Carga en el tiempo: Número de solicitudes por unidad de tiempo


3. Cálculo teórico de recursos necesarios: El resultado de la proyección,como se observa en la Figura 4.2, se relaciona el número de recursosesperados durante los cambios de carga en el tiempo. Así pues, se tienecomo resultado el número de recursos esperados por unidad de tiempocomo se evidencia en la Figura 4.3

0

1

2

3

4

5

0

12

24

36

48

60

72

0 60 120 180 240 300

Recursos

Pe*cione

s

Segundos

Pe-ciones/Tiempo

Recursos/Tiempo

Figure 4.3 Cambio de Carga y de recursos en el tiempo: Número de solicitudes porunidad de tiempo

Análsis y Consideraciones

En la validación (capítulo 5) se presentan los resultados de la prueba deelasticidad, los cálculos realizados, y por último, teniendo como base laexperiencia general, se incluye un listado de consideraciones necesarias paramejorar la capacidad de elasticidad en cada una de las arquitecturas. Lasconsideraciones están relacionadas con la curva de aprendizaje para desarrollarteniendo en cuanta cada una de las arquitecturas, la implementación denuevos desarrollos para mejorar la elasticidad, idoneidad para requerimientosde sistemas transaccionales y restricciones de desarrollo.

4.2 Prueba de Tolerancia a Fallos

El siguiente requerimiento a ser evaluado, es la capacidad de un sistemareaccionar a la inyección de fallos. La prueba diseñada se centra en la inyecciónde fallos permanentes (la falla no permite la recuperación del recurso) y detipo silentes o de detención, con la intención de revisar el comportamientode las arquitecturas frente la presencia de este tipo de fallos y poder obtenerdos resultados: En principio una arquitectura capaz de soportar fallas y lasconsideraciones a tener en cuenta para mejorar la tolerancia a fallos.

La especificación de la prueba de Tolerancia a Fallos se exhibe a través de laexposición del objetivo y la estrategia a ser implementada para la ejecución dela prueba.

26 4.2. Prueba de Tolerancia a Fallos

4.2.1 Objetivo

El objetivo de la prueba es definir la arquitectura con una mejor tolerancia afallos e identificar las consideraciones necesarias para mejorarla.

4.2.2 Estrategia

Los fallos permanentes y de detención, son fallos sencillos de inyectar y comunesen los sistemas distribuidos, este tipo de fallos brindan herramientas suficientespara determinar la capacidad de tolerar los fallos de las arquitecturas, además selogra evitar variables exógenas a la arquitectura como algoritmos de validaciónpara brindar tolerancia a fallos.

El algoritmo para el diseño de la prueba es el siguiente:

1. Determinar el tipo de fallos a inyectar: El primer paso consiste endeterminar el tipo de fallos más pertinente para el diseño de la prueba.Como se menciona en el párrafo anterior, el tipo de fallos con mayorfacilidad para la inyección y que permite un panorama de la reacciónpor parte de la arquitectura frente a los fallos, son los permanentes yde detención. Es decir, la detención permanente de un recurso brindaun panorama de cual es la solución más pertinente entre las arquitecturaspresentes.

2. Determinar el número de fallos a inyectar: La prueba consiste en iraumentando el número de fallos inyectadas durante la prueba hasta generara un fallo total en la que el sistema no es capaz de responder a ningunasolicitud.

3. Determinar los tiempos para la inyección de cada fallo: Sedeben identificar los momentos en los que se inyectan los diferentes errores.En este caso, se ha definido que los instantes de tiempo interesantes sonaquellos en los que se incrementa la carga. Estos son deseados, con elpropósito de observar el comportamiento de la tolerancia a fallos en uncontexto elástico.

4. Determinar la cantidad solicitudes por unidad de tiempo: Unescenario interesante para determinar la reacción por parte de lasarquitecturas, es aquel en el que existen cambios de carga de formaincremental, de esta manera se desea conocer la reacción en los instantesque se van incrementando el número de solicitudes. En la Figura 4.4 seevidencia los datos de la prueba: La cantidad de solicitudes por unidad detiempo y el instante en el que se debe inyectar la falla. A partir de estaprueba se pretende observar el comportamiento y obtener las métricas parahacer el análisis pertinente.

Con el objetivo de identificar la arquitectura más pertinente sobre elrequerimiento de tolerancia a fallas, se seleccionaron las siguientes métricas:

4.2.3 Métricas

• Carga por unidad de tiempo: Métrica necesaria para el cálculo delporcentaje de las solicitudes inválidas.


0

1

2

3

4

5

0

12

24

36

48

60

72

0 60 120 180 240 300

Fallo

s

Pe)cione

s

Segundos

Pe-ciones/Tiempo

Fallos/Tiempo

Figure 4.4 Cambio de Carga e inyección de fallos en el tiempo

• Fallas inyectas por unidad de tiempo: Permite determinar la relaciónentre el número de fallas inyectadas y el porcentaje de solicitudes inválidas.Posibilita determinar si la cantidad de fallas determinan el estado generaldel sistema.

• Tiempo requerido para registrar fallas: Métrica que permitedimensionar el nivel de eficiencia de la arquitectura para identificar lasfallas.

• Porcentaje de solicitudes inválidas por unidad de tiempo: Elcálculo del porcentaje de solicitudes inválidas se determina mediante larazón entre la diferencia entre el total de solicitudes realizadas y el totalde solicitudes exitosas contra el total de solicitudes realizadas.

%solicitudesinválidas = solicitudestotal − solicitudesexitosas

solicitudestotal

Análisis y Consideraciones

Teniendo como base la experiencia y los resultados de la experimentación, seincluye un listado de consideraciones necesarias para mejorar la capacidad detolerancia a fallos en cada una de las arquitecturas. Las consideraciones estánrelacionadas con la curva de aprendizaje para desarrollar teniendo en cuantacada una de las arquitecturas, la implementación de nuevos desarrollos paramejorar la elasticidad, idoneidad para requerimientos de sistemas transaccionalesy restricciones de desarrollo.

4.3 Software

Teniendo en cuenta el tipo de pruebas, basadas en pruebas de carga y estrés,la herramienta más utilizada es JMeter [9] con la configuración del plug-in:Throughput Shaping Timer [53] el cual permite configurar el cambio en las cargasde forma incremental.

La configuración del plug-in se muestra en 4.1

28 4.3. Software

SolicitudesIniciales

SolicitudesFinales

Tiempo enSegundos

Incremento

24 24 60 036 36 60 1248 48 60 1260 60 60 12

Table 4.1 Configuración de prueba de carga para evaluar Elasticidad y Tolerancia y Fallos

5Validación

Para describir la validación de este trabajo se va a dividir el capítulo en lassiguientes secciones: Desarrollo de prototipos de las arquitecturas de aplicacionesWeb. Selección de IaaS. Ejecución de las pruebas y por último análisis de losresultados obtenidos.

5.1 Prototipo

Los prototipos desarrollados resuelven el mismo problema el cual se describemediante los siguientes requerimientos funcionales (Tabla 5.1 y Tabla 5.2).Con la finalidad de presentar un caso de estudio real, se han seleccionado dosrequerimientos funcionales de los especificados de un producto, simulador decréditos para el sector no bancarizado, creado dentro del marco de un proyectoconjunto con la Universidad de los Andes.

Los siguientes requerimientos funcionales muestran características, talescomo el uso intensivo de recursos computacionales, procesamiento de solicitudesen tiempos mayores a un segundo e.g., generación de créditos, que permitenpresentar un escenario de pruebas con ciertas ventajas: 1. Un escenariocontrolado en el que se establece un número fijo de solicitudes. De esta manera,se prevén el número de solicitudes en el tiempo, facilitando la obtención deresultados para la comparación de la elasticidad y la tolerancia a fallos. 2. Eluso intensivo de CPU y los tiempos mayores a 1 segundo, requeridos paradar respuesta a una solicitud, ofrecen 2 escenarios interesantes para evaluarlas arquitecturas desde el requerimiento de tolerancia a fallos. Primero, lasconsecuencias de la inyección de fallos a las solicitudes enviadas previamentea la inyección de los mismos. Segundo, errores en las solicitudes posteriores a losfallos. 3. Al implementar el caso de estudio del simulador de crédito. Se cuentacon proceso de validación de los resultados del procesamiento y del servicio. Asípues, se tiene un mecanismo para validar las respuestas a las solicitudes.

Para evitar efectos no deseados e influencia por parte de la elección dellenguaje, se escoge un lenguaje y un framework específico para la construcción delos prototipos. Se identifica los posibles lenguajes de programación y frameworks

29

30 5.2. Arquitectura Reactiva

RequerimientoFuncional

R1 - Simular uso intensivo de CPU

Resumen Se crea un algoritmo que simule el uso intensivode CPU. En este caso es el algoritmo de obtenerel número N de la sucesión de Fibonacci. Debetener un tiempo de ejecución de aproximado de5 segundos.

Entradas NingunaResultado Ninguno

Table 5.1 Requerimiento Funcional: R1 - Simular uso intensivo de CPU

RequerimientoFuncional

R2 - Retornar cuotas del proceso de liquidaciónde un Crédito

Resumen Se procede a realizar el proceso de liquidacióndel crédito bajo un algoritmo de liquidación yacreado. Se retorna las cuotas del crédito

Enntradas Crédito a LiquidarResultado Cuotas para liquidar el crédito.

Table 5.2 Requerimiento Funcional: R2 - Retornar cuotas del proceso de liquidación deun Crédito

de desarrollo. Se debe considerar la restricción de la arquitectura reactiva yaque se debe desarrollar con el framework Play!. Así pues, se decide implementarlos dos prototipos bajo el mismo framework con la salvedad de una soluciónorientada a microservicios y la otra bajo la arquitectura reactiva. La siguientediscusión se centra en el lenguaje de programación, Play! permite el desarrolloen Java y Scala. Para escoger el lenguaje de programación se construyen dosargumentos:

1. Lenguaje recomendado por TypeSage: El lenguaje recomendado es Scala,dado que las librerías de Akka están construidas en este lenguaje.

2. Desempeño: Scala es un lenguaje orientado a objetos pero tiene laparticularidad que permite todas las ventajas de un lenguaje funcionaly crear funciones basándose en el cálculo lambda. No obstante, el lenguajese ejecuta sobre la máquina virtual de Java, que al hacer pruebas dedesempeño se evidenció un costo de overhead en el caso de Scala. Poreste resultado, se decide que el lenguaje de programación debe ser unopara los dos prototipos y el desarrollo se inclina a ser en Scala debido a lasrecomendaciones para el mismo Framework Play!

5.2 Arquitectura ReactivaTypeSafe ha definido a Play! Framework como la plataforma reactiva y así comotambién es la concepción de una solución basada en una arquitectura Reactiva.

Validación 31

5.2.1 Play! Framework usando akka-clúster

Play! es un framework web el cual cumple con los principios de una arquitecturareactiva. Para esto hace una integración de múltiples frameworks y plataformas,que tienen como finalidad ofrecer un mejor soporte a la tolerancia a fallos y laelasticidad.

Akka

Akka es una plataforma que implementa el modelo de concurrencia basado enActores. Se caracteriza por la ejecución concurrente de los procesos, un sistemade tolerancia a fallos basado en la filosofía Let it Crash de Erlang e implementaun sistema de supervisión para reaccionar frente a la aparición de fallos en elsistema.

Clústering y Supervisión

Akka brinda la posibilidad de crear un clúster de actores distribuidos enmáquinas remotas [54], además de la configuración de un sistema de supervisiónque es capaz de reconocer las fallas en cada uno de los actores, esto hace que elsistema sea tolerante a fallos y resiliente, i.e. tiene la capacidad de recuperarsefrente a los fallos. También se debe considerar la solución para el requerimientode elasticidad, en este caso, se encuentra la solución de clúster y un protocolode descubrimiento de nuevos actores.

Protocolo de descubrimiento de actores

Akka propone un protocolo mediante el cual permite el descubrimiento de nuevosactores en el clúster denominado Gossip Protocol [55], este protocolo define unospuntos de entrada al clúster y un intercambio de mensajes dentro del mismoque facilita tanto el descubrimiento de nuevos actores como la identificación defallas.

Se desarrolla el prototipo teniendo en cuenta la arquitectura reactiva yse resaltan los siguientes componentes: El clúster con 4 máquinas virtualesdesplegadas en EC2, cada una con 2 actores definidos por el número de CPUsen las máquinas. Un FrontEnd para acceder a la aplicación mediante unnavegador web. Como se muestra en 5.1, las conexiones punteadas representanla conformación de un clúster mientras que la conexión con color sólido muestranla recepción de solicitudes por parte de los clientes web usando REST.

5.3 Arquitectura basada en microserviciosEl prototipo desarrollado basado en microservicios tiene la particularidad dedividir la aplicación en servicios y para esto se tienen varias soluciones con elpropósito de crear soluciones elásticas y tolerantes a fallos.

5.3.1 Patrones de descubrimiento

En la literatura se distinguen varios patrones para el descubrimiento de nuevosmicroservicios, entre estos se encuentran el descubrimiento mediante DNS(Domain Name System) el cual se identifican los microservicios dependiendo del

32 5.3. Arquitectura basada en microservicios

ActorActor

ActorActor

ActorActor

ActorActor

FrontEnd

Figure 5.1 Prototipo desarrollado con Cluster de Actores

subdominio al cual pertenecen. El siguiente patrón se basa desde el cliente querealiza las solicitudes, en este caso el cliente debe consultar en algún servicio deregistro la ubicación de los servicios para generar nuevas solicitudes, un ejemplode este tipo de patrón es implementado por Netflix SSO. Por su parte, AmazonWeb Services ofrece el servicio de Elastic Load Balancer (ELB), el cual es usadopara distribuir carga usando algoritmo de Round Robin hacia las instanciasreconocidas, en este caso se utiliza un patrón desde el lado del servidor, asípues el ELB y los microservicios se encuentran en constante comunicación quepermiten descubrir y distribuir carga de forma automática a nuevos serviciosdisponibles.

5.3.2 Tolerancia a fallos

En [56] se describen patrones a utilizar para obtener resultados deseados en latolerancia a fallos, entre los cuales se menciona el bulkhead, en esencia el patrón sebasa en la replicación y redundancia de los microservicios, en una solución dondeexiste un balanceador de carga capaz de distribuir las solicitudes realizadas alsistema.

Con base en lo anterior, se desarrolla un prototipo teniendo en cuenta elpatrón de descubrimiento ofrecido por el Amazon Web Services, el ELB, y quefacilita el descubrimiento de nuevos servicios en un entorno elástico. Ademásse tiene en cuenta en el diseño el patrón de bulkhead para mantener un sistematolerante a fallos. En la Figura 5.2 se muestran que todas las conexiones entrelos microservicios es a través de REST, lo cual hace parte de las arquitecturasde microservicios.

Validación 33

microServicio

microServicio

microServicio

microServicio

FrontEnd

Figure 5.2 Prototipo desarrollado con microservicios

5.4 Selección del IaaS (Infrastructure as a Service)

El IaaS seleccionado es Amazon Web Services, debido a la oferta de serviciosque permiten el desarrollo de los prototipos, en especial para implementar laarquitectura basada en microservicios. ELB es un elemento importante para laintegración y descubrimiento de nuevos microservicios.

Es necesario mencionar, que no se ejecutan las pruebas usando mecanismosofrecidos por AWS, como el autoscaling. Debido a los tiempos de autoscaling ydemás variables, tales como warmup, que podrían afectar los resultados de laspruebas.

5.5 Ejecución de las pruebas

Además de los despliegues descritos en la sección anterior, se cuenta con unamáquina virtual adicional para realizar las pruebas. Todas las máquinas usadasdurante las pruebas son: c4.large, cuentan con 2 CPU, Memoria RAM de 3.75GB y Discos SSD 8 GB con 24 IOPS (Input/Output per Second) con ráfagashasta 3000 IOPS.

Cada prueba se ejecuta 3 veces, se calculan los promedios de todo teniendoen cuenta cada una de las métricas establecidas.

En las siguientes secciones se muestran los resultados obtenidos para cadauna de las pruebas.

5.5.1 Prueba de elasticidad

Esta sección tiene como propósito mostrar los resultados de las pruebasejecutadas en cada una de las arquitecturas, posteriormente realizar el análisisde los resultados y por último una sección de observaciones con el objetivo de

34 5.5. Ejecución de las pruebas

analizar las causas, limitaciones y consideraciones para mejorar los resultadosactuales de las pruebas en el requerimiento de elasticidad.

Arquitectura reactiva

Los resultados de las pruebas quedan plasmadas en la Tabla 5.3, se puede notarque la prueba consiste en cambios de la cantidad de solicitudes en el tiempo, asíse va incrementando de forma escalonada cada 60 segundos, con estos cambiosvienen acompañados del número de recursos necesarios para satisfacerlos. Cada60 segundos se espera un nuevo recurso, de esta manera este se convierte enel tiempo esperado, el extra de los resultados va a ser tomado como base parael cálculo del sobre-aprovisionamiento e infra-aprovisionamiento. Además, semuestran los cálculos adaptados de la fórmula propuesta por Klems, ahora secalcula como el cociente entre los tiempos esperados y obtenidos, se basan enlos tiempos de aprovisionamiento de nuevos recursos. Estos resultados indicanque no hay un sobre-aprovisionamiento ni infra-aprovisionamiento debido a lapequeña diferencia entre los tiempos esperados y los obtenidos.

Por último, se calcula la elasticidad, para lo cual se promedian los valores delos grupos de pruebas como se menciona en la propuesta de Klems y se realiza elcálculo usando la fórmula de elasticidad. En este caso, el resultado de elasticidades 1,004, que permite concluir que es una solución bastante elástica.

En la Figura 5.3 se muestra la mínima diferencia entre los recursos esperadosen un margen de tiempo y los recursos aprovisionados en el tiempo.

NúmerodeSolicitudes

Tiempo(Seg)

CantidaddeRecursos

TiempoEsperado(Seg)

TiempoResultado(Seg)

Infraaprovisio-namiento

Sobreaprovisio-namiento

24 0 1 0 0 0 036 60 2 60 60,48 1,008 0,9948 120 3 120 120,57 1,005 1,0060 180 4 180 180,56 1,002 1,00

Table 5.3 Resultados elasticidad - Arquitectura Reactiva

0

1

2

3

4

5

0

12

24

36

48

60

72

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260

Recursos

Pe*cione

s

Segundos

Pe.ciones/Tiempo

RecursosEsperados/Tiempo

nuevosrecursos/.empo

Figure 5.3 Resultados elasticidad - Arquitectura Reactiva

Validación 35

Microservicios

Los resultados de las pruebas ejecutadas sobre el segundo prototipo (arquitecturabasada en microservicios) se muestran en la Tabla 5.4, los cálculos desobre-aprovisionamiento e infra-aprovisionamiento son mayores comparados conlos obtenidos en las pruebas sobre el prototipo de la arquitectura reactiva. Porconsiguiente, el valor calculado para la elasticidad es 0,97 lo que demuestra queexiste un buen nivel de elasticidad debido a que la diferencia entre los tiemposesperados y obtenidos es cercana a 0.


Tiempo(Seg)

CantidaddeRecursos

TiempoEsperado

TiempoResultado

Infraaprovisio-namiento

Sobreaprovisio-namiento

24 0 1 0 0 0 036 60 2 60 66 1,1 0,909148 120 3 120 126,87 1,057 0,94660 180 4 180 189 0,7875 1,267

Table 5.4 Resultados elasticidad - Arquitectura basada en Microservicios

En la Figura 5.4 se evidencia la diferencia entre los tiempos esperados y losobtenidos para el aprovisionamiento de cada recurso en el tiempo. En contrastecon los resultados de la arquitectura reactiva, se presenta un mayor margen detiempo necesario para el aprovisionamiento de los nuevos recursos.

0

1

2

3

4

5

0

12

24

36

48

60

72

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260

Recursos

Pe*cione

s

Segundos

Pe.ciones/Tiempo

RecursosEsperados/Tiempo

NuevosRecursos/Tiempo

Figure 5.4 Resultados elasticidad - Arquitectura basada en Microservicios

Conclusiones

Los resultados de las pruebas de las dos arquitecturas permiten concluir que unaarquitectura reactiva tiene mejor elasticidad comparada con una arquitecturabasada en microservicios. Ahora bien, se quiere identificar cuales son loselementos de la arquitectura que permite una mejor elasticidad.

En el caso de la arquitectura reactiva se cuenta con un clúster de actores,con las pruebas se evidencia que el proceso de configuración del clúster y losretardos para agregar nuevos recursos computaciones son bastante pequeños. Porel contrario, en una arquitectura de microservicios y usando una implementacióndel patrón del lado del cliente como lo es ELB, los tiempos de configuración yde aprovisionamiento de nuevos recursos son mayores.


5.5.2 Prueba de tolerancia a fallos

El propósito de esta sección es presentar los resultados de las pruebas detolerancia a fallos en cada una de las arquitecturas. Con los resultados serealiza un análisis para concluir la arquitectura idónea para la tolerancia afallos, por último se desea mencionar causas, limitaciones y consideraciones delas arquitecturas para mejorar los resultados obtenidos.

Arquitectura reactiva

Los resultados de las pruebas de tolerancia a fallos se encuentran en la Tabla5.5, se evidencia los valores de las solicitudes y el marco de tiempo en quese realizaron, además se crea un conteo inicial y un conteo esperado por cadaconjunto de solicitudes, una vez ejecutada las pruebas se realiza el muestreo delas solicitudes fallidas y con los valores anteriores se hace el cálculo del porcentajede falla, como se logra observar en la última columna de la tabla.


Tiempo(Seg)

ConteoInicial

ConteoFinal

NúmerodeErrores

Númerode Fallas

Porcentaje%

24 60 0 24 0 0 036 60 24 60 1 16 26,7748 60 60 108 2 20 18,5260 60 108 168 3 39 23,21

Table 5.5 Resultados Tolerancia a Fallas - Arquitectura reactiva

En la Figura 5.5 se desea representar las diferentes relaciones con respectoal tiempo, por una parte la relación entre los cambios de carga, el número deinyección de errores y el porcentaje de error al inyectar cada error.

Los resultados reflejan que existe una relación entre el número de fallospresentes en el sistema y las solicitudes fallidas, sin embargo el porcentaje defallas no se presenta como una relación respecto al número de fallas inyectadas.Se puede deducir que aunque se presenta un número mayor de solicitudes fallidaslas pérdidas se concentran en el 22,8% sin importar el número de fallas. Así pues,se debe tener en cuenta que el sistema es susceptible a fallar este porcentaje concualquier falla. Lo anterior se puede observar en la Figura 5.6; no existe unarelación entre el número de solicitudes fallidas y el porcentaje de fallas, ahorabien se observa que el porcentaje de fallas en promedio se encuentra cerca al22,8%.

Durante la experimentación se encuentra que existen tiempos significativospara considerar un recurso ya no se encuentra disponible y se encuentre en lafacultad actualizar el estado del clúster, de esta manera las solicitudes se siguenenviando a estos recursos.

Arquitectura basada en microservicios

En la Tabla 5.6 y en las Figuras 5.7, 5.8 se encuentran los datos obtenidos delas pruebas, de los cuales se logra resaltar la relación directa entre el númerode fallas inyectadas y el porcentaje de fallas encontradas. Adicionalmente, elnúmero de fallas en las pruebas es bajo comparado con las fallas encontradas en

Validación 37

0

1

2

3

4

0

12

24

36

48

60

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260

ErroresInyectado

s

Pe/cione

syPo

rcen

taje

Segundos

Pe.ciones/Tiempo

PorcentajedeFallos

ErroresInyectados/Tiempo

Figure 5.5 Resultados Tolerancia a Fallos - Arquitectura Reactiva

Figure 5.6 Resultados Tolerancia a Fallos - Arquitectura Reactiva

las pruebas de la arquitectura reactiva. Con estos resultados, los desarrolladoresdeben tener presente que se pueden presentar más solicitudes fallidas con ungran número de fallas presentes, además de crear estrategias para solucionarproblemas relacionado con el control de fallas. Para esto, existen patrones detolerancia a fallos para microservicios propuestos por Krause [Krause2015],que en esencia son estrategias de replicación y redundancia. Lo que demuestrasimplicidad como una característica de la arquitectura, pero al mismo tiempouna limitación. Pues al solucionar estos inconvenientes a través de algoritmosy elementos de software, se crean efectos secundarios como sincronización delos servicios, estados en el procesamiento y aplicaciones robustas difíciles demodificar. Ahora bien, los autores de microservicios defienden la simplicidadcomo una característica de los microservicios, cualquier inconsistencia frente aeste principio, se podría convertir en un anti-patrón.

Conclusiones

Dentro del proceso de desarrollo y la experimentación, se logran observar laexistencia de mecanismos adicionales para mejorar la tolerancia a fallas enarquitecturas reactivas, entre los que se encuentran DeadLetters, algoritmoscapaces de reiniciar el sistema de actores (e.g., Akka en este momento versión2.4 no tienen la capacidad de recrear el estado interno de un actor paracontinuar la ejecución, pero si se logra reiniciar bajo el sistema de supervisión), la



Tiempo(Seg)

ConteoInicial

ConteoFinal

NúmerodeErrores

Númerode Fallas

Porcentaje%

24 60 0 24 0 0 036 60 24 60 1 3 5,0048 60 60 108 2 7 6,4860 60 108 168 3 13 7,74

Table 5.6 Resultados Tolerancia a Fallas - Arquitectura basada en microservicios

0

1

2

3

4

0

12

24

36

48

60

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260

ErroresInyectado

s

Pe/cione

syPo

rcen

taje

Segundos

Pe.ciones/Tiempo

PorcentajedeFallos

Errores/Tiempo

Figure 5.7 Resultados Tolerancia a Fallos - Arquitectura basada en microservicios

sincronización del clúster a través de algoritmos de consenso como el mencionadoen [57], permiten decidir y reaccionar frente a solicitudes fallidas o incompletas.Lo que se puede inducir, que este tipo de mecanismos pueden ser significativospara el desarrollo de aplicaciones transaccionales.

Para las arquitecturas basadas en microservicios, se logra evidenciar que lasimplicidad de la arquitectura y de los mecanismos no es para un sistema robustocon capacidad de resiliencia (capacidad de recuperarse frente a un fallo), noobstante, la facilidad para extender las soluciones permiten la implementación yuso de mecanismos que brinden la capacidad de resiliencia.

Validación 39

00,010,020,030,040,050,060,070,080,09

0 0,5 1 1,5 2 2,5 3 3,5

Porcen

taje

ErroresInyectados

Porcentaje

Figure 5.8 Resultados Tolerancia a Fallos - Arquitectura basada en microservicios

6Conclusiones y trabajo futuro

Esta tesis implementa y valida una serie de pruebas que permiten demostrar lacomparación de dos arquitecturas de aplicaciones Web, arquitectura reactivay microservicios. La comparación, así como también la elaboración de lasconsideraciones, para mejorar los requerimientos de elasticidad y tolerancia afallos se convierten en herramientas que facilitan la elección de la arquitecturade nuevos proyectos Web. Para resolver con el objetivo redactado en el capítulo1 se crean dos prototipos usando las dos arquitecturas propuestas, luego sediseñan y ejecutan un conjunto de pruebas sobre los prototipos construidosy por último se recogen datos y resultados con los cuales se concluye que:Dadas las ventajas de la creación de clúster y los tiempos de convergenciapara aprovisionar nuevos recursos computacionales sobre el mecanismo dedescubrimiento de los microservicios, una arquitectura reactiva es la mejoropción frente al requerimiento de elasticidad. Con respecto al requerimiento detolerancia a fallos, los microservicios, considerando las ventajas de los sencillosmecanismos de comunicación y se evita mantener sincronización de un clúster,las pérdida información es baja, no obstante no se cuenta con mecanismos deresiliencia para recuperar los datos fallidos. Caso contrario, en el caso de laarquitectura reactiva se cuentan con mecanismos para recuperar la aplicaciónde los fallos pero se deben considerar durante el desarrollo lo que convierte laaplicación en más robusta y al mismo tiempo más costosa de desarrollar.

El documento también presenta un conjunto de consideraciones para cumplircon los requerimientos. Respecto a la elasticidad, los desarrolladores demicroservicios deben considerar los patrones y software para el descubrimientode nuevos recursos, los tiempos que tardan en agregar y de esta manera ajustarla aplicación a las necesidades.

Para la tolerancia a fallos, una arquitectura reactiva se debe considerartodos los elementos que permitan brindar mejora en la tolerancia a fallos yconstruir una aplicación robusta con los elementos brindados. Para el casode los microservicios se deben considerar aplicaciones sensibles a pocos fallos yconsiderar el manejo de mecanismos como la consistencia eventual de los datos.

Es de destacar, que estas conclusiones se encuentran en marco deaplicaciones con características específicas, tales como el uso intensivo de recursos

40

Conclusiones y trabajo futuro 41

computacionales, procesamiento de solicitudes en tiempos mayores a un segundo.Como trabajo futuro, se desea conocer el comportamiento de una arquitectura

híbrida, en la que se pueda diseñar una aplicación usando microservicios perotambién con elementos de la arquitectura reactiva. También, la construcciónde una herramienta, que permita automatizar los cálculos de elasticidad deun sistema teniendo en cuenta la definición de Klems en [47] y la adaptaciónpresentada en este documento. Por último, extender la experimentación aotro tipo de aplicaciones con otras características: Aplicaciones transaccionales,aplicaciones en tiempo real, entre otras.

Bibliografía

[1] Internet World Statistics. Internet World Statistics. Visto en Julio del 2015.url: http://www.internetworldstats.com/stats.htm.

[2] Typesafe Inc. Akka Scala Documentation. Tech. rep., p. 390.[3] Reactive Manifesto Organisation. The Reactive Manifesto. Nov. 2014. url:

http://www.reactivemanifesto.org.[4] Martin Fowler. Microservices. 2014. url: http://martinfowler.com/

articles/microservices.html.[5] Yahoo Inc. Yahoo Cloud Serving Benchmark. 2010. url: http://labs.

yahoo . com / news / yahoo - cloud - serving - benchmark/ (visited on01/01/2015).

[6] SPEC. SPECweb. 2015. (Visited on 01/01/2015).[7] Tpc.org. Transactional Processing Performance Counci. 2015. (Visited on

01/01/2015).[8] Alessio Gambi, Waldemar Hummer, and Schahram Dustdar. “Automated

testing of cloud-based elastic systems with AUToCLES”. In: 2013 28thIEEE/ACM International Conference on Automated Software Engineering,ASE 2013 - Proceedings (2013), pp. 714–717. doi: 10.1109/ASE.2013.6693140.

[9] Apache. Jmeter. 2015. url: http : / / jmeter . apache . org (visited on01/01/2015).

[10] Len Bass, Paul Clements, and Rick Kazman. Software Architecture inPractice, 2nd Edition. isbn: 8177589962.

[11] Erich Gamma et al. Design Patterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley, 1995. isbn: 0-201-63361-2.

[12] Microservices.io. Microservices patterns. 2015. url: www.microservices.io/patterns.

[13] Chris Richardson. “InfoQ: Microservices: Decomposing Applications forDeployability and Scalability”. In: Infoq: Microservices eMag Issue 16(2014), pp. 4–11.

[14] Nordic APIs. Microservices Anti-Patterns. 2014. url: https : / / www .youtube.com/watch?v=I56HzTKvZKc.

[15] Tudor Dumitra and Priya Narasimhan. “A study of unpredictabilityin fault-tolerant middleware”. In: Computer Networks 57.3 (2013),pp. 682–698. issn: 13891286. doi: 10.1016/j.comnet.2012.10.015.

[16] Microservices.io. Microservices Monolithic patterns. 2015. url: http://microservices.io/patterns/monolithic.html.

42

http://www.internetworldstats.com/stats.htm

http://www.reactivemanifesto.org

http://martinfowler.com/articles/microservices.html

http://martinfowler.com/articles/microservices.html

http://labs.yahoo.com/news/yahoo-cloud-serving-benchmark/

http://labs.yahoo.com/news/yahoo-cloud-serving-benchmark/

http://dx.doi.org/10.1109/ASE.2013.6693140

http://dx.doi.org/10.1109/ASE.2013.6693140

http://jmeter.apache.org

www.microservices.io/patterns

www.microservices.io/patterns

https://www.youtube.com/watch?v=I56HzTKvZKc

https://www.youtube.com/watch?v=I56HzTKvZKc

http://dx.doi.org/10.1016/j.comnet.2012.10.015

http://microservices.io/patterns/monolithic.html

http://microservices.io/patterns/monolithic.html

Bibliografía 43

[17] Andrew S. Tanenbaum and Maarten van Steen. Distributed Systems:Principles and Paradigms (2Nd Edition). Upper Saddle River, NJ, USA:Prentice-Hall, Inc., 2006. isbn: 0132392275.

[18] Arnon Rotem-Gal-Oz. Fallacies of Distributed Computing Explained. 2006.url: http://www.rgoarchitects.com/Files/fallacies.pdf.

[19] World Wide Web Foundation. History of the Web. 2014. url: http://webfoundation.org/about/vision/history-of-the-web/.

[20] Netflix.com. Microservices at Netflix. 2014. url: https://www.youtube.com/watch?v=LEcdWVfbHvc.

[21] Tony Mauro. Adopting Microservices at Netflix: Lessons for ArchitecturalDesign. 2015. url: http : / / nginx . com / blog / microservices - at -netflix-architectural-best-practices/.

[22] Wt Tsai et al. “Introduction to Service-Oriented Computing”. In: ArizonaState University (2006). url: http://info.lnpu.edu.cn/website/jpkc/rjgc/ywzl/Introduction%20to%20Service- Oriented%20Computing.pdf.

[23] Thomas Erl. SOA Principles of Service Design. PrenticeHall/PearsonPTR, 2008, pp. 37–54.

[24] Thomas Erl. Service-Oriented Architecture: Concepts, Technology andDesign. Ed. by Inc. Pearson Education. Prentice Hall, 2005. isbn:0-13-185858-0.

[25] Douglas K Barry and David Dick. “Chapter 3 - Web Servicesand Service-Oriented Architectures”. In: Web Services, Service-orientedArchitectures, and Cloud Computing (Second Edition). Second. MorganKaufmann, 2013. Chap. 3, pp. 15–33. doi: 10.1016/B978-0-12-398357-2.00003-8. url: http://www.sciencedirect.com/science/article/pii/B9780123983572000038.

[26] H He. “What is service-oriented architecture”. In: Publicação eletrônica em(2003), pp. 1–5. url: http://www.nmis.isti.cnr.it/casarosa/SIA/readings/SOA%5C_Introduction.pdf.

[27] Arnon Rotem-Gal-Oz. “Practical SOA - SAGA pattern”. In: (), pp. 1–8.[28] Oasis. “Reference Model for Service Oriented Architecture”. In: Public

Review Draft 2 August (2006), pp. 1–28. url: http : / / docs . oasis -open.org/soa-rm/v1.0/soa-rm.pdf.

[29] IBM. Websphere Enterprise Service Bus. 2015. url: http://www-03.ibm.com/software/products/es/wsesb.

[30] Oracle Inc. Oracle Service Bus and Oracle Fusion Middleware. 2015. url:http://www.oracle.com/technetwork/middleware/service- bus/overview/index.html.

[31] Tigerteam ApS. Microservices: It’s not (only) size that matters, it’s (also)how you use them. 2014. url: https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-1/.

[32] Johan Uhle. “On Dependability Modeling in a Deployed MicroserviceArchitecture Author”. In: (2014).

http://www.rgoarchitects.com/Files/fallacies.pdf

http://webfoundation.org/about/vision/history-of-the-web/

http://webfoundation.org/about/vision/history-of-the-web/

https://www.youtube.com/watch?v=LEcdWVfbHvc

https://www.youtube.com/watch?v=LEcdWVfbHvc

http://nginx.com/blog/microservices-at-netflix-architectural-best-practices/

http://nginx.com/blog/microservices-at-netflix-architectural-best-practices/

http://info.lnpu.edu.cn/website/jpkc/rjgc/ywzl/Introduction%20to%20Service-Oriented%20Computing.pdf



http://dx.doi.org/10.1016/B978-0-12-398357-2.00003-8

http://dx.doi.org/10.1016/B978-0-12-398357-2.00003-8

http://www.sciencedirect.com/science/article/pii/B9780123983572000038

http://www.sciencedirect.com/science/article/pii/B9780123983572000038

http://www.nmis.isti.cnr.it/casarosa/SIA/readings/SOA%5C_Introduction.pdf

http://www.nmis.isti.cnr.it/casarosa/SIA/readings/SOA%5C_Introduction.pdf

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

http://www-03.ibm.com/software/products/es/wsesb

http://www-03.ibm.com/software/products/es/wsesb

http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html

http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html

https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-1/



44 Bibliografía

[33] Mark Little. “InfoQ: Microservices and SOA”. In: Infoq: MicroserviceseMag Issue 16 (2014), pp. 12–15.

[34] Robert C. Martin. “The Single Responsibility Principle”. In: Agile SoftwareDevelopment, Principles, Patterns, and Practice. 2002, pp. 149–154.

[35] Zhanyong Wan and Paul Hudak. “Functional Reactive Programming fromFirst Principles”. In: SIGPLAN Not. 35.5 (May 2000), pp. 242–252. issn:0362-1340. doi: 10.1145/358438.349331. url: http://doi.acm.org/10.1145/358438.349331.

[36] Haskell Group. Haskell Web Site. 2014. url: http://haskell.cs.yale.edu/publications/.

[37] Conal Elliott and Paul Hudak. “Functional Reactive Animation”.In: International Conference on Functional Programming. June 1997,pp. 163–173.

[38] Martin Odersky. “Deprecating the Observer Pattern with Scala . React”.In: Technical Report (2012).

[39] Play Framework. Play Web Framework. 2015. url: playframework.com.[40] Typesafe Inc. Reactive Stocks Tutorial. Tech. rep. 2015.[41] Janusz Kowalik. “ACTORS: A Model of Concurrent Computation

in Distributed Systems (Gul Agha)”. In: SIAM Review 30.1 (1988),pp. 146–146. issn: 0036-1445. doi: 10.1137/1030027.

[42] Nikolas Roman Herbst, Samuel Kounev, and Ralf Reussner. “Elasticityin Cloud Computing : What It Is , and What It Is Not”. In: Presentedas part of the 10th International Conference on Autonomic Computing(2013), pp. 23–27. url: http://sdqweb.ipd.kit.edu/publications/pdfs/HeKoRe2013-ICAC-Elasticity.pdf.

[43] Á Fernández-Dıaz, C Benac-Earle, and L Fredlund. “Adding distributionand fault tolerance to Jason”. In: Science of Computer Programming 98.98(2015), pp. 205–232. issn: 0167-6423. doi: 10.1016/j.scico.2014.01.007. url: www.elsevier.com/locate/scico%20http://dx.doi.org/10.1016/j.scico.2014.01.007.

[44] R Jhawar and V Piuri. “Chapter 1 - Fault Tolerance and Resilience inCloud Computing Environments”. In: Computer and Information SecurityHandbook. Elsevier Inc., 2013, pp. 125–141. isbn: 9780123943972 (ISBN).doi: 10.1016/B978- 0- 12- 394397- 2.00007- 6. url: http://www.scopus . com / inward / record . url ? eid = 2 - s2 . 0 - 84883954888 % 5C &partnerID=40%5C&md5=fe338291b01cb5f2741ac1732fb1c541.

[45] Lorenzo Falai. “Observing , Monitoring and Evaluating DistributedSystems”. PhD thesis. 2007.

[46] Asmaa Al-Naqi, Ahmet T. Erdogan, and Tughrul Arslan. “DynamicFault-Tolerant three-dimensional cellular genetic algorithms”. In: Journalof Parallel and Distributed Computing 73.2 (2013), pp. 122–136. issn:07437315. doi: 10.1016/j.jpdc.2012.09.011. url: http://dx.doi.org/10.1016/j.jpdc.2012.09.011.

[47] Markus Klems. “Benchmarking Scalability and Elasticity of DistributedDatabase Systems”. In: (2014), pp. 1219–1230. issn: 21508097.

http://dx.doi.org/10.1145/358438.349331

http://doi.acm.org/10.1145/358438.349331

http://doi.acm.org/10.1145/358438.349331

http://haskell.cs.yale.edu/publications/

http://haskell.cs.yale.edu/publications/

playframework.com

http://dx.doi.org/10.1137/1030027

http://sdqweb.ipd.kit.edu/publications/pdfs/HeKoRe2013-ICAC-Elasticity.pdf

http://sdqweb.ipd.kit.edu/publications/pdfs/HeKoRe2013-ICAC-Elasticity.pdf

http://dx.doi.org/10.1016/j.scico.2014.01.007

http://dx.doi.org/10.1016/j.scico.2014.01.007

www.elsevier.com/locate/scico%20http://dx.doi.org/10.1016/j.scico.2014.01.007

www.elsevier.com/locate/scico%20http://dx.doi.org/10.1016/j.scico.2014.01.007

http://dx.doi.org/10.1016/B978-0-12-394397-2.00007-6

http://www.scopus.com/inward/record.url?eid=2-s2.0-84883954888%5C&partnerID=40%5C&md5=fe338291b01cb5f2741ac1732fb1c541



http://dx.doi.org/10.1016/j.jpdc.2012.09.011



Bibliografía 45

[48] Rodrigo Felix De Almeida and Javam C Machado. “BenchXtend : a toolto benchmark and measure elasticity of cloud databases”. In: (2013),pp. 93–98.

[49] Andreas Weber, Nikolas Herbst, and Samuel Kounev. “Towards a ResourceElasticity Benchmark for Cloud Environments”. In: March (2014). doi:10.1145/2649563.2649571.

[50] T.K. Tsai, R.K. Iyer, and D. Jewitt. “An approach towards benchmarkingof fault-tolerant commercial systems”. In: Proceedings of AnnualSymposium on Fault Tolerant Computing June (1996), pp. 314–323. issn:07313071. doi: 10.1109/FTCS.1996.534616. url: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=534616.

[51] Working Group 26 (WG26) of the ISO/IEC JTC1/SC7 Software andSystems Engineering committee. The International Software TestingStandard - ISO/IEC/IEEE 29119. 2013. url: http : / / www .softwaretestingstandard.org/index.php.

[52] Mauricio Verano et al. “Re-architecting a JEE On-Premise WebApplication to Deploy It in the Cloud”. In: Workshops Proceedings of theGlobal Communications Conference, GLOBECOM 2015, 6-10 December2015, San Diego, California, USA. IEEE, En preparacin, 2015.

[53] Jmeter Plugins. Throughput Shaping Timer. 2015. url: http://jmeter-plugins.org/wiki/ThroughputShapingTimer/.

[54] Akka. Cluster Usage. 2015. url: http : / / doc . akka . io / docs / akka /snapshot/scala/cluster-usage.html.

[55] Jonas Bonr. Akka Cluster Implementation Notes. 2015. url: https://gist.github.com/jboner/7692270.

[56] Lucas Krause. Microservices: Patterns and applications: Designingfine-grained services by applying patterns. Amazon inc., 2015.

[57] Diego Ongaro and John Ousterhout. “In Search of an UnderstandableConsensus Algorithm”. In: 2014 USENIX Annual Technical Conference(USENIX ATC 14). Philadelphia, PA: USENIX Association, June 2014,pp. 305–319. isbn: 978-1-931971-10-2. url: https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro.

http://dx.doi.org/10.1145/2649563.2649571

http://dx.doi.org/10.1109/FTCS.1996.534616

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=534616

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=534616

http://www.softwaretestingstandard.org/index.php

http://www.softwaretestingstandard.org/index.php

http://jmeter-plugins.org/wiki/ThroughputShapingTimer/

http://jmeter-plugins.org/wiki/ThroughputShapingTimer/

http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html

http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html

https://gist.github.com/jboner/7692270

https://gist.github.com/jboner/7692270

https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro

https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro

análisis de elasticidad y tolerancia a fallos en

Documents