Arquitectura de microservicios

Ir a la navegaci�nIr a la b�squeda
La Arquitectura de micro- servicios, conocido por las siglas MSA (del ingl�s Micro
Services Architecture) es una aproximaci�n para el desarrollo de software que
consiste en construir una aplicaci�n como un conjunto de peque�os servicios, los
cuales se ejecutan en su propio proceso y se comunican con mecanismos ligeros
(normalmente una API de recursos HTTP). Cada servicio se encarga de implementar una
funcionalidad completa del negocio. Cada servicio es desplegado de forma
independiente y puede estar programado en distintos lenguajes y usar diferentes
tecnolog�as de almacenamiento de datos .1?

Se suele considerar la arquitectura de microservicios como una forma espec�fica de

realizar una arquitectura SOA.2?

�ndice
1 Caracter�sticas
2 Integraci�n de servicios
2.1 Ejemplo
3 Cr�ticas
3.1 Carga cognitiva
4 Referencias
Caracter�sticas
En el mundo real no todas las implementaciones de este estilo de arquitecturas
siguen las mismas caracter�sticas pero la mayor parte de las arquitecturas de
microservicios tienen la mayor parte de las siguientes caracter�sticas:2?3?

Los componentes son servicios. La principal manera de crear componentes (unidad de

software independientemente reemplazable y actualizable) es mediante la inserci�n
de un bot�n que autom�ticamente por detr�s, gestione la decomposici�n en servicios
en lugar de bibliotecas. Los servicios son componentes separados que se comunican
mediante mecanismos como los servicios web o los RPC en lugar de usar llamadas a
funciones en memoria como hacen las bibliotecas.
Organizada en torno a las funcionalidades del negocio. El sistema se divide en
distintos servicios donde cada uno est� organizado en torno a una capacidad del
negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada
servicio implementa toda la funcionalidad del negocio que agrupa desde la interfaz
de usuario, la persistencia en el almacenamiento y cualquiera de las colaboraciones
externas.
Productos no proyectos. En esta arquitectura normalmente se sigue la idea de que un
equipo debe estar a cargo de un componente (servicio) durante todo el ciclo de vida
del mismo, desde la etapa de dise�o y construcci�n, la fase de producci�n y hasta
la de mantenimiento. Esta mentalidad se acopla bien con la vinculaci�n a una
capacidad del negocio. En lugar de ver el software como un conjunto de
funcionalidades terminadas se ve como una relaci�n continua, donde la pregunta es
c�mo puede el software ayudar a sus usuarios a mejorar la funcionalidad del negocio
que implementa. Esto es facilitado por el bajo nivel de granularidad que ofrecen
los microservicios.
Extremos inteligentes tuber�as bobas. Las aplicaciones creadas desde microservicios
pretenden ser tan disociadas y cohesivas como sea posible, ellas poseen su propia
l�gica de dominio y act�an como filtros en el cl�sico sentido UNIX: recibe una
solicitud, aplica la l�gica apropiada y produce una respuesta. Estos pasos son
coreografiados usando protocolos simples (t�picamente HTTP con REST o mensajer�a
liviana como RabbitMQ o ZeroMQ) en lugar de protocolos complejos como WS-BPEL.
Tener gobierno descentralizado permite usar tecnolog�as que se adapten mejor a cada
funcionalidad. Con el sistema con m�ltiples servicios colaborativos, podemos
decidir utilizar diferentes lenguajes de programaci�n y tecnolog�as dentro de cada
servicio. De esta forma podemos elegir la herramienta adecuada para cada tipo de
trabajo en lugar de tener una estandarizada. Por ejemplo si una parte del sistema
necesita mejorar su rendimiento es posible usar una tecnolog�a, quiz�s m�s
complicada, que permita alcanzar el nivel de rendimiento requerido. Otro ejemplo
ser�a usar para ciertas cosas (reflejar interacciones entre usuarios) una base de
datos orientada a grafos, y usar para otra bases de datos orientadas a documentos.
la arquitectura de microservicios permite adoptar nuevas tecnolog�as m�s r�pido y
en aquellos lugares donde se puede aprovechar su potencial ya que se acota el
impacto.
Gesti�n de datos descentralizada. Los microservicios prefieren dejar a cada
servicio que gestione su propia base de datos, sean estos diferentes instancias de
la misma tecnolog�a de base de datos o sistemas de base de datos completamente
diferentes. Por ejemplo podr�amos tener Redis para sesiones de usuarios (base de
datos en memoria), MySQL (relacional) para los datos de pago, MongoDB (orientada a
documentos) para el cat�logo de productos, Neo4j (orientada a grafos) para las
recomendaciones y Apache Cassandra (orientado a clave-valor) para el an�lisis de
logs y anal�ticas. El estilo de microservicios tiene implicaciones en el manejo de
las actualizaciones las cuales tradicionalmente han usado transacciones para
garantizar la consistencia. Las transacciones impone un acoplamiento temporal lo
que se vuelve problem�tico cuando hay varios servicios. Como las transacciones
distribuidas son mucho m�s dif�ciles de implementar, las arquitecturas de
microservicios promueven la coordinaci�n no transaccional entre servicios, con el
reconocimiento expl�cito que la consistencia puede ser una consistencia eventual y
los problemas son compensados operativamente. El sistema merece la pena siempre y
cuando el costo de solucionar los errores sea menor que el costo de perder negocios
por una mayor consistencia. Los microservicios no obligan a tener distintas
tecnolog�as de almacenamiento, solo lo permiten.
Dise�o tolerante a fallos. Las aplicaciones necesitan ser dise�adas de modo que
puedan tolerar las fallas de los distintos servicios. Cualquier llamada de servicio
puede fallar y el cliente tiene que ser capaz de responder a esto con la mayor
facilidad y eficacia posible, evitando los muy habituales fallos en cascada de las
arquitecturas distribuidas. Patrones m�s importantes para conseguir estabilidad que
se usan en la arquitectura de microservicios:
Usar tiempos de espera m�ximos. Es un mecanismo simple que permite dejar de seguir
esperando por una respuesta que consideramos que ya no vendr�. Asociado al
vencimiento de un tiempo de espera es frecuente que aparezcan:
Reintento. Consiste en repetir una operaci�n para el cual finaliz� su tiempo de
espera
Encolar para reintentar la operaci�n para ser realizada m�s tarde
Disyuntores. Funcionan de forma similar a los interruptores autom�ticos accionados
por sobrecargas que hay en las instalaciones el�ctricas. En el software existen
para permitir que un subsistema ante una falla no destruya el sistema entero por
sobrecarga y una vez que el peligro ha pasado pueda reestablecerse. Este mecanismo
se suele usar para envolver operaciones peligrosas con un componente y as� poder
esquivar las llamadas cuando el sistema no est� operativo. Si el disyuntor detecta
que las fallas superan una frecuencia umbral el disyuntor salta abri�ndose y las
llamadas fallan sin realizar ning�n intento de ejecutar una operaci�n real. Despu�s
de esperar un tiempo adecuado se decide que la operaci�n tiene una oportunidad y
pasa a un estado de semiabierto en el que la pr�xima llamada es permitida, si tiene
�xito entonces el disyuntor se vuelve a cerrar y todo vuelve a funcionar
normalmente, si falla el disyuntor se vuelve a abrir y se vuelve a esperar el
tiempo adecuado para intentar.
Compartimentos estancos para contenci�n de da�os manteniendolos aislados. La forma
m�s com�n de tenerlos es usando redundancia f�sica teniendo por ejemplo varios
servidores y dentro de cada servidor varias instancias. A gran escala podr�amos
tener varias granjas de servidores.
Automatizaci�n de la infraestructura. La mayor�a de los productos y sistemas
desarrollados con el enfoque de microservicios han sido construidos por equipo que
usan entrega continua y su precursor la integraci�n continua. Para conseguir esto
es necesario:
Automatizar todo el proceso, desde el chequeo del c�digo, pruebas, despliegue, ...
Control de versiones y gesti�n de configuraci�n. Todo el software tiene que estar
versionado y poder gestionar las distintas configuraciones para conseguir la
entrega continua.
Arquitectura adecuada. La arquitectura tiene que permitir realizar cambios sin que
afecten al resto del sistema. La arquitectura de microservicios lo hace posible.
Dise�o evolutivo. Cuando se divide el sistema en servicios hay que tener en cuenta
que cada uno tiene que poder ser reemplazado o actualizado de forma independiente.
Es decir, tiene que permitir una f�cil evoluci�n. El dise�o del servicio tiene que
ser de tal forma que evite en lo posible que la evoluci�n de los servicios afecte a
sus consumidores.
Integraci�n de servicios
Cuando tratamos con problemas complejos es necesario tratar con el problema de
manejar procesos de negocio que involucran a varios servicios. Hay dos formas de
abordar este tipo de problemas: Orquestaci�n y coreograf�a.3?2?

Con orquestaci�n lo que hacemos es tener un software que gu�e y dirija el proceso,
de forma similar a como lo hace un director de orquesta.3?2?

Con coreograf�a lo que hacemos es dejar que cada parte del sistema realice su
trabajo y se les deja trabajar en los detalles, como hacen los bailarines en un
ballet. Es m�s adaptado a la arquitectura de microservicios que cada servicio sepa
c�mo actuar en cada momento, e interact�e con otros, en lugar de tener a alguien
que los coordine. Por eso para integrar se suele preferir tener coreograf�a.3?2?

Ejemplo
Veamos un ejemplo de un sistema en el que cuando doy de alta un cliente tengo
que:3?2?

Acreditarle una cantidad de puntos de bienvenida en su cuenta de fidelidad.

Enviarle un kit de bienvenida a trav�s del correo postal.
Enviarle un correo electr�nico de bienvenida al cliente.
La estrategia a tomar con un mecanismo de orquestaci�n ser�a que el servicio
cliente contenga la l�gica de control y en la creaci�n este se comunicar�a con el
Banco de puntos de fidelidad, el Servicio de correo postal y el Servicio de correo
electr�nico a trav�s de una serie de llamadas petici�n/respuesta. Por tanto el
Servicio Cliente realiza el seguimiento de las tareas y sabe si el proceso se ha
completado sin problemas. El problema de este enfoque es que el Servicio de Cliente
se puede convertir en una autoridad de gobierno central demasiado fuerte donde toda
la l�gica gira alrededor de �l.3?2?

La estrategia a tomar con un mecanismo de coreograf�a ser�a informar a cada parte

del sistema de su trabajo, y dejarlos trabajar en los detalles, como los bailarines
en un ballet que se encuentran en su camino y reaccionan ante otros a su alrededor.
Para ello el servicio cliente emitir�a un mensaje asincr�nico cuando se crea un
cliente. As� el Servicio de Correo Electr�nico, el Servicio Postal, y el Banco de
puntos de Fidelidad, solo es necesario que se suscriban a esos eventos y reaccionar
en consecuencia. Si alg�n otro servicio necesita llegar a la creaci�n de un nuevo
cliente, simplemente tiene que subscribirse a los eventos y hacer su trabajo cuando
sea necesario. Este dise�o implica que se necesita de trabajo adicional para
asegurarnos de que se han sucedido las cosas correctas. Por ejemplo, saber si el
banco de puntos de fidelidad tuvo un error y por alguna raz�n no estableci�
correctamente los puntos. Para solucionar este problema, normalmente es necesario
crear un sistema de monitoreo que refleje expl�citamente la vista del proceso de
negocio, y a su vez, haga un seguimiento de lo que cada uno de los servicios
realiza como entidad independiente que le permite ver excepciones mapeadas al flujo
de proceso m�s expl�cito.

En general, los sistemas que utilizan el enfoque del tipo coreograf�a, est�n
d�bilmente acoplados, son m�s flexibles y m�s susceptibles de cambiar. Sin embargo,
es necesario realizar el trabajo extra de monitorear y seguir los procesos a trav�s
de los l�mites del sistema.3?2?

Cr�ticas
El enfoque de microservicios esta sujeto a cr�ticas por una serie de problemas:

Los servicios forman barreras de informaci�n.4?

Los mensajes entre servicios sobre la misma red tienen un costo mayor en t�rminos
de latencia y tiempo de procesamiento de mensajes comparado con un proceso de
servidor monol�tico.5?
Las pruebas y el despliegue son m�s complicados en el modelo de microservicios.6?
Mover responsabilidades entre servicios es dif�cil. Puede requerir comunicaci�n
entre distintos equipos, reescribir funcionalidades en diferentes lenguajes o
cambiar la funcionalidad para que funcione en otra infraestructura.5?
Contemplar el tama�o de los servicios como el principal mecanismo de estructuraci�n
puede llevar a utilizar demasiados servicios cuando una estr�ctura de
modularizaci�n interna puede llevar a un dise�o m�s simple.7?
Carga cognitiva
La arquitectura introduce complejidad adicional y nuevos problemas a resolver, como
latencia en la red, formato de los mensajes, balanceo de carga y tolerancia a
fallas.8?6?

Una aplicaci�n compuesta por un n�mero de microservicios tiene que acceder a su

propio ecosistema, lo que puede crear complejidad innecesaria.9? Este tipo de
complejidad puede reducirse estandarizando el mecanismo de acceso. La Web,
considerada como un sistema, estandariz� el mecanismo de acceso a trav�s de
mantener el mismo sistema de acceso entre el navegador y los recursos de aplicaci�n
sobre los �ltimos 20 a�os. Utilizando el n�mero de sitios web indexados por Google,
se creci� desde 26 millones de p�ginas en 1998 a alrededor de 60 trillones de
p�ginas individuales en 2015 sin necesitar cambiar el mecanismo de acceso. La Web
en s� misma es un ejemplo de c�mo la complejidad inherente a un sistema tradicional
de software monol�tico puede superarse.10?11?

Referencias
Microservices a definition of this new architectural term. Martin Fowler 2014
Building microservices. Designing fine-grained systems. Sam Newman. O�Reilly 2015
Microservicios Parte II. Sergio Maurenzi. 13 de abril de 2015.
Jan Stenberg (11 de agosto de 2014). �Experiences from Failing with
Microservices�.
Martin Fowler. �Microservices�.
�Developing Microservices for PaaS with Spring and Cloud Foundry�.
Tilkov, Stefan (17 de noviembre de 2014). �How small should your microservice be?
�. innoq.com. Consultado el 4 de enero de 2017.
Pautasso, Cesare (2017). �Microservices in Practice, Part 2: Service Integration
and Sustainability�. IEEE Software 34 (2): 97-104. doi:10.1109/MS.2017.56.
�BRASS Building Resource Adaptive Software Systems�. U.S. Government. DARPA. 7 de
abril de 2015. "Access to system components and the interfaces between clients and
their applications, however, are mediated via a number of often unrelated
mechanisms, including informally documented application programming interfaces
(APIs), idiosyncratic foreign function interfaces, complex ill-understood model
definitions, or ad hoc data formats. These mechanisms usually provide only partial
and incomplete understanding of the semantics of the components themselves. In the
presence of such complexity, it is not surprising that applications typically bake-
in many assumptions about the expected behavior of the ecosystem they interact
with."
Alpert, Jesse; Hajaj, Nissan. �We knew the web was big�. Official Google Blog.
Google.com. Consultado el 22 de agosto de 2015.
�The Story�. How search works. Google.com. Consultado el 22 de agosto de 2015.