Migration From CH 1.0 to CH 2.0 and Mule 4.6 & Java 17 Upgrade.pptx

MuleSoft Meetup

1. Mohali MuleSoft Meetup 15-June-2024 Migration from CH 1.0 to CH 2.0 💡

2. Why Cloud Hub 2.0 Shared Space vs. Private Space Cloud Hub 2.0 Deployment Cloud Hub 2.0 Architecture Cloud Hub 1.0 and 2.0 Feature Comparision Live Demo of Migration From CH 1.0 to CH 2.0 Q & A Agenda 2

3. Senior Integration Consultant at Infosys MuleSoft Ambassador MuleSoft Meetup Leader MuleSoft Certified Integration Architect 13 years of Experience in Integration Domain https://www.linkedin.com/in/vikas-sharma-50b391a5/ https://www.youtube.com/@YourIntegrationBuddy 3 Vikas Sharma Speaker Your Photo

4. CloudHub 2.0

5. Why CloudHub 2.0 5 Orchestration Services Deploy and run applications in containerized environment based on EKS Provides a standardized isolation boundary by running each Mule instance and service as a separate container Provides for deployments across 12 regions globally. Dynamic Scalable. Horizontal Scaling can be easily achieved by increasing number of replica and Vertical Scaling can be easily achieved by increasing vCores size. More granular vCores option. Maximum vCores can be allocated to per replica is 4 vCores. Application can be deployed on Clustered mode. Minimum 2 replicas required for Clustering. Supports features like Intelligent Healing, Zero-Downtime updates etc. Support for the Rolling update and Recreate while application deployment.

6. Why CloudHub 2.0 Contd.. 6 Anypoint Control Pane Anypoint Monitoring & Logs Object Store V2 Runtime Manager Anypoint Exchange Access Management MuleSoft Platform Services Orchestration 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 Fully managed by MuleSoft Lightweight containerization Granular resource allocation Enhanced security CloudHub 2.0 features and its comparison with CloudHub 1.0 and RTF

7. Shared Space CloudHub 2.0 Shared and Private Space 7 Private Space A shared space is an elastic cloud of resources that includes Mule instances running in a multi-tenant environment You don’t require isolation from the public cloud. Your apps don’t need to connect to an on-premises data center Your apps can use the cloudhub.io domain name ( rather than a vanity domain name) You don’t need to configure custom certificates A private space is a virtual, private, and isolated logical space in CloudHub 2.0 in which to run your apps A  private network , which is a virtual cloud where apps deployed to this private space run. One or more connections from the private network to your external network, either via Anypoint VPN or a transit gateway. TLS contexts, which define the domains that are available when deploying apps to the private spaces. Firewall rules to allow and block inbound and outbound traffic to your private space. The environments and business groups to allow to deploy to the private space.

8. Shared Space 8 Orchestration Services Private Space

9. Deployment Model CloudHub 2.0 Deployment Rolling update Maintain older version before your application is redeployed Extra vCores needed Recreate Terminate old replica Deploy new replica Quicker then Rolling Update No-extra vCores needed 9 Replica Size (0.1, 0.2, 0.5 vCores etc.) Number of replicas (1 to 8) Sizing

10. Cloud Hub 2.0 Architecture 10 Orchestration Services

11. Cloud Hub 1.0 and 2.0 Comparison 11 Orchestration Services Feature Cloud Hub 1.0 Cloud Hub 2.0 Object Store Supported Supported VPC Supported Supported VPN Supported Supported AWS Transit Gateway Supported Supported High Availability Supported Supported Clustering Supported Not Supported Outbound Firewall Rules Supported Not Supported Deployment Rollback Supported Not Supported Datagraph Not Supported Supported VPC Peering Not Supported Supported Persistent VM Queues Not Supported Supported CH connector Not Supported Supported Direct Connect Not Supported Supported Static IP Address Supported ( private space) Supported ( app level) Inbound Firewalls Supported Supported

12. Summary Consistent experience Simplifies networking More fine-grained resourcing New deployment options Easy to use Useful links New Training: Anypoint Platform Operations: CloudHub 2.0 (2 days) https://docs.mulesoft.com/cloudhub-2/ 12

13. LIVE DEMO MIGRATION FROM CH 1.0 TO CH 2.0

14. Use Case Details 14 Orchestration Services

15. Mohali MuleSoft Meetup 15-June-2024 MuleSoft 4.6 and Java 17 Upgrade  💡

16. Speakers O ne of the Y oungest M uleSoft A mbassdor P rofessional I ntegration D eveloper in B illennium I ndia 4 + years of E xperience in I ntegrations M CIA, M CD L1, M CPA, M CIA, M CHS C ertified, S alesforce, A WS, G CP, A zure, W orkato C ertified M ulesoft M eetup L eader | M entor | B logger | S peaker A WS C ommunity B uilder https://www.linkedin.com/in/shubhamchaurasia1/ https://medium.com/@myid535 Shubham Chaurasia

17. Speakers MuleSoft Ambassador 2024 Sr. Software Specialist Working in LTIMindTree 5+ Years of Experience MuleSoft Certified IBM Certified PRIYA SHAW

18. AGENDA ● Java 17 Upgrade Overview ● Why and by when do customers need to upgrade to Java 17? ● Is there any immediate impact to upgrading to Mule Runtime 4.6 and beyond? ● Which MuleSoft products are in scope? ● Demo ● Q&A ● Quiz

19. MuleSoft is adopting Java’s long-term-support (LTS) release, beginning with the Mule Runtime 4.6 which will add support for Java 17 LTS Mule 4.6 & Java 17 Upgrade

20. New Runtime Release Cadence MuleSoft is transitioning from a provisional release cycle to a regular release cadence of three times each year (Winter, Spring, Summer) that aligns with the Salesforce release cycle. Beginning with the 4.5.0 release on October 3, 2023, two new release channels, Long-Term Support (LTS) and Edge have been introduced. LTS versions are focused on providing longer application maintenance periods, and once released, these versions will receive regular patches for security vulnerabilities and critical issues. Edge release channel is dedicated to enabling faster innovation. New features will be released more frequently through the Edge channel. Edge releases will also receive regular patches for security vulnerabilities and critical issues.

21. Edge and LTS releases for Mule Channel Type Release Cadence Recommended Customer Profile Support Coverage Differentiators Edge Three times per year: February June October CloudHub and On-premises 4 months of Standard Support 4 months of Extended Support Includes features on a frequent release cadence with shorter maintenance coverage. LTS Annual: February On-premises 12 months of Standard Support 12 months of Extended Support Includes new features introduced in the previous February Edge release.

22. V ersioning Schema For Cloudhub 1.0, Cloudhub 2.0 and RTF- Major[numeric] Minor[numeric] Patch[numeric]: Build[numeric] Channel[e for edge, nothing for LTS] Each February, MuleSoft releases both an Edge and an LTS release with the same Major. Minor version. To distinguish the versions, they are represented as: Edge: 4.6.0:le LTS: 4.6.0:1 For Standalone(On Premises ) - The Mule runtime versioning changes from date-based, for example, 4.4.0-20230317 to semantic versioning as: Major. Minor.Patch 4.5.1 4.5.2

23. Auto-upgrading Beginning with Mule Runtime 4.5, MuleSoft will auto-upgrade apps across minor releases in CloudHub , which will allow applications to always be on the latest and standard supported version of Mule Runtime, keeping you at the forefront of innovation and security.

24. Java 17 support Industry is moving away from Java 8 and inaction will lead to compliance and security risks along with the lack of supportability. Upgrade from a legacy Java version (8) to a secure Java version (17). Feature updates for Java 8 have already expired in 2022 (Security Support is expiring in 2026) Key libraries e.g. Spring, Graphql which are part of mule stack are dropping Java 8 support Studio is based on the Eclipse IDE and the latest version(4.28) requires JAVA 17 .

25. Java 17 Performance Considerations Java 17 provides important performance changes to MuleSoft products: New JIT compiler Java 17 includes a new JIT compiler, which improves code execution speed. Memory Management Java 17 reduces request latency and executes work more predictably. To achieve this, it adopts a different memory management approach. Although highly dependent on each application, in some cases, Java 17 preferentially commits to heap memory. Default TLS Cipher Selection When using TLS in a server with Java 11 and later, the server determines the default TLS cipher selection. Upgrading your server to Java 17 may cause cipher renegotiation (depending on the supported ciphers list of the client), which can affect the trade-off between security and performance.

26. Anypoint Connectors and Modules Anypoint Connectors and modules are certified by MuleSoft to run on Java 17. The most commonly used Anypoint Connectors and modules are Java 17-compatible now, and others are being released regularly. 4.6 GA - Feb 2024 A subset of available connectors will be Java 17 compatible, based on usage/adoption Customers can determine which connectors are Java 17 compatible via product documentation and Anypoint Exchange connector listing End of Q2 2024 Update remaining connectors

27. Java 17 Compatible Anypoint Connectors Java 17 Compatible Anypoint Connectors (salesforce.com)

28. Anypoint Studio Anypoint Studio 7.17 now supports Java 17 and Mule Runtime 4.6. Users can experience greater IDE stability and performance. MuleSoft has upgraded Studio to use Maven 3.9.6 and Eclipse 4.28, providing tools for Java version management, connector compatibility insights, and real-time guidance for compiling and deployment. With Studio 7.17, you’ll be able to: Select the Java version for your project at any time. Choose the right connectors and assets with Java compatibility information. Resolve compatibility issues proactively during compilation. Deploy more confidently with compatibility checks and deployment tools.

29. Anypoint Studio Anypoint Studio 7.17 now supports Java 17 and Mule Runtime 4.6. Users can experience greater IDE stability and performance. MuleSoft has upgraded Studio to use Maven 3.9.6 and Eclipse 4.28, providing tools for Java version management, connector compatibility insights, and real-time guidance for compiling and deployment. With Studio 7.17, you’ll be able to: Select the Java version for your project at any time. Choose the right connectors and assets with Java compatibility information. Resolve compatibility issues proactively during compilation. Deploy more confidently with compatibility checks and deployment tools.

30. Custom connectors Custom connectors are any connectors that are not developed and maintained by MuleSoft, including connectors that are built by MuleSoft partners or customers. If you are using a custom connector in your app, you must update your connector to run on Java 17 and Mule Runtime 4.6 and later. Connector Tooling Mule/Java SDK with Java 17 compatibility REST Connect with Java 17 compatibility Partner Certification Tool with Java 17 compatibility How to update custom connectors Connectors built with Anypoint Studio: Use the Mule Maven Plugin to generate the connector code Connectors built with REST SDK (Beta): Update manually following the Connector upgrade playbook

31. API Proxies MuleSoft-included API proxies are compatible with Java 17 beginning with the Mule runtime 4.6 release. These API proxies continue to have standard support for Java 8 until February 2025. Custom proxies require updating the underlying extensions and connectors to be Java 17 compatible first. Included proxies include MuleSoft Gateway API proxies (e.g., HTTPS, RAML / OAS). MuleSoft will provide updated versions of these proxies to be Java 17 compatible. Upgrade your API policies before upgrading your API proxies or Mule apps.

32. Demo

33. Networking time

34. Thank You