Microservices.

Microservices con
WSO2

Julio Cejas
Arquitecto Chakray

El objetivo de este documento es describir como el enfoque ,

Microservicios, denominado “SOA ligero” puede ser implementado
mediante el WSO2 Lean Enterprise Middleware.
 Índice

Introducción 3

Una pequeña historia 4

Que es un Microservice 5

Sobre las Aplicaciones Monolíticas 6

Microservices y un API Gateway 7

Microservices en WSO2 8

Patrón WSO2 ESB como API Gateway Microservice 8

Patrón WSO2 ESB como Message Gateway Microservice 9

Patrón WSO2 ESB como API Gateway y Message Gateway 10

Patrón WSO2 Stack y soporte WS-Eventing para Microservice 11

Patron WSO2 Gateway con WSO2 GW para Microservices 12

Patrón WSO2 Microservice con WSO2 MSS 13

Patrones Generales WSO2 Microservices sobre ESB 15

WSO2 Microservices y el Fracaso Parcial 15

WSO2 Microservices y Timeouts 16
WSO2 Microservices Bulkheads 17
WSO2 Microservices y Cache 17
WSO2 Microservices y la Distribución de Carga 17
WSO2 Microservices y descubrimiento de Endpoints 17
WSO2 Microservices Contenedores 17
WSO2 Microservices Máquinas Virtuales 18
WSO2 Microservices Monitoreo y Análisis de Datos 18

Recomendaciones Generales 18

En esencia 19

Sobr el autor 20

www.chakray.com 2
 Introducción

Actualmente los microservicios (microservices en inglés), han estado

irrumpiendo dentro de la disciplina SOA por su enfoque pragmático, ágil; y
su ajustado enfoque al negocio y no en la tecnología. El objetivo de este do-
cumento es describir como este enfoque denominado “SOA ligero” puede
ser implementado mediante el WSO2 Lean Enterprise Middleware. En las
siguientes secciones realizaré una pequeña inmersión en el concepto de mi-
croservice, algunas reflexiones y conclusiones.

www.chakray.com 3
 Una pequeña historia

Generalmente cuando iniciamos proyectos de software de gran envergadura comenzamos

con la identificación del vocabulario asociado a un determinando contexto o dominio, los
convertimos en un modelo de información y abordamos sus relaciones posteriormente. Es
muy común tener un modelo de dominio realmente grande que posteriormente es realiza-
do mediante un modelo relacional de base de datos. Sobre este modelo, se plantean todas
las necesidades de información, relaciones, persistencia y servicios. En la medida que crece
este modelo se generan problemas en el mantenimiento de sus relaciones, dependencias,
rendimiento y capacidades de cambio; sobre todo cuando crecen las demandas del siste-
ma y la existencia de nuevos requisitos. Generalmente si desarrollamos un servicio para
obtener el detalle de una factura, utilizamos un modelo subyacente con muchas relaciones
a otras tablas; sobre este modelo se establecen muchas dependencias; fácilmente recono-
cibles cuando un cambio pequeño en un atributo de una tabla implica el cambio de muchos
artefactos de software, o bajar y subir toda una solución; en esencia un cambio pequeño
impacta a toda la solución.

Por años se ha abordado el desarrollo de software con este enfoque estándar: el estable-

cimiento de un modelo de dominio que represente el vocabulario de un negocio y sus re-
laciones; representándola en toda su extensión. Microservice viene a plantear un enfoque
distinto.

www.chakray.com 4
 Que es un Microservice

En esencia, un microservice es un artefacto de software que está diseñado para evitar que
dependa de un modelo de relaciones extenso y pesado; el cual debe cumplir con una fun-
ción de negocio concreta; además de contar con una implementación simple y pensada en
la integración con otros. Su objetivo es propiciar el desarrollo de componentes individuales
que sean capaces de evolucionar y escalar de forma independiente. En este enfoque, los
contratos se adaptan a las necesidades del negocio y no a un modelo de dominio y/o una
estructura de datos grande y relacional. Su enfoque es evitar la creación de soluciones frá-
giles y complejas.

En el diagrama anterior se puede observar como una aplicación monolítica puede ser di-
vidida en servicios independientes que cumplen con una función concreta de negocio. A
continuación se enumeran las principales características de microservices:

01 Los servicios tiene una responsabilidad micro con un enfoque ajustado al negocio.

02 Viven dentro de un contenedor con un ciclo de vida independiente (ejecutado en su

propio proceso).

03 Son organizados de forma vertical sobre las capacidades de negocio y no de tecnología.

04 Están diseñado bajo el principio de bajo acoplamiento.

www.chakray.com 5
 05 Son desarrollados pensando en la coreografía y no en la orquestación.

06 Son diseñados para soportar el fracaso (tolerante a fallas).

07 Sus modelos de implementación y su gobierno se realizan de forma descentralizada.

08 Sus modelos de implementación no son compartidos, por ejemplo sus modelos de

dominio y el modelo de persistencia son exclusivos e individuales.

09 Se comunican sobre mecanismos ligeros como HTTP o JMS.

10 Crecen individualmente.

11 Pueden ser auto escalados de forma individual.

Sobre las Aplicaciones Monolíticas

El desarrollo de arquitecturas monolíticas seguirá siendo una alternativa para el desa-

rrollo de soluciones y dependerá del grado de distribución, tamaño, necesidades de in-
tegración y mediación de la solución, para optar por una arquitectura microservice. En
esencia, es importante recalcar que no toda solución debe ser abordada bajo un enfoque
de microservices.

Las aplicaciones monolíticas pueden ser

construidas con una modularidad útil, evi-
tando las áreas complejas que los micro-
services introducen en cualquier arquitec-
tura. Si los límites de la solución pueden
ser gestionados, son pequeños y no existe
la necesidad de conformación de una ar-
quitectura distribuida; la solución puede
abordarse bajo estrategias de  aplicaciones
monolíticas.. Inclusive, se puede combinar
una arquitectura monolítica y microservice
aprovechando lo mejor de ambos enfoques.

Una recomendación concreta es comenzar

con una arquitectura monolítica para luego
romperla o dividirla en microservices, con
este enfoque se puede explorar, descubrir
y explotar los límites y extensiones de la so-
lución, estableciendo un mapa de ruta más
sólido para el diseño y arquitectura de mi-
croservices.

www.chakray.com 6
 Microservices y un API Gateway

En arquitecturas basadas en microservice es recomendable la utilización de una puerta

de enlace conocida como API Gateway. La puerta de enlace es responsable de la petición,
encaminamiento, composición y traducción de protocolos. Todas las solicitudes de los
clientes se dirigen primero a la puerta de enlace para luego invocar al microservice apro-
piado. El Gateway a menudo maneja peticiones a múltiples microservices para agregar sus
resultados.

La recomendación general es que los clientes no invoquen directamente los microservices,

sino a través de un Gateway que permita simplificar y ajustar los requerimientos a las ne-
cesidades funcionales y específicas de la aplicación. La puerta de enlace API encapsula la
arquitectura del sistema interno proporcionando una API que se adapte a cada cliente. El
Gateway puede tener otras responsabilidades, como la autenticación, control, distribución
de carga, almacenamiento en caché, manipulación respuestas, entre otros.

El API Gateway proporciona:

01 Un único punto de acceso.

02 Oculta al cliente los detalles asociadas a la invocación de microservices enlazados o

relacionados.

03 Disminuye las solicitudes o invocaciones a servicios a través de la red.

04 Simplifica los clientes proxys de acceso.

05 Proporciona un api personalizado.

www.chakray.com 7
 Microservices en WSO2

WSO2 es un stack maduro que proporciona modelos de implementación flexibles y lige-

ros para soportar las características más importantes y relevantes de microservices. En las
próximas secciones describiré las estrategias y patrones que pueden ser incorporados en
sus iniciativas WSO2 para dar soporte a este enfoque.

Patrón WSO2 ESB como API Gateway Microservice

Un ESB (Enterprise Service Bus) es una infraestructura que puede realizar servicios de
mediación, enrutamiento, enriquecimiento y la incorporación de políticas sobre servicios
web y otros artefactos. Estas características pueden ser utilizadas para implementar un
Gateway para arquitecturas microservices. En esencia, en este patrón, utilizamos el WSO2
ESB y todas sus características para desplegar un Gateway para nuestra plataforma de mi-
croservices.

El WSO2 ESB Gateway puede ofrecer un mecanismo que permita el acceso a microser-
vices individuales desde aplicaciones mediante la conformación de una puerta de enlace,
proporcionando un único punto de entrada para todos los clientes. Este Gateway puede
ser distribuido y soportar alta disponibilidad (HA) y clustering; es importante destacar que
este ESB solo puede ser utilizado para tareas de Gateway. A continuación se enumeran las
funciones que este ESB debe cumplir como Gateway:

01 Aislar a los clientes sobre la lógica de integración, composición, entres los microser-
vicios.

02 Aislar al cliente de la ubicación de microservices.

03 Proporcionar una API óptima para cada cliente.

www.chakray.com 8
 04 Reducir el número de peticiones (ida y vuelta).

05 Simplificar la invocación o llamada a múltiples microservices desde el cliente.

06 Incorporar políticas de cache, autenticación, autorización, entre otros.

07 Exponer APIs adaptadas a las necesidades de los clientes.

WSO2 permite la conformación de un Gateway para arquitecturas basadas en microser-

vices que puede escalar de forma independiente, coordinados y gestionados sobre HA y
clustering; de igual forma pueden ser establecida en contenedores como Docker para ges-
tionar un ciclo de vida independiente y en cluster de contenedores Linux como Kubernetes.

Patrón WSO2 ESB como Message Gateway

Microservice

Utilizando el WSO2 ESB como un Gateway y limitando sus funciones para arquitecturas
microservices, podemos implementar dos tipos de gawatey, uno para APIs y otro para men-
sajes. Una de las características de microservices es su capacidad de comunicación sobre
mecanismos ligeros como HTTP o JMS. Un patrón de diseño recomendado es la conforma-
ción de un Gateway de mensajería que pueda enriquecer e incluir políticas a los mensajes
que son intercambiados entre microservices cuando utilizamos JMS como norma de co-
municación. Sobre este enfoque podemos utilizar un WSO2 ESB como mediador de men-
sajes (messages JMS).

www.chakray.com 9
 Bajo este patrón, podemos utilizar la capacidad del WSO2 ESB para la gestión de storage
de mensajes, utilizando la funcionalidad de Message Stores (Store Mediator) para almace-
nar mensajes de forma temporal. Actualmente el Store mediator puede ser utilizado para
almacenar mensajes en memoria, en jms o implementaciones que pueden ser customiza-
das como la utilización de REDIS, entre otras tecnologías. Otro componente que puede ser
utilizado en este patrón son los message processor, quienes pueden consumir mensajes de
los message stores y procesarlos. En este procesamiento, los mensajes pueden ser envia-
dos a endpoints almacenados y consultados sobre un registro.

WSO2 permite la conformación de un Gateway de mensajería para arquitecturas basadas

en microservices que puedan escalar de forma independiente, coordinados y gestionados
sobre HA y clustering; de igual forma pueden ser establecida en contenedores como Doc-
ker. Es importante destacar que este ESB solo puede ser utilizado para tareas de Gateway
Message.

Patrón WSO2 ESB como API Gateway y Message

Gateway

En la siguiente grafica se puede observar la inclusión de ambos enfoques:

Resumiendo, WSO2 ESB puede ser utilizado como componente para la conformación de
API Gateways y message Gateways; estableciendo un único punto de acceso para arqui-
tecturas basada en microservices. Los gateways pueden desarrollar políticas para la vali-
dación, seguridad, cache, garantía de entrega, tolerancia a fallas, logging, audit, entre otras.
Bajo este enfoque WSO2 ESB asume y desarrolla diversos roles, limitando y estandarizan-
do su función en contextos de arquitectura.

www.chakray.com 10
 Patrón WSO2 Stack y soporte WS-Eventing para
Microservice

WSO2 proporciona la capacidad para desarrollar servicios de datos, decisión y dominio

específico bajos diversos productos de su stack. Los servicios de datos (WSO2 DSS) pue-
den responder a las necesidades de la capa de persistencia y puede comunicarse con otros
servicios mediante una forma independiente y altamente desacoplada basada en el trans-
porte JMS. WSO2 DSS soporta el estándar WS-Eventing que puede ser utilizado para dis-
parar eventos durante la ocurrencia de ciertas condiciones en los datos, tanto en el request
como en su response. El event-trigger contiene una suscripción que cualquier cliente pue-
de utilizar para recibir notificaciones enviadas desde un tópico a una cola de mensajería o
incluso correo electrónico.

En esencia, WSO2 DSS, BRS, AS proporcionan soporte al estándar WS-Eventing, con lo

cual podemos habilitar la comunicación entre servicios de forma asíncrona. Este enfoque
permite que los servicios estén desacoplados utilizando un estilo de comunicación ligero
basado en mensajes por ejemplo JMS. Este enfoque permite por ejemplo establecer en-
dpoints como el siguiente:

jms:/Ordertopic?transport.jms.DestinationType=queue&transport.jms.
ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://localhost:61616&java.naming.
factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.Connection
FactoryType=queue&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory

De igual forma cada servicio de datos puede ser expuesto sobre el transporte JMS. En el
siguiente diagrama se puede observar que pueden ser inyectados al request o response
eventos que pueden ser disparados ante la ocurrencia de un evento, soportada por Xpath y
WS-Eventing. El payload o carga útil puede ser enviada a un topic interno y posteriormente
a un JMS Queue/Topic a través de una suscripción establecida. De igual forma pueden ser
utilizados listener para el envió a otros queues/topics.

Es importante destacar que se recomienda la utilización de una capa Facade(Gateway)

para evitar la proliferación de conexiones punto a punto entre los servicios.

www.chakray.com 11
 Patron WSO2 Gateway con WSO2 GW para
Microservices

WSO2 actualmente se encuentra desarrollando un Gateway más enfocado y dirigido

para el soporte del patrón Facade y microservices. Sobre este escenario, no se utilizaría el
WSO2 ESB (limitando sus funciones) como un Gateway. WSO2 Gateway (WSO2 GW) es
un Gateway de alto rendimiento, una puerta de entrada ligera para mensajes, centrada en
la implementación de patrón Gateway/Facade. Su objetivo es encapsular mensajes entre
sistemas heterogéneos con tecnologías, protocolos y normas diversas.

WSO2 GW será la puerta de enlace de mensajería que servirá de Gateway para productos
como WSO2 Enterprise Service Bus, WSO2 Security Gateway, entre otros.

Entre las características más relevantes:

01 Gateway de alto rendimiento y baja latencia.

02 10 veces más rápido que el transporte HTTP presente actualmente en WSO2 ESB.

03 Soporte de miles de conexiones concurrentes.

04 Enrutamiento basado en Apache Camel y Spring Framework.

05 Balanceo de carga y conmutación por error (Circuit Breaker / Kill Switch).

06 Soporte mejorado para gestión de errores.

07 REST/APIs basadas en DSL Camel RESTful.

08 Estadísticas de enrutamiento a través de JMX.

www.chakray.com 12
 Con este enfoque se podrá establecer servicios RESTfull directamente, por ejemplo:

<rest path=”/iot”>
<get uri=”/dispositivo”>
<to uri=”direct:getDispositivos”/>
</get>
<get uri=”/dispositivo/{id}”>
<to uri=”direct:getDispositivosById”/>
</get>
</rest>

Además, incluirá un modelo de enrutamiento, por ejemplo:

<route>
<from uri=” direct:getDispositivosById “/>
<recipientList>
<simple>iot:http://iot/posts/${header.id}</simple>
</recipientList>
</route>

Patrón WSO2 Microservice con WSO2 MSS

WSO2 se encuentra desarrollando un modelo más aislado del ESB para aquellas imple-
mentaciones que requieran la implementación del paradigma microservice mediante es-
trategias como el Non-blocking IO, procesamiento y programación concurrente basada en
Netty, Patrón Disruptor, Java 8, Programación Reactiva, entre otros; mejorando las limita-
ciones actuales del enfoque ESB y su planteamiento basado en roles. El producto es deno-
minado WSO2 Microservice Server (WSO2 MSS).

www.chakray.com 13
 WSO2 MSS permite la construcción y entrega de aplicaciones orientadas en microservices
sobre servicios REST, ofreciendo una arquitectura de alto rendimiento (tiempo de ejecu-
ción y arranque) y la garantía del bajo consumo de recursos. WSO2 MSS ha incorporado la
gestión de métricas y análisis a través de la integración con WSO2 Data Analytics Server
(WSO2 DAS), que ofrece una solución completa para el análisis de datos. Cada microser-
vice se desarrolla para un solo propósito y es desplegado de forma independiente, lo cual
garantizará su escalabilidad y fiabilidad.

Entre sus características más relevantes:

01 Tiempo de ejecución rápido.

02 Soportado sobre el kernel WSO2 Carbon 5.0.

03 Bajo consumo de memoria.

04 Modelo de desarrollo simple para su implementación y monitoreo.

05 Utilización de WSO2 Developer Studio para su desarrollo, incluye definición de su

API a través de Swagger.

06 Integración con WSO2 Data Analytics Server para análisis de datos.

07 Seguimiento de las solicitudes mediante un identificador único.

08 Transporte basado en Netty 4.0.

09 Seguridad basada en JWT.

10 Soporte de Interceptores personalizados.

11 Soporte a Streaming de entrada y salida.

Con WSO2 MSS ahora se podrá anotar los servicios. Entre las anotaciones más relevantes:

ANOTACIÓN PROPÓSITO

@HTTPMonitoring Anotación que permitirá que el microservice envié la información detallada

de su comportamiento en tiempo de ejecución al WSO2 DAS, por ejemplo:
startNanoTime, serviceName, serviceClass, responseTime, requestSizeBytes,
httpMethod, requestUri, entre otros.

@Metered Anotación que permite establecer una métrica para medir la tasa de eventos
en un tiempo determinado.

@Timed Anotación que permite establecer una métrica para medir la duración de
ejecución de una determinada función de negocio.

@Counted Anotación que permite establecer una métrica para incrementar o

decrementar un contador.

www.chakray.com 14
 Para establecer un microservice:

@Path(“/micro”)
@HTTPMonitoring
public class MicroService { …

@GET
@Path(“/dispositivo/{id}”)
@Metered
public int getDispositivo(@PathParam(“id”) int id) {
return persistence.getDispositivo(id);
}

Para iniciar un microservice, se podrá utilizar:

new MicroservicesRunner()
.deploy(new MicroService())
.start();

Pueden ser colocados interceptores que pueden gestionar políticas de validación, seguri-
dad, métricas entre otros; por ejemplo:

.addInterceptor(new MetricsInterceptor(MetricReporter.CONSOLE,
MetricReporter.JMX, MetricReporter.DAS))

WSO2 MSS esta soportada por las siguientes tecnologías: Carbon server, IO netty, Netty
jaxrs Http, gson, imbusDS Java library; entre otros marcos Open Source. Es importante
destacar que soporta JSON Web Token para la seguridad de servicios REST.

Patrones Generales WSO2 Microservices sobre ESB

WSO2 Microservices y el Fracaso Parcial

Generalmente cuando el Gateway debe componer u orquestar microservices que están
distribuidos este puede enfrentarse a un “fracaso parcial” cuando este invoca un servicio
que responde lentamente o no está disponible. Generalmente el Gateway no puede espe-
rar de forma indefinida a que el servicio envié una respuesta. El Gateway debe decidir si
retornar un error al cliente o proporcionar información parcial a partir de un cache.

WSO2 permite incorporar estrategias para el fracaso parcial y el cache mediante en-
dpoints en WSO2 ESB. Cuando la llamada a un microservice supere un umbral establecido,
se implementa un patrón denominado disyuntor o circuit-breaker, cancelando la espera

www.chakray.com 15
 innecesaria cuando un servicio no esté disponible o no responda. Si la tasa de error para
un servicio supera un umbral especifico, WSO2 puede disparar un interruptor y todas las
peticiones fallarán inmediatamente por un período de tiempo.

Este patrón puede ser implementado mediante la configuración adecuada de endpoints en

el WSO2 ESB. En la siguiente sección, se puede observar una configuración estándar de
Endpoints que permite implementar el patrón circuit-breaker.

<endpoint name=”CircuitBreakerEP”>
<address uri=”http://localhost:9764/app/microservices/call”>
<suspendOnFailure>
<initialDuration>60000</initialDuration>
</suspendOnFailure>
<markForSuspension>
<errorCodes>101507,101508</errorCodes>
<retriesBeforeSuspension>3</retriesBeforeSuspension>
<retryDelay>400</retryDelay>
</markForSuspension>
<timeout>
<duration>300</duration>
<responseAction>fault</responseAction>
</timeout>
</address>
</endpoint>

WSO2 Microservices y Timeouts

WSO2 ESB tiene la capacidad de aislar el acceso a la red utilizando patrones de timeouts.
Su función principal es evitar que el cliente (proxy) que requiere consumir un servicio es-
pere de forma indefinida por la respuesta del servicio proveedor.

Para implementar este patrón, WSO2 ESB proporciona Endpoints; los endpoints propor-
cionan propiedades como la duración del timeout y la acción si el timeout ha superado un
determinado umbral. De igual forma se pueden utilizar secuencias de excepción que pue-
den invocar servicios de cache o responder datos temporales.

En esencia, un endpoint permite la interrupción de forma definitiva cuando ha alcanzado

una taza de timeouts establecida. Este patrón evita que la falla se propague y degrade los
servicios de la solución. En la siguiente sección, se puede observar una configuración es-
tándar de Endpoints que permite implementar el patrón timeout sobre WSO2 ESB.

<endpoint name=”MicroService”>
<address uri=”http://localhost:8267/platform/microservice/func”>
<timeout>
<duration>320</duration>
<responseAction>fault</responseAction>
</timeout>
</address>
</endpoint>

www.chakray.com 16
 WSO2 Microservices Bulkheads
WSO2 ESB permite el establecimiento de estrategias para evitar el fracaso en cascada
mediante endpoints configurados de forma adecuada; pudiendo aislar problemas de red o
servicios sin afectar la arquitectura de la solución. El Bulkheads es un patrón que establece
prácticas para reducir el riesgo de fracaso y así evitar la degradación y sus consecuencias
mediante barreras como la implementación del patrón timeout, retries, circuit-breaker, en-
tre otros.

WSO2 Microservices y Cache

WSO2 ESB permite el establecimiento de cache en memoria o el desarrollo de implemen-
taciones customizables para la utilización de base de datos tradicionales o key-value (Redis
por ejemplo). La puerta de enlace o Gateway puede incluir una barrera para asegurar que
fallos en los sistemas externos afecten la funcionalidad.

WSO2 Microservices y la Distribución de Carga

NGINX es una alternativa escalable para microservices, que proporciona un servidor web
de alto rendimiento, fácil de desplegar, configurar y programar.

WSO2 Microservices y descubrimiento de Endpoints

WSO2 Gateway necesitará conocer la ubicación (dirección IP y puerto) de cada microser-
vice con el que se comunicará; su localización puede realizarse mediante un proceso de
descubrimiento contra un registro (WSO2 Governance Registry), permitiendo que los en-
dpoints puedan establecerse dinámicamente en tiempo de ejecución.

WSO2 Microservices Contenedores

La gestión operativa de microservicios puede convertirse fácilmente en una tarea muy
compleja en la medida que estos van creciendo; para facilitar su administración es reco-
mendable la utilización de contenedores como Docker. Docker es un ambiente virtual ba-
sado en Linux (LinuX Containers) que permite establecer contenedores para los microser-
vices o tecnologías como mysql, nginx, entre otros.

WSO2 Microservices Máquinas Virtuales

Generalmente las plataformas para microservices son virtualizadas mediante tecnologías
VM (virtual machines) como VirtualBox, VMWare, AWS, entre otros. En algunos casos po-
demos tener diversos entornos de virtualización para plataforma de microservices. WSO2
y todo su stack puede ser gestionado sobre ambiente virtualizados, recomendando la uti-
lización de Vagrant para la administración de diversos ambiente virtualizado. Tecnologías
como Puppet y Chef pueden ser utilizados con WSO2 para automatizar la infraestructura
de WSO2 Microservice.

www.chakray.com 17
 WSO2 Microservices Monitoreo y Análisis de Datos
WSO2 ESB y WSO2 MSS permiten la integración con el producto de análisis de datos
WSO2 DAS que soporta análisis batch, en tiempo real, predictivo e interactivo. Con esta
estrategia la capacidad de monitoreo y alertas en plataforma para Microservices es sopor-
tada de forma individual o centralizada.

Recomendaciones Generales

WSO2 ofrece un soporte completo a todo el stack de aspectos necesarios para construir
una plataforma de microservices, proporcionando estrategias concretas y viables a los de-
safíos de implementaciones sobre ambientes distribuidos.

01 Identifique el modelo de arquitectura WSO2 Microservice más ajustado a su solu-

ción.

02 Establezca una estrategia para responder a la latencia y tolerancia a fallas para su

arquitectura de Microservices. Utilice endpoints, y evita la fragilidad en esta área.

03 Establezca un API Gateway y un Messaje Gateway para su arquitectura de microser-

vices.

04 Desarrolle microservices mediante el stack actual de WSO2 o sobre el producto

WSO2 MSS.

05 Establezca un Gateway mediante WSO2 ESB o WSO2 GW.

06 Implemente una estrategia basada en Event Store para publicación y suscrición de

eventos.

07 Incorpore una estrategia de garantía de entrega en su arquitectura de microservice.

08 Framework como vagrant, saboteur, wiremock, hixtrix, cucumber pueden ser combi-
nado para establecer un stack sólido para las pruebas de microservices.

09 Utilice marcos como Docker,  Kubernetes y  Vagrant para simplificar la administra-

ción de contenedores y máquinas virtuales.

www.chakray.com 18
 En esencia

· Dentro de una arquitectura Microservices el WSO2 ESB puede desarrollar funcio-

nes asociadas a la conformación de un API Gateway y un Message Gateway.

· Los productos del stack WSO2 pueden utilizar el estándar ws-eventing para estable-
cer mecanismos de comunicación desacoplados y ligeros basados en HTTP o JMS.

· Los microservices pueden ser implementados sobre plataformas como WSO2 DSS,
BRS, AS dentro de un contenedor con un ciclo de vida independiente (ejecutado en
su propio proceso), por ejemplo Docker.

· Todos los microservicios sobre WSO2 pueden ser desplegados en un Cluster y HA

sobre servicios de contenedores como Docker y Kubernetes para su administración.

· Los microservices pueden ser desplegados como un war en contenedores como Jetty
o Tomcat e incluir el descubrimiento de servicios mediante un registro (WSO2 GR).

· Los microservices en WSO2 pueden ser soportados por bundels  OSGi.

· Patrones de tolerancia a falla como timeout y circuit-breaker puede ser implementa-

dos mediante endpoints en el Gateway (WSO2 ESB o WSO2 GW).

· El WSO2 ESB Gateway puede inyectar políticas de cache, seguridad, logging, audit,
validación, garantía de entrega, entre otros.

· La plataforma WSO2 ya incluye microservices especializados en servicios de gestión

de identidades para autenticación y autorización.

· Cada servicio es AutoMonitoreable, es decir informa constantemente su estado en

tiempo de ejecución.

· Cada servicio cuenta con un dashboard que permite ver su comportamiento en

tiempo de ejecución de forma individual.

· Si es necesaria la integración de indicadores del comportamiento de servicios en

tiempo de ejecución, estos pueden ser configurados utilizando eventos que pueden
enriquecer una plataforma WSO2 DAS.

· Cada servicio puede contar con aspectos de logging, auditoria, excepciones de forma
independiente o estos pueden ser inyectados dentro de un servicio Gateway (ESB o
servicios sobre un servidor de aplicaciones).

· OSGI es la base de WSO2, proporcionando  servicios con interfaces uniformes como

la forma primaria de encapsulación.

WSO2 es un stack Open Source que puede ser utilizado para implementar  en toda su
extensión una arquitectura de MicroService. Espero que estos modelos de implemen-
tación y recomendaciones fortalezcan su iniciativa y proporcionen una arquitectura más
sólida, ágil y flexible.

www.chakray.com 19
 ¡Muchas gracias!
Sobre el autor:

Julio Cejas
Arquitecto Chakray / julio.cejas@chakray.com

Especialista con más de 15 años de experiencia como Consultor y Arquitecto

en la construcción de Sistemas Críticos basados en productos free y open
source. Combina su experiencia en Computer Security y su pasión tecnolo-
gía free y opensource para construir disruptive solutions.

¿Quieres dominar WSO2 Microservices?

Conoce nuestro curso “WSO2 Microservices fundamentos para
desarrolladores” y especializate en la mayor tendencia del sector.

SABER MÁS

www.chakray.com 20
 info@chakray.com www.chakray.com

www.chakray.com 21