Pues volvemos de nuevo a la carga con un nuevo meetup donde os vamos a contar cómo podeis optimizar al máximo los recursos que CloudHub nos ofrece como por ejemplo: 1.- Saber dimensionar el número de operaciones por API 2.- Aplicar buenas prácticas para no saturar los recursos 3.- Aprovechar al máximo el 0.1 vCore 4.- Cuando escalar vertical y horizontalmente un API 5.- Utilizar herramientas de análisis de código como Sonar

1. FRANCISCO JAVIER TOSCANO LOPEZ
30/11/2023
SEVILLA MuleSoft Meetup Group

2. Who am I?
2
● Soy un gaditano que emigró hace ya casi 20
años a Sevilla donde resido actualmente.
● Llevo casi 20 años como Arquitecto Java,
experto en arquitecturas de Microservicios
basadas en Spring Boot y que hace 5 años
tuvo la oportunidad de conocer Mulesoft.
● Desde entonces, llevo ayudando a diseñar
arquitecturas de integración utilizando toda la
potencia que nos ofrece Mulesoft.
● Porque Mulesoft?, porque al estar basado en
Java me permitió conocer todos su potencial
desde el minuto uno , y me ayudo a entender
mejor como funciona por dentro.
Javier Toscano Lopez, Chief Architect, NTT Data
https://www.linkedin.com/in/francisco-javier-toscano-
lopez-1815919/
@fjtoscano
2

3. 3
Agenda
• Modelos de despliegues
• Aprovechamiento de recursos
• Buenas prácticas de desarrollo
• Mesa redonda.

4. All contents © MuleSoft, LLC
Modelos de despliegue

5. 5
Modelos de despliegue - CloudHub
CARACTERISTICAS
● Mínimo de capacidad consumida por API : 0,1
vCore
● Despliegue en infraestructura propia de
Cloudhub sin coste para el cliente
● Posibilidad de crear VPC y conexión con Red
interna por AWS (VPC Peering, Direct Connect,
Transist Gateway) u (Otras nubes) por VPN
● Publicación de API en modo interno y externo
● Integración nativa con Mulesoft API Manager,
Monitoring y Exchange
CONTRAS
● Selección de capacidades limitada: 0.1, 0.2, 1,
2, 4 vCores, Falta de aprovechamiento de
capacidades
● Privacidad: El API no se encuentra desplegado
en la red del cliente
External Network
Api Manager Monitoring Exchange
Runtime Manager
0,1 vCore
0,2 vCore
Capacidad consumida
por el API

6. 6
Modelos de despliegue – CloudHub 2.0
CARACTERISTICAS
● Mínimo de capacidad consumida por API : 0,1 vCore
● Mas opciones de capacidad: 0.5, 1.5, 2.5, 3,5
● Despliegue en infraestructura propia de Cloudhub sin coste
para el cliente
● Posibilidad de crear Private Spaces y conexión con Red interna
por AWS (Transist Gateway) u (Otras nubes) por VPN
● Publicación de API en modo interno y externo
● Integración nativa con Mulesoft API Manager, Monitoring y
Exchange
CONTRAS
● Privacidad: El API no se encuentra desplegado en la red del
cliente
External Network
Api Manager Monitoring Exchange
Runtime Manager
0,1 vCore
0,2 vCore
Capacidad consumida
por el API

7. 7
Modelos de despliegue - RTF
CARACTERISTICAS
● Mulesoft proporciona el software necesario para desplegar las
API´s en un runtime instalado sobre la nube del cliente Azure (AKS),
AWS (EKS), Google (GKS) u OpenShift.
● Mas parámetros de configuración de infra: CPU y Memoria
● Mínimo de capacidad consumida por API : 0,02 vCore, memoria
700MB RAM.
● Infraestructura propia del cliente.
● Soporte compartido entre cliente y Mulesoft.
● Publicación de API en modo interno y externo a través de
configuración de ingress controler en la infra del cliente
● Integración nativa con Mulesoft API Manager, Monitoring y
Exchange
● Logging externo a mulesoft, Splunk, Kibana, GrayLog, etc
PROS
● Aprovechamiento de los recursos vCores
● Seguridad: Instalación en red de cliente
● Gestión desde panel de control de Mulesoft
INCOVENIENTES
● Coste de infra a cargo del cliente
● Gestión de logging externo a la plataforma
● No compatible con Anypoint MQ
External Network
Api Manager Monitoring Exchange
Runtime Fabric
Internal Network
Runtime Fabric
Runtime Fabric
CNF

8. 8
Modelos de despliegue – Flex Gateway y UAPIM
CARACTERISTICAS
● MuleSoft proporciona un Gateway ligero que se instala
en la infra del cliente y que sirve de agente para que
MuleSoft API Manager pueda gestionar las API que se
configuren en el Flex Gateway
● Infraestructura propia del cliente compatible con Linux,
Docker o Kubernetes
● Soporte compartido entre cliente y MuleSoft
● Publicación de API según seguridad del propio cliente
● Integración nativa con MuleSoft API Manager,
Monitoring, Exchange
PROS
● Pricing por número de peticiones, no consume vCores
● Seguridad: Instalación en red de cliente
● Gestión desde panel de control de MuleSoft
INCOVENIENTES
● Posible logging descentralizado entre API de Mule y
otras piezas de integración
External Network
Api Manager Monitoring Exchange
ESB
Internal Network
ESB
Flex Gateway
CNF

9. All contents © MuleSoft, LLC
Aprovechamiento de recursos

10. 10
Preguntas que nos debemos hacer antes de
implementar
• Número de mensajes ?
• Tamaño de los mensajes ?
• Complejidad de negocio desarrollado
• SLA y latencia del backend
• Como vamos a agrupar las operaciones dentro de las MuleApps ?
• Tenemos operaciones asíncronas ?
• Tenemos ETLs o Schedulers ?
• Numero de entornos Productivos y no productivos
Capacidad de
CloudHub
Recursos
consumidos por
nuestro desarrollo
¿Qué tenemos?
Ajustar al máximo los recursos a
la capacidad y escalamiento de
CloudHub
¿Qué queremos?
0.1, 0.2, 1, 2, 4 vCores CH 1
0.1, 0.2, 0.5, 1, 1.5, 2, 2.5,… vCores CH 2

11. 11
Volumen y tamaño del mensaje
Deployment
config
CloudHub 1 vcore
worker Managed
API with
embedded
Gateway
Api detail APIkit Router with
OAS 2.0 GET
/orders
application/json
Request header ~500b (including
400b of JWT
token)
Protocol Plain HTTP
Backend
Latency
50 ms
SLA 500ms Strict (99%)
Complejidad Simple

12. 12
Business Logic Complexity

13. 13
Volumen
API detail APIkit Router with
OAS 2.0 GET
/orders
application/json
Request header ~500b (including
400b of JWT token)
Protocol Plain HTTP
Backend latency 50ms
Response payload 100kb JSON
Expected TPS 700+
Complejidad Simple

14. 14
Como agrupar las operaciones dentro de las APIs
El eterno dilema de como agrupar las operaciones dentro de una Mule App.
• Agrupar por Sistema Backend
• Agrupar por funcionalidad de negocio
• Agrupar por volumetrías en las operaciones
• MuleSoft recomienda para un buen aprovechamiento de los recursos unas 25-30
operaciones por MuleApps
• Para poder agrupar correctamente las operaciones es necesario que tengamos en cuenta
todos los puntos anteriores

15. 15
Patrones de integración

16. 16
Asincronía
• El desarrollo asíncrono siempre suele ir ligado a elementos intermedios que almacenan el
mensaje para ser tratado de forma desatendida.
• Suele haber un elemento de colas tipo ActiveMQ, Kafka,…
• Se recomienda desarrollarlo en MuleApps que solo tengan api asíncronas.
1.- Un servicio Rest que recibe el mensaje y devuelve un ACK
2.- Se guarda el mensaje en el sistema de colas
3.- Se lee el mensaje de la cola y se llama al Backend
4.- La respuesta del backend se puede enviar directamente a un servicio del sistema Front
que este escuchando.

17. 17
ETL
• MuleSoft, no es una herramienta de ETL, pero eso no quiere decir que no tenga
herramientas potentes para hacer ETL
• Herramientas BATCH
• Operaciones BULK en BBDD
• Streaming: No carga todo el contenido en memoria, va utilizando buffer
• Dataweave como herramienta de transformación de datos
• Programar inteligentemente los ETL para que no arranquen a la vez

18. 18
Numero de entornos
• A veces nos encontramos con clientes que quieren 4 entornos Sandbox (DEV, INT, QA,
PREPROD) y dos entornos productivos (PROD, RECOVER), y tienen 4 vcores Sandbox y 2
vCores Production.
• Clientes con sistemas Backend con solo dos entornos DEV y PRO.
• Se recomienda siempre que se pueda, 2 entornos Sandbox (DEV, UAT) y un entorno
Productivo.
• Si tienes un contrato ELA, crea entornos cuando estes aburrido, o APIs por deporte

19. 19
T-shirt sizing
𝚺(número de aplicaciones en cada talla de
camiseta x tamaño recomendado del core
de la camiseta)

20. 20
T-shirt sizing: Aproximación
Estimación aproximada basada en los factores más básicos: TPS, tamaño
de la carga útil y lógica
Size Criterio Cores
Small 5-30 TPS, Payload size upto 100kb, Simple Logic or File
size under 1GB
0.1
Medium 30-100 TPS, Payload size upto 100kb, Medium Logic or
File size 1-2GB
0.2
Large 100-400 TPS, Payload size 100kb - 200kb, Medium to
Complex Logic or File Size of 2–4GB
1
X-large 400 or above TPS, Payload size 200kb or more,
Complex Logic or File size 4GB or above
2
Otros factores que pueden
ser considerados:
● Sync vs async
● Real time vs batch
● Strict SLA requirements
● Payload size variations
● API-led Architecture
● High Availability

21. All contents © MuleSoft, LLC
Buenas prácticas de desarrollo

22. 22
Reglas de organización del código
• Crear global.xml con todos los global element (Elementos de
configuración de componentes y conectores)
• Crear error.xml con la definición y captura de todos los tipos de errores
del proyecto Mule
• Crear un [operación].xml con el flujo de cada una de las operaciones
Rest
• Crear un fichero commons.xml con todos los flujos comunes del
proyecto.
• Utilizar correctamente las properties de entorno ${env}
• Crear DW reutilizables en ficheros dwl

23. 23
Estructura de proyecto
• src/main/mule: Esta carpeta contiene todos los ficheros de configuración con
los flujos de las distintas operaciones que va a contener el API
o global.xml: Este fichero contiene todo los Global element que vaya a
contener el proyecto en los diferentes flujos de operaciones.
o s-example.xml: Contiene el flujo principal con el ApiKit y los diferentes
flujos de las operaciones.
o common/common.xml: Contendrá todos los flujos que sean reutilizables
o comunes en toda la API.
o error/error.xml: Contendrá toda la gestión de errores "Error handling" de
la API.
o service/[nombreOperacion].xml: contendrá por cada operación definida en
el RAML un fichero con el código de la operación.
· src/main/resources: Esta carpeta contiene:
o Log4j.xml: Fichero con la configuración de logs de la API
o Api/ : aquí se encuentra el API Specification que hemos obtenido
del Design Center con todos los datatypes, example y traits.
o Local/properties.yaml: Este fichero contiene todas las propiedades
que necesite nuestro código cuando estemos trabajando en local.

24. 24
Cosas que no te cuentan
No utilices Flow a diestro y siniestro
• los Flow consumen más memoria que los Subflow
• Los Flow crean eventos que son registrados al inicio y la Mule App
tarda más en arrancar y ejecutarse
• https://docs.mulesoft.com/mule-runtime/latest/about-flows
Estudia un poco antes de implementar For-Each para todo
• Debes tener en cuenta que el integrador es el peor sitio para
procesar grandes cantidades de datos.
• El uso de For-Each muchas veces se pueden evitar haciendo una
consulta u obteniendo los datos de una vez.
• Pregunta a alguien con más experiencia sobre esto
Analiza bien las dependencias que te hacen falta
• Cuando se sube una Mule App se sube con todas sus dependencias
• Revisar si no tiene conectores de mas
• Actualiza siempre que puedas
• Solo el conector de SalesForce coge 40 MB

25. 25
Cosas que no te cuentan
Cuando trabajes con BD siempre activa el pool de conexiones
• Java y por ende Mule, consume muchos recursos cada vez que tiene
que conectarse con una BD
• El pool de conexiones ayuda a mantener siempre abierto el canal de
comunicaciones y hace que consuma mucha menos memoria
Saber programar Java siempre ayuda
• MuleSoft está basado en Java
• Aunque tu mueves cajitas para programar el Flow, siempre es
recomendable saber cómo funciona por dentro y poder entender
mejor aquellos comportamientos que se salen de “lo normal”
• No se debe olvidar que MuleSoft es una herramienta de integración,
pero si quieres salirte del tiesto en Mule “Estudia Java y Spring ”
El acceso al Object Store es limitado
• El Object Store es la zona de memoria de almacenamiento temporal.
• Se utiliza para muchas cosas, Token Oauth, Cache, etc
• Por defecto tiene un límite de 10 TPS (Transferencias por segundo)
por aplicación

26. All contents © MuleSoft, LLC
Redis como Custom Object Store

27. 27
MuleSoft Object Store
Object Store
• Tipo de almacenamiento clave - valor
• Potente herramienta de almacenamiento temporal
Ej de utilización:
• Almacenamiento del token de Oauth
• Almacenamiento de las reglas de cache
Limitaciones:
• Básico: Permite por aplicación 10 accesos de escritura/lectura por
segundo. Y 100 Millones de transacciones al mes.
• Premium: Permite por aplicación 100 accesos de escritura/lectura
por segundo.

28. 28
Custom Object Store
Redis
• Tipo de almacenamiento clave - valor
• Potente herramienta de almacenamiento temporal
• MuleSoft permite sobrescribir la funcionalidad de
Object Store al redis
Ej de utilización:
• Almacenamiento del token de Oauth
• Almacenamiento de las reglas de cache
Limitaciones:
• NO TIENE
Contras
• El coste

29. Thank you