Anda di halaman 1dari 5

Arquitectura basada en microservicios y su

importancia en el desarrollo de software


Ejemplo prctico: procedimiento para el desarrollo de una aplicacin orientada a
microservicios utilizando grails framework
Eduardo Hernndez Gutirrez, Eduardo Cornejo Velzquez
Universidad Autnoma del Estado de Hidalgo
Pachuca de Soto, Hidalgo, Mxico
Email: {eduardo_hernandez, ecornejo} @uaeh.edu.mx

ResumenEn el presente artculo se expone la importancia


que tiene hoy da el desarrollo de sistemas basados en
microservicios y las diferencias que tienen stos con respecto a los
sistemas tradicionales basados en arquitecturas monolticas.
Tambin, a manera de ejemplo se hace mencin de un
procedimiento para la construccin de aplicaciones Web basadas
en una arquitectura de microservicios que se aplica
especficamente al desarrollo con Grails Framework y que surge
como resultado de la experiencia que los autores de este
documento han adquirido luego de la adopcin de tcnicas,
herramientas y metodologas del movimiento agile el cual tiene
como objetivo principal establecer las directrices y buenas
practicas que desembocan en el desarrollo de software ms
estable, gil y eficiente.
Palabras claveweb services, REST, grails, arquitectura
basada en microservicios, sistemas monolticos.

I. INTRODUCCIN

se despliega como un archivo WAR (en el caso de las


aplicaciones Web). El problema: la ms mnima modificacin
implica detener la aplicacin en su totalidad aun cuando
algunas partes de sta no necesariamente dependan de otras,
pero igual estn encapsuladas en el mismo aplicativo [8].
La solucin que eventualmente surgi: desarrollo de
sistemas basados en una arquitectura de microservicios que
siguen manteniendo el patrn de diseo MVC. Esto represent
un nuevo enfoque que revolucion la forma en que se
desarrolla el software actualmente. A travs de la
modularizacin de los requerimientos de un producto de
software, es decir, el desarrollo de mdulos independientes con
funcionalidades o tareas especficas y que son consumidos por
un cliente principal es posible crear soluciones eficientes y
descentralizadas.
II. SISTEMAS MONOLTICOS

Cuando una organizacin comienza a presentar un


crecimiento en componentes clave tales como: su nmina,
infraestructura fsica, clientes y los servicios que se ofrecen a
stos ltimos. La infraestructura tecnolgica y en especial los
sistemas de informacin se ven afectados de manera directa
debido al incremento en el nmero de transacciones y
requerimientos que los usuarios exigen da a da.
En este escenario, es muy comn que se soliciten nuevas
funcionalidades y/o adecuaciones a los sistemas existentes por
lo que es necesario que los equipos de desarrollo de software
realicen cambios en la estructura (cdigo) de dichas
aplicaciones. Esto, no siempre resulta ser una tarea simple aun
cuando los cambios pareciesen ser mnimos. Mucho tienen que
ver el patrn arquitectural bajo el cual fue concebida la
aplicacin, el lenguaje de programacin, la documentacin
existente y sobre todo, si los desarrolladores de aquel entonces
siguen formado parte de la organizacin.
Hasta hace pocos aos, la mayora de los sistemas
empresariales eran desarrollados siguiendo una arquitecta
monoltica y bajo el patrn de diseo modelo-vista-controlador
o MVC y a travs de los cuales se obtenan soluciones slidas
y funcionales salvo un nico inconveniente, la aplicacin
resultante se instala como un nico programa especializado o

Fig. 1 Arquitectura de 3 capas


Fuente: Elaboracin propia

A. Definicin
Un sistema o aplicacin monoltica es aquella que se
construye como una nica unidad. Actualmente este tipo de
aplicaciones tambin se apoyan en el uso del patrn MVC
(figura 1) para su construccin por lo que al final se tiene un
sistema que internamente encapsula tres componentes bsicos:

La capa de presentacin presentada como la interfaz


de usuario y que consiste normalmente en pginas
HTML/JavaScript que se ejecutan en el navegador del
usuario.

Simples de desplegar. Basta con instalar la aplicacin


(en el caso de aplicaciones de escritorio) o desplegarla
a travs de un servidor de aplicaciones si se trata de
una aplicacin Web.

Fcil de escalar por medio de rplicas en nuevos


servidores.

C. Desventajas

La necesidad de eventuales modificaciones implican


tener que detener toda la aplicacin.

La capa lgica que contiene la lgica de negocio sobre


un servidor de aplicaciones (operaciones y
procedimientos).

El equipo de desarrollo debe estar presente en cada


proceso que implique la realizacin de cambios a la
aplicacin en caso de alguna eventualidad crtica.

La capa de datos que se encarga de la conexin y


acceso con las bases de datos y los cuales son utilizados
por la capa lgica.

En este tipo de aplicaciones, al haber una


interdependencia de recursos es muy probable que el
ms mnimo cambio afecte a otras partes.

Una interaccin de ests tres capas se da cuando el servidor


en el que reside la capa lgica recibe las instrucciones o
solicitudes HTTP enviadas por el navegador, ejecuta las
instrucciones pertinentes, recupera y actualiza los datos de la
base de datos en caso de ser necesario para finalmente generar
o actualizar las vistas HTML que son presentadas al usuario
por medio del navegador web. En la figura 2 se muestra la
arquitectura bsica de un sistema monoltico.

III. ARQUITECTURA BASADA EN MICROSERVICIOS


A. Definicin
Los microservicios son una arquitectura basada en
pequeos y autnomos servicios que trabajan de forma
conjunta los cuales surgen como una alternativa a las
aplicaciones monolticas en donde todos los servicios estaban
contenidos en la misma aplicacin y desplegados en todos los
servidores [9].
Martin Fowler y James Lewis [6] definen un microservicio
como un estilo arquitectural, es decir, una forma de desarrollar
una aplicacin, basada en un conjunto de pequeos servicios,
cada uno corriendo o ejecutando sus propios procesos y
comunicndose mediante mecanismos livianos, generalmente
un recurso API de HTTP.

Fig. 2 Arquitectura monoltica


Fuente: Elaboracin propia

B. Ventajas
Simple de desarrollar al tener un nico ciclo de vida
que va desde el anlisis de requerimientos hasta la
puesta en produccin.

Simple de probar ya que las pruebas unitarias solo se


tiene que aplicar sobre una nica aplicacin.

Fig. 3 Arquitectura con microservicios


Fuente: Elaboracin propia

La arquitectura basada en microservicios propone que tanto


la interfaz como las aplicaciones de usuario sean clientes de
una coleccin de servicios. De esta forma se propicia en la
medida de lo posible, que ninguna parte dependa
necesariamente de otras partes, pudiendo as poder responder
cada una ante cualquier situacin. La figura 3 muestra de forma
grfica la arquitectura de las aplicaciones basadas en
microservicios.
B. Ventajas
Al trabajar con servicios como los basados en la
arquitectura REST, puede haber ms de un equipo de
desarrollo ya que la plataforma de desarrollo y los
lenguajes de programacin no representan
inconveniente alguno al momento de integrar cada
mdulo.

Trabajar por separado cada mdulo facilita realizar


modificaciones a funcionalidades especficas de la
aplicacin sin tener que detener el servicio por
completo.

A diferencia de los sistemas monolticos, el


escalamiento se hace a nivel de mdulos o servicios lo
cual reduce los costes en infraestructura tecnolgica.

C. Desventajas

El despliegue. Al estar distribuidos en diferentes


servidores y estar escritos en diferentes lenguajes
implica la gestin de cada una de stas tecnologas.

El problema del versionado. Cada grupo de desarrollo


debe encargarse de actualizar la documentacin
correspondiente.

Redundancia e inconsistencia de datos. Producto de


los cambios aplicados a algn modulo en particular y
no generar la documentacin correspondiente es
posible que dos ms de un mdulo generen
inconsistencias en la informacin procesada.

IV. ENTONCES EN QU CASOS ES CONVENIENTE DESARROLLAR


APLICACIONES BASADAS EN MICROSERVICIOS?
Actualmente nos encontramos en una era en la que la
integracin de plataformas y sistemas estn a orden del da,
sta, la denominada la era de los servicios [1] ha cambiado la
forma en que se construyen las aplicaciones mediante el
establecimiento de patrones arquitecturales basados en
microservicios que buscan generar productos ms estables,
giles y eficientes.
Decidir si es conveniente o no la implementacin de los
microservicios en nuestros proyectos de desarrollo de software
va a depender de las caractersticas del mismo los alcances
esperados. No por nada es que existen un incontable nmero de
tcnicas, patrones de diseo y arquitectural que han ofrecido a
ms de uno la solucin ms acorde a sus necesidades. Tal
como menciona [8], una arquitectura basada en microservicios

no es intrnsecamente ms costosa de desarrollar que una


monoltica, solo requiere de un conjunto de competencias
diferentes que algunos desarrolladores an no han adquirido,
adems, siempre se deben plantear soluciones que entes
orientados a cumplir los objetivos de negocio de la empresa a
corto y largo plazo.
V. EJEMPLO: PROCEDIMIENTO PARA EL DESARROLLO DE UNA
APLICACIN ORIENTADA A MICROSERVICIOS UTILIZANDO
GRAILS FRAMEWORK

Grails Framework
Grails es un framework creado por Graeme Rocher en el
ao 2006 como una respuesta a la necesidad de agilizar,
automatizar y simplificar el desarrollo de aplicaciones Web
que trabaja sobre la filosofa DRY: Dont repeat yourself! [2].
Grails se basa en el uso del lenguaje de Java, mediante la
implementacin de Groovy, adems de que internamente
implementa tcnicas y tecnologas ya existentes de Java como
Srping e Hibernate. El resultado es un framework que ofrece
estabilidad al implementar tecnologas ya conocidas y librando
al desarrollador de la tediosa y complicada tarea de
configuracin ya que Grails lo hace de forma automtica en la
mayora de los casos.
REST en Grails
Por defecto Grails permite la generacin de proyectos
basados en el patrn arquitectural de tipo REST [12], el cual
hace uso de XML y JSON como medio de comunicacin y
combinndolo con los mtodos HTTP.
A continuacin se describe de manera muy superficial el
procedimiento que ejemplifica el desarrollo de una aplicacin
basada en servicios con grails, si el lector desea verificar su
funcionalidad y aplicarlo a un proyecto propio puede acceder a
repositorio
de
GitHub
en
https://github.com/lalo9210/grailsTutoWebServices y revisar el
tutorial completo aplicado a un proyecto real. Este
procedimiento puede ser de gran utilidad para aquellos
desarrolladores que se inician en el uso de web services con
grails. Es importante mencionar que el procedimental es
resultado de la experiencia que los autores de este documento
han adquirido con el paso del tiempo por lo que en ningn
momento supone un estndar a seguir y es susceptible a
mejoras.
A. Creacin del proyecto y definicin del modelo de datos
1. Definicin de mdulos
Para poder comenzar el desarrollo del sistema es
necesario tener claro cada uno de los mdulos y las
funcionalidades que les corresponden tratando de no
duplicar trabajo.
2.

Generar el proyecto en Grails

3.

Crear las clases de dominio


Segn las convencionalidades de Grails, cada una de las
clases de dominio se mapea directamente con una tabla
en la base de datos, si no existe se crea al momento de

ejecutar la aplicacin, sin embargo, tambin es posible


que se desee utilizar alguna base de datos y/o tablas
existentes, para tal efecto, el desarrollador deber hacer
las configuraciones pertinentes.
4. Definir los atributos y las restricciones
Al igual que con las clases de dominio, cada atributo
representa a un elemento determinado en la base de
datos, en este caso, las columnas de cada tabla asociada
con la clase de dominio. Es posible establecer desde la
clase de dominio el tipo de dato y restricciones que cada
columna en la base de datos deber tener.
5. Generar las pruebas unitarias para los atributos de las
clases de dominio y sus restricciones
En cualquier proyecto de desarrollo de software es
indispensable no pasar por alto la generacin de las
pruebas unitarias para cada uno de los componentes que
se van generando a medida que el proyecto avanza, el
objetivo de las pruebas unitarias consiste en evaluar el
correcto funcionamiento de cada artefacto generado
incluso antes de tener una interfaz grfica, esto de
alguna manera permite detectar errores antes de la
puesta en marcha del primer prototipo funcional.
B. Definicin de servicios
6. Agregar una clase abstracta Service
El uso de clases abstractas permite definir aquellos
mtodos que son comunes e invariantes por los objetos
generados en el proyecto, por ejemplo, en un sistema no
pueden faltar las operaciones bsicas del CRUD para el
manejo de la informacin. En este caso, se puede
definir una clase abstracta que se encargue de ello y
posteriormente ir extendiendo las funcionalidades de la
misma segn lo requieran las clases que de ella hereden.
7. Crear las clases de NombreDominioService que
extienden de la clase abstracta Service
En estos artefactos de debe especificar todas aquellos
mtodos y procedimientos especificados dentro de la
lgica de negocios.
8. Crear las clases Utils para cada clase de dominio
Estos archivos son muy importantes ya que nos
permiten generar instancias temporales de las clases de
dominio al momento de realizar las pruebas unitarias
sin la necesidad de tener una base de datos y poder de
esta manera comprobar la funcionalidad de los servicios
generados hasta el momento.

comunicacin entre las peticiones del cliente y los servicios


definidos.
10. Crear un controlador abstracto
11. Crear los controladores correspondientes a cada clase
de dominio que extiendan del controlador abstracto
12. Desarrollo de pruebas o tests unitarios para los
controladores
D. Desarrollo del cliente
El desarrollo del cliente queda totalmente a libertad del
programador, ya que es en este punto donde la integracin de
plataformas queda en evidencia. Tanto la plataforma de
desarrollo y el lenguaje de programacin no deben ser un
impedimento para consumir los servicios generados por la
aplicacin desarrollada en Grails ya que son de tipo REST.
Cada lenguaje y/o framework de desarrollo mantienen
procedimientos y herramientas especficas para el desarrollo de
clientes REST que quedan fuera del alcance de este documento
y del tutorial ofrecido en el repositorio de GitHub.
VI. RESULTADOS (VENTAJAS OPERATIVAS)
El procedimiento para el desarrollo de aplicaciones basadas
en microservicios con grails que ha sido presentado a manera
de ejemplo en este documento es actualmente aplicado por los
autores de este documento en los proyectos de desarrollo de
software que tienen a su cargo. El desarrollo de software
basado en microservicios junto con la combinacin de tcnicas
y metodologas giles han significado un cambio en las formas
de trabajo ya que ahora en lugar de esperar varios meses para
tener un primer prototipo funcional como ocurra con el
desarrollo de sistemas monolticos se ha optado por un
desarrollo modular mediante una priorizacin previa de
requerimientos y funcionalidades. De este modo se cumple con
aquello que es importante y urgente, a la vez que se ponen a
prueba dichos componentes en un escenario real y se genera la
retroalimentacin correspondiente por parte de los usuarios
mientras el equipo de desarrollo se enfoca en la construccin
de los siguientes mdulos correspondientes.
Como parte de los resultados obtenidos, a continuacin se hace
mencin de las ventajas operativas que se han identificado en
los diversos proyectos desarrollados con la arquitectura basada
en microservicios.
1.

Tomar la decisin de crear aplicaciones basadas en


microservicios antes de pensar en aplicaciones
monolticas significa adelantarse al futuro. Si de
antemano se tiene conciencia de que la aplicacin
crecer de forma gradual a lo largo del tiempo y que
la lgica de negocios se pueda ver forzada a cambiar
constantemente, resulta ms apropiado un desarrollo
modular que adems permite el desarrollo de servicios
de una manera ms rpida, fcil de entender y fcil de
mantener. As, cuanto ms grande es la aplicacin,
ms fcil resulta realizar cualquier cambio sin afectar
la totalidad del sistema.

2.

Esta arquitectura permite que un equipo de desarrollo


se pueda enfocar en el desarrollo de un servicio o

9. Crear test unitarios para las clases de servicios


C. Generacin de controladores
Tal como lo establecen las directrices de la arquitectura
MVC, los controladores deben fungir como artefactos que
controlar las llamadas a operaciones y procedimientos
almacenados en la capa lgica de la aplicacin evitando.
Con este procedimiento propuesto se busca lograr que los
controladores nicamente sirvan como artefactos de

mdulo de forma independiente. Con esto se permite


adems que los desarrolladores puedan escoger el tipo
de tecnologa para con la cual levarn a cabo su
trabajo puesto, que al final se tienen microservicios
basados en una arquitectura estndar como lo es
REST.
3.

4.

5.

La arquitectura basada en microservicios permite que


cada servicio pueda ser desplegado de manera
independiente lo cual permite a los desarrolladores
poder hacer cualquier modificacin sin que ello
conlleve a la interrupcin de las actividades de otro
equipo de desarrollo o que se vea afectado el sistema
en su totalidad.
Cuanto ms grande es el nmero de peticiones y
consumo de los servicios de un sistema, resulta ms
econmico poder realizar el escalamiento de la
aplicacin, ya que, a diferencia de los que ocurre con
los sistemas monolticos en los que es necesario
replicar todo el sistema en distintos servidores aun
cuando los servicios que se estn consumiendo
mayormente son muy pocos, los sistemas basados en
microservicios permiten desplegar el nmero exacto
de instancias de un nico servicio evitando as el uso
excesivo de hardware y minimizando los costos del
mismo.
Por ltimo. Una de las principales ventajas que brinda
el trabajar con sistemas basados en microservicios
reside en la posibilidad de tener un nico backend que
funge como el ncleo base que es capaz alimentar de
una gran variedad de productos finales (aplicaciones
y/o sistemas) que solucionen las necesidades
especficas de cada tipo de usuario final sin importar
el sistema operativo, el lenguaje de programacin o el
dispositivo electrnico desde el que se accede a la
informacin (figura 4).
Al generar servicios
universales que mantengan bien definidos sus
procesos dentro de la lgica de negocio se evita la
duplicidad de procesos e informacin.

VII. CONCLUSIONES
Hoy da es cada vez ms comn que los sistemas de
software no sean concebidos como herramientas que trabajan
de forma individual. Actualmente, la mayora de los sistemas
hacen uso de recursos (informacin y procedimientos)
provenientes de otros sistemas ya sean internos o externos a la
organizacin misma y viceversa.
Anteriormente, pensar en este tipo de interaccin entre los
sistemas resultaba sino improbable muy conflictivo debido a
las diversas plataformas y lenguajes de desarrollo existentes.
En el escenario ms simple, la interaccin entre un sistema de
escritorio y uno desarrollado para web era imposible de
concebirse.
Con la llegada, o mejor dicho la estandarizacin de REST
como un estilo de arquitectura que permiti la comunicacin e
integracin de plataformas mediante el uso de servicios web,
un nuevo paradigma en el mbito de la programacin y
desarrollo de software surgi, a tal punto que ahora nos
encontramos en la era de los servicios.
Aun cuando el procedimiento propuesto est orientada al
uso de Grails, este documento tiene un enfoque terico que
puede ser de gran utilidad para aquellos desarrolladores desean
iniciar y entender los conceptos bsicos del desarrollo de
software orientado a microservicios. Para un desarrollador de
software entender conceptos nuevos y adoptar una nueva forma
de trabajo siempre resulta hasta cierto punto difcil, no tanto
por la cuestin terica, sino ms bien por el hecho de aprender
y aplicar de forma correcta las llamadas buenas prcticas de
programacin.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]

[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
Fig. 4 Integracin de plataformas
Fuente: Elaboracin propia

Alzate Sandoval, G. (2014). API's, Construyendo una nueva era. SG


Software Guru #45, 18-19.
Brito, N, (2009). Manual de desarrollo Web con Grails. Madrid, Espaa:
Ediciones agiles.
Brown, J. S., & Rocher, G. (2013). The Definitive Guide to Grails 2.
New York: Apress.
Cervantes, H. (2014). Las Interfaces y la Arquitectura. SG Software
Guru #45, 24-25.
Hernndez Gutirrez, E. (2013). Sistema de Geolocalizacin de
Espacios Universitarios en la UAEH (tesis de pregrado). Universidad
Autnoma del Estado de Hidalgo. Pachuca de Soto, Mxico.
Lewis, J., & Fowler, M. (25 de Marzo de 2014). Microservices.
Obtenido de http://martinfowler.com/articles/microservices.html
Luna, V., & Arana, F. (Noviembre de 2014). TDD y Clean Code. SG
Software Guru #46, 34-35.
Montoro, S. (12 de Julio de 2014). Microservicios | La pastilla roja.
http://lapastillaroja.net/2014/07/microservicios/
Newman, S. (2015). Building Microservices. United States of America:
O'REILLY.
Snchez, J. (Noviembre de 2014). Por qu documentar el Cdigo? SG
Software Guru #46, 41.
Smith, G., & Ledbrook, P. (2014). Grails in Action second edition.
Shelter Island, NY: Manning Publications Co.
Bernhardt, S. (Octubre de 2014). Microservices Architectures, Thougths from a SOA perspective. SOA Magazine, 22.
Thomas Fielding, R. (2000). Architectural Styles and the Design of
Network-based
Software
Architectures.
Obtenido
de
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Anda mungkin juga menyukai