MuleSoft y la Arquitectura Orientada a Microservicios (MSA)

MuleSoft y la Arquitectura Orientada a Microservicios (MSA)
Panama City
13/10/2018

All contents © MuleSoft Inc.
Agenda
2
➢ Definición, características, ventajas, desventajas, gobierno, Microservicios vs
Arquitecturas Monolíticas
➢ Estructura, variaciones, patrones, Microservicios vs APIs, mejores prácticas
➢ Coffee break + Networking
➢ Casos de éxito: HSBC, Bank of America
➢ Caso de éxito de Mulesoft en Panamá (Adopción MuleSoft): SuperXtra
➢ ¿Qué viene a continuación?
➢ Networking
➢ Q&A

¿Cómo se construía software?
➢ Anteriormente, las soluciones de software se
construían como un gran bloque.
➢ La aplicación contenía prácticamente todo lo que
necesitaba para su funcionamiento. Se solía usar
arquitectura de capas dentro de la herramienta.
➢ Cada funcionalidad nueva se iba agregando al
código fuente de la solución y se entregaba una
nueva versión de TODA la herramienta.
➢ Los equipos muchas veces tenían que modificar
código que no conocían o dominaban.
➢ Con el tiempo, estas soluciones terminan siendo
muy difíciles de manejar, evolucionar, cambiar y
mantener.
4

¿Cómo se construía software?
5
➢ La solución suele NO ser reutilizable debido a que se construyó pensando en las necesidades
de acceso actuales y, con el tiempo, no se adapta a las nuevas necesidades del negocio.
➢ Se suele terminar duplicando muchas veces la misma lógica para atender nuevas necesidades.
➢ Re-trabajo = Tiempos de respuesta muy lentos para el negocio.

Este enfoque no está funcionando!
➢ Los clientes son cada vez más exigentes y tienden a dejar de lado lo que tarda demasiado en
evolucionar y dar respuesta a sus necesidades.
➢ Todas las organizaciones, sin importar su industria, deben enfocarse en entregar la mejor
experiencia al usuario en el menor tiempo posible.
➢ Para lograr esto, los departamentos de arquitectura deben poder identificar los activos
digitales reutilizables que se alineen y, juntos, modelen el "core" del negocio.
➢ Cada componente debe ser responsable de tareas discretas y altamente definidas.
➢ Estos activos, deben poder ser orquestados con facilidad para lograr nuevas funcionalidades
en menos tiempo. También deben contar con un ciclo de vida de software propio
independiente al del resto de los componentes de la solución.
6

Microservicios
7
➢ La Arquitectura Orientada a Microservicios
(MSA) es un enfoque que busca dividir grandes
proyectos de software en módulos más pequeños,
independientes y poco compactos.
➢ Los módulos individuales son responsables de tareas
discretas y altamente definidas y se comunican con
otros módulos a través de API simples y
universalmente accesibles.
➢ Los microservicios son la evolución de las mejores
prácticas de los principios de arquitectura que
entregan solución al negocio en forma de servicios
(SOA).
➢ Los microservicios agregan valor a las organizaciones
al poder ser utilizados en múltiples contextos.

Características de los Microservicios
8
➢ Se basan en el concepto de servicios livianos y autocontenidos.
➢ Representan funcionalidades de negocios (Business Capabilities).
➢ Se comunican a través de mecanismos livianos.
– Típicamente HTTP (APIs REST).
– Mensajería de cola
➢ Desplegables de manera independiente y automatizada.
➢ Basados en arquitectura distribuida.
➢ Herramientas livianas de monitoreo.
➢ Suelen proveer un único servicio y lo ejecutan bien (Principio KISS).
➢ Crecen mediante escalamiento horizontal.
Ejemplo!

Microservicios vs. SOA
10
➢ Muchas organizaciones creen que SOA ha muerto.
– Esto no es cierto, simplemente evolucionó.
➢ En los microservicios, se hace una transición desde un middleware pesado y monolítico a un
modelo liviano y distribuido.
– Hoy en días los principales proveedores de este tipo de herramientas evitan mencionar ESB porque
recuerda al modelo anterior de SOA.
➢ SOA no es sólo WSDLs, UDDI, SOAP y WS-*. Muchos de sus conceptos son igualmente válidos dentro de las
arquitectura de software modernas.
➢ Muchas organizaciones con un buen modelo de servicios implementado tienen un gran camino avanzado en
cuanto a modernización y exposición de sus procesos de negocio.
➢ Los microservicios toman muchos principios de SOA pero le dan un enfoque distinto en cuanto a diseño y
gestión.

Microservicios vs. SOA
11
Monolítico SOA Microservicios

Principios de los microservicios
12
➢ Descomposición Funcional.
➢ Diseño orientado a dominio principalmente (DDD).
➢ Principio de responsabilidad única (SRP).
➢ Interfaces bien definidas y debidamente expuestas.
➢ Cada servicio es totalmente autónomo y contiene todo lo necesario para su funcionamiento.
➢ Se prefiere la coreografía a la orquestación de servicios.
➢ Bajo acoplamiento y alta cohesión.
➢ Un mismo equipo suele estar a cargo desde la construcción hasta la puesta en producción y
mantenimiento del componente.
➢ Enfoque API-First.

Ventajas de los microservicios

14
➢ Una buena arquitectura de microservicios se alinea con el negocio de manera que los
cambios en la organización pueden hacer de una manera más ágil y eficiente.
➢ Procesos de negocios y transacciones pueden automatizarse a través de la composición de
microservicios.
➢ Cuando se introduce un nuevo proceso, TI puede responder desarrollando sólo lo nuevo y
orquestando microservicios ya existentes. (Mayor facilidad y velocidad en respuesta a los
cambios).
➢ Las organizaciones pueden entregar soluciones al negocio en forma descentralizada y
reutilizable a través de los APIs de cada microservicio.
➢ Al manejarse en una arquitectura distribuida, los microservicios tiene la flexibilidad de poder
elegir "La mejor herramienta para el trabajo" (Tanto en software como en hardware) y así
sacar el máximo provecho del proceso modelado.

15
➢ Les da a los desarrolladores la libertad de construir y desplegar servicios de manera
independiente en equipos pequeños.
➢ Se alinean mejor al modelo ágil de desarrollo de software.
➢ Integraciones más sencillas y despliegues automatizados.
➢ Son más fácil de entender y modificar: Permite a los nuevos miembros del equipo ser
productivos más rápido.
➢ Se puede hacer uso de las últimas tecnologías más rápido.
➢ Mejor aislamiento de fallos: Si un servicio falla, el resto sigue funcionando.
➢ No se tiene un compromiso a largo plazo con grandes stacks de tecnología: Puedes ir
cambiando progresivamente sin impactar en exceso a la organización.

Desventajas de los microservicios

Desventajas de los microservicios
17
➢ Debido a su enfoque de arquitectura distribuida, hacer pruebas completas de los procesos
suele ser más complicado y tedioso.
➢ La arquitectura de microservicios trae consigo un extra de complejidad:
– Se deben construir de manera tolerante a fallos.
– Se debe contemplar elementos como la latencia de red.
– Hay que considerar desde el diseño cosas como el balanceo de carga en los llamados.
➢ Cuando existe una gran cantidad de servicios, la integración y gestión de los mismos suele
tornarse complicada sin las herramientas adecuadas.
➢ Sin el control adecuado, puede resultar en muchos esfuerzos duplicados en la organización.
➢ El manejo de casos de uso que requieren transaccionalidad en la orquestación de más de un
servicio no sólo es complejo. También requiere un alto grado de cooperación entre equipos.
➢ Particionar una aplicación en microservicios es en sí complejo.

➢ Los microservicios requieren de equipos (tanto de desarrollo como de infraestructura) muy
bien disciplinados y que dominen muchas herramientas y tecnologías.
➢ Se requiere un alto grado de madurez en estrategias de integración continua.
➢ Cultura de DevOps.
➢ El código debe mantenerse siempre sencillo de leer y mantener.
➢ La "Testabilidad" del servicio toma importancia crítica.
➢ Los APIs que se exponen deben estar muy bien documentados para su fácil descubrimiento y
posible reutilización.
➢ La gestión y control de muchos componentes suele ser compleja sin las herramientas
adecuadas.
Retos en los microservicios
19

➢ Cada microservicio requiere:
– Diseño
– Políticas de delivery
– Políticas de escalamiento
– Definición de dependencias
– Monitorización
– Repositorio de control de versiones
– Logging
– Scripts automatizados para construcción rápida
➢ Detección y seguimiento de errores más complejo
➢ Logging, Monitoreo, Seguridad y Trazabilidad distribuida
➢ Tolerancia a fallos
➢ Manejo más complejo de balanceo de carga en el escalamiento de los servicios
Retos en los microservicios
20

Alternativas de software para apalancar la MSA
21
Edge Server
Service Discovery
Monitoring
Lightweight Messaging
Distributed Tracing
Config Management

Microservicios al estilo MuleSoft

Protocolos y lógica de conexión:
MQ, Conectores de base de datos,
SOAP, HTTP, Polling, Conectores para
SaaS, Archivos, FTP..
Flujos con lógica de negocios:
● Enrutamiento
● Transformación de datos
● Procesamiento en paralelo
● Agregación
● Separación
Mule Runtime
Microservicios al estilo Mulesoft
23
API (Contrato)
Lógica de negocio
Lógica de conectividad
Archivo desplegable de
Mule (.jar)
Especificación del API: (RAML, OAS):
● Recursos
● Operaciones
● Propiedades reutilizables
● (Cacheable, Sortable, Etc.)
● Tipos de recursos
(Reutilización).

Tipos en los microservicios
24
Lógica de negocio
Integración
Conectividad
Lógica de negocio
Integración
Conectividad
Microservicio de negocios Microservicio de conectividad
Típico pensamiento de un microservicio!

Cómo las organizaciones ven los microservicios
25

Cómo son realmente
26

API-Led Connectivity

Mulesoft en el ciclo de vida de MSA
28

Anypoint Runtime Fabric
30
Anypoint Runtime Fabric es un servicio de orquestación
y automatización de despliegues de instancias de Mule en
contenedores en las principales nubes o en servidores
On-Prem.
➢ Despliega instancias de Mule de manera consistente
entre Azure, AWS y tus propios centros de datos.
➢ Despliega versiones diferentes de Mule en una misma
fábrica.
➢ No se necesitan equipos para administrar las
instancias en cada nube.

Anypoint Runtime Fabric
➢ Escala horizontalmente y re-despliega de
manera casi inmediata.
➢ Gestiona despliegues en varias nubes de
manera centralizada desde la Anypoint
Platform.
➢ No son necesarios grandes
conocimientos en herramientas como
Docker y Kubernetes. Anypoint
Runtime Fabric gestiona esa
complejidad por ti!

Microservicios con Anypoint Runtime Fabric
32
Contenedor Docker
JVM
Mule Runtime
API (Contrato)
Lógica
Conectividad
Contenedor Docker
JVM
Mule Runtime
API (Contrato)
Lógica
Conectividad
Kubernetes

MuleSoft y Patrones de
Arquitectura de Microservicios

Patrones de Arquitectura de Microservicios
34

SOA Granularidad fina
35
• Big Bang
• Netflix
• Los mismos principios que
SOA
• Piezas pequeñas
• Mayor consumo de red
• Administración y monitoreo
complejos
• Se hace necesario
orquestar
• Habilidad para cambiar
rapidamente
• Flexibilidad
• Complejidad en cambios
sobre servicios de grano
grueso
Inicios - Características Problemas
Divida los servicios en piezas de
grano más fino, lo que reduce el
alcance de cualquier cambio
dado, lo que permite que suceda
con mayor facilidad
Soluciones

SOA Granularidad fina
Enviar Remesa
Consulttar Costos Obtener Campos Enviar Confirmar
Reversar

SOA Granularidad fina sobre Capas de APIs
37
• API-led connectivity –
Coexistencia
• Evolución
• Aporta estructura – orden
• Multiples llamados a través
de las capas
• Buen patron para muchas
empresas
• Escalabilidad
• Enfoque en el proposito
Las arquitecturas de
microservicios sin cierta cantidad
de estructura son difíciles de
racionalizar y razonar, ya que no
hay una forma obvia de
categorizar y visualizar el
propósito de cada microservicio
Al crear capas de microservicios
que se agrupan por propósito
(sistemas, procesos o modelos
de dominio y experiencia), puede
administrar la complejidad de la
arquitectura más fácilmente
Soluciones

Administración de estado orientado a mensajes
sobre Capas de APIs
38
• Primer patrón
implementado con la mayor
confiabilidad
• Colas Asíncronas como
mecanismo de
comunicación
• Equipos con experiencia en
SOA – ESB.
• Inicial – Transitorio
• Cuando se produce un
cambio en los datos, se
envía como un mensaje a
través de una cola o ESB a
cualquier otro microservicio
o tienda que deba ser
notificado del cambio
Para garantizar la integridad de
los datos, es necesario replicar el
estado de los datos
empresariales clave entre
microservicios o almacenes de
datos
El uso de una cola de mensajes
permite que el estado se envíe
de forma asíncrona y confiable a
diferentes ubicaciones
Soluciones

Administración de estado orientado a eventos
sobre Capas de APIs
39
• Mule ESB - SEDA
• Queues
• Eventos: algo que ocurrio
con un estado y timestamp
• Preferible a orientación a
mensajes
• Cuando algo cambia en el
negocio, un evento que lo
encapsula en tiempo
pasado se envía a las
partes interesadas. Los
cambios en el negocio son
el producto de estos
eventos que se envían y
procesan.
• Eficiente - Escalable
Para garantizar la integridad de
los datos, es necesario replicar
eventos de negocio claves para
sincronizar entre microservicios o
almacenes de datos.
Utilice una abstracción de
eventos común para representar
la unidad de cambio en la
arquitectura.
Soluciones

Aislamiento de estado sobre Capas de APIs
40
• Cada Microservicio contiene
su propio estado
• Almacen de datos interno –
Actualización constante
• Fuente única de la verdad –
Administración de datos
maestros – practico
• La única forma de consultar
o actualizar ese concepto
en la organización.
• Escalable – Flexible –
sencilla – Rapidez en el
cambio
Es difícil lograr la integridad de
los datos cuando existen
múltiples fuentes de verdad.
Nomine un microservicio que
represente la única fuente de
verdad para cada entidad de
negocios dada, y encapsule el
estado dentro del microservicio.
Soluciones

Aislamiento de estado sobre Capas de APIs
41
TimeZones
Microservice
TimeZones
DB
Proceso de
sincronización
IANA

Replicación de estado sobre Capas de APIs
42
• El estado de replicación es
esencialmente el antídoto a
los problemas que surgen
del estado de aislamiento;
específicamente, se
requiere esa consistencia
• Catálogos, precios y
monedas
• Replicar el estado a un
único lugar donde cada
microservicio aislado puede
actualizar su estado
• Event Sourcing
• Escalable – Dependencias -
Sencilla – Rapidez en el
cambio
Es difícil lograr la integridad de
los datos cuando existen
múltiples fuentes de verdad..
Mantenga una única fuente de la
verdad de todos los cambios en
los datos, y replique los datos
según sea necesario..
Soluciones

Recomendaciones aplicables para Arquitecturas de
Microservicios
43
a
• Uso inteligente de valores predeterminados
• Administración directorios y archivos temporales
• Usar circuit Breakers
• Timeouts
• Implementar HealthZ

Patrones de integración aplicados en Microservicios
44

Patrones - Resultados
45
Sin aplicar patrones
Aplicando patrones

Mejores Prácticas aplicables a
Microservicios

Mejores prácticas aplicables a Microservicios
47
a
• Usar API – Led connectivity
• Definir el equipo y las responsabilidades
• Facil de publicar – entregas continuas CI/CD
• Enfoque en la reutilización
• Evitar crear soluciones arquitecturales monolíticas y
distribuidas

Mejores prácticas aplicables a Microservicios
48
a
• Habilitar autoservicios – Anypoint Exchange – API Portal
• Contenedores – Runtime Fabric
• Evitar la desorganización

Microservicios – Patrones – Mejores prácticas
49
“El desafío para las organizaciones es comprender cómo
construirán y aprovecharán su arquitectura de microservicio”
Ross Mason

Un vistazo a HSBC: un banco de 150 años
51
3.900 oficinas
Oficinas con presencia
global en 67 países
38 millones
De clients a nivel mundial
223mil
Como fuerza de
colaboradores alrededor
del mundo
51,1 Billones de USD
De ingresos annual durante
2017
World Best Bank
Ganando el premio a la
excelencia de Euromoney 2017

HSBC: La Transformación
52
... Y necesitaban integrar la
experencia a través de todos los
canales

Organizaciones tradicionales
53
En las organizaciones tradicionales
Mentalidad está centrada en el product o en el canal
• Silos organizacionales
• Sistemas y datos duplicados
• Procesos separados por
productos y/o por canal

Modelo de descomposición
54
Tienes esto Negocio quiere estoRespondemos esto

Una plataforma digital es el puente para el nuevo modelo operacional
55
Desde una organización tradicionales
Mentalidad está centrada en el product o en el canal
Hacia una organización digital
Mentalidad centrada en entregar valor al negocio y
la organización

HSBC con Mulesoft construyó su plataforma digital
56
Tienes esto Respondemos esto

Apps de HSBC ganan premios de Fintech
57

El camino de HSBC
58
Inician desarrollando APIs para
exponer funcionalidades y data de su
portafolio de más de 7.000
aplicaciones priorizando los sistemas
de productos como tarjetas, hipotecas,
pagos.
Con acceso a más de 4.000 System
APIs, las líneas de negocio diseñaron
nuevos servicios para impulsar sus
necesidades de negocio y ofrecer
mayor valor y experiencias únicas.
Produciendo servicios compuestos.
HSBC con un enfoque basado en
API, pasó de lanzar de 12
funciones nuevas por ciclo de
lanzamiento a cientos de funciones
nuevas por mes.
HSBC simplemente accionó el
interruptor en el Gateway, para
exponer los activos externamente, lo
que impulsó la reutilización de los
activos que ya había entregado.

Arquitectura de HSBC
59

Bank of America
60
Una de las principales instituciones financieras
del mundo que atiende a 47 millones de
consumidores y pequeñas empresas
MuleSoft ha permitido a Bank of America mejorar su relación de gastos a
ingresos y construir una plataforma global para impulsar la innovación a
velocidades de entrega de proyectos 4 veces más rápidas.
Los esfuerzos de Bank of America (BofA) para mejorar su relación entre gastos e ingresos a
través de la transformación de su capacidad de administración y entrega de software fue
clave para su éxito futuro.
Para cerrar esta brecha de entrega, BofA eligió a MuleSoft para soportar un cambio
dramático en el modelo operativo de TI, creando una red de aplicaciones de más de
500 aplicaciones conectadas a través de activos de API reutilizables. Este enfoque ha
permitido que los equipos más pequeños, que innovan más rápida y los modelos de
desarrollo federados resulten en un aumento 4x en la velocidad de entrega del proyecto.
Acelerar la innovación y aumentar la eficiencia operativa.
4 veces más rápido
“Bank of America considera a MuleSoft como un
socio estratégico que se integrará
globalmente en las aplicaciones más críticas
del banco, estandarizando la forma en que
nos integramos interna y externamente con
proveedores y clientes.”
- Patrick Ikhifa, SVP, Bank of America

BofA: Arquitectura de Microservicios
61

Buil + CI/CD + Runtime de BofA
62

Implementación de MULE
Casos de éxito en Supermercados Xtra
Octubre 2018

Agenda
Introducción de Supermercados Xtra
¿Por qué decidimos usar MULE?
Casos de éxito usando MULE
• Proceso de emisión de órdenes de compra
• Campaña de actualización de datos de clientes

¿Por qué decidimos usar Mule?
• Provee una serie de conectores listos para usarse
• Transformación de datos de manera dinámica usando estándares
como XSLT, XML, XPath.
• Fácil crecimiento desde la perspectiva de infraestructura.
• El costo es un poco más bajo que otras herramientas del mercado.
• Buen equipo de soporte desde Argentina y Estados Unidos.
• Experiencia previa en el uso de la herramienta.

Mule en Supermercados Xtra
Utilizamos la versión Cloud ¿por qué
Desde una misma interfaz se puede administrar los aplicativos e identificar el estado
de cada uno de ellos.
1

10/12/2018Nombre del documento67
Flexibilidad de publicación bajo diferentes Runtime2

Facilidad de acceso a los logs de las aplicaciones3
Nuevos esquemas para la implementación de tareas automáticas4

Estamos informados a tiempo respecto a los errores e incidentes que presente la
plataforma o algún aplicativo.
5

Sencilla administración de usuarios6

Agenda
Introducción de Supermercados Xtra
¿Por qué decidimos usar MULE?
Casos de éxito usando MULE
• Proceso de emisión de órdenes de compra
• Campaña de actualización de datos de clientes

Emisión de Ordenes de Compra - Proceso Actual
El proceso de emisión de ordenes de compra es crítico para la empresa dado a que
constituye uno de los pilares para el abastecimiento de las tiendas. El proceso se
desarrolla manualmente y puede demorar un par de días.
SuperXtraProveedo
r
Verificar abastecimiento
& generar O/C
Imprimir
escanear O/C
Enviar vía correo o en físico
a través de mensajería
22
Tiendas
Recibir O/C Transcribir
O/C en su sistema
Despacho
Orden de entrega

Emisión de Ordenes de Compra – Nuevo Proceso
El nuevo proceso es completamente automatizado, utilizamos MULE para enviar el
mensaje al proveedor. Todo el proceso demora sólo unos minutos.
SuperXtraProveedo
r 22
Tiendas
O/C registrada
en su sistema
Despacho
Orden de entrega
Generar automáticamente
IDOC con la O/C
Procesar IDOC
y generar XML
Envío O/C al
proveedor

¿Qué Obtenemos con el nuevo proceso?
• Gestión de personal
• Costos operativos
• Abastecimiento de las tiendas
Áreas de impacto
Mejorar la experiencia
del cliente

Se captura el archivo IDOC alojado en una carpeta
compartida en un servidor Windows.
Descripción general del flujo
1
Conector utilizado
Se captura la información del IDOC y se almacena en
variables
(Intermediate Document – IDOC)
2
Listado de variables
Desde la perspectiva técnica el nuevo proceso desarrollado en MULE se resume en 8
grandes acciones:

Se mapean las variables al formato XML
aceptado por el proveedor
3
Se invoca el Servicio Web del proveedor para la creación
de una orden de compra
4
Al obtener la respuesta se almacena en una base de datos
para controles de auditoría
5
Conector utilizado
grandes acciones:

Se valida la respuesta emitida por el servicio Web del
proveedor
6
Si la respuesta es satisfactoria se elimina el archivo de la
carpeta compartido
7
Si la respuesta no es satisfactoria se envía un correo
electrónico al área de abastecimiento indicando la
situación
8
Conector utilizado
grandes acciones:

Campaña de actualización de datos de clientes
Hemos desarrollado un conjunto de servicios Web para gestionar información de
nuestros clientes, apoyando iniciativas comerciales.
Corte realizado el 11 de Octubre

Campaña de actualización de datos de clientes
MÉTODOS:
/getCustomer
/createCustomer
/updateCustomer
/getCustomerBalance
/getCardBalance
Arquitectura general de nuestros servicios
Todos los servicios se
construyen a partir de un
modelo ontológico que define
las entidades de negocio
Siguiendo las mejores prácticas hemos desarrollado una arquitectura de varios niveles:

https://play.kahoot.it/#/k/fa76ac70-3af1-44e1-9418-2aa27d9bf192

¿Qué viene a continuación?
82
• Comparte:
– Publica tus fotos con el hashtag #MuleSoftMeetup
– Invita a tus compañeros a unirse al programa:
https://meetups.mulesoft.com/panama-city/
• Feedback:
– Contacta a los administradores para sugerir temas para próximos eventos.
– Contacta a Mulesoft en meetup@mulesoft.com para recomendaciones al
programa
• Estén atentos a nuestros próximos eventos!

Gracias !!!
Q&A
Respondamos algunas preguntas

MuleSoft y la Arquitectura Orientada a Microservicios (MSA)

MuleSoft y la Arquitectura Orientada a Microservicios (MSA)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a MuleSoft y la Arquitectura Orientada a Microservicios (MSA)

Similar a MuleSoft y la Arquitectura Orientada a Microservicios (MSA) (20)

Más de Larry Magallanes

Más de Larry Magallanes (6)

MuleSoft y la Arquitectura Orientada a Microservicios (MSA)