Speaker: Chris Du Preez Host: Angel Alberici Youtube: Virtual Muleys (https://www.youtube.com/c/VirtualMuleysOnline/videos) Meetups: https://meetups.mulesoft.com/events/details/mulesoft-online-group-english-presents-runtime-fabric-rtf-foundations/ Runtime Fabric Foundations. Tune in this time to get a full overview around RTF: architecture, learning paths, tips, how to avoid pitfalls and more. Time to learn. Chris Du Preez will be guiding us through this 50 minutes session! Anypoint Runtime Fabric is a container service that automates the deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and bare-metal servers. (Find out more: https://docs.mulesoft.com/runtime-fabric/1.7/)

1. All contents © MuleSoft, LLC
Anypoint Runtime Fabric (RTF)
Foundations
Chris Du Preez
Customer Success Strategy & Architecture
October 2020

2. All contents © MuleSoft Inc.
Agenda
2
1. Introduction: The dilemma
2. Resources
3. Background
4. Considerations
5. RTF Architecture
6. RTF Top Tips
7. When is RTF the right deployment topology for your organisation?
8. Q&A

3. All contents © MuleSoft, LLC
1. Introductions
The dilemma

4. All contents © MuleSoft, LLC
The application network platform
Anypoint Platform
On-premises
& private cloud
Hybrid Hosted
by MuleSoft
Cloud service providers
Design
Anypoint Design Center
Scale
Runtime services
Run
Mule
Manage
Anypoint Management Center
Engage
Anypoint Exchange

5. All contents © MuleSoft, LLC
The application network platform
Anypoint Platform
On-premises
& private cloud
Hybrid Hosted
by MuleSoft
Cloud service providers
Scale
Runtime services
Run
Mule
Design
Anypoint Design Center
Manage
Anypoint Management Center
Engage
Anypoint Exchange
control plane
runtime plane

6. All contents © MuleSoft, LLC
Background
6
Traditional On-Prem
Multiple years of
investment and refinement
Few modern benefits of
flexibility, self healing
etc. / Self built / High cost
Well understood
architecture
*aaS (Ifra- or Platform)
Containerisation, advanced
availability, scalability etc.
are possible
Still a high level of
investment in non core
capabilities / infra
Some of the Cloud-
Native benefits
Cloud-Native
Infrastructure footprint
reduced, more flexible
commercial model,
scalable, available
Cloud-native practices are
relatively new, perceived
as complex, Lock-in
Full cloud-native
benefits

7. All contents © MuleSoft, LLC
Background
7
Traditional On-Prem
Multiple years of
investment and refinement
Few modern benefits of
flexibility, self healing
etc. / Self built / High cost
Well understood
architecture
PaaS
Containerisation, advanced
availability, scalability etc.
are possible
Still a high level of
investment in non core
capabilities / infra
Some of the Cloud-
Native benefits
Cloud-Native
Infrastructure footprint
reduced, more flexible
commercial model,
scalable, available
Cloud-native practices are
relatively new, perceived
as complex
Full cloud-native
benefits
On-premise, customer
managed “naked mules”

8. All contents © MuleSoft, LLC
Background
8
Traditional On-Prem
Multiple years of
investment and refinement
Few modern benefits of
flexibility, self healing
etc. / Self built / High cost
Well understood
architecture
PaaS
Containerisation, advanced
availability, scalability etc.
are possible
Still a high level of
investment in non core
capabilities / infra
Some of the Cloud-
Native benefits
Cloud-Native
Infrastructure footprint
reduced, more flexible
commercial model,
scalable, available
Cloud-native practices are
relatively new, perceived
as complex
Full cloud-native
benefits
Runtime Fabric
On-premise, customer
managed “naked mules”

9. All contents © MuleSoft, LLC
Background
9
Traditional On-Prem
Multiple years of
investment and refinement
Few modern benefits of
flexibility, self healing
etc. / Self built / High cost
Well understood
architecture
PaaS
Containerisation, advanced
availability, scalability etc.
are possible
Still a high level of
investment in non core
capabilities / infra
Some of the Cloud-
Native benefits
Cloud-Native
Infrastructure footprint
reduced, more flexible
commercial model,
scalable, available
Cloud-native practices are
relatively new, perceived
as complex
Full cloud-native
benefits
Runtime Fabric
On-premise, customer
managed “naked mules”
Cloudhub

10. All contents © MuleSoft, LLC
1. Introductions
Resources

11. All contents © MuleSoft, LLC
Short introductory video
● https://www.mulesoft.com/platform/api/multi-cloud-
integration-runtime-fabric
Webinar
● https://www.mulesoft.com/webinars/api/anypoint-runtime-
fabric
Mulesoft documentation site
● https://docs.mulesoft.com/runtime-fabric/1.7/
Training
● https://training.mulesoft.com/course/operations-runtime-fabric
All things Catalyst
● https://catalyst.mulesoft.com/index.action
● Anypoint Platform account login required
Further background
● https://kubernetes.io/docs/tutorials/kubernetes-basics/
● https://docs.docker.com/get-started/overview/
Resources
11
CUSTOMER’S NETWORK
Server Server Server
Mule
App
Mule
App
Mule
App
Runtime Fabric services
Mule
App
Mule
App
Mule
App
Mule
App
Mule
App
Mule
App
Anypoint Runtime Fabric
Control
plane
Docker & Kubernetes

12. All contents © MuleSoft, LLC
1. Introductions
Background

13. All contents © MuleSoft, LLC
Why Anypoint Runtime Fabric
Multi / Hybrid Cloud Always Available Low barrier
Background
13
● Azure
● AWS
● VMs
● Bare metal
● High Availability
● Automated Failover
● Increased Isolation
● Rolling upgrades
● Single place to manage
● No Docker knowledge required
● No Kubernetes knowledge
required

14. All contents © MuleSoft, LLC
● Anypoint Runtime Fabric is a container service
that automates the deployment and
orchestration of Mule applications and API
gateways
● Software appliance installed on customer
infrastructure
○ Azure
○ AWS
○ VMs
○ Bare Metal
What is Anypoint Runtime Fabric?
14
CUSTOMER’S NETWORK
Server Server Server
Mule
App
Mule
App
Mule
App
Runtime Fabric services
Mule
App
Mule
App
Mule
App
Mule
App
Mule
App
Mule
App
Anypoint Runtime Fabric
Control
plane
Docker & Kubernetes

15. All contents © MuleSoft, LLC
1. Introductions
Considerations

16. All contents © MuleSoft, LLC
● MuleSoft
○ MuleSoft manages the Runtime Fabric appliance and is
responsible for:
■ Delivered components
■ Runtime Fabric appliance
■ Runtime Fabric agent
■ Mule runtime engine
■ Other dependencies for Mule applications
● Customer
○ Customers are responsible for provisioning, configuring, and
managing the infrastructure required for Runtime Fabric.
○ Infrastructure includes:
○ VM resources (CPU, Memory)
○ Disk performance and capacity
○ Operating systems and kernel patching
○ Network ports
○ Synchronization of system time across all VMs
○ Customers will need their DevOps team
(Infrastructure), Network team (Network ports and
config) and Security team (Compliance and
certificates) to participate in and agree on
configuration
What is Anypoint Runtime Fabric
16
Shared responsibility

17. All contents © MuleSoft, LLC
Benefits
Capabilities
Consistent deployments across AWS, Azure, VM or Bare Metal
Multiple Runtime Versions in same RTF
Scale horizontally and redeploy w/ zero-downtime
Easily manage via Mulesoft hosted control plane
No resources required to support/maintain orchestration and automation

18. All contents © MuleSoft, LLC
1. Introductions
RTF Architecture

19. All contents © MuleSoft, LLC
RTF Architecture
● Anypoint Runtime Fabric is composed of a set
of VMs that form a cluster
● Controller:
○ VM dedicated to operating the RTF
● Worker
○ VM dedicated to running Mule applications
and API Gateways
19

20. All contents © MuleSoft, LLC
20
Limitations
#Replicas per worker node: Max = 40
#RTFs in Business Group: Max = 50
#Worker Nodes: Max = 16
#Controller Nodes: Max = 5
#Environments per RTF: Max = 50
OS Persistence not currently
supported
Internal Load Balancer - #Reqs (https://
docs.mulesoft.com/runtime-fabric/1.7/runtime-fabric-
limitations)
vCPU
Cores
Max Requests per Second
(Connection Reuse)
Max Requests per Second (No
Connection Reuse)
1.00 2000 175
0.75 1500 100
0.50 1000 50
0.25 100 10
CUSTOMER’S NETWORK
Runtime Fabric services
Anypoint RTF
Control
plane
Docker & Kubernetes
Limitations

21. All contents © MuleSoft, LLC
RTF Architecture: Development Environments
NOT RECOMMENDED FOR PRODUCTION!
21

22. All contents © MuleSoft, LLC
RTF Architecture: Production Environments
22

23. All contents © MuleSoft, LLC
RTF Architecture: Network
23

24. All contents © MuleSoft, LLC
RTF Architecture: Network
24

25. All contents © MuleSoft, LLC
1. Introductions
RTF: Top tips to avoid common pitfalls

26. All contents © MuleSoft, LLC
1. Introductions
Top Tip 1: Resource Allocation

27. All contents © MuleSoft, LLC
Resource Allocation
● Before deploying an app it is important to understand its resource requirements
● Also important when configuring the internal load balancers inside your RTF
● Each app deployed to RTF has its own runtime instance
○ #Replicas also specified
● Figures quoted here is based on a specific Runtime Fabric cluster configuration on AWS
● You can allocate the following resources when deploying an application:
○ vCPU Cores
■ Reserved vCPU
■ vCPU Limit
○ Memory
https://docs.mulesoft.com/runtime-fabric/1.7/deploy-resource-allocation
● Physical core and Licensed core often differs
● Cannot purchase fractional cores
● License must cover compute power utilised
● To measure utilization use dashboard in Ops Center
CPU and licensed cores

28. All contents © MuleSoft, LLC
vCPU Allocation
● When the Reserved vCPU and vCPU Limit are equal, the CPU on the worker node is
allocated in a guaranteed model.
● When the value of vCPU Limit is set higher than the value of Reserved vCPU, the
application can burst
● Maximum recommended utilization per CPU core is 20 - 25 simple applications and API
gateways
● CPU limit is upper-bounded by the CPU cores provided on the worker nodes
● RTF runs a small number of services on worker nodes
● Applications compete for unallocated CPU remaining on worker nodes
● Strategies for maximising effective use of unallocated CPU:
○ Deploy nightly batch applications with other apps that process their peak load during
the day
○ Deploy multiple replicas of apps
○ Ensure that you do thorough performance testing!
https://docs.mulesoft.com/runtime-fabric/1.7/deploy-resource-allocation

29. All contents © MuleSoft, LLC
Memory allocation
● Minimum memory allocation for each replica of Mule application or API Gateway
○ 0.7 GB Mule 4
○ 0.5 GB Mule 3
● Anypoint Monitoring can affect this
● Anypoint Platform allocates native and heap memory for a deployed application.
● Differences in how memory allocation for each memory type is calculated:
○ Runtime Fabric lists the total memory available for an application.
○ CloudHub describes minimum memory requirements in terms of the heap
memory available to an application
https://docs.mulesoft.com/runtime-fabric/1.7/deploy-resource-allocation

30. All contents © MuleSoft, LLC
Impact of resource allocation
● Resource allocation can impact application startup times and performance of the apps
once started inside RTF
https://docs.mulesoft.com/runtime-fabric/1.7/deploy-resource-allocation

31. All contents © MuleSoft, LLC
Impact of resource allocation
https://docs.mulesoft.com/runtime-fabric/1.7/deploy-resource-allocation

32. All contents © MuleSoft, LLC
1. Introductions
Top Tip 2: Hardening

33. All contents © MuleSoft, LLC
RTF Hardening Checklist
https://docs.mulesoft.com/runtime-fabric/1.7/configure-hardening

34. All contents © MuleSoft, LLC
1. Introductions
Top Tip 3: Anypoint Security

35. All contents © MuleSoft, LLC
Anypoint Security
https://docs.mulesoft.com/anypoint-security/

36. All contents © MuleSoft, LLC
Anypoint Security: Edge Policies
https://docs.mulesoft.com/anypoint-security/

37. All contents © MuleSoft, LLC
Anypoint Security: Tokenization Service
● Create tokenization services to tokenize sensitive fields from the request payloads.
● Examples:
○ Credit Card Numbers
○ PI information
○ Primary Account Numbers
● Format-preserving tokens can be created
by the Tokenization service
● Tokenization services are deployed to RTFs
https://docs.mulesoft.com/anypoint-security/tokenization

38. All contents © MuleSoft, LLC
Anypoint Security: Secrets Manager
● Secure vault technology intended to store and control access to:
○ Private keys
○ Passwords
○ Certificates
○ Other secrets
● Designed for use with Anypoint platform
● Supports TLS Context management for:
○ Runtime Fabric ingress
○ API Manager in Cloudhub
● Secret groups can be used
○ Secret groups have unique encryption keys
https://docs.mulesoft.com/anypoint-security/index-secrets-manager

39. All contents © MuleSoft, LLC
Anypoint Security: Secrets Manager
● Supported Anypoint
Platform services can
request secrets stored in
secrets manager
● Two microservices work
together:
○ Secrets Manager
○ Secrets Provider
https://docs.mulesoft.com/anypoint-security/index-secrets-manager

40. All contents © MuleSoft, LLC
1. IntroductionsRTF: When is it the deployment topology
for you?

41. All contents © MuleSoft, LLC
RTF is the correct choice when...
41
Existing cloud
infrastructure
Customer has an AWS or
Azure instance, and can
leverage RTF on their
infrastructure, in some
cases with hybrid cloud.
Ongoing kubernetes
initiatives
RTF is built on kubernetes,
and is attractive to
customers that have
kubernetes initiatives
within their org.
Highly restricted
industries
Customers in industries
such as finance or
government want managed
cloud benefits but can only
deploy on-premises.
Need for automation
and isolation
Current on-premises
deployments are requiring
dedicated teams to monitor
and orchestrate
deployments.

42. All contents © MuleSoft, LLC
Thank you

43. All contents © MuleSoft, LLC
1. Introductions
Appendix