Operationalizing CloudHub 2.0 - Meetup.pptx

Operationalizing
CloudHub 2.0
Thurs, Apr 6, 12:00 PM (EDT)
Alex Pan
Senior Product Marketing
Manager, Platform
Manik Magar
Architect
AVIO Consulting
Sandeep Deshmukh
Senior Customer Success
Architect
Valerie Li
Director of Product
Management, Platform

Today’s Agenda
1. CloudHub 2.0 overview, benefits, and comparisons
2. Migrating from CH 1.0 to CH 2.0: what to consider
3. How CH 2.0 solves for common use cases
a. Securing APIs with OOTB controls and policies
b. Configuring monitoring and logging on CH 2.0
c. Configuring CI/CD scripts on / migrating CI/CD
scripts to CH 2.0
4. CH 2.0 + AWS
5. What’s coming next for CH 2.0
6. Q&A

CloudHub 2.0 Overview &
Features

CloudHub 2.0, 1.0 & RTF High-Level Comparison
Fully Managed PaaS Public & Private Cloud; On-Prem
MuleSoft CloudHub 2.0 Anypoint Runtime Fabric Anypoint Runtime Fabric
2.0 1.0
• Easy to use, UI-driven configuration workflow
to minimize environment deployment times
• Container-based app isolation for better
performance, resilience & quicker scalability
• Built-in autoscaling load balancer and
ingress
• Control plane and runtime plane decoupling
to improve agility and resilience
• Native support for AWS authentication to
easily access other services in AWS ecosystem
• Previous generation of MuleSoft-managed
SaaS – built on top of virtual-machine (VM)
based architecture
Many of features of CloudHub 1.0 are adopted
in CloudHub 2.0.
• Deployment flexibility onto any customer-
managed Kubernetes service
• Freedom to configure your K8s tech stack with
your preferred products
• Data residency and application isolation
within your trusted boundaries
For more on deployment comparisons:
https://docs.mulesoft.com/cloudhub-2/ch2-features

CloudHub 2.0 Architecture
Anypoint Control Plane
Anypoint
Monitoring & Logs
Object Store
V2
Runtime
Manager
Anypoint
Exchange
Access
Management
MuleSoft Platform Services
Worker Node
Mule App
Monitoring
Mule App
Monitoring
Worker Node
Mule App
Monitoring
Mule App
Monitoring
Worker Node
Mule App
Monitoring
Mule App
Monitoring
CloudHub 2.0 Shared Space VPC

CloudHub 2.0 Features
Terminology Changes
VPC - Virtual Private Cloud
Worker - EC2 server instance of an API
DLB - Dedicated Load Balancer
Private Space - Private K8s Cluster
Replica - Container instance of an API
Ingress Controller
CloudHub CloudHub 2.0
vs.

Overview
Deploy across different regions across
the world (incl. Americas, EU, APAC)
Example:
Myapp-uniq-id.shard.region.cloudhub.io
● uniq-id: new, 6-digit app ID
● shard: 6-digit space identifier
● region: deployment region of shared
space
Support across the control & runtime
planes
Runtime Plane
● Shared global space is multi-tenant
● Private space is single tenant
Runtime Plane
● The management console and platform
services have a “shared everything”
architecture
Shared Global Regions Multitenancy
Dedicated instances of Mule runtime
engine that run your integration
applications on CloudHub 2.0
● Capacity: determined by vCore (min. .1
vCore)
● Isolation: apps have their own replica
● Manageability: deployed & monitored
independently
● Locality: runs in the same specific
region/sub-region of space
New and existing CloudHub features
support how users operate and scale
their business
● Redundant platform: app failure
redundancy, even w/ only one replica
● Clustering: workload distribution across
replicas for added reliability
● Intelligent healing: monitoring &
migration of apps in case of failure
● Rolling updates: auto-updates to
support zero-downtime API experience
Availability &
Scalability
Replicas

Replicas are 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 & subregion, such as the US, EU, or
Asia-Pacific (e.g., “us-west-1”, “us-east-2”, etc.).
Replicas

CloudHub 2.0 provides the ability to deploy apps in different regions of the world: North America,
South America, the European Union, and 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 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.
Shared Global Regions

CloudHub 2.0 has three different levels of multitenancy:
Runtime Plane
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, and isolated areas in CloudHub 2.0 which you can use to run your apps
Control Plane
1. The management console and platform services have a “shared everything” architecture
a. All tenants share the same web UI, monitoring services, and load balancers
b. These services do not process or transmit customer data
Multitenancy

Availability & Scalability
New availability features include:
● 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 rolling updates (updating your applications at
runtime) so end users of your HTTP APIs experience zero downtime.
● Clustering: Provides scalability, workload distribution, and added reliability to applications on CH
2.0.
● App Recreate: In addition to “Rolling Updates,” users can also recreate their apps that cannot run
different versions concurrently

CloudHub 1.0 to 2.0
Migration Considerations

Considerations
● Mule Runtime 4.3.0 + are supported
● In CloudHub 2.0, applications will have bursting configured by default. Bursting will not be as
predictable as in CloudHub 1.0 (where it could be optimized via AWS credits).
● VPN and AWS Transit Gateway will be supported. VPC Peering and Direct Connect will be
supported through Transit Gateway moving forward
● Enabling/Disabling or modifying the schedule for an application will require an application restart
● Anypoint Security Tokenizer, WAF policies are not supported

Considerations (cont’d)
● With new Secure Properties feature in CloudHub 2.0, protected values no longer need to be
passed through the mule-artifact.json
● VPN High Availability option now available, allowing for reduced/negligible downtime during
VPN maintenance. # of VPN redundancies limited by user resource allotments
● Monitor vCore usage in Access Management (at the business group level) – previously available
in Runtime Manager
● CloudHub Connector / custom alert notifications (Bell icon) are deprecated in CH 2.0

How CloudHub 2.0 Solves for
Common Use Cases

Securing your APIs with
CloudHub 2.0

CloudHub 2.0 Private Space Architecture
Anypoint
Platform CloudHub 2.0
Private Space
API
Manager
Runtime
Manager
App App
Mule
Runtime
Mule
Runtime
Ingress Ingress
Replica Replica
NAT Gateway
IPSec
Tunnel
Corporate
Data Center
Network Load
Balancer
Consumers
AWS
Transit
Gateway
AWS
Cloud
Corporate
Data
Center
Special thanks to Diane Kesler (DigitalDee)!
VPN
VPC
Attachment

Securing APIs on CloudHub 2.0
Overview
1 Via Private Space 2 Via Ingress 3 Via CH2.0 natively
Inbound / Outbound
Firewall Rules
Static IP addresses
TLS Contexts
Public & Private Endpoints
SSL Forwarding
Last Mile Security
API Manager
Runtime Manager

Via Private Space – In/Outbound Firewall Traffic
Problem: Previously, with CloudHub 1.0, there was no way to control firewall rules for outbound
traffic (e.g., “I want to only allow SFTP traffic.”)
Solution: With CloudHub 2.0, users can easily manage inbound & outbound traffic rules for a
Private Space through the “Firewall Rules” tab.

Via Private Space – Static IPs
In CloudHub 2.0, the # of Static IPs provided is determined by the # of availability zones in the
region your Private Space is deployed in.
Static IPs allow for
whitelisting at the Private
Space level*
Static IPs are not free
for VPCs in CloudHub
1.0!
* = Previously, in CH 1.0, IP whitelisting needed to be done per application.
Key Benefits of Static IPs in CloudHub 2.0

Via Private Spaces – TLS Contexts
TLS Contexts define the domains that are available when deploying apps to the Private Spaces
& can enable mutual TLS.
Once these TLS Contexts are created, they can be used to define inbound and outbound firewall
traffic rules.
Each private space can have up to 10 custom TLS Contexts (1 is included by default.)
Found in your Private Space
Provided with each Private Space
Option to add your own TLS – just
add your own cert + private key

Via Private Spaces – TLS Contexts
Example scenarios on how APIs can be secured after TLS are configured:
1. Different domains
for Internal vs
External APIs
Adding multiple TLS gives service providers more granular control in how they define and
secure their privileged data across different types of service accounts.
2. Packing APIs as
products for different
consumers
3. Two-way SSL
validations

Via Ingress Controller – Public and Private Endpoints
Depending on whether an app is deployed on a Shared or Private space, users will have access
to secure your app via the endpoints exposed:
For apps deployed
in Shared Spaces :
For apps deployed
in Private Spaces :
Apps must have at least one public endpoint available,
and can have up to 3 different endpoints
All public endpoints associated with your app can be deleted,
stopping public access to any specific API
Other apps deployed within your Private Space can still
access via a private endpoint, created by default

Via Ingress Controller – Forward SSL Session & Last Mile Security
Documentation: https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space
Forward SSL Session
Used primarily for client authentication, SSL
forwarding forwards client certificate details
in HTTP request headers so they are
available to the application.
These fields can identify an authenticated
client and allow an application to determine
and use the identity.
Last Mile Security
Forwards HTTPS connections to be
decrypted by the application. This requires
an SSL certificate to be included in the Mule
application, and also requires more CPU
resources.

Anypoint API Manager with CloudHub 2.0
Serve data from all your APIs to developers instantly and manage using centralized
control plane
Secure your APIs and microservices
Apply pre-built or custom policies to individual or
groups of APIs based on your needs
Onboard with precision and ease
Enable and manage fine-grained access to APIs
natively or with your own IdPs
Make smarter API Program investments
Analyze, detect trends and get alerted on KPIs,
policy violations and user interactions

Monitoring features in
CloudHub 2.0

Configuring monitoring on CloudHub 2.0
1. CloudHub 2.0 monitors all applications and restarts them automatically if necessary so that
your applications recover without your intervention
2. Runtime Manager will alert on Deployment success & Deployment failure – other Monitoring
features can be configured using Anypoint Monitoring
○ Advanced monitoring with Titanium subscriptions will continue to be supported
3. App & ingress logs are collected automatically by the platform
○ Custom ingress logs can be configured & downloaded (Private Space)
4. Custom log4j.xml is now supported natively in CloudHub 2.0 to enable streaming logs to
external log collectors
Overview

Ingress Load Balancer Logs

Runtime Manager Logs
No longer required to disable application logs for log forwarding to Splunk
– use log4j to forward & have both simultaneously
Documentation:
https://docs.mulesoft.com/cloudhub-
2/ch2-integrate-log-system

Configuring & Migrating CI/CD
Scripts on/to CloudHub 2.0

Configuring & migrating CI/CD scripts on CH 2.0
Changes & new requirements on how to deploy apps onto CloudHub 2.0:
1. Apps must be deployed onto Anypoint Exchange before deploying onto a Shared Space or
Private Space.
a. This is due to how CloudHub 2.0 works under the hood. Leveraging RTF & K8s-based architecture,
applications must be pulled from a repository.
2. Exchange Maven Facade API must be upgraded to support SNAPSHOT assets
a. A SNAPSHOT asset is permanently in the development state and cannot be promoted to any other
state.
b. New pom.xml property “distributionManagement” to upload .jar file to Exchange v3
3. Mule Maven Plugin must be upgraded to at least 3.7.x +
4. Mule Runtime must be upgraded to at least 4.3.x +
Maven deployment method

Maven deployment method: diagrams and examples
Image courtesy of infomentum.com
distributionManagement step
deployment step

Distribution Management example:
Maven Plugin update example:
<distributionManagement>
<repository>
<id>anypoint-exchange-v3</id>
<name>Exchange Private Repository</name>
<url>https://maven.anypoint.mulesoft.com/api/v3/organizations/${project.groupId}/maven</url>
<layout>default</layout>
</repository>
</distributionManagement>
<properties> ...
<mule.maven.plugin.version>3.8.1</mule.maven.plugin.version>
</properties>

<cloudhub2Deployment>
<uri>https://anypoint.mulesoft.com </uri>
<provider>MC</provider>
<environment>dev</environment>
<target>Cloudhub-US-East-2</target>
<muleVersion>4.4.0</muleVersion>
<server>anypoint-exchange-v3</server>
<applicationName>${project.name}</applicationName>
<replicas>1</replicas>
<vCores>0.1</vCores>
<deploymentSettings>
<lastMileSecurity>false</lastMileSecurity>
<forwardSslSession>false</forwardSslSession>
<generateDefaultPublicUrl>true</generateDefaultPublicUrl>
</deploymentSettings>
</cloudhub2Deployment>
Maven config example:
type
target-name
version
requirements
ingress-settings

Deploying Apps to CloudHub 2.0 (via Studio)
Within your pom.xml file…
1. Update Maven plugin to 3.7.x + & Mule Runtime to 4.3.x +
2. Provide the necessary information (Mule provider name, target name, # of replicas, # of vCores,
Properties & Secure Properties [new to CH2.0], groupid)
3. [New to CH2.0] Add distribution management property to pom.xml file
a. The .jar file (SNAPSHOT asset) must be first available in Anypoint Exchange
Within your settings.xml file…
1. Configure with server entry w/ Client ID & Secret of your Connected App
Caution: Asset published to Exchange must have a unique GroupId, ArtifactId, and Version
Maven deployment method: example tutorial

Different Anypoint Platform CLI commands:
● CloudHub 1.0 – “runtime-mgr cloudhub-application”
● CloudHub 2.0 - “runtime-mgr application”
Anypoint Platform CLI method
Documentation: https://docs.mulesoft.com/cloudhub-2/ch2-
deploy-cli

Anypoint Platform Management Center / Console
1
2
3

CloudHub 2.0 + AWS
AWS Transit Gateway
AWS Transit Gateway (ATG)
● AWS Transit Gateway acts as a
cloud router in AWS, simplifying
network access between private
spaces, on-prem data centers, etc.
● On CloudHub 2.0, users can attach a
Private Space to ATG via their AWS
account
● ATG + Private Space must be
deployed in the same region

CloudHub 2.0 + AWS
AWS Service Roles
AWS Service Roles
● AWS service roles in CloudHub 2.0 Private Space enables CloudHub 2.0 applications
to access AWS resources in another AWS account
● By assigning your CloudHub 2.0 service role as a “Trust Principal” and with the proper
policies in AWS, apps deployed onto the Private Space will have access to any allowed
resources in your AWS account

Forward-looking statements
This presentation contains forward-looking statements about, among other things, trend analyses and future events, future financial performance, anticipated growth, industry prospects,
environmental, social and governance goals, and the anticipated benefits of acquired companies. The achievement or success of the matters covered by such forward-looking statements
involves risks, uncertainties and assumptions. If any such risks or uncertainties materialize or if any of the assumptions prove incorrect, Salesforce’s results could differ materially from the
results expressed or implied by these forward-looking statements. The risks and uncertainties referred to above include those factors discussed in Salesforce’s reports filed from time to
time with the Securities and Exchange Commission, including, but not limited to: the impact of, and actions we may take in response to, the COVID-19 pandemic, related public health
measures and resulting economic downturn and market volatility; our ability to maintain security levels and service performance meeting the expectations of our customers, and the
resources and costs required to avoid unanticipated downtime and prevent, detect and remediate performance degradation and security breaches; the expenses associated with our data
centers and third-party infrastructure providers; our ability to secure additional data center capacity; our reliance on third-party hardware, software and platform providers; the effect of
evolving domestic and foreign government regulations, including those related to the provision of services on the Internet, those related to accessing the Internet, and those addressing
data privacy, cross-border data transfers and import and export controls; current and potential litigation involving us or our industry, including litigation involving acquired entities such as
Tableau Software, Inc. and Slack Technologies, Inc., and the resolution or settlement thereof; regulatory developments and regulatory investigations involving us or affecting our industry;
our ability to successfully introduce new services and product features, including any efforts to expand our services; the success of our strategy of acquiring or making investments in
complementary businesses, joint ventures, services, technologies and intellectual property rights; our ability to complete, on a timely basis or at all, announced transactions; our ability to
realize the benefits from acquisitions, strategic partnerships, joint ventures and investments, including our July 2021 acquisition of Slack Technologies, Inc., and successfully integrate
acquired businesses and technologies; our ability to compete in the markets in which we participate; the success of our business strategy and our plan to build our business, including our
strategy to be a leading provider of enterprise cloud computing applications and platforms; our ability to execute our business plans; our ability to continue to grow unearned revenue and
remaining performance obligation; the pace of change and innovation in enterprise cloud computing services; the seasonal nature of our sales cycles; our ability to limit customer attrition
and costs related to those efforts; the success of our international expansion strategy; the demands on our personnel and infrastructure resulting from significant growth in our customer
base and operations, including as a result of acquisitions; our ability to preserve our workplace culture, including as a result of our decisions regarding our current and future office
environments or work-from-home policies; our dependency on the development and maintenance of the infrastructure of the Internet; our real estate and office facilities strategy and
related costs and uncertainties; fluctuations in, and our ability to predict, our operating results and cash flows; the variability in our results arising from the accounting for term license
revenue products; the performance and fair value of our investments in complementary businesses through our strategic investment portfolio; the impact of future gains or losses from our
strategic investment portfolio, including gains or losses from overall market conditions that may affect the publicly traded companies within our strategic investment portfolio; our ability to
protect our intellectual property rights; our ability to develop our brands; the impact of foreign currency exchange rate and interest rate fluctuations on our results; the valuation of our
deferred tax assets and the release of related valuation allowances; the potential availability of additional tax assets in the future; the impact of new accounting pronouncements and tax
laws; uncertainties affecting our ability to estimate our tax rate; uncertainties regarding our tax obligations in connection with potential jurisdictional transfers of intellectual property,
including the tax rate, the timing of the transfer and the value of such transferred intellectual property; uncertainties regarding the effect of general economic and market conditions; the
impact of geopolitical events; uncertainties regarding the impact of expensing stock options and other equity awards; the sufficiency of our capital resources; our ability to comply with our
debt covenants and lease obligations; and the impact of climate change, natural disasters and actual or threatened public health emergencies, including the ongoing COVID-19 pandemic.

CloudHub 2.0 (Q1 Deliverables)
Deploy Proxies from APIM
Support using APIM to deploy proxies into CH2 with tls
context
Enhanced Network Control
● Increase firewall rule limit
● Remove default route
HTTP Header Size Increase
Support 32KB header size
Ingress Log Download API
Support
Continue to help automate operations

H2 ‘23
H2 ‘23
Q1 ‘23
H1 ‘23
CloudHub 2.0 (Upcoming)
Non-HTTP Protocol Support
(Preview)
Support non-HTTP (TCP, HL7 MLLP, UDP, etc.)
inbound traffic through Ingress Controller
Enhanced Egress Control
● Domain-based egress control
VPC to Private Space upgrade
Migrate existing VPCs deployed on CloudHub to
Private Spaces & save time on configuration
Auto-scaling and Elastic
Provisioning
Take advantage of native container auto-scaling
strategy and achieve elastic deployment

Operationalizing CloudHub 2.0 - Meetup.pptx

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Operationalizing CloudHub 2.0 - Meetup.pptx

Similar to Operationalizing CloudHub 2.0 - Meetup.pptx (20)

More from Sandeep Deshmukh

More from Sandeep Deshmukh (7)

Recently uploaded

Recently uploaded (20)

Operationalizing CloudHub 2.0 - Meetup.pptx

Editor's Notes