2. A recording of this meetup will be uploaded to events page within 24 hours.
Questions can be submitted/asked at any time in the Chat/Questions & Answers Tab.
Make it more Interactive!!!
Give us feedback! Rate this meetup session by filling feedback form at the end of the day.
We Love Feedbacks!!! Its Bread & Butter for Meetup.
Housekeeping
2
3. 3
● Introductions
● CloudHub 2.0
❑ Overview (What & Why)
❑ Architecture
- Shared space
- Private space
- Connectivity
❑ Features
❑ Important Changes & Summary
● Trivia
● Networking time
Agenda
4. Introductions
●About the Organizers
Giridhar Meka
HashedIn
Sr. Technical Architect
4
Shubham Chaurasia
Billennium India
Professional Integration Developer
A SHOW OF HANDS:
Who is new to this Meetup?
5. ●About the Speaker :
Introductions
Dipankar Aich
Sr. Technical Architect @MuleSoft
Certified Architect in MuleSoft, AWS & Apigee
Strong technical expertise in diverse Integration & Cloud technologies
5
9. Why CloudHub 2.0?
More than a simple iteration of CloudHub
Completely re-architected onto a container-based platform
Complete re-imagining of the platform experience
More than just RTF in the cloud
Customers will not be exposed to the complexity of provisioning, scaling &
configuring the Kubernetes infrastructure
Customers don’t need to learn how to package & deploy applications as
containers
• CloudHub 2.0 uses a UI-driven, intuitive workflow to allow customers to save time and
money
10. CloudHub 2.0 : Highlights
Time to value
Instantly upload an app and get it running in shared space with a public URL.
Easy, UI-driven, configuration of private spaces and their corresponding DLB, ingress controls &
connectivity
Low Operational overhead
Fully managed infrastructure in the cloud
Perfect for businesses without fully staffed infrastructure teams
Lightweight Application isolation
Container based application isolation
Low point of entry
Granular application resource profiles allow you to start small and scale up incrementally
12. CloudHub 2.0 Architecture
Shared Spaces & Private Spaces
Shared Spaces
An elastic cloud of resources that includes Mule instances running in a multi-tenant
environment.
CloudHub 2.0 provides one shared space in each supported region.
Applications are deployed into a namespace, based on the application’s Anypoint
environment ID.
Private Spaces
A virtual, private & isolated logical space in CloudHub 2.0 to run your apps.
You can create multiple private spaces, either in the same or different regions.
13. CloudHub 2.0 - Shared Space
Internal & External APIs
RUNTIME
MANAGER
ACCESS
MANAGEMENT
MANAGEMENT
CENTER
VISUALIZER
ADVANCE
MONITORING
EXCHANGE
PARTNER
MANAGER`
API DESIGNER
DESIGN
CENTER
API
ANALYTICS
Runtime
Plane
Anypoint Runtime
Server Server
Mule
App
Mule
App
Mule
App
Mule
App
Server
Mule
App
Mule
App
Server
Mule
App
Mule
App
Server
Mule
App
Mule
App
Server
Mule
App
Mule
App
Runtime Fabric services
Docker & Kubernetes (nodes)
EKS Control Plane
Anypoint Platform
Control Plane
14. CloudHub 2.0 - Private Space
Internal & External APIs
RUNTIME
MANAGER
ACCESS
MANAGEMENT
MANAGEMENT
CENTER
VISUALIZER
ADVANCE
MONITORING
EXCHANGE
PARTNER
MANAGER`
API DESIGNER
DESIGN
CENTER
API
ANALYTICS
Runtime
Plane
Anypoint Runtime
Anypoint Platform
Worker Worker
Mule
App
Mule
App
Mule
App
Mule
App
Worker
Mule
App
Mule
App
Runtime Fabric services
Docker & Kubernetes (nodes)
EKS Management Plane
Anypoint Runtime Fabric
Worker Worker
Mule
App
Mule
App
Mule
App
Mule
App
Worker
Mule
App
Mule
App
Runtime Fabric services
Docker & Kubernetes (nodes)
EKS Management Plane
Anypoint Runtime Fabric
N Number of
Anypoint Runtime Fabric
Private Space Private Space Private Space
Control Plane
Region
Business Group
*
15. Private Spaces: Networking & Security
CloudHub 2.0 Architecture
In each private space, you define:
● A private network
○ Private network region
○ CIDR Block
○ Connection Type
■ VPN
■ Transit Gateway
○ Internal DNS Servers (Optional)
● TLS contexts, which define the domains that are available when deploying apps to the private spaces &
optionally enable mutual TLS.
● Firewall rules to allow and block inbound & outbound traffic to your private space.
● The environments & business groups to allow to deploy to the private space.
● 2 or 3 inbound & outbound static IPs depending on region and number of AZ’s.
17. CloudHub 2.0 Architecture
Shared Spaces vs Private Spaces
Shared Space Private Space
Level of isolation You don’t require isolation from the public cloud Single-tenancy for your apps is required
Network
connectivity
Your apps don’t need to connect to an on-premises
data center
Network connection (VPN or transit gateway
attachment) to a data center required for your apps
Domain names Your apps can use the cloudhub.io domain name Vanity domain names are required for your apps
Custom certificates You don’t need to configure custom certificates Custom certificates are required for your apps
Endpoint security No need for private endpoints Private endpoints are needed
19. Replicas
Dedicated instances of Mule runtime engine that run your integration applications on
CloudHub 2.0
Similar to the concept of CloudHub 1.0 workers
Each replica has the following features:
Capacity - Each replica has a specific amount of capacity to process data.
Capacity is determined by the number of vCores assigned to the replica.
Isolation - Each replica runs in a separate container from every other
application.
Manageability - Each replica is deployed and monitored independently.
Locality - Each replica runs in a specific global region, such as the US, EU or
Asia-Pacific.
20. Replicas - Capacity
Replicas with fewer than 1.0 vCores:
● Provide limited CPU and I/O for apps with
smaller workloads.
● Can burst to higher CPU speeds for a short time
(unpredictable)
○ Replicas are configured with Quality of
Service: Burstable.
○ Bursting depends on other applications
deployed in the shared/private space
Replicas with 1 or more vCores provide performance
consistency
vCore Size vCPU Heap Memory Total Memory Storage
0.1 0.1 500 MB 1 GB 8 GB
0.2 0.2 1 GB 2 GB 8 GB
0.5 0.5 1.3 GB 2.6 GB 10 GB
1.0 1 2 GB 4 GB 12 GB
1.5 1.5 3 GB 6 GB 24 GB
2.0 2 4 GB 8 GB 40 GB
2.5 2.5 4.75 GB 9.5 GB 50 GB
3.0 3 5.5 GB 11 GB 60 GB
3.5 3.5 6.5 GB 13 GB 70 GB
4.0 4 7.5 GB 15 GB. 88 GB
21. Shared Global Regions
CloudHub 2.0 provides the ability to deploy apps in 12 different regions of the world:
North America, South America, The European Union & Asia-Pacific.
The region that you deploy your application to determines the domain provided for your
application.
Myapp-uniq-id.shard.region.cloudhub.io
CloudHub 2.0 backend service assigned values:
• Uniq-id: A 6-digit value appended to the app name to ensure uniqueness.
• Shard: A 6-digit value associated with the space (private or shared) that the app is
deployed to.
• Each private space gets a value for shard.
• For apps deployed to shared spaces, each region might have multiple shard values.
The load balancer that CloudHub 2.0 uses to route requests resides in the same region as your
application.
22. Multitenancy
Three different levels of multi tenancy:
1. The shared global region is a multi tenant cloud of virtual machines (VMs)
a. These VMs provide the security and isolation needed for your integrations to run
custom code without affecting others.
2. Single-tenant private spaces
a. These are virtual, private & isolated areas in CloudHub 2.0 in which to run your
apps.
3. The management console and platform services have a shared everything
architecture
a. All tenants share the same web UI, monitoring services & load balancers.
b. These services do not process or transmit customer data.
23. Availability & Scalability
Availability
Redundant platform: All CloudHub 2.0 platform services have at least one built-in
layer of redundancy and are available in at least two data centers at all times.
Intelligent Healing: CloudHub 2.0 monitors the replicas for problems and provides
a self-healing mechanism to recover from them.
• If the underlying hardware experiences a failure, the platform migrates your
application to a new replica automatically.
• In the case of an application crash, the platform recognizes the crash and can
redeploy the replica automatically.
Zero-Downtime Updates: CloudHub 2.0 supports updating your applications at
runtime so end users of your HTTP APIs experience zero downtime.
24. Clustering
Provides scalability, workload distribution & added reliability to applications on
CloudHub 2.0
Horizontal Scalability: With clustering you can add multiple replicas to your
application to make it scale horizontally.
• CloudHub will automatically distributes replicas of the same application across two or
more data centers for maximum availability.
• HTTP load balancing automatically distributes requests across these replicas in a round
robin fashion.
Autoscaling
Application auto-scaling feature is available to all customers but the features will be
available to all customers once the new consumption based pricing launches.
Availability & Scalability
25. Security
● Lightweight application isolation & single-tenant private spaces.
● Secured connectivity through VPN & TGW.
● Firewall for both ingress and egress traffic.
● Endpoint security using private endpoint.
● Last mile security: Enable secured (HTTPS) traffic between ingress and application
runtime (port 8081 for HTTPS)
● SSL session forwarding.
● CloudHub 2.0 does not inspect, store or otherwise interact directly with payload
data.
● All communication with platform services are secured using 2-way mTLS.
● Application property values can securely be stored in a way that is not viewable or
retrievable by any user.
26. Monitoring
CloudHub 2.0 monitors all applications and restarts them automatically if necessary
so that your applications recover without your intervention.
CloudHub 2.0 displays a notification that the app is restarting and another to report
the success or failure of the restart.
Runtime Manager alert for Deployment Success & Deployment Failure.
More alerts in Anypoint monitoring.
Application and Ingress logs are collected automatically by the platform.
Runtime Manager UI checkbox “Enable application logs” for each individual
application.
Custom log4j.xml is supported by default to enable streaming logs to external log
collectors. It’s no longer required to contact the support team to have
this functionality available.
Ingress logs can be downloaded for troubleshooting.
27. Feature Comparison
CloudHub 1.0 CloudHub 2.0
Provision/Scaling Supported Supported
URL rewriting Support (DLB) Supported (app-level)
Load Balancer Logs Not supported Supported (download)
Multiple custom endpoints Partially Supported Supported
Multiple truststores (client certificates for mutual
TLS)
Not supported Supported
Direct Connect/VPC Peering Supported (not self-serve) Not Supported
VPC/VPN/Transit Gateway Supported Supported (private spaces)
Outbound firewall rules Not supported Supported
Log forwarding Supported (per app) Supported (per app)
Custom notifications (CloudHub Connector) Supported Not Supported
https://docs.mulesoft.com/cloudhub-2/ch2-features
30. Key Features to Highlight
● Private Space
○ Firewall rules for outbound traffic
○ Small set of inbound and outbound static IPs to simplify allowlisting
○ DLB/Ingress Controller log available for download
○ Multiple TLS context in each private space allowing multiple custom domains
● Application Deployment
○ HA clustering : Configured and managed by CloudHub 2.0
○ More fractional vCores sized available: 0.5, 1.5, 2.5, 3 & 3.5
○ Deployment Model: Rolling update & Recreate (for apps that can’t have multiple versions running in parallel)
○ Multiple endpoints for single application
○ Last mile security & SSL session forwarding
31. Important points to note
● Control Plane: US & EU in GA, US Gov Cloud in roadmap
● Runtime Support: 4.3.0 - 4.4.x
● OS patching : MuleSoft managed. Occurs monthly. Zero downtime
● Mule Runtime patching : Ad-hoc. Different schedule from CH 1.0
● Non-HTTP workloads are not supported
● DataGraph workloads still be limited to CH 1.0
● API Proxy (traditional Mule Proxy) workloads not available, but in roadmap
● Flex Gateways are not supported in CH 2.0; in roadmap
● Deploying directly from Studio is not supported at GA
● Migration from CH 1.0 to CH 2.0 requires redeployment
● Updated Mule Maven plugin & Updated Anypoint CLI are available
● Auto-scaling will be rolled out with Consumption Based Pricing model. Until then minimum
replica size will remain 0.1 vCore.
33. Take a stand !
33
●Nominate yourself for the next meetup speaker and suggest a topic as well.
34. 34
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Join Mysore Group: https://meetups.mulesoft.com/mysore/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?
35. Get ready to WIN a MuleSoft Voucher from MuleSoft
Quiz Time