universidad de guayaquilrepositorio.ug.edu.ec/bitstream/redug/32755/1/b-cisc-ptg...de la universidad...

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES

ESTUDIO COMPARATIVO ENTRE UNA ARQUITECTURA CON

MICROSERVICIOS Y CONTENEDORES DOCKERS Y UNA

ARQUITECTURA TRADICIONAL (MONOLÍTICA)

CON COMPROBACIÓN APLICATIVA

PROYECTO DE TITULACIÓN

Previa a la obtención del Título de:

INGENIERO EN SISTEMAS COMPUTACIONALES

AUTOR:

JOSÉ LUIS PACHECO LAJE

TUTOR:

ING. PEDRO MONCADA ROMERO

GUAYAQUIL – ECUADOR

2018

REPOSITARIO NACIONAL EN CIENCIA Y TECNOLOGÍA

FICHA DE REGISTRO de tesis

TITULO Y SUBTITULO: “ESTUDIO COMPARATIVO ENTRE UNA ARQUITECTURA CON MICROSERVICIOS Y CONTENEDORES DOCKERS Y UNA ARQUITECTURA TRADICIONAL (MONOLÍTICA) CON COMPROBACIÓN APLICATIVA”

REVISORES:

INSTITUCIÓN:


FACULTAD:

Ciencias Matemáticas y Físicas

CARRERA:

FECHA DE PUBLICACIÓN: 09/13/2018 N. DE PAGS: 101

ÁREAS TEMÁTICAS: Estudio comparativo entre dos Arquitecturas

PALABRAS CLAVE: Microservicios, Dockers, Contenedor, Imagen, Tradicional

RESUMEN: En este presente trabajo se investiga la comparación entre una arquitectura de microservicios en contenedores Dockers y una arquitectura tradicional donde su enfoque principal es observar las ventajas y desventajas de cada arquitectura. En el primer capítulo se abarcan los objetivos de esta investigación, tales como el análisis del impacto en el tiempo de implementación al usar una arquitectura de microservicios. Además, se estudiarán los conceptos principales para entender cada arquitectura, como, por ejemplo: razones para utilizar los microservicios, qué es un contenedor de software e imágenes, las diferencias de virtualización y contenedores. La metodología que se utilizó es la documental y bibliográfica, la cual tiene como enfoque ampliar, estudiar y profundizar el problema. Adicionalmente se detallan en los anexos los comandos básicos para crear y ejecutar un contenedor con una imagen de un microservicio.

N. DE REGISTRO (en base de datos): N. DE CLASIFICACIÓN:

DIRECCIÓN URL (tesis en la web):

ADJUNTO URL (tesis en la web):

ADJUNTO PDF: SI X NO

CONTACTO CON AUTORES/ES: Teléfono:

0980411221

E-mail:

[email protected]

CONTACTO EN LA INSTITUCION: Nombre: Ab. Juan Chávez A.

Teléfono: 042307729

mailto:[email protected]

APROBACIÓN DEL TUTOR

En mi calidad de Tutor del trabajo de investigación, Ing. Pedro Moncada

Romero elaborado por el Sr.

José Luis Pacheco Laje, Alumno titulado de la Carrera de Ingeniería en

Sistemas Computacionales, Facultad de Ciencias Matemáticas y Físicas

de la Universidad de Guayaquil, previo a la obtención del Título de

Ingeniero en Sistemas Computacionales, me permito declarar que luego

de haber orientado, estudiado y revisado, la Apruebo en todas sus partes.

Atentamente,

Ing. Pedro Moncada Romero

IV

DEDICATORIA

A:

Dios por guiarme en cada

paso que doy, por iluminar

mi mente y permitir llegar a

cumplir mis objetivos.

Mi esposa Hariana

González, por su apoyo

incondicional, por estar

siempre apoyándome pese

a los momentos difíciles

que pasamos, siempre

brindándome su cariño y

amor.

Mi Hijo Luis que es el motor

de mi vida, la razón por el

cual cada día me esforzaré

para ofrecerle un futuro

mejor.

Mis Padres, piezas

fundamentales en mi vida

que gracias a su apoyo

incondicional he logrado

llegar hasta aquí.

V

AGRADECIMIENTO

Agradezco a Dios por darle

la fortaleza en todo momento

y dirigirme por el sendero

correcto.

A mis Padres por darme su

apoyo en todo momento, por

inculcarme los valores y

haberme dado una excelente

educación.

A mi esposa y a mi hijo que

son piezas importantes en

mi vida y que me apoyaron

en todo momento.

VI

TRIBUNAL PROYECTO DE TITULACIÓN

Ing. Eduardo Santos Baquerizo, M.Sc.

DECANO DE LA FACULTAD

CIENCIAS MATEMATICAS Y

FISICAS

Ing. Abel Alarcón Salvatierra, Mgs.

DIRECTOR DE LA CARRERA DE

INGENIERIA EN SISTEMAS

COMPUTACIONALES

Ing. Cristian Tomalá Mazzini, MSIG.

PROFESOR REVISOR DEL

ÁREA TRIBUNAL

Ing. Alfredo Arrese Vilche

PROFESOR REVISOR DEL

ÁREA TRIBUNAL

Ing. Pedro Moncada Romero

PROFESOR TUTOR DEL PROYECTO

DE TITULACION

Ab. Juan Chávez Atocha, Esp.

SECRETARIO

VII

DECLARACIÓN EXPRESA

“La responsabilidad del contenido de este

Proyecto de Titulación, me corresponden

exclusivamente; y el patrimonio

intelectual de la misma a la

UNIVERSIDAD DE GUAYAQUIL”

JOSÉ LUIS PACHECO LAJE

C.I.: 1311461790

VIII



CARRERA DE INGENIERIA EN SISTEMAS

COMPUTACIONALES





Proyecto de Titulación que se presenta como requisito para optar por el

título de

INGENIERO EN SISTEMAS COMPUTAC|IONALES

Autor: JOSE LUIS PACHECO LAJE

C.I: 1311461790

Tutor: Ing. Pedro Moncada Romero

Guayaquil, septiembre de 2018

IX

CERTIFICADO DE ACEPTACIÓN DEL TUTOR

En mi calidad de Tutor del proyecto de titulación, nombrado por el

Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la

Universidad de Guayaquil.

CERTIFICO:

Que he analizado el Proyecto de Titulación presentado por el

estudiante JOSÉ LUIS PACHECO LAJE, como requisito previo para optar

por el título de Ingeniero en Sistemas Computacionales cuyo título es:



ARQUITECTURA TRADICIONAL (MONOLÍTICA) CON

COMPROBACIÓN APLICATIVA

Considero aprobado el trabajo en su totalidad.

Presentado por:

José Luis Pacheco Laje C.I.: 1311461790


Guayaquil, septiembre de 2018

X



CARRERA DE INGENIERIA EN SISTEMAS

COMPUTACIONALES

Autorización para Publicación de Proyecto de Titulación en Formato

Digital

1. Identificación del Proyecto de Titulación

Nombre Alumno: JOSÉ LUIS PACHECO LAJE

Dirección: Bastión Popular Bl. 6 Mz. 194 Sl.1

Teléfono: 0980411221 E-mail: [email protected]

Facultad: CIENCIAS MATEMATICAS Y FISICAS

Carrera: INGENIERÍA EN SISTEMAS COMPUTACIONALES

Proyecto de titulación al que opta: Ingeniero en Sistemas

Computacionales

Profesor guía: Ing. Pedro Moncada Romero

Título del Proyecto de titulación: ESTUDIO COMPARATIVO ENTRE

UNA ARQUITECTURA CON MICROSERVICIOS Y CONTENEDORES

DOCKERS Y UNA ARQUITECTURA TRADICIONAL (MONOLÍTICA)


XI

Tema del Proyecto de Titulación: ESTUDIO COMPARATIVO ENTRE

UNA ARQUITECTURA CON MICROSERVICIOS EN CONTENEDORES

DOCKERS Y UNA ARQUITECTURA TRADICIONAL (MONOLÍTICA)

2. Autorización de Publicación de Versión Electrónica del

Proyecto de Titulación

A través de este medio autorizo a la Biblioteca de la Universidad de

Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la

versión electrónica de este Proyecto de titulación.

Publicación electrónica:

Inmediata X Después de 1 año

Firma Alumno:

3. Forma de envío:

El texto del proyecto de titulación debe ser enviado en formato Word,

como archivo .Doc. O .RTF y Puf para PC. Las imágenes que la

acompañen pueden ser: .gif, .jpg o .TIFF.

DVDROM CDROM X

XII

ÍNDICE GENERAL

Contenido

AGRADECIMIENTO .................................................................................. V TRIBUNAL PROYECTO DE TITULACIÓN ............................................ VI DECLARACIÓN EXPRESA .................................................................... VII CERTIFICADO DE ACEPTACIÓN DEL TUTOR ..................................... IX ÍNDICE GENERAL .................................................................................. XII ÍNDICE DE GRÁFICAS ......................................................................... XIV ÍNDICE DE CUADROS ........................................................................... XV

ÍNDICE DE ILUSTRACIÓN ................................................................... XVI ABREVIATURAS ................................................................................ XVIII RESUMEN ............................................................................................. XIX

ABSTRACT ............................................................................................ XX INTRODUCCIÓN ....................................................................................... 1 CAPÍTULO I............................................................................................... 2

Ubicación del Problema en un Contexto .............................................. 2

Situación Conflicto. Nudos Críticos ....................................................... 3 Causas y Consecuencias del Problema ............................................... 3

Delimitación del Problema ...................................................................... 4 Formulación del Problema ...................................................................... 4

Evaluación del Problema ........................................................................ 5 OBJETIVO GENERAL ............................................................................. 6

OBJETIVOS ESPECÍFICOS .................................................................. 6

CAPÍTULO II .............................................................................................. 9

2.1. Arquitectura Monolítica ............................................................ 11 2.2. Arquitectura de Microservicios ............................................... 14

2.2.1. Ventajas de los Microservicios. .......................................... 17 2.2.2. Desventajas de Microservicios ........................................... 18

2.2.3. Características de los microservicios ................................ 19 2.2.4. Objetivos de los microservicios. ......................................... 19

2.2.5. Tipos de comunicación entre los microservicios ............. 20

2.2.6. Comunicación de los Microservicios por HTTP y REST 21 2.2.7. Razones para utilizar microservicios ................................. 22

2.3. Comunicación entre Microservicios ....................................... 23 2.3.1. REST (Representational State Transfer) .......................... 23

2.3.2. SOAP (Simple Object Access Protocol) ........................... 24

2.3.3. Ventajas y Desventajas de REST y SOAP ....................... 25

2.4. Contenedor ................................................................................ 28

2.4.1. Contenedor de software ...................................................... 29 2.4.2. Contenedor de Imágenes .................................................... 29

2.4.3. Virtualización ......................................................................... 29 2.4.4. Diferencias entre Virtualización y Contenedores ............. 31

2.5. Docker ........................................................................................ 32

XIII

2.5.1. Beneficios al utilizar Contenedores ................................... 34 2.5.2. Ventajas y Desventajas de Dockers .................................. 35

2.5.3. Estadísticas de la utilización de Dockers .......................... 36 2.5.4. El ecosistema de Dockers ................................................... 36

2.5.5. Docker Machine ................................................................ 37

2.5.6. Docker Swarm ................................................................... 38

2.5.7. Docker Compose .............................................................. 38 2.6. Registrador de servicios .......................................................... 38

2.7.1. Consul ..................................................................................... 40

2.7.2. Netflix Eureka ........................................................................ 41 2.8. Git ................................................................................................ 43

2.9. Maven ......................................................................................... 43

2.10. Metodologías Agiles ................................................................. 44

2.11. F5 Load Balancer ..................................................................... 45 2.12. cAdvisor ...................................................................................... 46

CAPÍTULO III ........................................................................................... 56 METODOLOGÍA DE LA INVESTIGACIÓN ........................................................ 56

DISEÑO DE LA INVESTIGACIÓN ...................................................................... 56

CAPÍTULO IV .......................................................................................... 71 RESULTADOS, CONCLUSIONES Y RECOMENDACIONES .................... 71

PRESENTACIÓN DE RESULTADOS ................................................................ 71

4. Desarrollo y diseño de un prototipo de Sistemas de Módulos de gestión

de Productos y Usuarios. ...................................................................................... 73

4.1. Funcionalidad del Prototipo ..................................................... 73

4.2. Caso de uso .................................................................................. 74

4.2.1. Caso de uso de la funcionalidad del sistema de prototipo 74

4.2.1.1. Caso de uso de Registro de Usuario ......................... 74

4.2.1.2. Caso de Uso de Autenticación de Usuarios ............. 74

4.2.1.3. Caso de Uso de Consulta e Ingreso de Productos .. 75

4.2.2. Diagramas de Secuencias .................................................. 76 4.2.3. Diagrama de Base de Datos ............................................... 78

4.2.4. Diagrama de Arquitectura ................................................... 79

4.3. Pruebas de Rendimiento utilizando la aplicación Jmeter... 80 4.3.1. Pruebas de estrés en el servicio de arquitectura monolítica ................................................................................................ 80

4.3.2. Pruebas de estrés en el servicio de arquitectura basadas en microservicios. ................................................................................... 82

CONCLUSIONES ................................................................................................ 85

RECOMENDACIONES ...................................................................................... 86 REFERENCIAS BIBLIOGRAFÍA ............................................................ 87 ANEXOS ............................................................................................................... 89

XIV

ÍNDICE DE GRÁFICAS

GRÁFICA 1. ECOSISTEMA DE DOCKERS EN GITHUB ........................... 37

GRÁFICA 2. MEJORAS EN EL RENDIMIENTO EN LAS APLICACIONES UTILIZANDO ARQUITECTURA DE MICROSERVICIOS ........................... 63 GRÁFICA 3. DISMINUCIÓN EN TIEMPO DE DESPLIEGUES EN LAS APLICACIONES UTILIZANDO ARQUITECTIRA DE MICROSERVICIOS64 GRÁFICA 4. DISMINUCIÓN EN TIEMPO DE IMPLEMENTACIÓN .......... 65

GRÁFICA 5. IMPACTO POSITIVO EN LA ORGANIZACIÓN AL UTILIZAR ARQUITECTURA DE MICROSERVICIOS .................................................... 67

GRÁFICA 6. IMPACTO NEGATIVO AL UTILIZAR MICROSERVICIOS .. 68

GRÁFICA 7. IMPORTANCIA EN UTILIZAR UNA METODOLOGÍA PARA LA IMPLEMENTACIÓN DE MICROSERVICIOS .......................................... 69

XV

ÍNDICE DE CUADROS CUADRO 1. CAUSAS Y CONSECUENCIAS DEL PROBLEMA .................. 3

CUADRO 2. OPERACIONES O MÉTODOS REST ..................................... 24 CUADRO 3. VENTAJAS Y DESVENTAJAS DE REST VS SOAP ............ 25 CUADRO 4. COMPARACIÓN DE ARQUITECURA SOAP Y REST ......... 26

CUADRO 5. VENTAJAS Y DESVENTAJAS DE DOCKERS ...................... 35 CUADRO 6. CUADRO COMPARATIVO DE METODOLOGIAS AGILES 44

CUADRO 7. DISTRIBUCIÓN DE LA MUESTRA .......................................... 59 CUADRO 8. MATRIZ DE OPERACIONALIZACIÒN DE VARIABLES ...... 60

CUADRO 9. RESULTADO DE LA PREGUNTA 1 ........................................ 62 CUADRO 10. RESULTADO DE LA PREGUNTA 2 ...................................... 63 CUADRO 11. RESULTADO DE LA PREGUNTA 3 ...................................... 65

CUADRO 12. RESULTADO DE LA PREGUNTA 4 ...................................... 66 CUADRO 13. RESULTADO DE LA PREGUNTA 5 ...................................... 67

CUADRO 14. RESULTADO DE LA PREGUNTA 6 ...................................... 69

CUADRO 15. RECURSOS DE HARDWARE ................................................ 72

CUADRO 16. RECURSOS DE SOFTWARE ................................................. 72

CUADRO 17. CASO DE USO DE REGISTRO DE USUARIO .................... 74 CUADRO 18. CASO DE USO DE AUTENTICACIÓN DE USUARIOS ..... 74

CUADRO 19. CASO DE USO DE CONSULTA E INGRESO DE PRODUCTOS ..................................................................................................... 75

XVI

ÍNDICE DE ILUSTRACIÓN

Ilustración 1. ARQUITECTURA MONOLÍTICA .............................................. 12

Ilustración 2. ARQUITECTURA DE MICROSERVICIOS ............................. 16 Ilustración 3. VENTAJAS DE MICROSERVICIOS ........................................ 18

Ilustración 4. PETICIONES SINCRÓNICA ..................................................... 20

Ilustración 5. PETICIONES ASINCRÓNICA .................................................. 21

Ilustración 6. COMUNICACIÓN SOLICITUD-RESPUESTA (HTTP-REST) ............................................................................................................................... 22

Ilustración 7. XML EN SOAP ............................................................................ 25 Ilustración 8. EXTRUCTURA DE UN JSON .................................................. 28

Ilustración 9. VIRTUALIZACION DE SERVIDORES .................................... 30

Ilustración 10. DIFERENCIA ENTRE VIRTUALIZACÓN Y CONTENEDOR ............................................................................................................................... 31

Ilustración 11. PLATAFORMA DE DOCKERS .............................................. 32 Ilustración 12. REGISTRADOR DE SERVICIOS .......................................... 39

Ilustración 13. INTERFAZ CONSUL ................................................................ 41 Ilustración 14. REGISTRY EUREKA ............................................................... 42

Ilustración 15. F5 LOAD BALANCER .............................................................. 46

Ilustración 16. EJECUTAR CADVISOR EN UN DOCKER CONTAINER .. 47

Ilustración 17. DIAGRAMA DE SECUENCIA DE REGISTRO DE USUARIO ............................................................................................................ 76

Ilustración 18. DIAGRAMA DE SECUENCIA DE AUTENTICACIÓN DE USUARIO ............................................................................................................ 77 Ilustración 19. DIAGRAMA DE SECUENCIA DE CONSULTA E INGRESO DE PRODUCTOS .............................................................................................. 78

Ilustración 20. DIAGRAMA DE ARQUITECTURA ........................................ 79 Ilustración 21. PRUEBAS DE ESTRÉS EN APACHE JMETER-RESPUESTA DEL SERVIDOR ........................................................................ 80 Ilustración 22. PRUEBAS DE ESTRÉS SERVICIO DE AUTENTICACIÓN DE USUARIO ...................................................................................................... 81

Ilustración 23. USO MEMORIA EN ARQUITECTURA MONOLITICA ....... 81 Ilustración 24. PRUEBA DE ESTRÉS SERVICIO DE AUTENTICACIÓN-ERRORES ........................................................................................................... 82 Ilustración 25. PRUEBAS DE ESTRÉS SERVICIO DE AUTENTICACIÓN DE USUARIO ...................................................................................................... 83

Ilustración 26. USO MEMORIA EN ARQUITECTURA DE MICROSERVICIO .............................................................................................. 83

Ilustración 27 ESTRUCTURA DE PROTOTIPO INGRESOMS, PRODUCTOMS Y LOGINMS EN JAVA ......................................................... 93

Ilustración 28. EXTRUCTURA POM.XML ...................................................... 94

Ilustración 29. PAGINA PRINCIPAL- LOGIN ................................................. 95

Ilustración 30. PAGINA DE REGISTRO DE USUARIO ............................... 95

XVII

Ilustración 31. INGRESO A LA PANTALLA DE PRODUCTOS Y AUTENTICACIÓN EXITOSA ............................................................................ 96

Ilustración 32. INGRESO DE PRODUCTOS ................................................. 96 Ilustración 33. LISTADO DE LOS PRODUCTOS INGRESADOS .............. 97

Ilustración 34. CREACÓN DE MAQUINA VIRTUAL DOCKER .................. 98

Ilustración 35. VISUALIZAR IP DE MAQUINA VIRTUAL DE DOCKER .. 98

Ilustración 36. ASIGNACION EN VARIABLES DE ENTORNO .................. 99 Ilustración 37. DESCARGAR LA IMAGEN DE LA BASE DE MYSQL DEL REPOSITORIO DOCKER HUB ....................................................................... 99

Ilustración 38. CREANDO BASE DE DATOS EN MYSQL ........................ 100

XVIII

ABREVIATURAS

AWS Amazon Web Services

UG Universidad de Guayaquil

HTML Lenguaje de Marca de salida de Hyper Texto

HTTP Protocolo de transferencia de Hyper Texto

Ing. Ingeniero

URL Localizador de Fuente Uniforme

WWW World Wide Web (red mundial)

DNS Sistema de nombres de dominio

REST Transferencia de Estado Representacional

API Interfaz de programación de aplicaciones

TI Tecnología de la Información

CRM Gestión de Relaciones con Clientes.

JS JavaScript

WSDL Web Services Description Language

XIX


FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS



MICROSERVICIOS EN CONTENEDORES DOCKERS Y UNA



RESUMEN

En este presente trabajo se investiga la comparación entre una

arquitectura de microservicios en contenedores Dockers y una

arquitectura tradicional donde su enfoque principal es observar las

ventajas y desventajas de cada arquitectura. En el primer capítulo se

abarcan los objetivos de esta investigación, tales como el análisis del

impacto en el tiempo de implementación al usar una arquitectura de

microservicios. Además, se estudiarán los conceptos principales para

entender cada arquitectura, como, por ejemplo: razones para utilizar los

microservicios, qué es un contenedor de software e imágenes, las

diferencias de virtualización y contenedores. La metodología que se utilizó

es la documental y bibliográfica, la cual tiene como enfoque ampliar,

estudiar y profundizar el problema. Adicionalmente se detallan en los

anexos los comandos básicos para crear y ejecutar un contenedor con

una imagen de un microservicio.

Palabras clave: Microservicios, Dockers, Contenedor, Imagen,

Tradicional.

Autor: José Luis Pacheco Laje


XX


FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS


COMPARATIVE STUDY BETWEEN AN ARCHITECTURE WITH

MICROSERVICES IN CONTAINERS DOCKERS

AND A TRADITIONAL ARCHITECTURE

(MONOLITHIC) WITH APPLICATION

VERIFICATION

ABSTRACT

In this present work the comparison between an architecture of microservices

in Dockers containers and a traditional architecture is investigated where its

main approach is to observe the advantages and disadvantages of each

architecture. In the first chapter the objectives of this investigation are

included, such as the analysis of the impact in the time of implementation

when using an architecture of microservices. In addition, the main concepts

will study to understand each architecture, like, for example: reasons to use

the microservices, what is a container of software and images, the differences

of virtualization and containers. The methodology that was used is

documentary and the bibliographical one, which aims to expand, study and

deepen the problem. Additionally, they are detailed in annexed the basic

commandos to create and to execute a container with an image of a

microservice.

Keywords: Microservices, Dockers, Container, Image, Traditional.

Autor: José Luis Pacheco Laje


1

INTRODUCCIÓN

Hoy en día la tecnología avanza a grandes pasos, exigiendo con ellos

nuevas formas de comunicación entre los diferentes módulos de las

empresas, ya que su principal objetivo es brindar un producto y servicio

de calidad. Las organizaciones lo que buscan es optimizar las tareas en

sus procesos con los nuevos servicios tecnológicos que la industria

ofrece.

Una mala elección en la arquitectura en el momento de la entrega de los

sistemas, representa insatisfacción en el consumidor final y para las

empresas grandes pérdidas.

En este trabajo de investigación se propone utilizar una arquitectura de

microservicios que, como su nombre lo indica, son pequeños servicios

que trabajan en conjunto para lograr algo en común, y así contribuir a la

entrega continua, además se plantea utilizar contenedores Dockers para

que se reduzcan los niveles de riesgos en producción, los mismos que

ayudarán a aislar los fallos y no afectar a todos los módulos del Sistema.

Este enfoque propuesto está orientado a eliminar la mayoría de

problemas de configuraciones y despliegues dependientes en el entorno

de producción.

La presentación del uso de herramientas de testeo en esta investigación

propone resolver los problemas entre la arquitectura tradicional y la

arquitectura de microservicios, donde se medirá el rendimiento y el

monitoreo a fin de demostrar el correcto funcionamiento del sistema.

2

CAPÍTULO I

EL PROBLEMA

PLANTEAMIENTO DEL PROBLEMA

Ubicación del Problema en un Contexto

Actualmente, las empresas que se dedican a desarrollar aplicaciones se

han enfrentado a una serie de problemas al escoger la arquitectura para

diseñar sus proyectos de desarrollo, de modo que muchas empresas

desde sus inicios vieron la necesidad de tomar la decisión de optar por

una arquitectura tradicional. Tiempo después estos proyectos se volvieron

más grandes, hasta darse cuenta de que el tipo de arquitectura definida

en sus inicios afectaba y afecta al tiempo de desarrollo e implementación

de cualquier modificación; además de no poder manejar los fallos de los

sistemas. Varias empresas tomaron la iniciativa de un enfoque diferente y

decidieron elegir la arquitectura de microservicios para prevenir el uso de

una arquitectura tradicional (monolítica) ya que las empresas al escoger

esta última arquitectura se dieron cuenta de que tienen algunas

desventajas, entre ellas el hecho de que ante un fallo en los servicios

resulta difícil tener un control de la unidad causante del problema.

3

Situación Conflicto. Nudos Críticos

Con el presente trabajo de grado se pretende comparar la arquitectura

tradicional con la arquitectura de microservicios con contenedores

Dockers, la cual nos permitirá tener un mejor rendimiento en los recursos

de los sistemas en Producción.

Causas y Consecuencias del Problema

CUADRO 1. CAUSAS Y CONSECUENCIAS DEL PROBLEMA

Causas Consecuencias

Fallo en los sistemas al no

controlar la memoria del servidor.

La empresa no puede

transaccionar por ende genera

insatisfacción en los clientes, y

pérdidas económicas.

La empresa debe contar con

presupuesto para adquirir

servidores F5 para el balanceo de

las peticiones en las aplicaciones.

Mayor costo en el mantenimiento

ya que se debe incrementar los

recursos de los servidores

Las instancias del servicio deben

ser replicados en cada uno de los

nodos del servidor

Mayor coste en la empresa debido

a que se debe replicar todas las

instancias en los servidores que

implica recursos humanos para la

gestión.

4

Utiliza un solo lenguaje de

programación.

Que al realizar una actualización

en el sistema este debe ser

modificado por una persona que

conozca del lenguaje que se utilizó

para poder implementarlo.

El equipo de desarrollo debe

entender el código para luego

modificarlo.

Elaborado por: José Pacheco Laje

Fuente: Datos de la investigación

Delimitación del Problema

Campo: Tecnología de la Información y Comunicación

Área: Arquitectura de Microservicios con contenedores Dockers

Aspecto: Empresas

Tema: Estudio comparativo entre una arquitectura con microservicios y

contenedores Dockers y una arquitectura tradicional (monolítica) mediante

comprobación aplicativa

Formulación del Problema

En base al análisis previo, esta propuesta de investigación la planteo con

la siguiente pregunta: ¿Por qué utilizar la arquitectura de microservicios

con contenedores Dockers en un ambiente productivo?

5

Evaluación del Problema

Los siguientes aspectos han sido tomados en cuenta para la evaluación

del problema:

Delimitado: El concepto de entrega continua demuestra cómo se puede

hacer que el software de producción sea más efectivo y eficiente,

teniendo como idea realizar en cada check-in un candidato de

lanzamiento a desarrollar mejoras para que las máquinas hablen con

otras máquinas. Gizlo (2012) afirma:

Las plataformas de virtualización nos permiten aprovisionar y

cambiar el tamaño de la infraestructura que nos brinda una manera

de manejar estas máquinas a gran escala. Algunas organizaciones

grandes y exitosas como Amazon y Google adoptaron la visión de

pequeños equipos que poseen el ciclo de vida completo de sus

servicios. Y, más recientemente, Netflix ha compartido con

nosotros formas de construir sistemas antifragiles a una escala que

hubiera sido difícil de comprender hace solo 10 años. (p.6).

Claro: Lo que se busca en este estudio es poder comparar el rendimiento

entre la arquitectura tradicional y la arquitectura de microservicios con

contenedores Dockers, por lo tanto, es necesario conocer el rendimiento

de esta arquitectura en ambiente de producción.

Evidente: Las arquitecturas tradicionales escalan de forma horizontal; es

decir realizando réplicas exactas del sistema y utilizando un servidor de

balanceo de carga, lo cual produce desperdicios de recursos, por otro

lado, a la hora de realizar una actualización en sistemas tradicionales se

debe desplegar y replicar el sistema en los nodos disponibles, provocando

que los procesos de replicación sean complejos. Se busca una

6

arquitectura que sea escalable en forma vertical, y la arquitectura de

microservicios se acopla a la necesidad.

Factible: Con las herramientas que existen actualmente de Open Source

se podrán demostrar el rendimiento que se obtendrá al elegir una

arquitectura de microservicios versus la arquitectura tradicional.

Relevante: El ambiente de producción de cualquier empresa necesita que

sus aplicaciones sean escalables, de forma vertical.

Original: En la actualidad muy pocas empresas conocen de esta

arquitectura, por lo que esta propuesta tecnológica busca ayudar a tomar

la decisión de que sus próximos proyectos se ejecuten considerando la

arquitectura de microservicios con contenedores Dockers.

OBJETIVOS

OBJETIVO GENERAL

Estudiar y comparar una arquitectura de microservicios en contenedores

Dockers con una arquitectura tradicional (monolítica) mediante

comprobación aplicativa para verificar el rendimiento y los recursos

utilizados en la aplicación.

OBJETIVOS ESPECÍFICOS

Analizar el impacto en el tiempo de implementación que se tiene al usar

una arquitectura tradicional y una arquitectura basada en microservicios

7

con contenedores Dockers mediante el instrumento de la recolección de

datos y el prototipo de la aplicación

Analizar la implementación mediante el desarrollo de prototipo de

aplicación entre una arquitectura tradicional y una arquitectura de

microservicio en contenedores Dockers.

Comparar los tiempos de rendimiento entre una aplicación con

arquitectura tradicional y una arquitectura de microservicios con

contenedores Dockers.

ALCANCES DEL PROBLEMA

➢ Comparación entre las arquitecturas monolíticas y arquitecturas

basadas en microservicios con contenedores Dockers, así como

también sus ventajas y desventajas.

➢ Plantear un registrador de servicios para el descubrimiento de

estos.

➢ Implementar un servicio basado en la arquitectura de microservicio

con contenedores Dockers para la comprobación de rendimiento

en recursos.

➢ Realizar pruebas de estrés en la aplicación “Jmeter” para obtener

resultados de rendimiento.

JUSTIFICACION E IMPORTANCIA

El tema propuesto en este trabajo de investigación sigue la línea de

Tecnología para el apoyo en las empresas que utilizan las arquitecturas

8

tradicionales (monolíticas), donde sus sistemas tienen un consumo

excesivo de memoria y que en algún momento cualquier módulo que se

está ejecutando requerirá más recursos del sistema y esto podrá dejar sin

requerimiento al sistema en general. Por otro lado, al realizar una

actualización en los sistemas o módulos de una arquitectura tradicional,

se debe desplegar el sistema en los servidores, donde, si falla uno de sus

componentes el sistema quedará inhabilitado, por lo que se plantea una

arquitectura que permita estar hecha de pequeños servicios que se

puedan juntar para cumplir requerimientos de uno o muchos clientes. En

muchos casos, estos componentes son candidatos perfectos para la

proliferación de contenedores, sobre todo de Dockers.

METODOLOGÍA DEL PROYECTO:

La metodología que se aplicó en este trabajo de investigación es la

documental, la misma que consiste en la selección y recopilación de

información por medio de la lectura y critica de documentos y materiales

bibliográficos. Además, también se utilizó la metodología de investigación

experimental, que consiste en la manipulación de una variable

experimental no comprobada, con el fin de describir de qué modo o por

que causa se produce una situación.

La metodología que se aplicó en el desarrollo del prototipo fue la

metodología Ágil Scrum. Todos los días se realizó el Daily meeting

(reunión diaria) donde se respondía las preguntas ¿Qué se realizó el día

de ayer? ¿Qué se va a realizar el día de hoy? ¿Existe algún tipo de

bloqueo? Al final de la semana se realizaba una retroalimentación de

todas las tareas realizadas del prototipo

9

CAPÍTULO II

MARCO TEÓRICO

ANTECEDENTES DEL ESTUDIO

Empresas como Amazon y Netflix desempeñan un papel fundamental

como casos de éxito utilizando arquitecturas de microservicios con

Dockers. Estrada (2017) afirma: En 1994 nació una filosofía similar a lo

que hoy llamamos microservicios, los cuales en sus inicios eran pequeños

equipos trabajando de forma más optima, con la capacidad para generar

las suficientes herramientas para apoyar a sus desarrolladores. (p.3).

Además, crearon los Amazon Web Services (AWS), para permitir que el

equipo de desarrolladores se encargue de todo el ciclo de vida y la

infraestructura diseñada para sus proyectos.

En la historia la utilización del término microservicios se puede rastrear a

mayo del 2011 en Venecia, donde un grupo de arquitectos de software se

pusieron de acuerdo en utilizar la palabra para caracterizar los sistemas

en cuyo desarrollo estaban involucrados.

Con la influencia de algunos de los pioneros en el campo (Adrián

Cockcroft, Netflix y otros) los microservicios han ido ganando presencia y,

hoy en día, se aceptan en la industria como un estilo arquitectónico bien

establecido.

10

Estrada (2017) indica que, en 1997, Netflix tomo como ejemplo a Amazon:

Mientras inició sus labores como videoclub, aseguró que la estructura de

estos equipos trabaje independientemente, esto es para facilitar los

cambios y no se entorpecieran entre ellos. Por ello, Netflix se ha

convertido en una de las empresas pioneras en microservicios, al crear

servicios independientes que les permitieron escalar y optimizar sus

procesos de despliegue. (p.4)

Goya (2018) indica: Muchas organizaciones están migrando sus sistemas

a esta arquitectura, descomponiendo sus monolitos en unidades más

pequeñas y distribuidas. (p.6)

Muchas de las organizaciones a nivel mundial han descubierto que, al

adoptar arquitecturas de microservicio de grano fino, pueden entregar

software más rápido y adoptar nuevas tecnologías. Los microservicios

dan mucha más libertad para reaccionar y tomar decisiones diferentes, lo

que nos permite responder más rápido al cambio inevitable que nos

impacta a todos.

Durante muchos años, se ha estado buscando mejores formas de

construir sistemas. Lo cual se ha aprendiendo que las nuevas tecnologías

opera de diferentes maneras para crear sistemas de TI que ayuden al

cliente como a los desarrolladores.

Se realizo una investigación de campo a un consultor del medio, el cual

indica que a nivel local pocas son las empresas que han iniciado con la

adopción de esta arquitectura, entre las empresas que se están

incluyendo esta arquitectura en su infraestructura se puede decir que son:

una empresa de Telecomunicación y 4 empresas del sector Bancario.

Además, comenta que existe una problemática porque existe un estudio

comparativo entre una arquitectura tradicional con una arquitectura de

11

microservicios con contenedores Dockers para lo cual este documento se

adjunta en el anexo 1.

FUNDAMENTACIÓN TEÓRICA

En este capítulo se abarcarán los conceptos generales de virtualización,

así como también daremos un vistazo a los patrones necesarios para

poder realizar la implementación de una arquitectura de microservicios

con contenedores Dockers, además hablaremos de temas fundamentales

tales como: que es un microservicio, los tipos de contendores que pueden

alinearse a esta arquitectura, y una herramienta que nos permita

descubrir y configurar los servicios desplegados.

2.1. Arquitectura Monolítica

Una arquitectura monolítica es una única unidad, que se compone de tres

partes: acceso a datos también llamado la capa del Modelo, interfaz de

usuario como la vista y el controlador el cual comunica la capa de la base

de datos con la capa de la interfaz.

Se define que esta arquitectura emplea una tecnología que limita la

disponibilidad de herramientas adecuadas para ejecutar el sistema.

Esta arquitectura está diseñada para ser autónoma, sus componentes

asociados en el código son ejecutados por un solo compilador de lenguaje

de programación lo cual obliga a estar interconectado y ser dependiente

de sí mismo para su funcionalidad.

12

Ilustración 1. ARQUITECTURA MONOLÍTICA

Elaborado por: José Pacheco

Fuente: Datos de la Investigación

Como ejemplo en la ilustración 1 se puede visualizar como se puede

acceder desde una página web a una tienda para realizar compras,

pedidos, etc., gracias a un servidor solo se ejecuta un código de

aplicación en forma de archivo WAR y a la vez se conecta a la base de

datos para extraer información, cuando el cliente consulta un producto por

la web, este mostrará los productos habilitados, de tal manera que la

aplicación de una u otra forma tendrá la información disponible de

acuerdo a la lógica de negocio implementada (Pagos, Inventarios e

Ingreso de Clientes), aunque es transparente para el cliente, se están

ejecutando varios módulos que a simple vista parecería que estuvieran

separados, pero en realidad su código se encuentra empaquetado en un

solo archivo. Al realizar una actualización en el módulo de Ingreso de

Cliente, se tendrá que subir los cambios realizados a producción, a pesar

de que en los módulos de pagos e inventarios no se realizaron cambios.

Esto afectaría mayormente si en el despliegue de la aplicación hubiera

error, causando graves pérdidas en la empresa.

http://comunytek.com/introduccion-a-los-microservicios/

13

Desde el punto de vista organizacional, este diseño fue una de las

primeras aplicaciones de software que se desarrolló con ventajas

importantes tales como: despliegue único, ejecución de un solo archivo y

facilidad de desarrollo. Debido a su estructura, este desarrollo de

aplicaciones monolíticas es menos costoso, por lo que se concentra su

funcionalidad en un solo archivo de ejecución.

Al tratarse de una arquitectura monolítica, requiere que en cada

despliegue el código único sea sobrescrito. Además, el tamaño de este

código hace que al momento de buscar y/o solucionar inconvenientes

estos sean más difíciles de identificar. Para los desarrolladores es una

gran desventaja, ya que resulta muy complicado entender en su totalidad

el código para empezar a programar y cualquier mala interpretación

puede comprometer el código en su lógica.

La arquitectura monolítica se construye bajo tres capas o componentes:

interfaz de usuario o presentación que consiste en la visualización de las

páginas HTML, JavaScript (JS) las cuales se ejecutan sobre el

navegador. La capa del servidor, el cual tiene la funcionalidad de ejecutar

la lógica del negocio y la capa de acceso a base de datos que contiene

las estructuras y es manejada por el gestor de base de datos. Por tal

razón es un reto de crecimiento en el código, ya que no es posible

trabajar en diferentes ambientes debido a la complejidad y sobrecarga en

la aplicación.

Una empresa a la hora de elegir usar esta arquitectura monolítica debería

considerar la lógica de negocio y que no es conveniente esté atada a una

sola unidad, sino más bien decidirse por una arquitectura que sea

escalable, resistente y de fácil de implementación.

14

Por ejemplo, un CRM con arquitectura monolítica que contenga

funcionalidades complejas y lógica del negocio en crecimiento donde se

evidencia que debe realizarse un despliegue de toda la aplicación por el

más mínimo cambio a un componente, implica un alto riesgo de falla en la

actualización del sistema y por ende estas son menos frecuentes, ya que

se requiere más ciclos de pruebas y la comunicación entre los grupos de

desarrollo. Por otro lado, la calidad del cambio en el código no está

garantizada y es más complicado encontrar dependencias entre los

módulos. En definitiva, esta empresa, al querer realizar un cambio

funcional, se encontrará con el problema del despliegue y deberán sus

funcionarios estar atentos a fallas o convivir con las contingencias hasta

que se desarrollen los correctivos a la actualización.

Actualmente la tendencia global es el de usar una arquitectura alternativa

que ofrezca flexibilidad en el desarrollo, escalabilidad, autonomía y

eficiencia en la gestión multifuncional. Varias empresas locales ya han

iniciado pasos hacia este objetivo.

2.2. Arquitectura de Microservicios

El término "arquitectura de microservicio" como lo definen Martin Fowler y

James Lewis en su artículo: “Microservices”, el cual tiene aceptación

generalizada entre los especialistas , dice: “es una forma muy particular

de diseñar aplicaciones de software como conjuntos de servicios de

implementación independiente” pero hacen énfasis, en que “a pesar de no

existir una definición precisa de este estilo arquitectónico, existen ciertas

características comunes en torno a la organización, capacidad

empresarial, implementación automatizada, Inteligencia en los puntos

finales y el control descentralizado de idiomas y datos”. (Lewis y Fowler,

2014).

15

Además, Sam Newman en su libro: “Building Microservices” indica: “los

microservicios son pequeños y autónomos servicios que trabajan juntos”,

los cuales deben estar enfocados en un beneficio clave, de tal forma que

permitan utilizar tecnologías heterogéneas, capacidad de escalar,

facilidad de despliegue y alineamiento organizacional (Newman, 2015).

La arquitectura de microservicios nos da la facilidad de escribirse en

varios lenguajes de programación, esto es gracias a que estos servicios

exponen una API a los demás microservicios.

Esta arquitectura es una solución clara a los problemas a las grandes

aplicaciones monolíticas, es decir que los despliegues continuos y

escalados en las plataformas y el rápido lanzamiento de las aplicaciones

satisface las necesidades de los clientes.

En la siguiente ilustración tenemos el ejemplo de cómo se implementa

una interfaz de usuario que interactúa con cierta lógica para invocar un

servicio de Ingreso a Clientes, pagos e inventarios cuando este lo

requiera.

Este enfoque de microservicios nos facilita el despliegue de forma

independiente, es decir una actualización en el módulo de pagos, no

afectará a los demás sistemas. Además, podremos decir que un

microservicio puede ser multifuncional debido a que puede tener acceso a

base de datos, backend, etc.

16

Ilustración 2. ARQUITECTURA DE MICROSERVICIOS



Las empresas de hoy en día se sienten tan orgullosas de sus proyectos o

software que desarrollan, que difunden sus conocimientos y liberan parte

de sus frameworks en repositorios en la nube (GitHub, GitLab, SVN).

Precisamente esta arquitectura, es un tema que se está hablando mucho

en la actualidad en los entornos de las telecomunicaciones y redes. Esta

estrategia de microservicios tiene sus inicios en la Tecnología de la

Información (TI) que fue impulsado por las empresas web como Netflix en

su búsqueda por mecanismos flexibles, escalables y adaptables en las

aplicaciones en la nube.


17

2.2.1. Ventajas de los Microservicios.

- Escalabilidad. – Estos microservicios tienen la habilidad de

adaptarse y reaccionar de manera independiente. Es decir;

manejan su crecimiento continuo de una manera fluida.

- Implementación independiente. – Se compone de servicios

pequeños, cada uno de estos se implementa de forma

independiente sin comprometer la integridad de la aplicación del

conjunto del sistema.

- Desarrollo independiente. - Un equipo de desarrollo de

software (DEV) puede ejecutar, compilar e implementar un

servicio, este resultado es considerado como una innovación de

entrega continua y una rápida publicación del sistema.

- Servicios Pequeños y centralizados. – Los DEV tienen la

facilidad de centrarse en una parte del sistema, esto hace que

el código sea más entendible a los miembros del equipo.

- Aislamiento de Fallos. – Si uno de los servicios deja de operar

no será necesario detener todo el sistema.

- Agilidad. – Se implementa de manera que resulte fácil la

administración de corrección de errores.

- Resistencia. – Si un servicio no se encuentra disponible, la

aplicación no interrumpe su operatividad, siempre que esté

diseñado para controlar los errores.

A continuación, la siguiente ilustración nos presenta las ventajas antes

mencionadas de la arquitectura de microservicios.

18

Ilustración 3. VENTAJAS DE MICROSERVICIOS



2.2.2. Desventajas de Microservicios

- Complejidad. – Requiere de Despliegues distribuidos.

- Gestión de trazas. – Requiere de centralización de trazas que

permitan controlar, gestionar y administrar los sistemas

- Despliegues. – Al tener un sistema en pequeñas partes, es

rápido su ejecución, pero como es un sistema distribuido es

más difícil su administración.

- Consumo de Memoria. – Al ser un sistema distribuido ocupa

un alto consumo de memoria.

- Monitoreo. – Es más complejo monitorear, debido a que el

sistema está hecho en pequeñas partes.


19

2.2.3. Características de los microservicios

o Pueden ser desplegados de manera independiente y ser

modificados sin afectar a otra parte del sistema.

o Se tiene en cuenta la necesidad, capacidad y la

preferencia del cliente donde será implementado.

o Su arquitectura es independiente, es decir cada uno de

estos servicios cuenta con su propia base de datos.

o Cuenta con un sistema de aviso, que, si se registra un

fallo en los servicios, nos enviará una alerta por email.

2.2.4. Objetivos de los microservicios.

Entre los objetivos más importantes de los microservicios tenemos:

o Permite desplegarse en diferentes plataformas con

mínimas capacidades lo cual los hace económicos.

o Independencia al seleccionar el modelo de Base de

Datos.

o Escalar a nivel del servicio, mas no del sistema.

o Controlar fallos en el sistema

20

2.2.5. Tipos de comunicación entre los microservicios

✓ Sincrónica. Tenemos el Protocolo de Transferencia de

Hipertexto (HTTP), que consiste en enviar y recibir una solicitud

del servicio. La tarea del cliente continúa cuando se recibe una

respuesta del servidor, como se visualiza en la siguiente

ilustración.

Ilustración 4. PETICIONES SINCRÓNICA



✓ Asincrónica. Los microservicios usan mensajes asincrónicos,

es decir el cliente envía un mensaje sin esperar una respuesta.

Ejemplo, al enviar un mensaje a un agente de mensajería y no

esperar una respuesta como se muestra en la siguiente

ilustración.


21

Ilustración 5. PETICIONES ASINCRÓNICA



ActiveMQ. – Es un intermediario de mensajes de código abierto muy

estable y de alto rendimiento que se puede ejecutar de forma autónoma o

dentro de otro servidor, proceso o en una aplicación Java y se integra

bien con otros productos. Tienes diferentes estrategias para almacenar

mensajes en bases de datos, archivos locales o remotas o ambos.

2.2.6. Comunicación de los Microservicios por HTTP y REST

Al utilizar esta comunicación de solicitud-respuesta resulta idónea para

consultar datos desde la interfaz de la aplicación en tiempo real a los

servicios como se muestra en la siguiente ilustración.


22

Ilustración 6. COMUNICACIÓN SOLICITUD-RESPUESTA (HTTP-REST)

Elaborado por: Cesar de la Torre y Olprod

Fuente: https://docs.microsoft.com/es-es/dotnet/standard/microservices-

architecture/architect-microservice-container-applications/communication-

in-microservice-architecture

2.2.7. Razones para utilizar microservicios

Alguna de las razones que se proponen en este trabajo de investigación

es dividir en función a quienes los utilizarán.

Arquitectos de IT

- El proceso y las Bases de Datos de cada módulo es

independiente.

23

- Un servicio puede completar una acción usando otros

microservicios.

- Aislamiento del módulo que facilita la búsqueda del fallo.

Desarrolladores

- Tener una metodología ágil, es decir dividir el trabajo en

pequeñas partes.

- Un microservicio puede desarrollarse en paralelo, no esperar a

que otro equipo finalice su desarrollo para empezar.

- Depuración más eficaz al encontrar un fallo en el sistema

Testers

- Es más fácil encontrar un error en un API que en un “mega-

servicio”.

- Cambios que se determinen en las pruebas sean más sencillos,

directos y que cumplan una función específica.

2.3. Comunicación entre Microservicios

2.3.1. REST (Representational State Transfer)

Transferencia de estado Representacional (REST) es un tipo de

arquitectura sencillo con estándares más eficientes, habituales y lógicos

24

para la creación de una Interfaz de programación de aplicaciones (APIs)

para servicios en Internet.

REST, tiende a un tipo de programación web orientada a generar

operaciones sobre formatos como JSON y XML para el intercambio de

datos entre el cliente y servidor.

Las operaciones o métodos que soporta esta arquitectura REST son:

GET, POST, PUT y DELETE, los mismos que se parecen a las

operaciones de la Base de Datos CRUD (LEER, CREAR, ACTUALIZAR y

ELIMINAR).

CUADRO 2. OPERACIONES O MÉTODOS REST

HTTP CRUD DESCRIPCIÓN

GET LEER Leer y consultar un

recurso

POST CREAR Crear y recurso

PUT ACTUALIZAR Editar un recurso

DELETE ELIMINAR Eliminar un recurso



2.3.2. SOAP (Simple Object Access Protocol)

SOAP es un servicio que utiliza un formato XML en interacciones que se

envían sobre el protocolo HTTP o JMS y se escribe mediante la definición

25

de un WSDL. Además, el intercambio de información lo realiza mediante

formato XML como se muestra en la siguiente ilustración.

Ilustración 7. XML EN SOAP



2.3.3. Ventajas y Desventajas de REST y SOAP

Las características de REST y SOAP la podemos visualizar en el

siguiente cuadro:

CUADRO 3. VENTAJAS Y DESVENTAJAS DE REST VS SOAP

REST SOAP

Ventajas Son muy ligeros.

Operaciones se definen

en el mensaje.

Los recursos se crean

con una dirección que los

Utiliza los WSDL para

definir los puertos de las

operaciones.

Las operaciones se

encuentran en una sola


26

identifica.

Soporta el protocolo

HTTP.

Fácil de integrar con los

sitios web.

Comunicación Síncrono.

dirección.

Soporta varios

tecnologías y protocolos

como WSDL, XSD, etc.

Comunicación

Asíncrona y Síncrono.

Desventajas La Seguridad en los

servicios difícil de

implementar

No existen estándar en

las respuestas

Si se modifica el

contrato tiene impacto

negativo en los clientes

Si no cuenta con

herramientas

adecuadas, la

interpretación de la

utilización se vuelve

compleja



Además, de las ventajas y desventajas de estas dos arquitecturas

podemos compararla en el siguiente cuadro.

CUADRO 4. COMPARACIÓN DE ARQUITECURA SOAP Y REST

REST SOAP

Mensajes en JSON Mensajes en XML

Usa JSON o XML para la

comunicación Cliente-Servidor

WSDL para comunicación entre

Cliente-Servidor


27

La invocación del servicio es a través

de una URL

La invocación de los servicios es

a través de Métodos RPC

El protocolo que utiliza es HTTP Utiliza los siguientes protocolos:

HTTP, FTP, SMTP, etc.



XML (Extensible Markup Language). – Lenguaje de Marca extensible,

que consiste en definir una estructura jerárquica de la información,

además permite que una aplicación se comunique con otra, recibiendo y

enviado los datos bien estructurados con toda la seguridad que necesita.

JSON (JavaScript Object Notation). - Notación de Objeto de JavaScript,

es un formato de texto muy ligero al momento de intercambio de datos y

está compuesto por tipos de datos primitivos como numbers, boolean,

string, array, list, etc.

La estructura de un JSON está compuesta por:

✓ Empieza y termina con llaves “{}”

✓ La Clave y valor está separada por dos puntos “:”

✓ Están separado por coma “,”


28

Ilustración 8. EXTRUCTURA DE UN JSON



RCP (Remote Procedure Call). - Una llamada de procedimiento remoto

consiste en un protocolo que permite a un software o programa ejecutar

código en otra máquina remota sin preocuparse por la comunicación, por

lo regular es bastante utilizado en el paradigma cliente y servidor.

WSDL (Web Services Description Language). - una aplicación software,

identificada por un URI que se puede definir, describir y descubrir a través

de documentos XML. Soporta la interacción directa con otros agentes

software usando mensajes basados en documentos XML intercambiados

vía protocolos de Internet.

2.4. Contenedor

Se puede decir que contenedor es una tecnología de visualización que no

necesita hypervisor para que se ejecute. Estos se ejecutan sobre el kernel

del sistema anfitrión. Es decir, sobre la maquina física.


29

2.4.1. Contenedor de software

Los contenedores de software permiten ejecutar una aplicación en

cualquier sistema operativo. Los contenedores son máquinas

virtuales mucho más portables y menos exigentes a nivel recursos de

cómputo que las máquinas virtuales convencionales (de ahí que se les

conozca como “máquinas virtuales ligeras”). (Olmo, 2016).

2.4.2. Contenedor de Imágenes

Los contenedores de Imágenes son instancias que se crean para ejecutar

aplicaciones, además, estos contenedores solo tienen permisos a sus

propios archivos y se ejecutan en un solo proceso.

2.4.3. Virtualización

La empresa VMware, define a la virtualización como “el proceso de crear

una representación basada en software (o virtual), en lugar de una física”.

Esta virtualización es aplicable para servidores, aplicaciones,

almacenamiento y redes, lo cual de manera eficaz hace que se reduzcan

los costos y aumente la eficiencia de TI.

Esta virtualización de servidores permite a la empresa ahorro en espacio

(varios servidores en una sola máquina) y electricidad (solo se ejecuta

una máquina y no varias) y esto minimizaría los gastos en equipos en la

empresa.

30

La virtualización puede realizarse a nivel completo, esto significa que en

la simulación de un sistema operativo “huésped” se virtualizan todos los

componentes de hardware que se instalan en un sistema operativo

“anfitrión” sin necesidad de ser modificado. Además, la virtualización se

puede realizar de manera parcial, lo cual permite virtualizar ciertos

componentes de hardware necesarios para ser ejecutados en un sistema

operativo. Y, por último, se tiene la virtualización compartida, la cual

permite ejecutar el sistema operativo sobre el software de virtualización;

es decir crea particiones aisladas en un único servidor físico para

maximizar los recursos del hardware, software y datos como se muestra

en la siguiente ilustración.

Ilustración 9. VIRTUALIZACION DE SERVIDORES




31

2.4.4. Diferencias entre Virtualización y Contenedores

La principal diferencia entre virtualización y contenedor, es que al ejecutar

una virtualización es como que instaláramos un sistema operativo

completo, es decir, se instala el kernel, dependencias y librerías como si

fuera un ordenador real y al utilizar contenedores esto cambia, en vez de

instalar el sistema operativo y ocupar recursos de la maquina anfitrión

solo se crea un pequeño kernel con dependencias y librerías necesarias

para ejecutar un sistema operativo sin depender del anfitrión como se

muestra en la siguiente ilustración.

Ilustración 10. DIFERENCIA ENTRE VIRTUALIZACÓN Y

CONTENEDOR




32

2.5. Docker

La idea detrás de Docker es crear contenedores ligeros y portables para

las aplicaciones de software que puedan ejecutarse en cualquier máquina

con Docker instalado, independientemente del sistema operativo que la

máquina tenga por debajo, facilitando así también los despliegues.

(Garzas & García, 2015).

Entre las ventajas de Dockers, se pueden observar que existen gran

variedad de documentos bien detallados, además de tutoriales en línea,

cursos, así como también certificados oficiales sobre el tema. Además,

Docker cuenta con un repositorio público (hub) de imágenes disponibles

del mismo, muchos de estos configurados por los mismos creadores de

los sistemas operativos de acuerdo con siguiente ilustración.

Ilustración 11. PLATAFORMA DE DOCKERS

Elaborado por: SDTime

Fuente: https://sdtimes.com/wp-content/uploads/2014/09/0916.sdt-

dotcker.png

33

Oscar Villacampa dice en su artículo de marketing: “Docker es un

proyecto de código libre que se ha convertido en uno de los términos de

moda por las ventajas que proporciona, entre otros, a los profesionales

del desarrollo web y de aplicaciones, o los administradores de sistemas,

por la facilidad que supone el trabajar con el concepto de contenedores”.

Villacampa (2017).

Docker también permite empaquetar un sistema con todas sus

dependencias estandarizadas del desarrollo del código con su entorno de

ejecución y administración del contenedor. Los contenedores son una

pieza fundamental del software donde contiene un sistema de archivos

necesarios para la ejecución de la aplicación, es decir bibliotecas de

sistemas, herramientas del sistema, código, el tiempo de ejecución y lo

que se podría instalar en el servidor. De esta forma se garantiza que al

pasar a otro entorno (producción), se ejecutará correctamente.

Dockers es un contenedor de imágenes con muchas ventajas que facilita

la virtualización y aísla los recursos del sistema. Además, utiliza un

entorno de ejecución que estandariza las interfaces llamado “libcontainer”,

que permite hacer uso de su núcleo, grupos de control y espacios de

nombres para que varios contenedores se ejecuten en el mismo kernel y

se aíslen uno del otro.

Libcontainer. – Es una configuración estándar de Linux, que dispone de

información de los recursos disponibles y sobre cualquier información de

los procesos que se ejecutan en un contenedor.

34

“Dockerizar” un microservicio en el desarrollo de software le da una

ventaja más ágil al sistema, es decir:

- Crear imágenes del servicio en contenedores

- Ejecutar imágenes como contenedores

- Reducir el tiempo al crear aplicaciones

- Agilidad en el proceso de desarrollo de sistemas

- Docker elimina las barreras entre el desarrollador y el equipo de

operaciones

El resultado final de un servicio “dockerizado” es:

- Mejoras en el servicio.

- Satisfacción en los clientes.

- Crecimiento en el negocio.

2.5.1. Beneficios al utilizar Contenedores

- Ahorro en costos, esto se debe a que los contenedores brindan

una solución a los problemas de implementación en el entorno

de producción.

- Ecosistemas en los proveedores Windows y Linux, que incluyen

AWS, IBM, Google y Microsoft.

- Implementación estándar para cualquier aplicación basada en

un servidor.

35

- Utilizar un enfoque de arquitectura de microservicios distribuida

e independiente de servicios autónomo.

- Se puede “Dockerizar” una aplicación monolítica, pero más

conveniente es “Dockerizar” microservicios.

2.5.2. Ventajas y Desventajas de Dockers

CUADRO 5. VENTAJAS Y DESVENTAJAS DE DOCKERS

Docker

Ventajas Desventajas

Los contenedores se replican

fácilmente y se inician en segundos.

Requiere Kernel 3.8 mínimo.

Consume menos recursos de

hardware, y los que consume van

directamente a la aplicación

En algunas versiones de Docker

podría dar error debido al constante

desarrollo.

Es fácil de automatizar y de integrar. En Linux solo soporta arquitecturas

de 64 bits, Ubuntu 16.04 en adelante

Las imágenes e instancias suelen

ocupar menos espacio que las

máquinas virtuales.

En Windows solo soporta 64 bits con

sistema Operativo Windows 8 en

adelante.

Existen miles de imágenes que

pueden ser descargadas y

modificadas libremente.

En Mac en Sistema Operativo OSX

Generar contenedores autónomos y

compartir su código en su repositorio.

Se necesita acceso a internet para la

descarga de las imágenes

“Dockerizadas” Están aislados de la máquina física.

Esto hace que el contenedor sea

36

seguro y fácil de administrar.

La instalación de un servicio solo

consiste en ejecutar una línea de

comando.

Tiene habilitado un control de

versiones, parecido a “Git”



2.5.3. Estadísticas de la utilización de Dockers

Apiumhub (hub tecnológico especializado en arquitectura de software)

demuestra las siguientes estadísticas Ekaterina (2018):

- 2/3 empresas que utilizan Dockers, en ambientes de desarrollo

y pruebas dentro de los 30 días posteriores lo utilizaron en

producción.

- El aumento en la adopción de Dockers tiene una tasa del 35%

por año.

- Java, PHP, Node y Ruby son los frameworks de programación

más utilizados por los contenedores.

2.5.4. El ecosistema de Dockers

Se analizan las características de los proyectos que utilizan Dockers para

conocer el ecosistema, entre ellos encontramos que estos contenedores

37

se pueden generar a partir de un archivo “DockerFile”. Según datos de la

empresa GitHub el siguiente histograma considera el tamaño del conjunto

de datos de los proyectos top que se han generado a partir de un archivo

“DockerFile”.

GRÁFICA 1. ECOSISTEMA DE DOCKERS EN GITHUB

El

aborado por: Lab University of Zurich

Fuente: Software Evolution and Architecture Lab University of Zurich,

Switzerland,

2.5.5. Docker Machine

Estrada (2017) indica que “es una herramienta que permite la creación de

hosts (anfitriones) para contenedores Docker. Además de la creación de

hosts, también permite instalar Docker en cada uno de ellos, así como

configurar automáticamente el cliente de Docker para comunicarse con él

de forma remota” (p. 12).

38

2.5.6. Docker Swarm

Estrada (2017) indica que “es herramienta que permite a un grupo de

hosts presentarse como un solo host virtual de contenedores Docker, esto

permite que cualquier aplicación o herramienta que se comunique con el

demonio de Docker pueda utilizar Swarm para escalar transparentemente

a múltiples instancias”. (p. 12).

2.5.7. Docker Compose

Estrada (2017) indica que “es una herramienta para la definición y

ejecución de aplicaciones multi-contenedor de Docker. Esto permite que

con un simple comando se puedan crear y ejecutar todos los servicios

definidos en un archivo de configuración”. (p. 12).

2.6. Registrador de servicios

Hablar de microservicios es referirse a tener múltiples servicios que van a

trabajar en conjunto, por ello es necesario una herramienta que permita a

cada cliente de cada servicio localizar la instancias que se están

ejecutando.

Para ello es necesaria una base de datos de los servicios, sus instancias

y sus locaciones y un administrador (registrador de servicios) que permita

39

el registro y dar de baja a los servicios, así como una interfaz que sirva

para la consulta de servicios por parte de sus clientes. Newman (2015).

El registrador de servicio como de visualiza en la siguiente ilustración,

consulta la ubicación de los servicios, quien se encarga de reenviar la

invocación a través de un enrutador a la dirección antes consultada.

Además, se puede apreciar como el enrutador también actúa como

balanceador de carga, el mismo que puede ocultar el número de

microservicios levantados

Ilustración 12. REGISTRADOR DE SERVICIOS




40

Este servicio desempeña un papel importante, ya que realiza

continuamente seguimiento a los microservicios activos, da ubicación

desde que se inicia la instancia y al terminar la misma se elimina.

2.7.1. Consul

Desarrollada por HashiCorp, Consul tiene múltiples componentes, pero en

conjunto, es una herramienta para descubrir y configurar servicios en su

infraestructura. HashiCorp [HC] (2018).

Eduardo (2017) en su publicación “Spring Cloud Consul” define a Consul

como un agente: “Y un agente es un proceso de larga duración que se

ejecuta en cada nodo que forma parte del sistema Consul”. Es el

responsable de surtir de información de sí mismo y recoger información

de los demás agentes. Se comunica vía HTTP y, además, integra un

servidor DNS. Puede ejecutarse en dos modos: cliente o servidor.

Los clientes Consul pueden descubrir proveedores usando DNS o HTTP

que dependan de si, además proporcionan comprobaciones del estado

del servicio, las mismas que pueden ser utilizadas para monitorear el

estado del clúster. Y por último puede hacer uso del almacén de claves

jerárquico de Consul para cualquier propósito, incluida la configuración

dinámica. (…) HC (2018).

Consul, es uno de los principales registradores de servicios con

compatibilidad múltiple de descubrimientos de servicios incorporados,

41

como nos muestra en la siguiente ilustración, Consul puede redireccionar

dinámicamente un servicio hacia otro, además de ofrecer consolas de

administración, interfaz de usuario y API REST para buscar y registrar sus

servicios.

Ilustración 13. INTERFAZ CONSUL

Elaborado por: GitHub

Fuente: https://sagarkrkv.github.io/CloudAgnostic-LoadBalancing-

HighAvailability/

2.7.2. Netflix Eureka

El articulo Eureka-Services define: “Eureka es un servicio REST que se

utiliza principalmente en la nube de AWS para ubicar servicios con el

objetivo de equilibrar la carga”. (Memorynotfound, 2018). Esta

herramienta es de código abierto y desarrollada por Netflix, entre sus

desventajas se encuentra que solamente está disponible para ser

utilizada con el lenguaje de programación Java, y es necesario el uso de

otras librerías para tener clientes desarrollados en otros lenguajes de

42

programación. Y como ventaja se puede apreciar la compatibilidad que

tiene con las otras herramientas de código abierto provistas por Netflix.

Newman (2015).

En la siguiente ilustración, tenemos como ejemplo 3 microservicios A, B y

C. El servicio A expone una API REST externa a través de la puerta de

enlace Zuul. Se comunica de forma asincrónica con el Servicio B

mediante el uso de notificaciones. Procesos de servicio la notificación

puede realizar una llamada REST al Servicio B. El Servicio C expone una

API REST a la que solo pueden acceder los servicios de nivel medio.

Ritesh Patel (2014)

Ilustración 14. REGISTRY EUREKA

Elaborado por: Ritesh Patel

Fuente: https://www.nirmata.com/2014/08/13/getting-started-with-

microservices-using-netflix-oss-docker/

https://www.nirmata.com/2014/08/13/getting-started-with-microservices-using-netflix-oss-docker/

https://www.nirmata.com/2014/08/13/getting-started-with-microservices-using-netflix-oss-docker/

43

2.8. Git

Es un sistema donde se registran el control de versiones sobre un

conjunto de archivos de diferentes tamaños, de modo que en cualquier

momento se puedan recuperar versiones anteriores o alguna en

específico, haciendo el trabajo más eficiente. Cada repositorio guarda un

historial de los cambios realizados, esto permitirá revertir el código a un

estado anterior, además permite ver quien realizó la última modificación

en el proyecto. Este control de versionamiento es utilizado por muchas

empresas ya que facilitan ahorro de tiempo en sincronización de código al

momento de realizar un pase a Producción.

2.9. Maven

Herramienta de Open Source que tiene por objetivo generar y compilar

código fuentes, para que se incluyan en el ejecutable las dependencias,

módulos y librerías. Esto simplifica el proceso de compilación del código

permitiendo gestionar los proyectos desde la etapa de desarrollo hasta el

despliegue de la aplicación, no sin antes gestionar la ejecución de

pruebas y generación de documentación e informes. Maven define los

siguientes ciclos que debe tener un Proyecto:

• Validación (Build): Validar que el código es correcto.

• Compilación (compile). Ejecución del código fuente

• Test (test): Pruebas del código con algún framework.

• Empaquetar (package): Generar él ejecutable .jar o .war.

44

• Pruebas de integración (integration-test): Proceso y despliege el

código en entorno de pruebas.

• Instalar (Install): Instalar el empaquetado en el repositorio local.

• Desplegar (Deploy). Despliegue del código en ambiente Productivo.

2.10. Metodologías Agiles

A continuación, se muestra el comparativo entre las metodologías agiles

más usadas en las organizaciones.

CUADRO 6. CUADRO COMPARATIVO DE METODOLOGIAS AGILES

SCRUM KABAN PROGRAMACIÓN

EXTREMA (XP)

Se basa en un

desarrollo del producto

incremental.

Es un proceso tan

sencillo como eficaz

Se valora al individuo y

las interacciones del

equipo de desarrollo

sobre el proceso y las

herramientas.

El trabajo se desarrolla

a base de grupos auto-

organizados

Trata de medir

tiempos y cantidades

en procesos de

fabricación.

Desarrollar software

que funciona más que

conseguir una buena

documentación.

Las fases de

desarrollo conviven y

se revisan

constantemente

Optimiza cada una de

las actividades que se

llevan a cabo.

La colaboración con el

cliente. Se propone

que exista una

interacción constante

entre el cliente y el

45

equipo de desarrollo.



2.11. F5 Load Balancer

Es un dispositivo de equilibrador de carga que actúa como un proxy

inverso y distribuye el tráfico de red o de aplicaciones a través de una

serie de servidores. Los equilibradores de carga se utilizan para aumentar

la capacidad (usuarios simultáneos) y la fiabilidad de las aplicaciones.

Mejoran el rendimiento general de las aplicaciones al disminuir la carga

en los servidores asociados con la administración y el mantenimiento de

las aplicaciones y las sesiones de red, así como al realizar tareas

específicas de la aplicación.

Los equilibradores de carga generalmente se agrupan en dos categorías:

capa 4 y capa 7. Los equilibradores de carga de capa 4 actúan según los

datos encontrados en protocolos de red y capa de transporte (IP, TCP,

FTP, UDP). Los equilibradores de carga de Capa 7 distribuyen las

solicitudes en función de los datos encontrados en protocolos de capa de

aplicación como HTTP.

46

Ilustración 15. F5 LOAD BALANCER



2.12. cAdvisor

cAdvisor (Container Advisor) proporciona a los usuarios de contenedores

una comprensión del uso de los recursos y las características de

rendimiento de sus contenedores en funcionamiento. Es un Daemon en

ejecución que recopila, agrega, procesa y exporta información sobre

contenedores en ejecución. Específicamente, para cada contenedor

mantiene parámetros de aislamiento de recursos, uso histórico de

recursos, histogramas de uso completo de recursos históricos y

estadísticas de red. Esta información se exporta por contenedor y por

toda la máquina.

cAdvisor tiene soporte nativo para contenedores Docker y debería ser

compatible con cualquier otro tipo de contenedor de forma inmediata.

Para probar rápidamente cAdvisor en su máquina con Docker, tenemos

una imagen Docker que incluye todo lo que necesita para

47

comenzar. Puede ejecutar un solo cAdvisor para monitorear toda la

máquina. Simplemente se ejecuta algo similar a la siguiente ilustración.

Ilustración 16. EJECUTAR CADVISOR EN UN DOCKER CONTAINER



FUNDAMENTACIÓN LEGAL

Con el fin de dar a conocer y valorar esta tecnología de arquitectura de

microservicios basadas en Dockers a las empresas a la hora de

desarrollar o implementar sus servicios de este tipo, es mostrar las

diferencias y ventajas que se pudieran aportar.

En gran parte de este documento se sintetizará las diferentes ventajas y

desventajas que ofrece esta arquitectura, se realizará un ejemplo para

demostrar en que se basa el modelo de desarrollo de la arquitectura

48

Por lo tanto, en este trabajo de grado me basaré en los siguientes

fundamentos legales:

Art. 80.- El Estado fomentará la ciencia y la tecnología, especialmente en

todos los niveles educativos, dirigidas a mejorar la productividad, la

competitividad, el manejo sustentable de los recursos naturales, y a

satisfacer las necesidades básicas de la población. Garantizará la libertad

de las actividades científicas y tecnológicas y la protección legal de sus

resultados, así como el conocimiento ancestral colectivo.

La investigación científica y tecnológica se llevará a cabo en las

universidades, escuelas politécnicas, institutos superiores técnicos y

tecnológicos y centros de investigación científica, en coordinación con los

sectores productivos cuando sea pertinente, y con el organismo público

que establezca la ley, la que regulará también el estatuto del investigador

científico.

LEY DE COMERCIO ELECTRÓNICO, FIRMAS

LECTRÓNICAS Y MENSAJES DE DATOS

Art. 2.- “Reconocimiento jurídico de los mensajes de datos. - Los

mensajes de datos tendrán igual valor jurídico que los documentos

escritos. Su eficacia, valoración y efectos se someterá al cumplimiento de

lo establecido en esta Ley y su reglamento.”

49

Art. 4.- “Propiedad Intelectual. - Los mensajes de datos estarán

sometidos a las leyes, reglamentos y acuerdos internacionales relativos a

la propiedad intelectual.”

Art. 5.- “Confidencialidad y reserva. - Se establecen los principios de

confidencialidad y reserva para los mensajes de datos, cualquiera sea su

forma, medio o intención. Toda violación a estos principios, principalmente

aquellas referidas a la intrusión electrónica, transferencia ilegal de

mensajes de datos o violación del secreto profesional, será sancionada

conforme a lo dispuesto en esta Ley y demás normas que rigen la

materia.”

CÓDIGO ORGÁNICO INTEGRAL PENAL

Artículo 229.- “Revelación ilegal de base de datos. - La persona que, en

provecho propio o de un tercero, revele información registrada, contenida

en ficheros, archivos, bases de datos o medios semejantes, a través o

dirigidas a un sistema electrónico, informático, telemático o de

telecomunicaciones; materializando voluntaria e intencionalmente la

violación del secreto, la intimidad y la privacidad de las personas, será

sancionada con pena privativa de libertad de uno a tres años.”

“Si esta conducta se comete por una o un servidor público, empleadas o

empleados bancarios internos o de instituciones de la economía popular y

solidaria que realicen intermediación financiera o contratistas, será

sancionada con pena privativa de libertad de tres a cinco años.”

50

Artículo 230.- “Interceptación ilegal de datos. - Será sancionada con pena

privativa de libertad de tres a cinco años:”

1. “La persona que, sin orden judicial previa, en provecho propio o de un

tercero, intercepte, escuche, desvíe, grabe u observe, en cualquier forma

un dato informático en su origen, destino o en el interior de un sistema

informático, una señal o una transmisión de datos o señales con la

finalidad de obtener información registrada o disponible.”

2. “La persona que diseñe, desarrolle, venda, ejecute, programe o envíe

mensajes, certificados de seguridad o páginas electrónicas, enlaces o

ventanas emergentes o modifique el sistema de resolución de nombres de

dominio de un servicio financiero o pago electrónico u otro sitio personal o

de confianza, de tal manera que induzca a una persona a ingresar a una

dirección o sitio de internet diferente a la que quiere acceder.”

3. “La persona que a través de cualquier medio copie, clone o

comercialice información contenida en las bandas magnéticas, chips u

otro dispositivo electrónico que esté soportada en las tarjetas de crédito,

débito, pago o similares.”

4. “La persona que produzca, fabrique, distribuya, posea o facilite

materiales, dispositivos electrónicos o sistemas informáticos destinados a

la comisión del delito descrito en el inciso anterior.”

51

Artículo 231.- “Transferencia electrónica de activo patrimonial. – La

persona que, con ánimo de lucro, altere, manipule o modifique el

funcionamiento de programa o sistema informático o telemático o mensaje

de datos, para procurarse la transferencia o apropiación no consentida de

un activo patrimonial de otra persona en perjuicio de esta o de un tercero,

será sanciona da con pena privativa de libertad de tres a cinco años. “

“Con igual pena, será sanciona da la persona que facilite o proporcione

datos de su cuenta bancaria con la intención de obtener, recibir o captar

de forma ilegítima un activo patrimonial a través de una transferencia

electrónica producto de este delito para sí mismo o para otra persona.”

Artículo 232.- “Ataque a la integridad de sistemas informáticos. – La

persona que destruya, dañe, borre, deteriore, altere, suspenda, trabe,

cause malfuncionamiento, comportamiento no deseado o suprima datos

informáticos, mensajes de correo electrónico, de sistemas de tratamiento

de información, telemático o de telecomunicaciones a todo o partes de

sus componentes lógicos que lo rigen, será sancionada con pena privativa

de libertad de tres a cinco años.”

Con igual pena será sancionada la persona que:

1. “Diseñe, desarrolle, programe, adquiera, envíe, introduzca, ejecute,

venda o distribuya de cualquier manera, dispositivos o programas

informáticos maliciosos o programas destinados a causar los efectos

señalados en el primer inciso de este artículo. “

52

2. “Destruya o altere sin la autorización de su titular, la infraestructura

tecnológica necesaria para la transmisión, recepción o procesamiento de

información en general.”

“Si la infracción se comete sobre bienes informáticos destinados a la

prestación de un servicio público o vinculado con la seguridad ciudadana,

la pena será de cinco a siete años de privación de libertad.”

Artículo 233.- “Delitos contra la información pública reservada

legalmente. La persona que destruya o inutilice información clasificada de

conformidad con la Ley, será sancionada con pena privativa de libertad de

cinco a siete años. “

“La o el servidor público que, utilizando cualquier medio electrónico o

informático, obtenga este tipo de información, será sancionado con pena

privativa de libertad de tres a cinco años. “

“Cuando se trate de información reservada, cuya revelación pueda

comprometer gravemente la seguridad del Estado, la o el servidor público

encargado de la custodia o utilización legítima de la información que sin la

autorización correspondiente revele dicha información, será sancionado

con pena privativa de libertad de siete a diez años y la inhabilitación para

ejercer un cargo o función pública por seis meses, siempre que no se

configure otra infracción de mayor gravedad. “

53

Artículo 234.- “Acceso no consentido a un sistema informático,

telemático o de telecomunicaciones. - La persona que sin autorización

acceda en todo o en partea un sistema informático o sistema telemático o

de telecomunicaciones o se mantenga dentro del mismo en contra de la

voluntad de quien tenga el legítimo derecho, para explotar ilegítimamente

el acceso logrado, modificar un portal web, desviar o re direccionar de

tráfico de datos o voz u ofrecer servicios que estos sistemas proveen a

terceros, sin pagarlos a los proveedores de servicios legítimos, será

sancionada con la pena privativa de la libertad de tres a cinco años.”

54

HIPÓTESIS

¿Se podrá verificar el escalamiento, rendimiento y entrega continua en los

sistemas en un ambiente productivo, facilitando la adopción de

metodologías de desarrollo ágil por medio de la implementación de la

arquitectura de microservicios en contendores docker?

VARIABLES DE LA INVESTIGACIÓN

Variables Independientes

Arquitectura de microservicios con contenedores Dockers

Variables Dependientes

➢ Integración continúa.

➢ Mejorar tiempos de respuesta e implementación.

➢ Facilitar la adopción de metodologías de desarrollo Ágil

DEFINICIONES CONCEPTUALES

Arquitectura de Microservicios. – Es una aplicación de software que

está hecha en pequeños servicios.

Contenedores. – Es un elemento que permite aislar y empaquetar

aplicaciones con las librerías necesarias para su ejecución.

Integración continúa. - La integración continua es una práctica que en

su mayoría se desarrolla en la fase de integración o creación del

desarrollo de software la misma que sirve para detectar errores en la

implementación.

55

Implementación. – Puesta en ejecución de alguna tarea.

Desarrollo Ágil. – Toma de decisiones para el desarrollo incremental.

56

CAPÍTULO III

METODOLOGÍA DE LA INVESTIGACIÓN

En este capítulo del trabajo de investigación se explica la propuesta

metodológica que define las directrices para la comparación de una

arquitectura monolítica con una arquitectura de microservicio basada en

Dockers, tomando en consideración los conceptos del capítulo anterior.

Se analizan dos esquemas para la comparación de estas arquitecturas y

un mecanismo de desarrollo de la metodología que se acopla al uso de

contenedores para un mejor rendimiento que logre el objetivo propuesto.

DISEÑO DE LA INVESTIGACIÓN

En vista de que no existe mucha información sobre el tema, pues aún son

pocas las empresas que utilizan esta tecnología, se toman como

precedente esta investigación para definir los conceptos más importantes

y llevar a cabo el trabajo de titulación en el que se basa la solución de

este proyecto.

57

Modalidad de la Investigación

La modalidad de investigación de este trabajo es del tipo documental y

bibliográfica, la misma que consiste en ampliar, estudiar y profundizar el

problema con apoyo de datos, trabajos de tesis, medios impresos que

permitan descubrir las necesidades del diseño de una arquitectura de

software de microservicios basada en contenedores Dockers.

La modalidad de investigación seleccionada es la que se encarga de

analizar y recoger información para transformarla en datos numéricos, los

mismos que deben constar en las variables del proyecto, es decir, medir

las respuestas de cada una de las preguntas.

La población de este proyecto corresponde a Empresas que utilizan

microservicios basados en contenedores Docker. De esta población se

selecciona una muestra representativa para que basados en los distintos

instrumentos de recolección de datos (entre ellos cuestionarios) sustentar

las tabulaciones estadísticas y representaciones en gráficos

correspondientes.

Tipo de Investigación

El tipo de investigación en este tema de grado se enfoca en un tipo de

investigación descriptiva, tal como su nombre lo dice, este tipo de

investigación describirá el entorno, los procesos y eventos que plantea

una arquitectura de microservicios basadas en contenedores Dockers.

58

Además, este trabajo de investigación tiene otro enfoque, el cual se hace

referencia al tipo de investigación bibliográfica, el cual permite recopilar

información de fuentes primarias o secundarias, como indica Raúl Rojas

(Rojas, 2002) “La investigación bibliográfica utiliza materiales

provenientes de revistas, periódicos, libros, documentos públicos y

privados. (..) Esta investigación está ligada a fuentes documentales y

temas relevantes para una investigación de las variables seleccionadas”

(Pág. 156).

Se evidencia en este tema de grado en el capítulo 2 (Marco Teórico) la

utilización de fuentes de información como tesis de grado, sitios web,

libros, repositorios de tesis, etc., las mismas que sustentan las bases

teóricas de este trabajo de titulación.

POBLACIÓN Y MUESTRA

Población

La población en esta propuesta de trabajo de investigación representa a

un grupo de empresas que migraron de una arquitectura tradicional a una

arquitectura más eficaz que cumple con las características de entrega

continua y agilidad en sus procesos (microservicios).

Según datos recolectados en el medio local a enero de 2018 son pocas

empresas de la ciudad de Guayaquil, las que ya cuentan con esta

arquitectura de microservicios basadas en contenedores Dockers

implementada a cabalidad. De ese grupo, sólo cinco de estas empresas

fueron pioneras en la adopción de esta arquitectura y por ello, son las que

59

llevan utilizándola por un tiempo aproximado a 1 año. Se considera este

tiempo como un lapso mínimo que permite apreciar mejoras,

diferenciadores y datos que pueden ser utilizados por esta investigación.

Muestra

Se analizarán las características a las que hace referencia la muestra

seleccionada (5 empresas con mayor madurez en utilización de la

arquitectura de Microservicios).

La muestra que se considera para este proyecto y en las encuestas a

realizarse estará conformada por 5 empresas, las mismas que ya tienen

implementado en sus servidores contenedores Dockers por un tiempo

aproximado a 1 año.

CUADRO 7. DISTRIBUCIÓN DE LA MUESTRA

Muestra Cantidad

Empresas de

Telecomunicaciones

1

Empresas del Sector

Bancario

4

Total 5




60

Operacionalización de variables

CUADRO 8. MATRIZ DE OPERACIONALIZACIÒN DE VARIABLES

Variables Dimensiones Indicadores Técnicas y/o

Instrumentos

VARIABLE

INDEPENDIENTE

Empresas con

sistemas basados

en una

arquitectura de

microservicios.

Evaluar el

tiempo de

respuesta en

los servicios.

% de uso de

Recursos de

Hardware y

Software

Encuesta a las

empresas y

Evaluación en

aplicación

Evaluar los

fallos en los

sistemas

% Tiempo

promedio en

encontrar los

errores

Bibliografía

Encuesta

Evaluar

desempeño en

los despliegues

en los módulos

Tiempos

promedio en

realizar un

despliegue

Bibliografía

Encuesta y

Evaluación en

aplicación

VARIABLE

DEPENDIENTE

Mejorar tiempos

de respuesta e

implementación.

Integración

continua

Tiempos de

respuesta entre

el cliente y

servidor

Pruebas Evaluación en

aplicación

Pequeños

servicios que se

ejecutan por

separado

Ventajas Bibliografía

Mejoran los

tiempos de

respuesta ante

un fallo en el

sistema

Características Bibliografía

61

Uso de

Contenedores

Dockers

Concepto Bibliografía



Instrumentos de Recolección de Datos

Técnica: La técnica que se utiliza para la recolección de datos es la de

campo, en la cual se realiza una encuesta dirigida a las empresas que

actualmente utilizan esta arquitectura de microservicios basados en

contenedores Dockers.

Instrumentos de Investigación: El instrumento que se utiliza para

generar la información es el cuestionario, la encuesta utiliza esta

herramienta la cual recopila información de preguntas sencillas y

aplicadas a la muestra, con el objetivo de obtener una opinión. El

cuestionario es un medio útil y fiable para recoger información de un

objetivo en concreto en un tiempo breve.

Encuesta:

Es un método de investigación que agrega datos específicos a los

cuestionarios para la recopilación de datos que se utiliza para obtener

información de diversos temas para finalizar con un análisis estadístico.

Recolección de la información

Las encuestas se realizaron en 4 empresas del sector Bancario y una

empresa de telecomunicaciones.


62

Procesamiento y Análisis

Las siguientes preguntas se realizaron en base al tema de grado para

comprobar los objetivos planteados al inicio de esta investigación. Las

preguntas se enviaron por Google Drive. A continuación, se muestran las

preguntas realizadas.

ENCUESTA

Marque con una X sus respuestas.

Pregunta 1: ¿Considera usted que, con la utilización de la

Arquitectura de Microservicios versus la Arquitectura tradicional, ha

tenido un mejor rendimiento en las aplicaciones? ¿En qué

porcentaje?

CUADRO 9. RESULTADO DE LA PREGUNTA 1

¿Considera usted que, con la utilización de

la Arquitectura de Microservicios versus la

Arquitectura tradicional, ha tenido un mejor

rendimiento en las aplicaciones? ¿En qué

porcentaje?

Encuestas

% Repuestas

1% - 10% 0 0%

11% – 20% 2 40%

21% - 30% 2 40%

Mayor al 30% 1 20%

TOTAL 5 100%


Fuente: Datos de la recolección en la Encuesta


63

GRÁFICA 2. MEJORAS EN EL RENDIMIENTO EN LAS

APLICACIONES UTILIZANDO ARQUITECTURA DE MICROSERVICIOS



Análisis: El 100% de los encuestados manifiesta haber observado

mejoras en el rendimiento de las aplicaciones utilizando arquitectura de

microservicios. Un 20% de los encuestados ha observado una mejora en

los rendimientos en sus aplicaciones mayor al 30%, el 80% de los

encuestados consideran mejoras de menor rango, pero aun así

significativas (del 11% - al 30%), esto significa que al utilizar esta

arquitectura de microservicios en contenedores Dockers mejoraron el

rendimiento en las aplicaciones.

Pregunta 2: ¿En qué porcentaje considera usted que, con la

utilización de la Arquitectura de Microservicios versus la

Arquitectura tradicional, ha tenido una disminución en el tiempo de

despliegues de las aplicaciones?


¿En qué porcentaje considera usted que,

con la utilización de La Arquitectura de

Microservicios versus la Arquitectura

Encuestas

% Repuestas


64

tradicional, ha tenido una disminución en el

tiempo de despliegues de las aplicaciones?

1% - 10% 0 0%

11% – 20% 3 60%

21% - 30% 2 40%

Mayor al 30% 0 0%

TOTAL 5 100%



GRÁFICA 3. DISMINUCIÓN EN TIEMPO DE DESPLIEGUES EN LAS

APLICACIONES UTILIZANDO ARQUITECTIRA DE MICROSERVICIOS



Análisis: El 100% de los encuestados consideran que han disminuido el

tiempo de despliegues en sus aplicaciones, un 40% de los encuestados

ha observado que ha disminuido el tiempo en los despliegues entre el 21

y el 30%, y el otro 60% de los encuestados considera que mejoró el

tiempo de despliegues entre el 11% y 20 %, lo cual significa que al utilizar



65

esta arquitectura de microservicios en contenedores Dockers mejoraron

los tiempos en despliegues en las aplicaciones.

Pregunta 3: ¿Cuál ha sido la disminución porcentual en tiempo de

implementación de nuevos desarrollos utilizando la arquitectura de

microservicios versus la arquitectura tradicional?


¿Cuál ha sido la disminución porcentual en

tiempo de implementación de nuevos

desarrollos utilizando la arquitectura de

microservicios versus la arquitectura

tradicional?

Encuestas

% Repuestas

1% - 10% 0 0%

11% – 20% 1 20%

21% - 30% 2 60%

Mayor al 30% 2 20%

TOTAL 5 100%



GRÁFICA 4. DISMINUCIÓN EN TIEMPO DE IMPLEMENTACIÓN





66

Análisis: El 100% de los encuestados considera mejoras en los tiempos

de implementación de nuevos desarrollos. Un 20% de los encuestados ha

observado una mejora en los tiempos en las nuevas implementaciones

mayor al 30%, el 80% de los encuestados consideran mejoras de menor

rango, pero aun así significativas (del 11% - al 30%), esto significa que al

utilizar esta arquitectura mejoraron los tiempos al realizar nuevas

implementaciones.

Pregunta 4: ¿Según su perspectiva si tuviera que ponerle un

porcentaje de impacto positivo que tuvo la organización al

implementar esta arquitectura seria de?


¿Según su perspectiva si tuviera que

ponerle un porcentaje de impacto positivo

que tuvo la organización al implementar

esta arquitectura seria de?

Encuestas

% Repuestas

1% - 10% 0 0%

11% – 20% 0 0%

21% - 30% 2 40%

Mayor al 30% 3 60%

TOTAL 5 100%




67

GRÁFICA 5. IMPACTO POSITIVO EN LA ORGANIZACIÓN AL

UTILIZAR ARQUITECTURA DE MICROSERVICIOS



Análisis: El 100% de los encuestados consideran que han observado un

impacto positivo al utilizar esta arquitectura. El 60% considera que ha

tenido un impacto positivo mayor al 30%, por lo que se están enfocando

en implementar nuevos proyectos con esta arquitectura.

Pregunta 5: ¿De los siguientes ítems, seleccione aquellos que

considere usted tuvieron un impacto negativo?


¿De los siguientes ítems, seleccione

aquellos que considere usted tuvieron un

impacto negativo?

Encuestas

% Repuestas

Despliegues distribuidos 3 60%

Centralización de la administración de los

sistemas

4 80%

Despliegue del sistema 0 0%


68

Alto consumo de memoria. 0 0%

Monitoreo del sistema 4 80%

Ninguno 1 20%



GRÁFICA 6. IMPACTO NEGATIVO AL UTILIZAR MICROSERVICIOS



Análisis: Según datos recolectados a los encuestados consideran que la

Centralización de la Administración y el Monitoreo de los Sistema han

sido un impacto negativo en las empresas, debido a que no existía como

controlar o monitorear esta arquitectura de microservicios. Para esto se

implementó la arquitectura de microservicios en contendores Dockers

como paliativo a estas desventajas y para ayudar a controlar la

administración y el monitoreo de los sistemas y evitar que las empresas

sean afectadas en este aspecto.

Pregunta 6: ¿Cuán importante cree usted que es la utilización de una

arquitectura de microservicios para lograr la adopción rápida de una

metodología y desarrollo ágil?



69


¿Cuán importante cree usted que es la

utilización de una arquitectura de

microservicios para lograr la adopción

rápida de una metodología y desarrollo

ágil?

Encuestas

% Repuestas

Muy Importante 4 80%

Importante 1 20%

Moderadamente Importante 0 0%

De poca importancia 0 0%

Sin importancia 0

TOTAL 5 100%



GRÁFICA 7. IMPORTANCIA EN UTILIZAR UNA METODOLOGÍA PARA

LA IMPLEMENTACIÓN DE MICROSERVICIOS





70

Análisis: El 100% de los encuestados considera importante la adopción

de una metodología ágil al implementar nuevos desarrollos con la

arquitectura de microservicio.

Análisis General: El 100% de los encuestados considera que al utilizar

esta arquitectura han observado mejoras en el rendimiento de las

aplicaciones, el tiempo de despliegues ha disminuido, la implementación

de nuevos desarrollos en menor tiempo, y un impacto positivo al utilizar

esta arquitectura.

71

CAPÍTULO IV

RESULTADOS, CONCLUSIONES Y RECOMENDACIONES

PRESENTACIÓN DE RESULTADOS

Para la presentación de los resultados se realizaron dos escenarios en los

cuales se demuestra el rendimiento de la arquitectura tradicional con la

arquitectura de microservicios con contenedores Dockers.

La aplicación que se realizó para la comprobación de las arquitecturas se

describe a continuación:

➢ Aplicación Web

➢ Opción de Módulo de Productos

o Opción de listados de Productos.

o Opción de Ingreso de Productos.

➢ Opción de Registro de Usuarios

➢ Opción de Autenticación de Usuarios.

La aplicación se redirecciona cuando se realiza el Login a otra página

donde lista todos los productos que se encuentran registrados en la base

de datos, además, se puede registrar un nuevo producto. Si las

credenciales no son las correctas se muestra un mensaje “Usuario y/o

72

Contraseñas incorrectas”, además, se tiene la opción de poder registrar

un nuevo usuario en el sistema.

Esta aplicación utiliza las dos arquitecturas (Monolítica y de

Microservicios) para lo cual se utilizarán los siguientes recursos:

CUADRO 15. RECURSOS DE HARDWARE

Recursos de Hardware Características

Modelo Laptop Sony Vaio

Memoria 8 GB DD3 10150MHz

Disco Duro SATA 1 TB, 7200RPM

Sistema Operativo Windows 8.1, 64bit

Procesador Intel(R) Core (TM) i5-3210 M 2.50

GHz



CUADRO 16. RECURSOS DE SOFTWARE

Recursos de Software Software Monolítico Software

Microservicios

Framework JEE Spring Boot

Software de desarrollo Eclipse Eclipse

Lenguaje de

Programación

Java, Jsp, HTML,

JavaScript

Java, HTML,

JavaScript

Software para medir los

recursos

Jmeter Jmeter

Software para servidor apache-tomcat-8

(Servidor)

apache-tomcat-8

(imbebible)

Software de contenedor Dockers





73

4. Desarrollo y diseño de un prototipo de Sistemas de Módulos de

gestión de Productos y Usuarios.

4.1. Funcionalidad del Prototipo

El presente trabajo, presenta las funcionalidades básicas del prototipo que

se implementó para lograr demostrar el propósito de esta investigación.

• Registros de Usuarios

Permite la creación de usuarios para login de la aplicación, con los datos

básicos y necesarios, los mismos que son:

o Usuario

o Contraseña

o Email

o Edad

o Teléfono

• Módulo de Autenticación de Usuarios

Puede ingresar a la aplicación un usuario luego de haberse registrado en

el módulo anterior. Los datos necesarios son:

o Usuario y

o Contraseña.

• Módulo Ingreso y Consulta de Productos

Permite ingresar nuevos productos a la base de datos del sistema, luego

esto se pueden visualizar en la misma página los datos antes ingresados.

Por ser un prototipo se visualizan todos los registros, pero en un sistema

completo debería manejar roles de acceso, de tal forma que solo el

usuario administrador debería poder registrar, modificar, consultar y

eliminar el/los productos del sistema y los usuarios normales solo

deberían estar en la capacidad de consultar.

74

4.2. Caso de uso

Para este trabajo de grado, se detallan solo los casos de uso del sistema

de Gestión de Productos y Usuarios, que se presentó en el punto anterior.

4.2.1. Caso de uso de la funcionalidad del sistema de prototipo

4.2.1.1. Caso de uso de Registro de Usuario

CUADRO 17. CASO DE USO DE REGISTRO DE USUARIO

Nombre Registro de Usuarios

Actor Usuarios

Flujo Eventos Actor Eventos Sistema

1. Ingresar a la opción

de registro

3. Registrar los datos

del usuario

2. Solicita los datos básicos

como: usuario, contraseña,

confirmar contraseña, email,

edad y teléfono

4. Se Visualiza mensaje de

confirmación de registro

exitoso y se redirecciona a

login



4.2.1.2. Caso de Uso de Autenticación de Usuarios

CUADRO 18. CASO DE USO DE AUTENTICACIÓN DE USUARIOS

Nombre Autenticación de Usuarios

Actor Usuarios


1. Ingresar a la opción

de login

2. Solicita los datos autenticación

como: usuario y contraseña.


75

3. Ingresa los datos al

login de la aplicación

4. Se Visualiza mensaje de

Autenticación exitosa y se

redirecciona a la página de

consulta e ingreso de

Productos



4.2.1.3. Caso de Uso de Consulta e Ingreso de Productos

CUADRO 19. CASO DE USO DE CONSULTA E INGRESO DE PRODUCTOS

Nombre Consulta e Ingreso de Productos

Actor Usuarios


1. Visualizar la

pantalla de ingreso

de Productos

3. Ingresa los datos en

el formulario de la

aplicación

2. Solicita los datos de registro

de productos como: nombre

del producto, descripción del

producto, precio, y fecha de

ingreso

4. Se Muestra el dato recién

ingresado en la aplicación

Precondición:

1. El usuario debe estar autenticado para poder ingresar

y consultar los productos





76

4.2.2. Diagramas de Secuencias

Para logra entender mejor los casos presentados anteriormente, a

continuación, en la siguiente ilustración se puede visualizar el diagrama

de secuencia que representa el registro de usuarios.

Ilustración 17. DIAGRAMA DE SECUENCIA DE REGISTRO DE USUARIO



A continuación, en la ilustración 18 se puede visualizar el diagrama de

secuencia de autenticación de usuario en el sistema.


77

Ilustración 18. DIAGRAMA DE SECUENCIA DE AUTENTICACIÓN DE USUARIO



A continuación, en la ilustración 19 se puede visualizar el diagrama de

secuencia de consulta e Ingreso de Productos.


78

Ilustración 19. DIAGRAMA DE SECUENCIA DE CONSULTA E INGRESO DE PRODUCTOS



4.2.3. Diagrama de Base de Datos

Para la presentación de los resultados de este prototipo se creó una Base

de datos en MYSQL que se la nombró como “Proyecto”, la misma que

tiene dos estructuras.

o user_registry

o product


79

4.2.4. Diagrama de Arquitectura

En la siguiente ilustración, se muestra el diagrama de arquitectura para

este prototipo de sistema de gestión de usuarios y productos, el mismo

que satisface las funcionalidades que anteriormente se comentó en los

anteriores puntos.

Ilustración 20. DIAGRAMA DE ARQUITECTURA




80

4.3. Pruebas de Rendimiento utilizando la aplicación Jmeter

Para la evaluación del rendimiento de este prototipo, se utilizó la

aplicación “Jmeter”, el hacer uso de esta aplicación permitió monitorear el

desempeño de este sistema.

Durante las pruebas de estrés se tomó en cuenta el servicio de

Autenticación de usuarios para medir el rendimiento de la aplicación.

Apache Jmeter se configuró de manera que se genera una carga de 240

usuarios durante 60 segundos, esto significa que 4 peticiones se generan

cada segundo, cabe recalcar que “Jmeter” toma un número de peticiones

de forma aleatoria para realizar las pruebas, en este caso no siempre se

toman las 4 solicitudes por segundo.

4.3.1. Pruebas de estrés en el servicio de arquitectura

monolítica

En la siguiente ilustración podemos observar el tiempo promedio en que

respondió el servidor las peticiones realizadas en las pruebas sobre esta

arquitectura. Durante esta prueba se detuvo el servicio por 20 segundos,

simulando un despliegue por actualización o por una falla en el sistema.

Ilustración 21. PRUEBAS DE ESTRÉS EN APACHE JMETER-RESPUESTA DEL SERVIDOR




81

Como se puede observar en la siguiente ilustración, las peticiones

tuvieron un tiempo aproximado a 30 segundos en las respuestas del

servidor, esto se debe en que en lapso de tiempo el servidor no estaba

atendiendo peticiones, y el rendimiento subió en promedio 278 segundos.

Ilustración 22. PRUEBAS DE ESTRÉS SERVICIO DE AUTENTICACIÓN

DE USUARIO



En la siguiente ilustración observamos el detalle de la memoria utilizada al

ejecutarse el servicio, la misma que se utilizó en alrededor de 450 MB.

Ilustración 23. USO MEMORIA EN ARQUITECTURA MONOLITICA





82

4.3.2. Pruebas de estrés en el servicio de arquitectura basadas

en microservicios.

Se toma la misma prueba de estrés del escenario de arquitectura

monolítica con el fin de demostrar el tiempo en rendimiento entre estas

arquitecturas. Como se observa en la siguiente ilustración, el tiempo que

tardó en responder las solicitudes en promedio es de 0.5 segundos con

código 200 de respuesta del servidor, esto significa que todas las

solicitudes fueron exitosas, además, durante las pruebas se detuvo el

servicio de Registro de Usuarios simulando una actualización o una falla,

el mismo que no causo ninguna caída en el sistema

Como se visualiza en la siguiente imagen, el servicio de autenticación de

usuarios no registro ningún error en las peticiones, a pesar que el servicio

de ingreso de usuarios no está operativo.

Ilustración 24. PRUEBA DE ESTRÉS SERVICIO DE AUTENTICACIÓN-ERRORES



Se puede visualizar en la siguiente que el rendimiento tiene un promedio

de 16 segundos, es decir que mejora el rendimiento al utilizar esta

arquitectura.


83

Ilustración 25. PRUEBAS DE ESTRÉS SERVICIO DE AUTENTICACIÓN DE USUARIO



En la siguiente ilustración observamos el detalle de la memoria utilizada al

ejecutarse el servicio de Autenticación de Usuario, la misma que utilizó en

promedio 180 MB. Para verificar este resultado se utilizó la imagen

“Cadvisor” del repositorio de Dockers.

Ilustración 26. USO MEMORIA EN ARQUITECTURA DE MICROSERVICIO





84

4.3.3. Comparativa entre el servicio de arquitectura basadas

en microservicios y la arquitectura tradicional

(monolítica).

Como se puede observar en la ilustración 25 la arquitectura de

microservicio en contenedores Dockers, en el servicio de autenticación

tiene un promedio de 16 segundos en rendimiento menor que la

arquitectura tradicional que tiene un rendimiento de 278 segundos como

se visualiza en la ilustración 22

Además, se puede visualizar que los recursos utilizados por la

arquitectura de microservicios en contenedores Dockers es menor que la

arquitectura tradicional.

85

CONCLUSIONES

Al implementar microservicios basados en contenedores Dockers, el

tiempo mejora considerablemente en un promedio superior al 20% que la

arquitectura tradicional, de acuerdo a la recolección da datos que se

realizó a las empresas. Al desarrollar el prototipo, permitió verificar la

disponibilidad y escalabilidad del 100% en fallos o inactividad del servicio.

Además, se pudo verificar con este prototipo que el tiempo se reduce en

nuevos despliegues del 20% al 0%.

Durante la investigación de este trabajo y con el desarrollo del prototipo

se pudo evidenciar que una arquitectura de microservicios basados en

Dockers puede llegar a convertirse en una infraestructura muy compleja

de administrar si no existe alguna metodología de desarrollo ágil. El

implementar microservicios basados en contenedores Dockers se puede

decir que es el punto de unión para la utilización de metodologías ágil y

entrega continua, ya que al utilizar contenedores mejora los tiempos de

despliegues a tal modo que es perfecto para utilizar las metodologías de

desarrollo ágil como por ejemplo Scrum o Extreme.

En base a las pruebas de rendimiento realizadas se puede concluir que la

arquitectura de microservicios mejora en tiempo de respuesta y es

tolerante a fallos, ya que retorna los datos solicitados de forma exitosa, no

importando que otro servicio se encuentre detenido por una falla o por

una actualización en ese momento.

86

RECOMENDACIONES

Durante la realización de este trabajo se puede observar que es lo que se

necesita para la implementación de esta arquitectura, se recomienda

antes de la implementación realizar un análisis profundo para determinar

si el sistema que se implementará se ajusta a la infraestructura de tener

pequeños servicios. La arquitectura de microservicios puede llegar a ser

muy compleja, por lo que se recomienda el uso de contenedores Docker

el cual permitirá estandarizar estos pequeños servicios, de manera que se

puedan tener controlados bajo alguna herramienta de monitoreo.

Para alcanzar los principios de agilidad se sugiere que todos los

miembros de la empresa colaboren entre sí para lograr los mejores

resultados, este enfoque incluye que se alinean los profesionales, socios,

ejecutivos, proveedores, etc. Ya que la arquitectura de microservicios con

contenedores Docker actualmente es una tendencia como tecnología para

adoptar en la estrategia del negocio.

Se sugiere utilizar la imagen de “Cadvisor” (Imagen publicado en docker

hub) para monitorear el espacio en disco, memoria RAM y uso de CPU

del contenedor de software, esta herramienta es un software libre de

Google. Además, para la creación de los contenedores Docker e

imágenes de los microservicios, se recomienda utilizar un archivo llamado

“DockerFile”, el mismo que nos permitirá reutilizar las configuraciones

existentes para los diferentes ambientes de desarrollo, testing y

producción.

87

REFERENCIAS BIBLIOGRAFÍA

1. VMware, Inc. Virtualization: How It Works. Recuperado de

https://www.vmware.com/solutions/virtualization.html#how-it-works

2. Lewis, J., Fowler, M. (2014). Microservices. Chicago, Estados

Unidos. Martin Fowler. Recuperado de

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

3. Olmo, L., (2016) Recuperado de

http://www.ticbeat.com/tecnologias/que-son-y-como-funcionan-los-

contenedores-virtuales-infografia/ [Consulta: 19 de mayo de 2018].

4. Mocevicius, R. (2015). CoreOS Essentials (pp. 91). Estados

Unidos. Pack Publishing.

5. Garzas, J., García, A., (2015) Recuperado de

http://www.javiergarzas.com/2015/07/que-es-docker-sencillo.html

6. Newman, S. (2015). Building Microservices. Estados Unidos.

O’Reilly.

7. Villacampa, O., (2017) Recuperado de https://www.ondho.com/que-

es-docker-para-que-sirve/

8. Estrada, J., (2017) Diseño e Implementación de una Arquitectura

escalable basada en Microservicios para un Sistema de Gestión de

Aprendizaje con Características de Red Social. Universidad de

Guatemala. Recuperado de

http://www.repositorio.usac.edu.gt/7023/1/JOS%C3%89%20MANU

EL%20DE%20PAZ%20ESTRADA.pdf

9. HashiCorp, Recuperado de https://www.consul.io/intro/index.html.

10. Ignacio Goya, (2018) Recuperado de


11. Constitucional, T. (1998) Registro Oficial CONSTITUCIÓN

POLÍTICA DE LA REPÚBLICA DEL ECUADOR Consultado e:

http://pdba.georgetown.edu/Parties/Ecuador/Leyes/constitucion.pdf

12. SHARMA, Sanjeev. DevOps para Dummies. Limited. Hoboken:

John Wiley & Sons, Inc., 2014. 63 p. ISBN: 978-1-119-00406-6.

88

13. William S., (2017), IMPLEMENTACIÓN DE ARQUITECTURA DE

MICROSERVICIOS UTILIZANDO VIRTUALIZACIÓN POR

SISTEMA OPERATIVO

14. Daniel, (2016) Recuperado de:

http://enmilocalfunciona.io/arquitectura-microservicios-1/

15. Cesar, (2017) Recuperado de: https://docs.microsoft.com/es-

es/dotnet/standard/microservices-architecture/architect-

microservice-container-applications/communication-in-microservice-

architecture

16. Julien, (2017) PWC | GLOBAL. Recuperado de:

https://www.pwc.com/gx/en/industries/financial-

services/publications/financial-services-technology-2020-and-

beyond-embracing-disruption.html

17. Mark, (2015) PWC | GLOBAL Recuperado de:

https://www.pwc.com/gx/en/industries/technology/publications/glob

al-100-software-leaders/software-disruption-accelerates.html

18. Jancorg, (2015), LibContainer Overview. Recuperado de

http://jancorg.github.io/blog/2015/01/03/libcontainer-overview/

19. Syspixel, (2016). Recuperado de http://blog.syspixel.com/que-es-

docker-ventajas/

20. Ekaterina N. (2018). TOP 10 BENEFICIOS DE UTILIZAR

DOCKER. Recuperado de https://apiumhub.com/es/tech-blog-

barcelona/beneficios-de-utilizar-docker/

21. Springer Link, (2015). Introduction to JMS & Apache ActiveMQ

Recuperado de https://link.springer.com/chapter/10.1007/978-3-

540-69962-0_10

22. An Empirical Analysis of the Docker Container Ecosystem on

GitHub, (2017). Recuperado de

https://www.computer.org/csdl/proceedings/msr/2017/1544/00/0796

2382.pdf.

89

ANEXOS

ANEXO 1

CRONOGRAMA GENERAL DE TRABAJO

Actividad Duración Inicio Fin

Propuesta 5 días 04/26/2018 05/04/2018

Entrega de Propuesta de Trabajo 1 días 04/26/2018 04/27/2018

Revisión de Propuesta de Trabajo 2 días 05/01/2018 05/02/2018

Aprobación de Propuesta de Trabajo 2 días 05/03/2018 05/04/2018

Análisis 6 días 05/07/2018 05/14/2018

Análisis y Revisión de la Propuesta de

Trabajo

1 días 05/07/2018 05/07/2018

Revisión de Bibliografía 5 días 05/08/2018 05/14/2018

Desarrollo 64 días 05/15/2018 08/10/2018

Objetivos Generales 2 días 05/15/2018 05/16/2018

Objetivos Específicos 1 días 05/17/2018 05/17/2018

Introducción 1 días 05/18/2018 05/18/2018

Marco Teórico 14 días 05/21/2018 06/07/2018

Informe de Avance de Gestión (Anexo 3) 1 días 06/08/2018 06/08/2018

Marco Metodológico 21 días 06/11/2018 07/09/2018

Informe de Avance de Gestión (Anexo 3) 1 días 07/10/2018 07/10/2018

Resultado, Conclusiones y

Recomendaciones

23 días 07/11/2018 08/10/2018

Informe Final 3 días 08/13/2018 08/15/2018

Anexo 4 1 días 08/13/2018 08/13/2018

Anexo 5 1 días 08/14/2018 08/14/2018

Anexo 6 1 días 08/15/2018 08/15/2018

Cierre de Proyecto 28 días 08/16/2018 09/24/2018

Ingreso de Notas SIUG por el Tutor 4 días 08/16/2018 08/21/2018

Revisión del proyecto (Tutor) 12 días 08/16/2018 08/31/2018

Anexo 2 Revisor 1 días 08/22/2018 08/22/2018

Anexo 3, 4,8,11 (Tutor) 6 días 08/23/2018 08/30/2018

Ingreso notas SIUG(Revisor) 1 días 09/03/2018 09/03/2018

Sustentación 12 días 09/04/2018 09/19/2018

Registro de Actas e ingreso de

Calificaciones

3 días 09/20/2018 09/24/2018

90

ANEXO 3

ENCUESTA

Marque con una X sus respuestas.

Pregunta 1: ¿Considera usted que, con la utilización de la

Arquitectura de Microservicios versus la Arquitectura tradicional, ha

tenido un mejor rendimiento en las aplicaciones? ¿En qué

porcentaje?

__ 1% - 10%

__ 11% – 20%

__ 21% - 30%

__ Mayor al 30%

Pregunta 2: ¿En qué porcentaje considera usted que, con la

utilización de la Arquitectura de Microservicios versus la

Arquitectura tradicional, ha tenido una disminución en el tiempo de

despliegues de las aplicaciones?

__ 1% - 10%

__ 11% – 20%

__ 21% - 30%

__ Mayor al 30%

Pregunta 3: ¿Cuál ha sido la disminución porcentual en tiempo de

implementación de nuevos desarrollos utilizando la arquitectura de

microservicios versus la arquitectura tradicional?

__ 1% - 10%

__ 11% – 20%

91

__ 21% - 30%

__ Mayor al 30%

Pregunta 4: ¿Según su perspectiva si tuviera que ponerle un

porcentaje de impacto positivo que tuvo la organización al

implementar esta arquitectura seria de?

__ 1% - 10%

__ 11% – 20%

__ 21% - 30%

__ Mayor al 30%

Pregunta 5: ¿De los siguientes ítems, seleccione aquellos que

considere usted tuvieron un impacto negativo?

__ Despliegues distribuidos

__ Centralización de la administración de los sistemas

__ Despliegue del sistema

__ Alto consumo de memoria.

__ Monitoreo del sistema

__ Ninguno

Pregunta 6: ¿Cuán importante cree usted que es la utilización de una

arquitectura de microservicios para lograr la adopción rápida de una

metodología y desarrollo ágil?

__ Muy Importante

__ Importante

__ Moderadamente Importante

__ De poca importancia

__ Sin importancia

92

ANEXO 4

PRESUPUESTO Y FINANCIAMINENTO

PRESUPUESTO Y FINANCIAMIENTO

Descripción Valor

Uso de Internet $120.00

Viáticos $100.00

Impresión de Hojas $50.00

Laptop $700.00

Memorias RAM $90.00

Total $1,060.00

93

ANEXO 5

Creación de Prototipo de Sistemas de Usuarios y Productos

Requerimientos para el desarrollo:

• Apache-maven-3.5.4

• Spring Boot 1.4.3. RELEASE

• Eclipse

• Thymeleaf

• Java 8

Ilustración 27 ESTRUCTURA DE PROTOTIPO INGRESOMS,

PRODUCTOMS Y LOGINMS EN JAVA




94

Ilustración 28. EXTRUCTURA POM.XML




95

Ilustración 29. PAGINA PRINCIPAL- LOGIN



Ilustración 30. PAGINA DE REGISTRO DE USUARIO





96

Ilustración 31. INGRESO A LA PANTALLA DE PRODUCTOS Y AUTENTICACIÓN EXITOSA



Ilustración 32. INGRESO DE PRODUCTOS





97

Ilustración 33. LISTADO DE LOS PRODUCTOS INGRESADOS




98

ANEXO 6

Crear contenedores Dockers en Windows

• Utilizar el siguiente comando para crear un contenedor Docker

o Docker-machine créate node-1, como se visualiza en la

siguiente ilustración, se muestra las líneas que se está

creando una máquina virtual de Docker

Ilustración 34. CREACÓN DE MAQUINA VIRTUAL DOCKER



o Verificar que Ip se asignó a la máquina virtual Docker con el

comando docker-machine ls

Ilustración 35. VISUALIZAR IP DE MAQUINA VIRTUAL DE DOCKER





99

o Una vez verificado que docker Daemon asigno IP a la

máquina virtual, procedemos a setear a las variables de

entorno en la sesión con el siguiente comando:

▪ set DOCKER_HOST=tcp://192.168.99.101:2376

Ilustración 36. ASIGNACION EN VARIABLES DE ENTORNO



Descargar imágenes del repositorio Docker hub

• Descargar la imagen de la base de MySQL versión 5.7 con el comando: docker pull mysql:5.7

Ilustración 37. DESCARGAR LA IMAGEN DE LA BASE DE MYSQL

DEL REPOSITORIO DOCKER HUB



• Poner en marcha la base de datos con el siguiente comando

docker run -p 3306:3306 --name mysqldb -v ruta

/alfitrion:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=secret -d

mysql:5.7 --character-set-server=utf8mb4 --collation-

server=utf8mb4_unicode_ci

Significado de cada parámetro:

➢ -p 3306:3306: Corresponde al puerto que se expone y al

puerto Interno del Contenedor



100

➢ --name mysqldb: asigna nombre a imagen al contenedor

➢ -v volumen de datos donde se guardarán los el respaldo de

la base de datos.

➢ -d: correr en modo separado

➢ --character-set-server=utf8mb4: Para la codificación de

caracteres

➢ --collation-server=utf8mb4_unicode_ci: Se asigna para

colecciones de base de datos

➢ -e MYSQL_ROOT_PASSWORD=secret: Asigna a las

variables de entorno la contraseña de la base de datos

• Ingresar y crear una base de datos con el siguiente comando:

docker exec -it mysqldb mysql -uroot -p

Ilustración 38. CREANDO BASE DE DATOS EN MYSQL



Crear contenedor de los microservicios.

➢ Crear archivo “dockerfile” que tendrá las siguientes líneas

FROM openjdk:8-jre-alpine

MAINTAINER [email protected]

EXPOSE 9010

CMD java -jar LoginMS-0.0.1.jar

ADD LoginMS-0.0.1.jar /LoginMS-0.0.1.jar.jar


101

➢ Compilar la imagen en el contendor docker del microservicio

con el comando:

docker build – t login_ms: v1

➢ Ejecutar el contenedor de la imagen anteriormente creada

docker run -d -p 9081:8080 –name logims_v1 login_ms: v1

➢ Detener un contenedor de la imagen anteriormente creada

docker stop logims_v1

➢ Eliminar un contendor de la imagen anteriormente creada

docker rm logims_v1

➢ Detener y eliminar un contendor de la imagen anteriormente

creada

docker rm -f logims_v1

➢ Borrar una imagen de la imagen anteriormente creada

Docker rmi login_ms: v1

universidad de guayaquilrepositorio.ug.edu.ec/bitstream/redug/32755/1/b-cisc-ptg...de la universidad...

Documents