1.

Introducción

a. Microservicios es el nombre de un estilo de arquitectura del software,

fuertemente influenciado por el software distribuido. Los Microservicios están
de moda porque muchas compañías grandes y tecnológicamente sofisticadas
lo usan. Amazon, eBay, Twitter, Netflix, PayPal, son algunos ejemplos exitosos
de Microservicios.

2. Microservicios

a. Que son Los Microservicios?

i. Tradicionalmente los sistemas grandes y complejos se han abordado

mediante grandes sistemas mono-proceso (monolitos), donde el
mantenimiento y evolución del mismo era complejo. En
contraposición, los Microservicios son un patrón de diseño software a
nivel arquitectónico que implementa servicios mediante la
colaboración otros servicios más pequeños y autónomos.

Cada microservicio debe dar solución a un área de negocio concreta,

abstrayendo al resto del sistema de los detalles concretos de la
implementación, favoreciendo su independencia, el mantenimiento y
la evolución de cada uno de ellos.

Al trabajar cada uno sobre su propio proceso, permiten ser

desplegados sin perjudicar a los demás, favoreciendo así la
escalabilidad, y se comunican a través de mecanismos ligeros, como
pueden ser peticiones HTTP, entre las diferentes APIs de cada
microservicio.
 b. Características de Microservicios

i. Pequeños
ii. Basados en sistemas de mensajería
iii. Limitados por contextos
iv. Desarrollados de forma autónoma
v. Implementados de forma independiente
vi. Descentralizados
vii. Independientes del lenguaje
viii. Desarrollados y lanzados con procesos automatizados

c. Ventajas y Desventajas de Microservicios

i. Ventajas:
 Otorga a los desarrolladores libertad de desarrollar y
desplegar servicios de forma independiente.
 Un Microservicio se puede desarrollar con un equipo de
trabajo mínimo.
 Se pueden usar diferentes lenguajes de programación en
diferentes módulos.
 Fácil de entender y modificar, por lo que la integración de
nuevos miembros al equipo de desarrollo será muy rápida.
 Los desarrolladores podrán hacer uso de las tecnologías más
actuales. Fácil de escalar e integrar con aplicaciones de
terceros.

ii. Desventajas
 Las pruebas o testeos pueden resultar complicados debido al
despliegue distribuido.
 Un gran número de servicios puede dar lugar a grandes
bloques de información que gestionar.
 Será labor de los desarrolladores lidiar con aspectos como la
latencia de la red, tolerancia a fallos, balanceo de carga,
cantidad de formatos admitidos, etc…
 Sistema distribuido puede llegar a significar doble trabajo.
 Si se cuenta con un gran número de servicios, integrarlos y
gestionarlos puede resultar muy complejo.
 Esta tecnología suele incurrir en un alto consumo de memoria.
3. Patrones en Microservicios
a. Patrones base
i. Monolítico - diseña la aplicación como una unidad desplegable
individual.
ii. Microservicios - diseña la aplicación como una colección de servicios
ligeramente acoplados.

b. Patrones de despliegue
 i. ¿Cómo desplegar los servicios de la aplicación?
 Múltiples instancias de servicios por host - despliega múltiples
instancias de servicios en un sólo host.
 Una instancia de servicio por host - despliega cada instancia de
servicio en su propio host.
 Una instancia de servicio por máquina virtual - despliega cada
instancia de servicio en su propia máquina virtual.
 Una instancia de servicio por contenedor - despliega cada
instancia de servicio en su propio contenedor.
 Despliegue sin servidor (BaaS) - despliega un servicio en una
plataforma de "BaaS" (Backend-As-A-Service).
 Plataforma de despliegue de servicios - despliega servicios
usando una plataforma de despliegue altamente automatizada
que provee abstracción de servicios.

c. Patrones de Interfaz de Usuario

i. ¿Cómo implementar una interfaz de usuario que muestra datos desde
múltiples servicios?
 Composición de fragmentos de página en el lado del servidor -
construye una página en el servidor mediante la composición
de fragmentos HTML generados por múltiples aplicaciones
web específicas de los distintos subdominios/áreas del
negocio.
 Composición de la interfaz de usuario en el lado del cliente -
Construye la interfaz de usuario en el cliente mediante la
composición de fragmentos de interfaz renderizados por
múltiples componentes de interfaz de usuario específicos de
los distintos subdominios/áreas del negocio.

d. Patrones de comunicación
i. Estilo
¿Qué mecanismos de comunicación usan los servicios para
comunicarse entre ellos y con sus clientes externos?
 Llamada a procedimiento remoto - usa un protocolo orientado
a RPC para la comunicación entre servicios.
 Mensajería - usa mensajes asíncronos para la comunicación
entre servicios.
 Protocolo específico del dominio - usa un protocolo
especificado por el dominio.
ii. API Externa
¿Cómo se comunican los clientes con los servicios?
 API Gateway (Puerta de enlace) - un servicio que provee a
todos los clientes con una interfaz única hacia los servicios.
 Backend para el front-end - una puerta de enlace por cada tipo
de cliente

iii. Descubrimiento de Servicios

 ¿Cómo descubren la ubicación de red de una instancia los clientes de
un servicio orientado a RPC?
 Descubrimiento en el lado del cliente - el cliente consulta un
registro de servicios para descubrir la ubicación de una
instancia de servicio.
 Descubrimiento en el lado del servidor - un enrutador consulta
un registro de servicios para descubrir la ubicación de una
instancia de servicio.
 Registro de servicios - una base de datos para las ubicaciones
de instancias de servicio.
 Autoregistro - una instancia de servicio se registra a sí misma
en el registro de servicios.
 Registro de terceros - un tercero registra una instancia de
servicio en el registro de servicios.

iv. Confiabilidad
¿Cómo prevenimos que la falla de un servicio afecte a los demás?
 Corta circuitos - invoca un servicio remoto a través de un
proxy, el cual falla inmediatamente cuando la tasa de fallos de
la llamada remota excede un umbral.

4. Diseños en Microservicios
a. Para la implantación de una arquitectura de Microservicios hemos tener en
cuenta 3 aspectos principalmente:

i. Un modelo de referencia en el que definir las necesidades de una

arquitectura de Microservicios.

ii. Un modelo de implementación en el que decidiremos y concretaremos

la implementación de los componentes vistos en el modelo de
referencia.

iii. Un modelo de despliegue donde definir cómo se van a desplegar los

distintos componentes de la arquitectura en los diferentes entornos.

b. Modelo de Referencia
i. Los siguientes serán los componentes que vamos a necesitar en una
arquitectura de Microservicios:
 ii. Servidor de configuración central
iii. Servicio de registro / descubrimiento
iv. Balanceo de carga (Load balancer)
v. Tolerancia a fallos (Circuit breaker)
vi. Servidor perimetral / exposición de servicios (Edge server)
vii. Centralización de logs
viii. Servidor de Autorización
ix. Monitorización

c. Modelo Implementación

i. Basándonos en el modelo de referencia, vamos a definir un modelo de

implementación para cada uno de los componentes descritos. Para
ello haremos uso del stack tecnológico de Spring Cloud y Netflix OSS:
 ii. Microservicios propiamente dichos: Serán aplicaciones Spring Boot
con controladores Spring MVC. Utilizaremos Swagger para
documentar y definir nuestro API.

iii. Config Server: microservicio basado en Spring Cloud Config.

Utilizaremos Git como repositorio de configuración.

iv. Registry / Discovery Service: microservicio basado en Eureka de Netflix

OSS.

v. Load Balancer: utilizaremos Ribbon de Netflix OSS que ya viene

integrado en REST-template de Spring.

vi. Circuit breaker: utilizaremos Hystrix de Netflix OSS.

vii. Gestión de Logs: utilizaremos Graylog

viii. Servidor perimetral: utilizaremos Zuul de Netflix OSS.

ix. Servidor de autorización: implementaremos el servicio con Spring

Cloud Security.

d. Modelo de Despliegue

i. La siguiente cuestión a tener en cuenta cuando pensamos en

arquitecturas de microservicios es su modelo de despliegue. Nos
referimos aquí al modo en que vamos a organizar y gestionar los
despliegues de los microservicios, así como a las tecnologías que
podemos usar para tal fin.

Existen convencionalmente dos tendencias en este sentido a la hora

de encapsular microservicios:

 Máquinas virtuales.
 Contenedores.
 En nuestro caso optaremos por contenedores Docker, ya que esta
tecnología es la que está teniendo mayor acogida y repercusión en
entornos cloud y PaaS.

El siguiente paso será pensar en la automatización y orquestación de

los despliegues siguiendo el paradigma cloud.
Las opciones son montar sobre una PaaS un cluster de Docker donde
desplegar de forma automágica y transparente nuestros
contenedores.
En este punto, herramientas como Kubernetes y OpenShift aportan
registry y config management a nivel de infraestructura, mientras que
en nuestro ejemplo hemos utilizado las opciones de Spring Cloud y
Netflix OSS para implementar estos servicios.

Aquí entrarían también cuestiones sobre alta disponibilidad, pero

estos temas los relegaremos a futuros artículos.

El siguiente diagrama muestra un modelo simple de despliegue:

5. GraphQl
 a. ¿Qué es GraphQL?

i. GraphQL es un lenguaje de consultas creado por Facebook. Un

lenguaje como SQL, con la diferencia de qué GraphQL es un lenguaje
creado netamente para la comunicación Backend - Frontend.

ii. Diferencias entre REST y GraphQL

REST es solo una convención, es decir, es una manera en donde todos

nos ponemos de acuerdo de cómo nos vamos a comunicar de servidor
a cliente, pero al ser una convención, es muy flexible a como se
implementa.

GraphQL, al ser un lenguaje tipado y validable, es mucho más

confiable y menos flexible a la implementación.

Otra diferencia entre REST y GraphQL, es la forma de recibir y enviar

información, en REST, el servidor expone recursos y tiende a enviar
más información de la que necesitas, en cambio, en GraphQL, el
cliente define que recibe y solo envía la información necesaria.

6. Conclusiones

a. Finalmente, vale la pena mencionar que con la simplicidad de los servicios,

cierta complejidad se traslada necesariamente a la arquitectura. Espero
haberle proporcionado una forma de construir mentalmente sistemas de
Microservicio en su cabeza con algunos bloques genéricos de lego.

b. El actual desarrollo de software bajo la metodología aplicada se contrapone a

la arquitectura utilizada, lo cual dificulta su correcta aplicación.

c. El mantenimiento o cambio en las funcionalidades de las aplicaciones

representa un problema debido a su naturaleza monolítica.

d. Existe una clara intención de establecer una nueva arquitectura de desarrollo

de aplicaciones acorde a la utilización de nuevas tecnologías

e. Como hemos podido ver, GraphQL nos da herramientas para desarrollar un

API de forma rápida, natural e independiente del acceso a la base de datos.
Además soporta una gran cantidad de lenguajes y clientes.

f. Durante el desarrollo he podido darme cuenta de que los tipos de schema son
limitados ya que el hecho de solo disponer de Query y Mutation limita el tipo
de API que podemos construir conceptualmente hablando. Por ejemplo, si
quisiéramos implementar un servicio que enviara un email, en nuestra opinión
debería existir un tercer tipo denominado “Service”, ya que no es ni una Query
ni un Mutation.
7. Bibliografia

https://docs.microsoft.com/es-es/azure/service-fabric/service-fabric-overview-
microservices
https://www.ca.com/content/dam/ca/us/files/ebook/microservice-architecture-
aligning-principles-practices-and-culture.pdf
https://platzi.com/blog/arquitectura-microservicios/
https://enmilocalfunciona.io/tag/microservicios/
https://platzi.com/blog/introduccion-a-graphql/
https://www.aplyca.com/es/blog/graphql
https://deku.github.io/microservice-architecture-es/