PDF de programación - Arquitectura de Software basada en Microservicios para Desarrollo de Aplicaciones Web

Séptima Conferencia de Directores de Tecnología de Información, TICAL 2017 Gestión de
las TICs para la Investigación y la Colaboración, San José, del XX al XX de julio de 2017

Arquitectura de Software basada en Microservicios para

Desarrollo de Aplicaciones Web

Daniel Lópeza, Edgar Mayab

a Asamblea Nacional del Ecuador, Coordinación General de Tecnologías de la Información

y Comunicación, Piedrahita 5-21 y Av. Gran Colombia, Pichincha, Ecuador

[email protected]

b Universidad Técnica del Norte, Instituto de Posgrados, Av. 17 de Julio 5-21 Gral. José

María Cordova, Imbabura, Ecuador

[email protected]

Resumen. Actualmente, el proceso de desarrollo de software que realiza la Coordinación
General de Tecnologías de la Información y Comunicación (CGTIC) de la Asamblea Nacional
del Ecuador (ANE) constituye el empleo de una arquitectura de software tradicional o
monolítica que ha sido adoptada del lenguaje de programación utilizado, la plataforma o de la
experiencia del personal del área de desarrollo; por el aspecto monolítico, este tipo de
aplicaciones empaquetan toda la funcionalidad en una sola y gran unidad ejecutable (un solo
archivo o aplicación), lo que ha provocado dificultades en aspectos como mantenimiento,
escalabilidad y entregas. El objetivo del presente estudio fue identificar las tecnologías,
metodología y arquitectura que utiliza la CGTIC para el desarrollo de aplicaciones web y la
correspondiente identificación de las tecnologías existentes para el desarrollo e implementación
de microservicios, utilizando como base de la investigación un enfoque cualitativo, con un tipo
de investigación descriptiva y diseño documental. Se empleó la técnica de grupo focal aplicado
a los funcionarios del área de desarrollo de software de la CGTIC, revisión bibliográfica de
arquitectura de microservicios. Como avance de la investigación, el análisis ha permitido
identificar el estado del arte respecto a microservicios y su implementación así como la
identificación de los requisitos y necesidades relativos al desarrollo de aplicaciones web y como
satisfacerlas mediante el diseño de una arquitectura de software.
Palabras Clave: Microservicios, arquitectura de software, aplicaciones web.
Eje temático: Infraestructura y desarrollo de software.

1 Introducción

En la actualidad, a nivel empresarial y tanto en el sector privado como público se
realiza desarrollo de software para suplir las necesidades de automatización de
procesos internos, este desarrollo ha seguido las tendencias impuestas por la
plataforma, lenguaje de programación o por la experiencia del área de desarrollo, lo
cual deviene en la implantación de sistemas de construcción tradicional o monolítico.

El proceso de desarrollo de software que realiza la Coordinación General de
Tecnologías de la Información y Comunicación (CGTIC) de la Asamblea Nacional
del Ecuador (ANE) constituye el empleo de una arquitectura de software monolítica,

misma que ha sido adoptada por el uso de un lenguaje de programación específico
para construcción de aplicaciones web empresariales; por el aspecto monolítico, este
tipo de aplicaciones empaquetan toda la funcionalidad en una sola y gran unidad
ejecutable (un solo archivo o aplicación),
lo que ha provocado dificultades en
aspectos como mantenimiento, escalabilidad y entregas [1]

1.1 Problema

El presente trabajo de investigación, parte de un análisis de la problemática existente
con el desarrollo de aplicaciones web de la CGTIC, dicho desarrollo hace uso de una
arquitectura monolítica la cual incide en diferentes aspectos tanto tecnológicos y
administrativos. Las incidencias más evidentes se pueden observar al aplicar procesos
de mantenimiento en sistemas complejos, sea por una petición de cambio, nueva
funcionalidad o corrección de un fallo, en los cuales, la resolución de un problema o
cambio simple implica el redespliegue de toda la aplicación debido a que se tiene
todas las funcionalidades en un único paquete incrementando los riesgos de fallos. De
igual forma, por el tiempo que toma la implementación de un cambio o nueva
funcionalidad, se presenta resistencia al cambio en el usuario final, y en consecuencia
las actualizaciones son menos frecuentes porque requieren de un mayor esfuerzo y
coordinación de los grupos de desarrollo y la realización de pruebas más extensas.

En aspectos de calidad, surgen complicaciones en la escalabilidad ya que puede
requerirse escalar un módulo específico, pero, por el aspecto monolítico es necesario
escalar la aplicación en su totalidad. De igual manera sucede con la resilencia, al
ocurrir un fallo por caída o sobrecarga en una parte de la aplicación, se pierden todas
sus funcionalidades; si bien este último aspecto puede ser subsanado mediante
replicación o clusters,
también incrementa las dificultades de coordinación,
configuración y eleva los costos de equipamiento y esfuerzo.

Otra problemática a resaltar, es la incidencia que produce el mantenimiento
aplicaciones en el normal desenvolvimiento de las actividades de los usuarios; en este
sentido, una de las áreas más críticas es el Plenario de la ANE, el cual hace uso de
software para registrar las votaciones de los legisladores en la creación o reforma de
leyes de afectación nacional, por lo que resulta difícil cambiar, agregar o actualizarlo.
Adicionalmente, algunos de los sistemas se encuentran impedidos de actualización
que es de vital importancia por su nivel de criticidad y afectación, esto se debe una
vez más por estar construida bajo el esquema monolítico.

Por los aspectos descritos se concluye que existe la necesidad de definir una nueva
arquitectura de software con un enfoque de vanguardia que facilite el desarrollo de
nuevas aplicaciones para las diferentes unidades organizacionales de la ANE. Bajo
esta nueva perspectiva, se pretende obtener arquitectura de software flexible que
permita el mantenimiento de las aplicaciones evitando la interrupción de actividades
del personal que las usa.

2 Antecedentes

En la Universidad de Aarhus de Dinamarca [2], evalúa diferentes tácticas de
disponibilidad y mantenibilidad en la construcción de un prototipo con arquitectura de
microservicios, en el proceso, concluye con una revisión de las características de los
microservicios enunciadas por Fowler y Lewis [3]en cuatro criterios principales que
definen a un microservicio:

Enfoque en las capacidades de negocio. El proceso de desarrollo de software se
vuelve más flexible bajo el enfoque de microservicios, cada microservicio está
compuesto por su propia lógica de negocios, interfaz de usuario, base de datos y
funcionalidad de comunicación con otros servicios, por lo tanto, en el equipo de
desarrollo que cada miembro necesita experiencia en desarrollo de backend, frontend,
y bases de datos, permitiéndoles agregar nuevas características rápidamente sin
arriesgar la estabilidad y el funcionamiento de todo el sistema.

Independencia de los servicios autónomos. Cada servicio contiene su propia lógica
de negocio y se despliega por separado. Esto hace posible cambiar y extender
gradualmente con nuevas características sin afectar el resto del sistema. La propiedad
autónoma permite la flexibilidad en la selección de la tecnología más adecuada para
un servicio específico.

Gestión descentralizada de datos. Todos los servicios tienen su propia base de datos
en esquemas pequeños y simples, que se ven por separado. Los datos están
desacoplados, lo que requiere mucha gestión y pruebas para garantizar que un sistema
nunca actualice o elimine los datos en un servicio sin actualizar o eliminar los datos
correspondientes en otros servicios que contienen los mismos datos o conjunto de
referencias.

Tolerancia a fallos. Los sistemas de microservicio consisten en múltiples unidades
pequeñas que pueden fallar; Estas unidades están ligeramente acopladas y pueden ser
restauradas automáticamente. lo que resulta en un sistema más estable y robusto.

Por su parte Borčin [4] en su trabajo de investigación, realiza un análisis de los
atributos de calidad de la arquitectura de microservicios profundizando en los retos de
su implementación:

Interfaces y comunicación. Cada microservicio debe exponer alguna interfase, para
algunas tecnologías no equipadas con una especificación, esto puede representar
serios problemas incluso REST que es utilizado en la arquitectura de microservicio
para la comunicación no tiene una interfaz bien definida.

Transacciones y bloqueos. Se necesita un conjunto completamente nuevo de
operaciones para una transacción que comprueba la comunicación de microservicios.
se debe asegurar de que ningún microservicio utilice flujos cerrados o recursos
bloqueados y que no modifique los datos que otros servicios están utilizando. Estos
bloqueos podrían provocar la suspensión de todo el sistema.

Programación coreográfica. El paradigma de programación coreográfica puede
ayudar en la creación de sistemas libres de bloqueos, sin errores de comunicación. La
programación coreográfica puede llegar a ser más importante con el desarrollo
ulterior de la arquitectura del microservicio, ya que proporcionan un terreno sólido
para una formalización de la comunicación.

Puntos de entrada. La seguridad es un problema importante cuando se trata de la
arquitectura de microservicios y los sistemas distribuidos en general. En aplicaciones
monolíticas se puede asegurar fácilmente la seguridad de toda la aplicación, ya que
toda la comunicación pasa a través de los puntos de entrada que posee cada módulo
que lo compone. En contraste, en microservicios, garantizar la seguridad se vuelve
mucho más difícil. Toda la aplicación se compone de un microservicio independiente
(lenguaje y máquina) que expone sus interfaces y el núcleo de la aplicación para la
comunicación exterior, proporcionando nuevos puntos de entrada para los intrusos.

Red compleja. Una extensa red de comunicación puede ser fácilmente expuesta a
ataques, ya que es difícil administrar c