DESARROLLO Y PRUEBA DE SOFTWARE WEB BACK-END BASADO EN ARQUITECTURA DE MICROSERVICIOS CUMPLIENDO CON LOS

LINEAMIENTOS DE DEVOPS PARA UN SISTEMA DE GESTIÓN DE SERVICIOS DE TELECOMUNICACIONES PARA PERSONAS

NATURALES

Yeison Steven Sánchez Figueroa

Universidad de Antioquia Facultad de Ingeniería

Departamento de Ingeniería Electrónica y Telecomunicaciones Medellin - Colombia

2019

Titulo Desarrollo y prueba de software web back-end basado en arquitectura de microservicios cumpliendo con los lineamientos de DevOps para un sistema de gestión de servicios de telecomunicaciones para personas naturales. Resumen Un cliente interno de Accenture, dedicado a proveer servicios de telecomunicaciones, desarrolló en la fase inicial de la implementación del software back-end de un canal digital web de adquisición de servicios de telecomunicaciones, el cual tiene como funcionalidad principal exponer los diferentes servicios que este ofrece a sus clientes, bajo una arquitectura monolítica en el lado del servidor. Esto indica que el software en dicho canal digital es una única unidad lógica desplegable con su respectiva base de datos encargada de realizar todas las funcionalidades del canal. Al inicio para el cliente contar con el software del canal basado en arquitectura monolítica no presentaba ningún problema para él, pero con el transcurrir de los años, debido al aumento de la necesidad de adquirir servicios de telecomunicaciones a través de canales digitales, exigió al cliente a ofrecer cada vez mas funcionalidades en el canal digital en cuestión en lapsos de tiempo cortos, esto dejó como consecuencia para el software en el lado del servidor del canal la necesidad de tener un alto acoplamiento y crecer tanto en funcionalidad como en su correspondiente base de datos. Las exigencias en conjunto a las consecuencias que estas dejaron mencionadas en el anterior párrafo implicaron que cada vez que el cliente solicitaba la inclusión de una nueva funcionalidad al canal tuviera que esperar mas tiempo de lo exigido por el negocio implementarla por parte del equipo de desarrollo del canal, esto conllevó a nivel de negocio para el cliente dar ventajas comerciales con respecto a sus competidores y al mismo tiempo perder reputación y dinero. Por otro lado, también implicó tener un software difícil de mantener y de corregir errores, además de disminución en el ritmo de desarrollo. De acuerdo con lo anterior, la arquitectura monolítica y acoplada con la que contaba el software del canal del cliente ha dejado de cumplir con las exigencias de este, es por esto por lo que se separaron las funcionalidades del canal, en tres componentes: gestión de clientes, gestión de servicios y adquisición de servicios, basados en la arquitectura de microservicios. Esto le dio al cliente con respecto al software del canal, un sistema no monolítico, escalable horizontalmente, de bajo acoplamiento, implementación y realización de cambios sobre este de forma rápida y sencilla, estables, en pocas palabras un software fácil de mantener y de modificar para el equipo de soporte y desarrollo de software del canal en cuestión del cliente, satisfaciendo de esta manera las necesidades de este.

Introducción La evolución de las tecnologías en cuanto a software ha cambiado la manera en que se construye la arquitectura de software en los canales digitales. Algunas tecnologías que hacen parte de dicha evolución son los servicios Docker, Cloud y de orquestación de contenedores las cuales han brindado la capacidad de desarrollar soluciones distribuidas, mas escalables y confiables, además de sustentar una nueva arquitectura de software la cual ha permitido construir una gran aplicación basada en arquitectura monolítica como un conjunto de servicios modulares, pequeños, versionados de forma independiente y escalables centrados en el cliente con objetivos comerciales específicos, llamada arquitectura de microservicios, la cual en conjunto de las tecnologías que la sustentan fundamentan el tema de interés del presente informe, que consiste en la implementación de un sistema web back-end el cual fue implementado con una arquitectura monolítica, de un canal digital web que permite adquirir servicios de telecomunicaciones basado en arquitectura de microservicios, de un cliente de Accenture. En gran medida grandes empresas, de igual forma como las nuevas, construyen sus respectivos canales digitales usando una arquitectura monolítica. El fin de comenzar de esta manera es debido a que en la fase inicial de los proyectos se es mucho mas acelerado configurar un monolito y hacer que el negocio avance. Pero luego de algún tiempo, debido a la madurez del canal, necesidades del mercado y aumento de los usuarios del canal, exige que este tenga mas funcionalidades las cuales luego de ser adicionadas logra en cuanto a software se engrandezca con un alto acoplamiento. Tal es el caso por ejemplo de la empresa Walmart, inicio su canal digital basado en arquitectura monolítica, después de algún tiempo, debido a la necesidad del mercado y aumento de usuarios sobre su canal, agregaron mas funcionalidades sobre su canal, trayendo esto como consecuencia que el software de este creciera con un alto acoplamiento, al punto que les fue totalmente difícil lograr mantener activo su canal y manejar seis millones de visitas por minuto durante los eventos pico, generando perdidas millonarias. Es en este punto donde la mencionada empresa tuvo la necesidad de migrar el software monolito de su canal a una arquitectura que garantice disponibilidad cercana al 100%, la cual fue la arquitectura de microservicios. Similar a Walmart, el problema con el que se encuentra el cliente de Accenture y que además es objeto de estudio en este informe es: contar con el software de un canal digital web del lado del servidor lo suficientemente grande, acoplado y basado en arquitectura monolítica hasta el punto de que es totalmente difícil mantenerlo, corregirle errores, disponerlo activo en horarios de mayor demanda del canal, causando de esta forma perdida de

reputación del canal, dinero, de velocidad de desarrollo de nuevas funcionalidades por parte del equipo de implementación de software del canal lo que dificulta la reacción a las necesidades del mercado, trayendo como consecuencia dar ventajas comerciales sobre competidores. De acuerdo con lo anterior, se resalta que el alcance de la solución al problema mencionado anteriormente, y que se ilustra en este informe, es el desarrollo de un software web back-end de un canal digital web con la funcionalidad de adquirir servicios de telecomunicaciones, basado en arquitectura de microservicios, con la finalidad de entregarle al cliente de Accenture un canal digital en cuanto a software: no monolítico, escalable horizontalmente, de bajo acoplamiento, implementación y realización de cambios en el software de forma rápida y sencilla, estables, con el propósito de suplir las necesidades del cliente tanto a nivel de negocio como técnico. Cabe mencionar que durante la solución al problema se tuvo la limitante de no poder probar las diferentes funcionalidades desarrolladas con datos reales por motivos de confidencialidad de datos por parte del cliente. La implementación del software mencionado anteriormente se realizo bajo la metodología SCRUM. Esta proporciona técnicas y herramientas para el continuo avance en cuanto a software se refiere, además exigió la implementación del proyecto en cuestión, dividido en entregas de funcionalidades en intervalos de tiempo de dos semanas llamados sprints, donde al finalizar cada sprint se le mostró al cliente dueño del desarrollo los avances de este. Finalmente, de acuerdo con todo lo anterior no cabe duda de que la industria del software exige que las empresas de desarrollo se vuelvan más agiles, más flexibles y aumenten la velocidad de sus esfuerzos de desarrollo, es por esto por lo que adoptar la arquitectura de microservicios para la implementación de software significa suplir las necesidades que la industria exige, de hecho muchas compañías actualmente están recurriendo a los microservicios como una opción de diseño arquitectónico que reemplace sus monolitos de software, ya que estos no pueden cumplir con el ritmo acelerado y la naturaleza competitiva de la industria Objetivos Objetivo general Desarrollar microservicios para un sistema de gestión de servicios de telecomunicaciones haciendo uso contenedores Docker sobre un servidor de AWS.

Objetivos Especifico • Diseñar los microservicios para la gestión de clientes, gestión de servicios

y adquisición de servicios. • Implementar cada uno de los microservicios mencionados en el ítem

anterior con el lenguaje de programación Java y el Framework Spring Boot.

• Construir los modelos de las bases de datos NoSQL para cada uno de los microservicios a implementar.

• Desplegar cada microservicio empaquetado por medio de contenedores Docker sobre un servidor de AWS.

• Realizar pruebas de aceptación y de carga al sistema completo de adquisición de servicios de telecomunicaciones para corroborar el correcto funcionamiento del sistema solicitado por el cliente.

Marco Teórico En la etapa inicial de la implementación del software de un canal digital las empresas disponen de un pequeño equipo de desarrollo para implementarlo, ya que al inicio se requiere implementar una simple aplicación que no requiere mucha lógica empresarial, escalabilidad superior y flexibilidad, además exigen lanzar el canal lo antes posible al publico para que generen ingresos. De acuerdo con esto, en la mayoría de los casos los equipos de desarrollo optan por usar la arquitectura monolítica para la implementación del software del canal. El estilo arquitectónico monolítico es una arquitectura tradicional y ha sido ampliamente usado en la industria del software, a menudo se compone de tres capas, tal y como lo muestra la figura 1:

1) Interfaz de usuario: Este maneja toda la interacción del usuario

2) Aplicación del lado del servidor (Lógica de negocio) Maneja las solicitudes HTTP, ejecuta la lógica de dominio, recupera y actualiza los datos de la base de datos y actualiza la interfaz de usuario.

3) Base de datos Alberga la funcionalidad completa para acceder a la base de datos con el propósito de consultar y persistir objetos. Lo utilizan los módulos empresariales y nunca directamente los componentes orientados al Usuario.

Figura 1. Capas de un canal digital monolítico

Recuperado de: https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/

La arquitectura monolítica implica tener una única unidad lógica desplegable con su respectiva base de datos, la cual se ejecuta en un solo proceso al momento de atender solicitudes. Donde de acuerdo con [1] los ciclos de cambio sobre la unidad están unidos: un cambio realizado en una pequeña parte de la aplicación requiere que todo el monolito sea reconstruido y desplegado. Con el tiempo, a menudo es difícil mantener una buena estructura modular, por lo que es más difícil mantener los cambios que solo deberían afectar a un módulo dentro de ese módulo. El escalado requiere el escalado de toda la aplicación en lugar de partes que requieren un mayor recurso, esto se resume visualizando la figura 2.

Figura 2. Monolito

Recuperado de: https://martinfowler.com/articles/microservices.html

La mayoría de los sistemas de clase empresarial actuales tienen una arquitectura monolítica. Su ventaja indiscutible es, por supuesto, el hecho de que trabajan y generan ingresos o ahorros para las empresas que los poseen. Sin embargo, a medida que los sistemas crecen, una arquitectura monolítica hace que el ritmo de su desarrollo disminuya gradualmente. Los dueños de negocios deben esperar más por las funcionalidades que han ordenado. Para empeorar las cosas, la escalabilidad del proceso de desarrollo de software está lejos de ser lineal. Involucrar a más personas o equipos para trabajar en dichos sistemas genera cada vez menos beneficios. Presentar nuevos empleados lleva más y más tiempo, mientras que los existentes se desaniman y exigen un pago adicional por condiciones de trabajo perjudiciales o comienzan a reflexionar sobre una carrera profesional fuera de la organización [2]. Tales síntomas indican claramente que la arquitectura de software monolítico ha dejado de cumplir con los requerimientos que las empresas exigen, es por esto por lo que se hace totalmente necesario aplicar una arquitectura que atienda el problema de un ritmo insuficiente de desarrollo. De acuerdo con lo anterior se deduce claramente que la industria del software esta exigiendo actualmente que las empresas de desarrollo se vuelvan mas agiles, mas flexibles y aumenten la velocidad de sus esfuerzos de desarrollo. Según [3] para satisfacer estas demandas muchas compañías están recurriendo a los microservicios como una opción de diseño arquitectónico, Ya que los monolitos de software ya no pueden cumplir con el ritmo acelerado y la naturaleza competitiva de la industria. Los microservicios son tanto un estilo de arquitectura como un modo de programar software [4], un enfoque para el desarrollo de software en el que una gran aplicación se construye como un conjunto de pequeños servicios modulares altamente mantenibles y comprobables, cada uno ejecutándose en su propio proceso, [5]; Servicios pequeños, versionados de forma independiente y escalables centrados en el cliente con objetivos comerciales específicos, que se comunican entre sí a través de protocolos estándar con interfaces bien definidas. Como son implementables y escalables de forma independiente, cada servicio puede ser escrito en diferentes lenguajes de programación y administrados por diferentes equipos de desarrollo de software, además de acuerdo con [6] pueden ser actualizados o escalados sin que esto afecte a la disponibilidad de las demás unidades y de la aplicación en su conjunto. Ya que cada microservicio es autónomo y no comparten una capa de datos entre ellos, esto indica que cada microservicio administra su propia base de datos, que de hecho para el desarrollo del sistema a desarrollar el cual se presenta en este informe será la base de datos Amazon DynamoDB, la cual es una base de datos NoSQL de claves-valor y documentos [7].

De acuerdo con el anterior párrafo se evidencia que la arquitectura de microservicios es una manera de separar grandes proyectos de software en módulos más pequeños, independientes y poco acoplados, donde dichos módulos individuales son responsables de tareas altamente explicitas y discretas y se comunican entre si a través de API simples y accesibles universalmente. De manera grafica la arquitectura de microservicios se resume en la figura 3.

Figura 3. Microservicios

Recuperado de: https://martinfowler.com/articles/microservices.html

En resumen, con respecto a la arquitectura basada en microservicios, se percibe que es la indicada a elegir cuando se trata de desarrollar un software del lado del servidor lo suficientemente grande y acoplado, difícil de mantenerlo, corregirle errores disponerlo activo en horarios de mayor demanda para él, en un conjunto de piezas mas pequeñas que trabajan juntas. En pocas palabras, cada pieza se desarrolla por separado, y el software completo será simplemente la suma de las piezas. Esto arrojara como resultado un software no monolítico, escalable horizontalmente, de bajo acoplamiento, implementación y realización de cambios en el software de forma rápida y sencilla, estables etc. Lo expuesto hasta aquí en cuanto a la arquitectura monolítica y de microservicios, se puede a simple vista observar sus diferencias, por medio de la figura 4.

Figura 4. Microservicios

Recuperado de: https://dev.to/alex_barashkov/microservices-vs-monolith-architecture-4l1m

En pocos pasos, de acuerdo con [8] el proceso de iniciar un desarrollo web back-end consiste en empaquetar el desarrollo, adicionar las dependencias de las bases de datos a usar, elegir qué tipo de servidores web usar y descargarlo, configurar dicho servidor, por último, organizar el proceso de desplegar el desarrollo en el servidor, además de iniciarlo. Para los casos de configurar el servidor y desplegar el desarrollo, además de adicionar las dependencias de las bases de datos, es necesario, codificar configuraciones en archivos XML repetitivos. Con el fin de simplificar estos pasos, y así reducir el tiempo de desarrollo, facilitar el desarrollo, aumentar la productividad, evitar escribir muchos códigos repetitivos, anotaciones y configuraciones XML, se es necesario el uso de una herramienta que proporcione estas facilidades de desarrollo, y que además este dirigida al desarrollo de software basado en arquitectura de microservicios. De acuerdo con [9] la herramienta ideal para lograr esto es el Framework Spring Boot, el cual es el que se utilizo en la implementación del software que aquí se presenta. Spring Boot es un Framework de "The Spring Team" para facilitar el arranque y el desarrollo de las nuevas aplicaciones Spring. Proporciona valores predeterminados para la configuración de códigos y anotaciones para iniciar rápidamente los nuevos proyectos Spring en poco tiempo, además es uno de los mejores Framework de microservicios de Java [10]. En pocas palabras Spring Boot es de acuerdo con la figura 5:

Figura 5. Spring Boot

Recuperado de: https://www.journaldev.com/7969/spring-boot-tutorial

De la imagen se evidencia, que Spring Boot cuenta con Spring Framework, el cual básicamente, es un Framework para la inyección de dependencias que permite construir sistemas muy desacoplados, además cuenta con la arquitectura MVC (modelo vista controlador). Por otra parte, también por medio de la imagen, se puede notar que Spring Boot proporciona servidores http incrustados como Tomcat, Jetty, que por motivos de performance se excluyen y se agrega Undertow. Los cuales por medio de él son configurados e iniciados automáticamente, además de facilitar el despliegue del desarrollo en cualquier servidor con el que cuente. En cuanto a la configuración de las bases de datos a usar, se agrega las dependencias de estas al proyecto, y el Framework inteligentemente asume que se desea usar una base de datos, luego el hace las configuraciones pertinentes de manera automática para el acceso a dichas bases de datos. En cuanto a Spring Boot se refiere, con este únicamente se tendrá que empaquetar el desarrollo y luego ejecutarlo sobre el Framework, ya que este se encarga de las demás configuraciones. De esta manera Spring Boot proporciona mas tiempo para desarrollar y satisfacer las necesidades del cliente. Cabe resaltar que lo que se presenta en este informe es la implementación de un sistema web back-end encargado de administrar la gestión de servicios de telecomunicaciones, con alto acoplamiento y basado bajo una arquitectura monolítica, en un conjunto de pequeñas funcionalidades que trabajan juntas, es decir, la suma de las funcionalidades sustenta el software completo del canal. Siendo mas preciso, dicha implementación se hará basado en arquitectura de microservicios. Las mencionadas funcionalidades son: gestión de clientes, gestión de servicios y adquisición de servicios, donde cada funcionalidad a nivel de software representa un microservicio. Con esto en mente, una vez se haya terminado de desarrollar cada uno de los microservicios que conforman el sistema a implementar, y teniendo en consideración que estos corren en su propio proceso sobre un servidor se hace explícitamente necesario que este sea portable y fácil de desplegar sobre un servidor, esto con el fin de cumplir con uno de los objetivos de este trabajo. Para suplir esta necesidad, la tecnología indicada a usar es Docker. Docker es una plataforma de código abierto diseñada para facilitar la creación, implementación y ejecución de aplicaciones mediante el uso de contenedores. Los contenedores le permiten al desarrollador empaquetar una aplicación con todas las partes que necesita, como bibliotecas y otras dependencias, y distribuirla como un solo paquete. Al hacerlo, gracias al contenedor, el desarrollador puede estar seguro de que la aplicación se ejecutará en cualquier otra máquina Linux, independientemente de las configuraciones personalizadas que la máquina pueda y que puedan diferir de la máquina utilizada para escribir y probar el código desarrollado [11].

Siendo mas precisos Docker se utiliza para construir, enviar y ejecutar servicios distribuidos. Otra razón por la cual se seleccionó Docker como herramienta de contenerización, es que se presta a la integración continua / implementación continua (CI/CD). Esta es una metodología de DevOps, diseñada para alentar a los desarrolladores a integrar su código en un repositorio compartido de manera temprana y frecuente, y luego implementar el código de manera rápida y eficiente. que además es uno de los lineamientos a cumplir en la implementación del sistema mencionado anteriormente. Por otra parte, DevOps también se refiere a la unión de personas, procesos y tecnologías para permitir la entrega continua de valor a los clientes. El término DevOps, compuesto por dev (desarrollo) y ops (operaciones), da nombre a una práctica de desarrollo de software que unifica el desarrollo y las operaciones de TI. Significa coordinación y colaboración entre disciplinas que antes estaban aisladas [12]. Ahora, al tener en contenedores cada uno de los microservicios, se requiere que cada uno de estos se ejecuten y se comuniquen entre si con el fin de conformar todo el sistema por completo. Para lograr esto se usa Kubernetes, que es una plataforma de orquestación de contenedores de código abierto, que permiten que gran cantidad de contenedores trabajen juntos en armonía, además de también permitir escalado hacia arriba o hacia abajo agregando o eliminando contenedores cuando la demanda cambia, lanzamiento de nuevos contenedores en diferentes máquinas si algo falla [13]. También automatiza el escalado y las operaciones de contenedores de aplicaciones en clústeres de hosts, proporcionando una infraestructura centrada en contenedores. Fue diseñado originalmente por Google. Tiene muchas características que son especialmente útiles para las aplicaciones que se ejecutan en producción, como la denominación y el descubrimiento de servicios, el equilibrio de carga, la comprobación del estado de las aplicaciones, el escalado automático horizontal y las actualizaciones continuas [14]. A continuación, se definen otros conceptos importantes sobre contenedores, los cuales además se mencionarán en la siguiente sección. Pod - esta es la unidad básica en Kubernetes. Puede constar de uno o más contenedores que se garantiza que se ubican en la máquina host y comparten los mismos recursos. Todos los contenedores desplegados dentro del pod pueden ver otros contenedores a través de localhost. Cada pod tiene una dirección IP única dentro del clúster [14] Controlador de replicación: este es un tipo específico de controlador de Kubernetes. Maneja la replicación y el escalado ejecutando un número específico de copias de un pod en todo el clúster. También es responsable del reemplazo del pod si falla el nodo subyacente [14].

A modo de ejemplo en la figura 6 se ilustra una arquitectura basada en microservicios, kubernetes y contenedores. De acuerdo con [14] Cada módulo de microservicios consta de dos contenedores: primero con la aplicación de microservicios y segundo con la base de datos Mongo. Los microservicios de cuenta y cliente tienen su propia base de datos donde se almacenan todos los datos. Cada pod se expone como un servicio y se puede buscar por nombre en Kubernetes.

Figura 6. figura de componentes de arquitectura basada en microservicios, kubernetes y

contenedores Recuperado de: https://dzone.com/articles/microservices-with-kubernetes-and-docker

Por ultimo y con el fin de probar el funcionamiento de cada uno de los microservicios a desarrollar, se le hace a cada uno de estos, peticiones REST con Postman. Por otra parte, para realizar pruebas de carga y así analizar y medir el desempeño de cada uno de los microservicios, con el propósito de observar los beneficios de usar arquitectura de microservicios contra la monolítica se usará la JMeter, según [15] es una herramienta de carga para llevar acabo simulaciones sobre cualquier recurso de Software. Además, posee la capacidad de realizar desde una solicitud sencilla hasta secuencias de requisiciones que permiten diagnosticar el comportamiento de una aplicación en condiciones de producción. En este sentido, simula todas las funcionalidades de un Navegador ("Browser"), o de cualquier otro cliente, siendo capaz de manipular resultados en determinada requisición y reutilizarlos para ser empleados en una nueva secuencia.

Metodología Para la realización del proyecto este se hizo siguiendo el marco ágil SCRUM, el cual exige realizar previamente la planeación de ejecución de tareas en periodos de tiempo de dos semanas llamados sprints que conlleven todas juntas a la implementación del proyecto que se presenta en este informe. Dicha planeación se presenta en la tabla 1.

MAYO JUNIO JULIO AGOSTO Semanas 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Estudio de Java Estudio de Spring Boot Desarrollo del microservicio para la gestión de clientes junto con su base de datos

Desarrollo del microservicio para la gestión de servicios junto con su base de datos

Desarrollo del microservicio para la adquisición de servicios junto con su base de datos

Empaquetar y desplegar cada microservicio sobre un servidor de AWS

Formar y probar el funcionamiento del sistema final comunicando entre si los microservicios,

Entrega del producto final al cliente, con su respectivo informe y documentación

Tabla1. Cronograma de Actividades

De acuerdo con la tabla en lo que sigue en esta sección, se mostrará en cada sprint los pasos a realizar con el fin de cumplir con la tarea planeada en este.

Sprint 1: Estudio de Java (Semana 1,2 Mayo) Ya que el sistema que se expone en este informe se implemento con el lenguaje de programación Java, durante esta etapa se estudiaron los conceptos principales de programación orientada a objetos (OOP) y como se aplican en Java, y su uso en la arquitectura de microservicios. Dichos conceptos estudiados son:

• ¿Qué es un objeto? Un objeto es una colección de datos (atributos) que tiene comportamientos (operaciones) asociados.

• ¿Qué es orientado a objetos? Significa dirigido por el modelado de objetos. Esta es una de las muchas técnicas utilizadas para modelar sistemas complejos, en la cual se describe una colección de objetos que interactúan a través de sus datos y comportamientos.

• ¿Qué es la OOP? Programación orientada a objetos (OOP) es el proceso de convertir el diseño o modelado orientado a objetos en un programa de software.

• Caracteristicas principales de la OOP o La OOP organiza los programas de manera que representa la

interaccion de las cosas en el mundi real. o En la OOP un programa consta de un conjunto de objetos. o En la OOP los objetos son abstracciones de cosas del mundo real. o En la OOP nos interesa qué se puede hacer con los objetos más

que cómo se hace. o En la OOP cada objeto es responsable de unas tareas. o En la OOP cada objeto es un ejemplar de una clase. o En la OOP los objetos interactúan entre sí por medio de mensajes. o En la OOP las clases se pueden organizar en una jerarquía de

herencia. o La programación orientada a objetos es una simulación de un

modelo del universo. o

• Constructores Los constructores son un tipo especial de método. Tienen tres particularidades:

o Un constructor debe tener el mismo nombre que la propia clase. o Los constructores no tienen un tipo de retorno, ni siquiera void. o Los constructores se invocan utilizando la palabra new cuando se

crea un objeto.

• Sobrecarga de métodos la sobrecarga de métodos se refiere a la posibilidad de tener dos o más métodos con el mismo nombre, pero distinta funcionalidad. Es decir, dos o más métodos con el mismo nombre realizan acciones diferentes y el compilador usará una u otra dependiendo de los parámetros usados.

• Herencia

La herencia es una de las características mas importantes y mas poderosas de la POO. Permite gran nivel de reutilización de código. Se utiliza cuando se encuentra gran similitud, ya sea de atributos y/o métodos entre varias clases.

o Superclase Clase padre o clase base. Una superclase no necesita a las subclases para existir y cualquier modificación en cualquiera de las subclases no afecta el comportamiento ni los elementos de la superclase.

o Subclase: también llamada clase hijo, derivada o extendida. Una subclase hereda todos los atributos y métodos de la clase padre. Sin embargo, dependiendo de la manera en que se definan estos métodos o atributos y del lenguaje de programación, la subclase puede tener o no acceso a ciertos elementos heredados. La subclase, también podrá agregar o redefinir elementos heredados. Una subclase requiere que exista la superclase.

• Pilares de la OOP Encapsulamiento, herencia y polimorfismo.

• Interfaz Una interfaz es un tipo de referencia en Java. Es similar a la clase. Es una colección de métodos abstractos. Una clase implementa una interfaz, heredando así los métodos abstractos de la interfaz [16].

• Métodos y clases abstractas Los métodos abstractos, similares a los métodos dentro de una interfaz, se declaran sin ninguna implementación. Se declaran con el propósito de que la subclase proporcione implementación. Una clase declarada abstracta puede o no incluir métodos abstractos. Se crean con el propósito de ser una superclase

Sprint 2: Estudio de Spring Boot (Semana 3,4 Mayo) Como herramienta elegida para la implementación del sistema en cuestión que ayudará agilizar el proceso de desarrollarlo se había elegido Spring Boot, fue estrictamente estudiar los conceptos principales y necesarios de este que llevarán al desarrollo del sistema, dichos conceptos son:

• Inversión de control: Este es uno de los principios de la programación orientada a objetos, en el que los objetos del programa no dependen de implementaciones concretas de otros objetos, pero pueden tener conocimiento sobre sus abstracciones (interfaces) para una interacción posterior.

• Inyección de dependencia: Es una composición de patrones de diseño estructural, en el que para cada función de la aplicación hay uno, un objeto (servicio) condicionalmente independiente que puede tener la necesidad de usar otros objetos (dependencias) conocidos por las interfaces. Las dependencias se transfieren (implementan) al servicio en el momento de su creación. Esta es una situación en la que se introduce un elemento de una clase en otra. En la práctica, DI se implementa pasando parámetros al constructor o usando setters.

• Anotaciones de Spring o Spring @Bean

Se aplica en un método para especificar que devuelve un bean para que sea administrado por el contexto Spring. Esta declaración generalmente se declara en los métodos de las clases de configuración.

o Spring @Service Solo se aplica a las clases, y se usa para marcar que estas de forma individual son un proveedor de servicio.

o Spring @Component

Es usada para denotar una clase como componente. Esta conlleva a que el Spring Framework detectará automáticamente estas clases para la inyección de dependencia cuando se use la configuración basada en anotaciones y el escaneo de classpath.

o Spring @RestController Se aplica sobre las clases para marcarla como un controlador de solicitud.

o Spring @Repository

Se usa con el propósito de indicarle a la clase que proporcione le mecanismo para la operación de almacenamiento, recuperación, búsqueda, actualización y eliminación de objetos.

• Patrón de diseño Modelo–Vista–Controlador (MVC) Comúnmente implementado sobre el Spring Boot Framework, con el propósito dar una solución al como conectar al cliente con el servidor, para este caso específico con el canal en mención, de manera rápida, organizada y sencilla. A grandes rasgos, la capa llamada vista se refiere al cliente el cual se comunica con la capa de negocio que sería el servidor, por medio de modelos. Con el fin de dar a conocer como sería en un alto nivel de análisis, la comunicación del cliente del canal con este usando el patrón de diseño en mención ver la figura 7.

Figura 7. Patrón de diseño MVC

Sprint 3, Sprint 4, Sprint 5: Desarrollo de microservicios de gestión de clientes, gestión de servicios, adquisición de servicios (semana 1,2,3,4 Junio), (semana 1,2 Julio) La metodología seguida para implementar los microservicios de gestión de clientes, gestión de servicios y adquisición de servicios se muestran de manera conjunta ya que para los tres el procedimiento es igual. Por otra parte, es de aclarar que en cuanto a lo que sigue, se muestra únicamente la metodología o los pasos requeridos para la implementación del microservicio gestión de servicios, ya que para los restantes los pasos son los mismos, por lo que lo único que difieren entre estos es su respectivo dominio de interés. Esto se hace con el animo de no entrar en redundancia en este documento. Luego de definir la arquitectura de los microservicios, hecho que se realizo durante el sprint 1 y 2, en lo que sigue se detalla el paso a paso de la implementación del microservicio en mención.

Antes de comenzar a diseñar los microservicios es necesario que se tengan identificadas las operaciones de la mensajería Json API, es decir, los request de cada microservicio y el request de error en caso de suceder.

• Request: Gestión de servicios { "data":[ { "type":"canal", "id":"numero documento del cliente", "attributes":{ "clientDocumentType": "tipo de document del cliente" } }, { "type":"gestion de servicios", "id":"identificador del producto", "attributes":{

"name": "nombre producto", "description": "descripción del producto"

} } ] }

• Request error:

{ "errors":[ { "code":"codigo", "detail":"detalle", "id":"id", "source":"fuenta", "status":"estado", "title":"titulo" } ] }

Con el fin de agilizar la configuración de cada microservicio, y de esta forma empezar a desarrollar lo mas pronto posible, cada microservicio tuvo como punto de partida un proyecto Spring Boot básico el cual proporciona Spring Initializr, esta herramienta ofrece una interfaz grafica fácil de usar para generar un proyecto Spring Boot básico, precisamente se recurrió a dicha interfaz la cual se observa en la figura 8, con el fin de generar dicho proyecto, donde los valores de configuración para nuestro caso son: tipo de proyecto Gradle, lenguaje de programación Java, versión de Spring Boot 2.1.8, datos del

proyecto co.edu.ude.nombre del servicio y unas dependencias iniciales como lombok y Spring Web.

Figura 8. Interfaz SpringInitializr

Una vez generado el proyecto inicial, en este caso el proyecto Gradle, se procede a importarlo en intelliJIDEA o cualquier otro IDE, que de hecho luce como lo muestra la figura 9.

Figura 9. Proyecto inicial con Spring Initializr

De aquí en adelante se configura el proyecto generado con el fin de adecuarlo a la necesidad del proyecto de interés, y además se organiza a

nivel de paquetes y clases de tal forma que cumpla con la arquitectura mostrada en la figura 28. La implementación del microservicio gestión de cliente se realizó bajo el modelo arquitectónico ilustrado en la figura 29 y esta consistió en los siguientes pasos:

1. Configuración de la base de datos DynamoDB Inicialmente primero se descarga la dependencia “compile group: 'com.github.derjust', name: 'spring-data-dynamodb', version: '5.1.0'”, por medio del archivo build.gradle del proyecto, referente a DynamoDB. Luego se establece la configuración de DynamoDB, esta se compone de una pieza de configuración fundamental con el fin de que la integración funcione:

o Credenciales de configuración de AWS Para esto solo se crea un Bean que retorna un objeto

BasicAWSCredentials, el cual acepta clave de acceso y la clave secreta como parámetro de construcción. Esta pieza de configuración se puede visualizar completamente por medio de la figura 10.

Figura 10. Configuración base de datos Dynamo

2. Implementación de la capa modelo Una vez se cuente con la configuración de la base de datos, se define la capa de modelo, la cual es mostrada en la figura 11. Esta capa establece los atributos, en este caso de los productos.

Figura 11. Implementación capa modelo

3. Implementación de la capa repositorio

Esta capa llamada para nuestro caso persistencia, es de gran importancia, ya que por medio de esta se definen las acciones a ejecutar sobre la base de datos. Esta implementación es sencilla y se visualiza por medio de la figura 12

Figura 12. Implementación capa repositorio

4. Implementación capa servicio Esta etapa es la intermediaria entre el controlador y los datos, y se usa con el fin de tomar valores de la base de datos serializarlos en objetos, y pasárselos al controlador, para que este haga las acciones solicitadas por el usuario. Esta implementación se ilustra en la figura 13.

Figura 13. Implementación capa servicio

5. Implementación capa controlador

Por último, se implementa la capa de controlador, por medio del cual se identifica a que método acceder de acuerdo con la acción del cliente sobre la interfaz de usuario, de igual forma actualiza los datos de los modelos. Esta implementación se visualiza por medio de la figura 14.

Figura 14. Implementación capa controlador

6. Conexión a la base de datos Dynamo Hasta este punto se tiene la implementación del microservicio en mención, pero sin la conexión a la base de datos de interés, precisamente esta conexión se ilustra a continuación, haciendo la aclaración que el paso inicial es realizar la conexión de manera local, con el fin de asegurarse de que funciona la integración de la base de datos con el microservicio, una vez teniendo en certeza esto, se tendrá un pequeño margen de error al conectar el microservicio con una base de datos remota. Para lograr este paso primero se configuran los puertos del microservicio y de la base de datos, sobre el proyecto, esto se muestra en la figura 15.

Figura 15. Configuración de puertos

Pero antes de exponer la base de datos por medio de un puerto, esta debe de ser construida, esto se realizó bajo revisión del cliente, asegurándose de esta manera que la base de datos que se creó localmente correspondiera al mismo modelo de base de datos que él ya tiene en la nube. Para lograr esto inicialmente se descarga la base de datos Dynamo local, se ejecuta el comando “java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb” y posteriormente se escribe sobre el navegador http://localhost:8000/shell/, esto último arroja una interfaz mostrada en la figura 17 por medio de la cual se puede construir el modelo de la base de datos. Los scripts usados para la construcción de la base de datos Dynamo son:

o Crear base de datos var params = { TableName: 'Productos', KeySchema: [ { AttributeName: 'Id', KeyType: 'HASH', } ], AttributeDefinitions: [ { AttributeName: 'Id', AttributeType: ’S’, // (S | N | B) for string, number, binary } ], ProvisionedThroughput: { ReadCapacityUnits: 1, WriteCapacityUnits: 1, } }; dynamodb.createTable(params, function(err, data) { if (err) ppJson(err); // an error occurred else ppJson(data); // successful response });

o Guardar dato var params = {

TableName: 'Productos', Item: { // a map of attribute name to AttributeValue Id: 1, Nombre: "plan telefonia", Descripcion: "plan familiar", Tarifa: 90000, FechaExpiracion: "2016-11-11" }, ReturnValues: 'NONE', // optional (NONE | ALL_OLD) ReturnConsumedCapacity: 'NONE', // optional (NONE | TOTAL | INDEXES) ReturnItemCollectionMetrics: 'NONE', // optional (NONE | SIZE) }; docClient.put(params, function(err, data) { if (err) ppJson(err); // an error occurred else ppJson(data); // successful response });

o Describir tabla var params = {

TableName: 'Productos', }; dynamodb.describeTable(params, function(err, data) { if (err) ppJson(err); // an error occurred else ppJson(data); // successful response });

Se aclara que los valores con los que se puebla la base de datos locales no son datos valores reales del cliente, por motivos por parte de este de confidencialidad de datos. Luego de construida la base de datos, esta se expone por medio de un puerto y se ejecuta el proyecto Spring Boot. Estos pasos se visualizan por medio de la figura 17 y 18 respectivamente.

Figura 16. Interfaz para crear bases de datos

Figura 17. Inicio Base de Datos

Figura 18. Ejecución del microservicio con la conexión a la base de datos

De acuerdo con todo lo mostrado en esta sección hasta aquí se evidencia la implementación del microservicio gestión de servicios con su respectiva base de datos, siguiendo la arquitectura de la figura 21, donde esta a nivel de distribución de paquetes y clases sobre un IDE de desarrollo luce como lo muestra la figura 19

Figura 19. Distribución de paquetes y clase

Bajo esta metodología se implementaron cada uno de los microservicios que componen el sistema de interés, los resultados de esta se observan en la

sección de análisis y resultados coincidentes claro esta con los sprints que se presentan en esta sección. Por otra parte, es de notarse que esta metodología conlleva a la implementación de los microservicios pero en un ambiente local, y de cuerdo con los objetivos de este informe este debe de exponerse sobre un servidor, la metodología que conlleva a esto último se muestra en la siguiente sección. Sprint 6, 7: Empaquetar y desplegar cada microservicio sobre un servidor de AWS (Semana 3,4 Julio) (Semana 1,2 Agosto) En cuanto a lo que concierne el trabajo realizado durante el sprint 6, es exponer cada uno de los microservicios que componen el sistema de interés en un ambiente productivo, es decir, sobre un servidor, en este caso de AWS, con el fin de que el cliente pueda conectar este sistema al software restante del canal, además de comprobar su correcto funcionamiento bajo sus exigencias. Con esto en mente a continuación se muestra la metodología o los pasos a seguir llevada a cabo que conlleva a desplegar el sistema implementado sobre un servidor. Como aclaración dichos pasos son generales, es decir, son los mismos para el despliegue de cada microservicio. Por otra parte, se presenta como se prueba el sistema después de desplegarlo, esto fue lo realizado durante el sprint 7.

1. Construcción de la imagen docker El propósito principal en este ítem es construir una imagen donde se despliega el jar generado por cada microservicio desarrollado. Esto se realizó adicionando sobre el proyecto de la implementación de cada microservicio el archivo de configuración mostrada en la figura 20.

Figura 20. Archivo de configuración para construir imagen Docker

A parte de esto, se hacen las siguientes configuraciones sobre el archivo build.gradle de cada proyecto:

o Agregar las dependencias y el plugin de docker para gradle dependencies {

classpath('org.springframework.boot:spring-boot-gradle-plugin:2.0.5.RELEASE') classpath('se.transmode.gradle:gradle-docker:1.2') }

apply plugin: 'docker'

o Adicionar tarea de bootJar la cual es la responsable de generar

el jar ejecutable de la aplicación con todas sus dependencias. bootJar {

baseName = 'service-manage-api-controller' version = '1.0.0' }

2. Configuraciones de recurso y cambio de base de datos Como es de esperarse, se necesita cambiar la conexión de la base de datos de local al de la nube del cliente, esto se hace por medio de la siguiente configuración mostrada en la figura 21:

Figura 21. Configuración para conectar base de datos

Como se puede ver por medio de la figura 21 se muestra el contextPath por donde se expone el servicio una vez este desplegado sobre el servidor, además del nombre de la base de datos que el cliente tiene sobre AWS, con respecto a conexiones de la base de datos y el microservicio respectivo una vez este se encuentre desplegado, se encargó el equipo de nube del cliente en realizarla, por motivos de seguridad por parte de este. Por otra parte, se configuraron los recursos de memoria y procesamiento que tendrá cada microservicio una vez este sobre un pod de la nube, en pocas palabras sobre el servidor, estas líneas de configuración se ilustran por medio de la figura 22.

Figura 22. Configuración de recursos

3. Despliegue de cada microservicio

En este ítem se muestra la metodología realizada para el despliegue de un microservicio a un ambiente productivo. Esta metodología consiste en pasar por unos elementos llamados pipelines de devOps, los cuales cuentan con una serie de tareas, las cuales deben de ser todas

realizadas, entre estas está el despliegue mencionado anteriormente. Con esto en mente se muestra en lo que sigue dicha metodología.

o Ejecución pipeline CI Se ejecuta una vez se haga un pull request de lo desarrollado en ambiente local a desarrollo, en este punto se evalúa por parte del pipeline lo mostrado por medio de la figura 23

Figura 23. Pipeline CI

Aquí se evaluó principalmente que el microservicio desarrollado tuviera una cobertura superior al 75% de pruebas unitarias, además de que no tuviera código que generará vulnerabilidades de seguridad.

o Ejecución pipeline CD Se ejecuta manualmente, y se realizan las tareas mostradas en la figura 24.

Figura 24. Pipeline CD

Este pipeline copia el archivo de configuración dependiendo del ambiente sobre el que se este ejecutando, los cuales son de desarrollo, certificación y producción, de hecho, inicialmente es el de desarrollo, con el propósito de realizar lo que ahí se indique, que particularmente es descargar la imagen donde a su vez cuenta con el jar compilado del respectivo microservicio, para luego copiarlo y generar la imagen docker.

o Ejecución pipeline RM

Cabe resaltar que este pipeline se ejecuta con diferentes tareas dependiendo del ambiente en el que se encuentre. Inicialmente se despliega lo desarrollado en ambiente de desarrollo, para esto se corre el pipeline CI, CD y RM, luego se hace un pull request de desarrollo a certificación, aquí se ejecuta el pipeline CD y RM, pero en certificación, y por último se hace un pull request de certificación a producción y de igual forma se ejecuta el CD y RM. Es de esta manera como se llevó a cabo el despliegue de los microservicios. A continuación, se muestra las tareas relacionadas del pipeline RM en ambiente de desarrollo, certificación y producción por medio de las figuras 25, 26, 27 respectivamente.

Figura 25. Pipeline RM desarrollo

Figura 26. Pipeline RM certificación

Figura 27. Pipeline RM producción

Para el caso del pipeline RM de desarrollo este realiza el despliegue del microservicio respectivo de la imagen docker generada por medio del pipeline CD, también valida que las pruebas de performance y de aceptación del microservicio cumplan con las exigencias del cliente. De igual forma esto también lo hace el pipeline CD de certificación, adicionando las tareas de E2E, las cuales consisten en hacer pruebas por parte del equipo de certificación del cliente, con el fin de validar que el sistema desarrollado funciona correctamente con el restante software del canal. Por otra parte, el pipeline RM de certificación cuenta igualmente con la tarea de despliegue, pero diferenciándose de los demás con una tarea de validación, esta tarea es la que tiene la autorización del cliente para desplegar lo desarrollado a producción. Como se puede ver antes de que el cliente valide que se pueda pasar lo desarrollado a producción se debe de pasar por un conjunto de validaciones rigurosas que pone el cliente. De manera aclaratoria, cada una de las pruebas de performance y de aceptación que valida los pipelines RM de desarrollo y certificación fueron realizadas por parte del equipo de desarrollo del cliente, ya que este quiso asegurarse que cada microservicio cumpliera con las pruebas de su elección. Para terminar, es de notar que es por medio del cumplimiento de la metodología de devOps que se despliega el sistema que se presenta en este informe en un ambiente productivo que se encuentra en un servidor de AWS. Para probar el funcionamiento del sistema final, se usa la herramienta postman, teniendo en consideración que en esta oportunidad se hace dicha prueba, pero apuntando a un end- point correspondiente al ambiente productivo mencionado anteriormente. De igual forma por medio del mismo end-point se realizan pruebas de carga o de rendimiento sobre el sistema por

medio de JMeter con el fin de mostrarle al cliente lo favorable que fue para él, decidir tener un sistema basado en microservicios. Dichas pruebas se muestran en la sección de resultados y análisis del sprint 6 y 7.

Sprint 8: Entrega del producto final al cliente, con su respectivo informe y documentación (Semana 3,4 Agosto) Luego de conectar el sistema de interés con el software del canal del cliente, este sprint consistió en monitorear, y comprobar el correcto funcionamiento de la mencionada conexión, una vez realizado esto el cliente comprobó que lo solicitado por él se cumpliera, validando de esta manera el recibimiento de lo implementado. Aparte de lo anterior se le explico la arquitectura del sistema implementado al equipo de desarrollo del canal del cliente por medio de la figura 37 mostrada en la sección de resultado y análisis. Resultados y análisis En esta sección se expone la respectiva descripción y análisis de los resultados obtenidos al finalizar cada una de las actividades mostradas anteriormente en la tabla. Sprint 1, Sprint 2: Estudio de Java, Estudio Spring Boot (Semana 1,2,3,4 Mayo) En este caso se muestran los resultados obtenidos del sprint 1 y 2 ya que ambos en conjunto implicaron obtener resultados mas concretos en cuanto a la implementación del software de interés. Al haber comprendido el paradigma OOP en conjunto con el patrón de diseño MVC, permitió modelar el problema a resolver por medio de interacciones entre capas de desarrollo (Modelo, Vista, Controlador), esto conllevo a intuir como sería la respectiva distribución de paquetes sobre la herramienta de desarrollo, en este caso intelliJIDEA, donde a modo de ejemplo esta se puede ver en la figura 28, la cual muestra la distribución de paquetes correspondiente al microservicio de gestión de servicios. De igual forma también conllevo a tener la capacidad de diseñar una arquitectura general de como sería cada microservicio, la cual se puede visualizar en la figura 29 seguido de su respectivo análisis. Por otra parte, después de conocer un poco mas los conceptos principales de Spring Boot, arrojo a tener en consciencia que herramientas propias de este Framework son las indicadas a usar las cuales permitirían resolver los problemas del cliente, por ejemplo, al usar inyección de dependencia e inversión de control durante el desarrollo de cada microservicio, resolvió el problema principal del cliente de tener diferentes funcionalidades de su software acopladas lo cual implicaba no poder hacer ningún cambio sobre alguna de estas sin que se reflejara en errores sobre las restantes, en su lugar por medio

de estas herramientas se dieron al cliente funcionalidades totalmente desacopladas, con la posibilidad de realizarles cambios a una de ellas sin que afectara el funcionamiento de las otras.

Figura 28. Distribución de paquetes de un microservicio

Figura 29. Arquitectura de microservicio

De acuerdo con esta arquitectura, muestra que una vez el cliente del canal realice una acción relacionada a alguna funcionalidad de gestión de servicios, gestión de cliente, adquisición de servicios, sobre el canal, se genera un request el cual pasa primero por un Api Gateway de Aws, donde este sirve como puerta de enlace para poder tener acceso a los datos, lógica de negocio o funcionalidades del software back-end del canal. La decisión de usar Amazon Api Gateway fue una exigencia del cliente ya que este cuenta con unos servicios de interés del cliente como gestionar todas las tareas implicadas en la aceptación y el procesamiento de hasta cientos de miles de llamadas a API simultáneamente, entre ellas, la administración del tráfico, el control de autorizaciones y acceso, el monitoreo y la administración de versiones de API. Después de que el request pase por el Api Gateway, este llega al controlador del microservicio, este por su parte identifica a que método se quiere acceder, como, por ejemplo, listar servicios, comprar servicios, cancelar servicios, actualizar datos de cliente, para luego de acuerdo con la acción que identifique el controlador que el cliente quiere

hacer ingresar a la base de datos en caso de ser necesario, donde esta devuelve información al controlador y este a su vez actualiza los datos del modelo en cuestión. Además, en caso de que los atributos del request sean iguales a los del modelo, la implementación de Spring Boot MVC asignara esos valores automáticamente, permitiendo utilizar esa información para la lógica de negocio y persistencia. Antes de continuar, se aclara que las acciones realizadas por parte del canal que conlleven a hacerle peticiones REST al sistema de interés, se realizan para nuestro caso por medio de postman, es decir, sin ninguna interfaz grafica front-end, ya que, a petición del cliente, él solo requiere el back-end con las respectivas funcionalidades de interés, queriendo decir que la integración de dicho back-end con el front-end del canal correría por parte de él. Sprint 3, Sprint 4, Sprint 5: Desarrollo de microservicios de gestión de clientes, gestión de servicios, adquisición de servicios (semana 1,2,3,4 junio), (semana 1,2 Julio) En este punto de la implementación del sistema de interés, se tiene el desarrollo de cada uno de los microservicios que compone dicho sistema bajo un ambiente local. Teniendo en cuenta que en la metodología para implementar los microservicios se mostró el funcionamiento del microservicio gestión de servicios, a continuación, se muestra el funcionamiento del sistema en conjunto bajo un ambiente local, el cual concretamente le debe permitir a un cliente del canal adquirir un servicio, de esta forma se comprueba el funcionamiento de cada microservicio, al igual que el sistema completo, esto se puede visualizar por medio de la figura 30. Dicha prueba se realizo por medio de postman. Tal y como se ve en la figura 30, se puede observar que el request del sistema se envía vacío y igualmente la respuesta es vacía. Esta prueba se realizó de esta manera por petición del cliente, ya que el comprobará el correcto funcionamiento de este sistema al unirlo a su canal bajo este mismo escenario, pero en un ambiente de producción con el propósito de no exponer datos de su base de datos.

Figura 30. Funcionamiento local del sistema

Por último, como se puede evidenciar hasta aquí que se ha cumplido con los objetivos específicos de diseñar y desarrollar los microservicios para la gestión de clientes, gestión de servicios y adquisición de servicios, utilizando el lenguaje de programación Java y el Framework Spring Boot, al igual que la construcción de las bases de datos de cada microservicio. Sprint 6, 7: Empaquetar y desplegar cada microservicio sobre un servidor de AWS (Semana 3,4 Julio) (Semana 1,2 Agosto) Después de seguir la metodología del sprint 6 mostrada en la sección anterior se obtiene el despliegue de cada microservicio sobre el servidor de interés, esto precisamente arrojo como resultado la creación de un pod sobre kubernetes de aws, esto se puede visualizar por medio de la figura 31, donde se muestra por ejemplo el pod donde esta desplegado el microservicio correspondiente a la gestión de servicios.

Figura 31. Despliegue microservicio de gestión de servicios

Por medio de este resultado se da por cumplido el despliegue de los microservicios empaquetados por medio de contenedores docker sobre un servidor de aws, bajo la metodología de DevOps. Por otro lado, con el fin de probar el funcionamiento del sistema de interés, se realiza la misma prueba que representa la figura 30. Exactamente esta prueba consiste en solicitarle al sistema que le permita a un cliente del canal adquirir un servicio, donde por parte del cliente dicha prueba se realiza por medio de un request vacío y esperando recibir un response vacío, esto con el fin de proteger datos sensibles de usuarios del canal. Esta prueba se visualiza en la figura 32.

Figura 32. Funcionamiento en producción del sistema

Para terminar, se muestra las pruebas de carga realizadas sobre el canal antes de migrar a microservicios, que conciernen adquirir un servicio, y posteriormente se muestra la misma prueba, pero del sistema basado en microservicios, esto con el fin de comparar, y mostrarle al cliente las nuevas ventajas que tiene sobre el software de su canal, correspondiente a adquirir servicios.

• Adquirir un servicio sin microservicios o Recursos

Por medio de la figura 33 se muestra como se realizó la configuración para hacerle peticiones al sistema inicial del cliente a una rata de diez peticiones por segundo, además de mostrar los recursos que este consume resources:

limits: cpu: 2500m memory: 2000Mi requests: cpu: 1000m memory: 800Mi

Figura 33. Configuración de numero de peticiones por segundo al sistema

o Configuración de la prueba:

En la figura 34 las rampas inclinadas simulan un aumento de las peticiones al transcurrir el tiempo hasta llegar a diez peticiones por segundo, y las rampas declinada simulan la disminución de peticiones hasta llegar al punto de no haber. La duración de la prueba es de 15 minutos.

Figura 34. Configuración de peticiones al sistema

o Resultado de la prueba:

Por medio de la figura 35 se muestra el tiempo de respuesta realizadas durante un lapso de 15 minutos al sistema inicial del cliente, también se puede observar que dicho tiempo se mantiene por los 6ms con una gran cantidad de datos con tiempos de respuesta superior a los 6ms.

Figura 35. Configuración de peticiones al sistema

• Adquirir un servicio con microservicios Con el fin de comparar el sistema inicial del cliente con el reciente basado en microservicios, ambos cuentan con las mismas configuraciones del número de peticiones por segundo y de peticiones representadas por medio de la figura 34 y 35, pero entre estos difieren los recursos que consumen y como es de esperarse el tiempo de respuesta, el cual se puede visualizar por medio de la figura 36.

o Recursos: resources:

limits: cpu: 450m memory: 400Mi requests: cpu: 350m memory: 300Mi

o Resultado de la prueba: Para este caso se puede observar de la figura 35 que el tiempo de respuesta a través del tiempo se mantiene en un valor de 500ms.

Figura 36. Configuración de peticiones al sistema

De acuerdo con estos resultados, se evidencia claramente que la funcionalidad del canal correspondiente a adquirir servicios de telecomunicaciones diseñado bajo una arquitectura basada en microservicios en comparación a una basada en una arquitectura monolítica consume en cuanto a recursos sobre el servidor de memoria y de procesamiento menos de la mitad, esto implicó menos gasto de dinero en servicios de nube, y que los tiempos de respuesta a través del tiempo es menor y mas homogéneo. Por otra parte, le permitió al equipo de desarrollo del canal del cliente: contar con el software de la funcionalidad de interés fácil de mantener y corregirle errores en lapsos de tiempo cortos, mayor velocidad en la implementación de nuevas funcionalidades, esto fue consecuencia al momento de desarrollarlas no tener que preocuparse que estas se acoplaran a la de adquirir servicios, es decir, que los nuevos cambios al software del canal

debido a la nueva funcionalidad no implicarán hacerle cambios a la de adquirir servicios, esto es debido a que esta está totalmente desacoplada a las demás funcionalidades del canal por medio de pequeñas tareas que corren en su propio proceso, solo tienen la responsabilidad de hacer una acción, desacopladas entre si y que conllevan a adquirir un servicio las cuales son: gestionar cliente y servicio, adquirir servicio. De esta manera, el cliente quedo con el software de la funcionalidad relacionada a adquirir servicios de telecomunicaciones. De acuerdo con lo anterior, se concluye que se resolvieron las exigencias del cliente, al punto que el cliente inicio la migración de otras funcionalidades altamente acopladas entre si a una arquitectura basada en microservicios. Por medio de los anteriores resultados correspondientes a pruebas de funcionalidad, se evidencia el cumplimiento del objetivo específico de la realización de pruebas de aceptación y de carga a la funcionalidad concreta de adquirir servicios de telecomunicaciones, claro está en cuanto a software. Ahora por medio de toda la sección de resultados se concluye que se cumplió con el objetivo general de desarrollar microservicios para un sistema de gestión de servicios de telecomunicaciones haciendo uso de contenedores docker sobre un servidor de AWS. Sprint 8: Entrega del producto final al cliente, con su respectivo informe y documentación (Semana 3,4 Agosto) Como resultado de este sprint, se realizo la arquitectura del sistema implementado, la cual se muestra en la siguiente figura.

Figura 37. Arquitectura del sistema adquisición de servicios de telecomunicaciones

Conclusiones

• Usar la arquitectura basada en microservicios en conjunto con contenedores mejora las capacidades de la nube. De esta manera cada microservicio es escalable y reutilizable, por otra parte, los contenedores proporcionan recursos eficientes. Un microservicio al igual que un contenedor pueden funcionar de manera independiente, pero como se pudo evidenciar en este informe, al fusionarlos mejora la frecuencia de tiempo de ejecución, las políticas de alojamiento en la nube y las herramientas en la nube, además de ayudar a hacer posible un rápido desarrollo y pruebas.

• La mayoría de las aplicaciones son desarrolladas con arquitectura monolítica, esto es debido a que dichas aplicaciones inician siendo simples y livianas, pero una vez la aplicación empieza a crecer debido a la implementación de nuevas funcionalidades, pasa a ser una aplicación compleja y altamente acoplada, y esto acarrea como consecuencia ralentizar la velocidad de desarrollo al iterar sobre la aplicación con el fin de adicionarle nuevas funcionalidades. En cambio, luego de desacoplar o independizar cada funcionalidad a través de microservicios aumenta drásticamente la productividad del desarrollo además de permitir una mejora sustancial sobre la aplicación de interés. De acuerdo con lo anterior, en pocas palabras, la arquitectura de microservicios es la mejor opción para aplicaciones complejas y en evolución.

• Con respecto a las configuraciones con el fin de desplegar software sobre un servidor, las aplicaciones monolíticas permiten hacer estas configuraciones una vez y luego ajustarla en caso de ser necesario y desplegarla. Pero si hay un punto de falla durante este procedimiento, interrumpe el funcionamiento de la aplicación por completo. En el caso de los microservicios, estos requieren de mas trabajo para implementarlos y realizar las configuraciones en mención de forma independiente, pero si algo sale mal en este caso solo se romperá un pequeño microservicio, lo cual es menos perjudicial que toda la aplicación.

• Al desarrollar basado en microservicios enfocados con la metodología de DevOps aumenta enormemente la frecuencia de entrega de software de manera más eficiente, ya que este automatiza las tareas de despliegue de software. Esto evidentemente proporciona una ventaja competitiva al negocio, ya que permite hacer mas rápido la liberación al publico de nuevas funcionalidades adicionadas a cualquier software.

Referencias Bibliográficas [1] James Lewis; Microservices; 25/03/2014; Online] Disponible en: https://martinfowler.com/articles/microservices.html; [Consultado: 22 de Septiembre de 2019]; [2] Robert Kuśmierek; From Monolih to microservices – to migrate or not to migrate?; 12/09/2018; [Online] Disponible en: https://altkomsoftware.pl/en/blog/monolith-microservices/; [Consultado: 22 de Septiembre de 2019]; [3] Phil Wittmer; Monolithic vs Microservices Architecture – Why Microservices Win; 28/11/2018;[Online] Disponible en: https://www.tiempodev.com/blog/monolithic-vs-microservices-architecture/; [Consultado: 22 de Septiembre de 2019]; [4] ¿Qué son los microservicios?; [Online] Disponible en: https://www.redhat.com/es/topics/microservices; [Consultado: 22 de Septiembre de 2019]; [5] ¿Que son los microservicios? Definición, Características y retos; [Online] Disponible en: https://blog.mdcloud.es/queson-los-microservicios-definicion-caracteristicas-y-retos/; [Consultado: 22 de Septiembre de 2019]; [6] Lucas Carlson; Lightweight software development explained; 29/11/2017; [Online] Disponible en: https://www.infoworld.com/article/3237697/what-are-microservices-lightweight-software-development-explained.html; [Consultado: 22 de Septiembre de 2019]; [7] ¿Qué es NoSQL?; [Online] Disponible en: https://aws.amazon.com/es/nosql/; [Consultado: 22 de Septiembre de 2019]; [8] What is Spring Boot?; [Online] Disponible en: https://dzone.com/articles/what-is-spring-boot; [Consultado: 22 de Septiembre de 2019]; [9] GeeksforGeeks; [Online] Disponible en: https://www.geeksforgeeks.org/microservices-introduction/; [Consultado: 22 de Septiembre de 2019]; [10] Spring Boot Tutorial; [Online] Disponible en: https://www.journaldev.com/7969/spring-boot-tutorial; [Consultado: 22 de Septiembre de 2019]; [11] What is Docker?; [Online] Disponible en: https://opensource.com/resources/what-docker; [Consultado: 22 de Septiembre de 2019];

[12] ¿Qué es DevOps?; [Online] Disponible en: https://azure.microsoft.com/es-es/overview/what-is-devops/; [Consultado: 22 de Septiembre de 2019]; [13] Norman Joyner; Kubernetes? Docker? What is the difference?; 20/08/2018; [Online] Disponible en: https://blog.containership.io/k8svsdocker/; [Consultado: 22 de Septiembre de 2019]; [14] Piotr Mińkowski; Microservices With Kubernetes and Docker; 10/04/2017; [Online] Disponible en: https://dzone.com/articles/microservices-with-kubernetes-and-docker [Consultado: 22 de Septiembre de 2019]; [15] ¿Que es JMeter? ¿Qué hace JMeter?; [Online] Disponible en: https://www.osmosislatina.com/jmeter/basico.htm; [Consultado: 22 de Septiembre de 2019]; [16] Java Interface; [Online] Disponible en: https://www.tutorialspoint.com/java/java_interfaces.htm; [Consultado: 24 de Septiembre de 2019]; [17] Object Oriented Programing; [Online] Disponible en: https://syntaxdb.com/ref/java/abstract; [Consultado: 24 de Septiembre de 2019];