What’s Mule 4.3? How Does Anytime RTF Help? Our insights explain.
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,074 vues
Read to learn what Mule Runtime Fabric (RTF) and Anypoint RTF are, how you can leverage these integration engines, the best adoption strategies, and the right way to conduct the risk-cost-benefit analysis for your business.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à What’s Mule 4.3? How Does Anytime RTF Help? Our insights explain.
Similaire à What’s Mule 4.3? How Does Anytime RTF Help? Our insights explain. (20)
Plus de Kellton Tech Solutions Ltd
Plus de Kellton Tech Solutions Ltd (20)
Dernier
Dernier (20)
What’s Mule 4.3? How Does Anytime RTF Help? Our insights explain.
- 1. 1 Webinar: Mule Runtime Fabric (RTF): Key Practices for Driving Automated, Easy-to-Scale Deployments
- 2. Foundation 1997 Footprint USA, UK, Ireland, Asia Pacific Clients Startups to Fortune 500 Core Strength People and Technology ISO 9001:2015 & CMMi Level 5 Ownership Public Limited BSE, NSE: KELLTOTEC Team 1500+ Employees United States | United Kingdom | Ireland | Asia Pacific 2 KELLTON TECH - A PIONEER OF DIGITAL TRANSFORMATION
- 3. 3 WHAT WE DO
- 4. SPEAKERS 4 Murali Polakam Digital Integration Leader Kellton Tech Solutions Sadik Ali Solution and Integration Specialist - MuleSoft 4
- 5. AGENDA Accelerators in Mule 4 . About, architecture & components in Anypoint Runtime Fabric. Runtime Fabric Installations RTF Logging, Monitorin g Demo Q & A 5
- 6. Digital Transformation of Business and IT Analytics and Decisions Process Integration Data Fabric and Cloud Enablement Business - IT Strategy & Planning Software R & D Design & Analysis Enterprise Reference Architecture Digital Maturity Roadmaps Governance Real-time Streaming Analytics Business Dashboards & Process Monitoring Predictive Analytics Business Process Discovery Pattern Detection Process Orchestration Case Management Rules Management Process Automation and RPA Task and Workflow Management API Portals and Gateways Cloud and SaaS Integration API Life-cycle Management Application and B2B Integration IoT and Mobile Integration No-SQL and Continuous Query Messaging In-Memory Data Management (IMDG) Software AG | IBM | APIGEE | MuleSoft | Dell Boomi | Informatica | Jitterbit KELLTON TECH’s - DIGITAL INTEGRATION – SERVICE PORTFOLIO 6
- 8. Dynamic and Pervasive integration approach provides COMPETITIVE EDGE Legacy integration methodologies and technologies are not enough anymore IMPLICATIONS 8 Digital Business Requires a “Pervasive” Approach to Integration 8
- 9. PaaS Applications Kellton Hybrid Integration Strategy Data Integration SaaS Applications Cloud Services Data Lakes Providing cloud and on-premise data integration and management IoT Embedded Systems API Management On Premise Private Cloud Deployment Application Integration AWS/ Azure Deployment Legacy Systems AIMessagingRPA Hybrid Integration Platform: Enabler for Digital Enterprise 9
- 10. Cloud Enablement Dockerization Swarm Analytics Data as a Service Data Lakes Architecture UI / UX High Speed Digital UI/UX Application Services Application Modernization Micro Services Micro Services Architecture Application Re-Engineering SaaS Integration Rapid SaaS Integration SaaS throttling Synchronization API Led Connectivity Application Integration Legacy Modernization Agile Normalization API Monetization Runtime Provisioning Security and A&A Gateways Unified API Portal API Strategy: The Prime Force for System (Re-) Engineering 10
- 11. WHAT’S NEW IN Mule 4.3 and 4.4!
- 12. IMPROVED FEATURES IN MULE 4 New Mule Message Structure Mule 4 - PaletteMule Event- Exhibit Try Scope- Exhibit Error Handlers-Types 12
- 13. THREADS ACCELERATORS IN MULE 4 (UBER THREAD POOL) Reactive Programming ❖ This information drives the logic forward rather than having control flow driven by a thread-of-execution. ❖ Supports decomposing to execute an asynchronous and nonblocking fashion. ❖ Allows non-blocking execution. It’s flow of data rather than the flow of control The Benefits (And Limitations) Of Reactive Programming❖ Increased utilization of computing resources on multicore and multi-CPU hardware and increased performance by reducing serialization points. ❖ Developer productivity as straightforward and maintainable approach to dealing with asynchronous and nonblocking computation and IO. ❖ Inclusion of back-pressure is crucial to avoid over- utilization, or rather unbounded consumption of resourcesBack-Pressure Management 13
- 14. Deep Dive into ANYPOINT RTF!
- 15. WHAT IS RUNTIME FABRIC? ❖ Runtime Fabric is a managed software appliance. ❖ Automate and Orchestrate by Container Services. ❖ Customer-Hosted Infrastructures. ❖ Managed by Anypoint Control Planel. ❖ Isolated in Pods. ❖ Supports Multi Runtime Versions. ❖ Scaling Replicas. ❖ Automation in Failover. ❖ Automated Runtime Update. 15
- 16. WHAT IS RUNTIME FABRIC? 16 CONTROL PANEL
- 17. Cloud Hub Hybrid RTF PCE PCF High Availability Yes (OOTB) Configure YES Configure Configure Load Balancing SLB/DLB On Prem LB Basic Configure Configure Logging YES NO (Titanium) NO (Titanium) NO NO Monitoring YES YES YES On Alerts On Alerts Object Store YES Configure Configure Configure Configure Scheduling YES NO NO NO NO Security Updates YES MANUAL MANUAL MANUAL MANUAL Shared Resources NO YES NO YES YES COMPARE WITH OTHER DEPLOYMENTS 17
- 18. 01 02 03 04 05 06 07 08 Regulatory requirement Manage at least 6 servers. Option to deploy On- Premise and Cloud Enhanced Horizontal scaling Enable API through control planel Zero downtime Supported virtual and physical servers Self support for orchestration and automation RTF RECOMMENDATIONS AND ITS BENEFITS ? 18
- 19. RTF ARCHITECTURE :– PHYSICAL ARCHITECTURE 19
- 20. RTF ARCHITECTURE :– LOGICAL COMPONENTS 20
- 21. 21 On Azure : - Configure and prepare template to attach it with Azure template bases infrastructure preparation.. RUNTIME FABRIC INSTALLATIONS -> AZURE
- 22. Infra. Automation Yes Yes No. Treat as manual installation Automation tool(s) Terraform (native and containerized) ARM (Azure Resource Manager) template No RUNTIME FABRIC INSTALLATIONS -> INFRASTRUCTURES 22 RTF installation process on any cloud platform is similar. (Think of it as if you were going to install RTF manually) The differences lie in how the infrastructure is built and is it supported by MuleSoft Currently MuleSoft supports automation for AWS and Azure. For any other cloud providers, treat as manual installation
- 23. On Amazon : - Configure and prepare template to attach it with Azure template bases infrastructure preparation.. RUNTIME FABRIC INSTALLATIONS -> AWS 23
- 24. At least 1 controller VM to operate Runtime Fabric (max 5) – 2 cores each minimum – 8 Gb memory minimum – 80 Gb dedicated disk for the operating system – 60 Gb dedicated disk with 3000 provisioned for Etcd – 100 Gb dedicated disk with 1000 provisioned IOPS for Docker • At least 2 worker VMs to run Mule applications (max 16) – 2 cores each minimum – 15 Gb memory minimum – 80 Gb dedicated disk for the operating system – 100 Gb dedicated disk with 1000 provisioned IOPS for Docker deployment configuration RUNTIME FABRIC CONFIGURATION -> DEVELOPMENT 24
- 25. 25 At least 3 controller VMs to operate Runtime Fabric (max 5) – 2 cores each minimum – 8 Gb memory minimum – 80 Gb dedicated disk for the operating system – 60 Gb dedicated disk with 3000 provisioned IOPS for Etcd – 250 Gb dedicated disk with 1000 provisioned IOPS for Docker At least 2 worker VMs to run Mule applications (max 16) – 2 cores each minimum – 15 Gb memory minimum – 80 Gb dedicated disk for the operating system – 250 Gb dedicated disk with 1000 provisioned IOPS for Docker RUNTIME FABRIC CONFIGURATION -> PRODUCTION
- 26. 26 KEY FACTORS TO DECIDE RUNTIME FABRIC PLATFORM vCPU Cores Approximate Startup Time 1 Less than 1 minute 0.5 Under 2 Minutes 0.1 6 to 8 minutes 0.07 10 to 14 minutes vCPU Cores Concurrent Connections Avg Response Times (MS) 1 10 15 0.5 5 15 0.1 1 25 0.07 1 78 0.5 GB Default For fewer than 500 simultaneous active connections 1.5 GB Large For one or both of the following scenarios * 500 or more simultaneous active connections * Security policies are enabled. • Number of APIS/Proxies • TPS requirement on platform • Process load of applications. • Recovery Time Objective • Understanding of reserved CPU for Inbuild services • Bursting Application for Unallocated CPUs. CI/CD Approach Mutually Maven Plugin Anypoint Platform APIs.
- 27. RUNTIME FABRIC PLATFORM MONITORING AND LOGGING Telegraf (POD) APP (POD) Telegraf (POD) APP (POD) Telegraf (POD) Kubelet Kubelet Worker Worker Controller Based on K8s Kubelet Metrics & Events Heapster (POD) Grafana (POD) Kapaciator (POD) InfluxDB (POD) Metrics & Events Configure Email Gravity Configuration File (Yami) Alerts 160 x 74 27
- 28. Demo 28
- 29. Q & A 29
Notes de l'éditeur
- Kellton Tech has been at the forefront of Digital Transformation for the past two decades. We are a global company with operations in the United States, United Kingdom, Ireland, and Asia Pacific. Our clients range in size from nimble Startups to Fortune 500 companies. Kellton Tech is a publicly traded company and with over 1,500 employees, we are large enough to deliver with excellence but still small enough to care.
- Digital Transformation - is a journey to reach the ideal state of a Digital Enterprise. Kellton Tech’s Strategy and Architecture Services can help you define your digital goals and objectives and develop a strong digital strategy, roadmap and architecture. Analytics and Decisions - Digital noise needs to be matched with enterprise IP to deliver monetize-able insight for the business Process - Process Optimization, Automation and Business Activity Monitoring is fundamental to Digital Innovation feedback we help creating Case Management systems and Dynamic Applications with RPA. Integration - Integration is the Killer app of your future digital enterprise – it has been our core strength for more than 2 decades. Data Fabric and Cloud Enablement - Performance and scale of Data and Insight is fundamental for Digital Business
- This Digital Business which is looking to deliver new Digital Services, Products and Experiences face a lot of challenges As more applications and data move to the cloud, application leaders face increasingly complex integration requirements: within the same cloud, across different clouds and with on-premises endpoints. Supporting these diverse topologies – a hybrid integration platform and strategy has become crucial because: 1. Established on-prem integration platforms are not able to address the new digital and cloud integration requirements 2. Although iPaaS, iSaaS and API tools support these new needs, they require new specialized skills and do not support integration content portability across each other in multi-cloud and on-prem scenarios 3. One-platform for all Integration scenarios remains sub-optimal - Although it is technically possible to achieve, it is not a realistic proposition for organizations with complex integration challenges Additionally application leaders in charge of integration are under pressure to integrate digital transformation projects involving the cloud, mobility, IoT, and APIs. About Platform Providers and Vendors: Many integration platform providers are trying to formulate a coherent integration platform capable of fully supporting multi-cloud service integration requirements. Several are still working hard to consolidate multiple generations of technologies, such as ESBs, data integration tools, B2B gateway software, MFT platforms, iPaaS offerings and API management platforms. They may not yet have reached the optimal combination of functionality and even maturity and production readiness for all the component parts, meaning that the one-vendor approach remains suboptimal. Application leaders in charge of integration are under pressure to reshape their integration infrastructure strategy in order to tackle the new "pervasive" integration challenges stemming from digital transformation projects that involve the cloud, mobility, the IoT and API integration. The hybrid integration platform (HIP) is a framework of on-premises and cloud-based integration and governance capabilities that enables differently skilled personas (integration specialists and nonspecialists) to support a wide range of integration use cases (see picture above). An organization's HIP is usually implemented by assembling a variety of technology building blocks, from one or more providers, which are managed as a cohesive, federated and integrated whole. Responsibility for HIP management is well-defined. Typical HIP building blocks include: • On-premises application and data integration platforms, such as ESBs, ETL tools, B2B Gateway Software, message oriented middleware and the likes. • integration platform as a service (iPaaS) • Full life cycle API management platforms (APIM) • integration software as a service (iSaaS) • other use case specific components, such as, managed file transfer, IoT platforms and mobile back-end services
- As many enterprises move from on-premises only to cloud-based solutions and redefine who does the integration work (not just specialists within IT, but now line-of-business and casual integrators), the hybrid integration platform (HIP) is becoming more important in creating a robust, forward-looking capabilities model. A Hybrid Integration Platform (HIP) permits on-premise applications to seamlessly and securely integrate with cloud-based applications. This permits your IT Team to quick track development and improve efficiency and lower the risk factors in accomplishing Digital Integration. Why Hybrid Cloud Integration Organizations have re-defined their integration strategy to liaison between legacy systems and cloud technologies. Converting to an out and out cloud platform is not a viable solution for all enterprises, nor continuing the on-premise legacy systems. Hybrid Cloud Integration is a perfect pitch for businesses to integrate legacy on-premise systems with cloud data. It helps to resolve many of the challenges businesses face when moving to the Cloud. Hybrid Integration: Ensures Regulatory Compliance: Regulatory compliance prevents businesses from adopting full cloud Integration. Some country specific data protection laws forbid data from leaving its source and sometimes certain confidential data must remain behind the enterprise firewall. Hybrid integration provides the perfect solution by giving companies more control to how their data is handled. Security & Privacy: Organizations can determine the kind of data that should stay behind the firewall and which can be operated on the cloud. This also helps businesses segregate and track data movement. Fosters Innovation: Hybrid Integration provides an opportunity for businesses to incrementally deploy low-risk applications in small chunks to test the waters. This reduces the risk and grow the applications incrementally in cloud at their own pace. Maximize Investment: To maximize the investment, it is important for organizations to combine both on-premise and cloud systems. The Hybrid Integration Layer allows businesses to work with newer applications in cloud while continue to drive the value from legacy applications. What is Multi-Cloud? The term multi-cloud typically refers to using more than one of the public cloud hosting providers in a organization Eg: AWS, Azure, GCP Multi-Cloud vs Hybrid Cloud Multi-cloud applications rely on more than one cloud provider hybrid cloud is classified as an environment that uses a combination of different cloud and on-premises systems Extra ------ What is Multi-Cloud Application Integration? It is an Integration Strategy which enables integrating multiple public and private cloud environments via APIs leveraging iPaas Platforms Many Organizations that are having their applications on the different cloud also want to integrate into different cloud environments and with the availability of multi-cloud management platform, organizations can reduce their dependency on a single cloud provider Leveraging Kellton HIP strategy businesses can integrate to multi-cloud environments via API gateways. It is important not to confuse the term multi-cloud with hybrid cloud because these terms refer to two different aspects of cloud computing. Multi-Cloud use cases rely on more than one cloud provider, where as hybrid clouds are classified as an environment that uses a combination of different cloud and on-premise systems Increased Productivity and Efficiency: organizations can significantly improve their productivity, efficiency and their businesses by using multiple clouds. Improved Flexibility: Multi-cloud integration is ideal for the flexibility required to effectively complete different tasks. Dynamic Pricing: Organizations that use multi-cloud integration have the benefit of switching between cloud applications with different pricing models. Avoid Vendor Lock-In: Multi-cloud integration helps avoid costly situations while keeping cloud providers honest. Enable Failovers and Disaster Recovery: Multi-cloud deployments usually include failovers between cloud providers for this reason. If there’s downtime with one provider, organizations can quickly shift their resources to another for high availability. Service Grid Architecture Side Car Container Architecture
- API Strategy: The Vital Force for Digital Transformation and IT Re-Engineering Today’s Digital Businesses are on a constant journey of digital transformation, innovation, modernization, digitization, and increasing agility, may it be of their customer, supplier and partner engagement channels, operations technology, systems of record and insight, business models, models for asset monetization or value creation. While transforming all interactions between IT applications and digital systems within and outside the organization to API-based integration is an obvious step in the right direction to address all these needs, it is very important to formulate and adopt an API Strategy at the enterprise level. This will ensure that the entire IT organization and the resources available to it are aligned with the overarching strategic goals and tactical initiatives of the business. MICROSERVICES: To Bring Innovation in Differentiating Digital Cloud Applications that Enterprises build New-age Digital Enterprises leverage cloud application platforms to build systems, applications and solutions that can deliver to latest digital demand but fall short in being able to sustain the ability to meet future demand or enable an eco-system of high-speed change to the speed of innovation. API Strategy primarily addresses such short falls in Micro-Services Architecture. B2B Integration: API Strategy will allow to create new business opportunities in partner and b2b ecosystems with rapid on-boarding capabilities Enterprises of Digital era are unable to meet the new Rapid Partner Integration and/or Partner Self Service and Enablement needs from the Business Networks that extend overall value proposition for end customers of the enterprise API Monetization: API Strategy defines the ability to monitor manage and monetize internal IP and insightful data. Digital Enterprises are focused on finding, generating and monetizing valuable data and insight of the enterprise with its customers, partners and other business networks, when such monetizable insight and data grows management and governance of monetization and scalability of the digital systems is un manageable problem API Led Connectivity: Enterprise level API Strategy enables the ability to leverage digital IT assets across multiple line-of-business channels Large Enterprises with multiple business silos and dis-jointed IT are unable to leverage re-usability and scalability of Digital and Other IT Assets including people and processes across the business silos, enterprises needing Bi-Modal IT Digital Enterprises with rapid moving interconnected systems have multiple types of Digital IT assets from Micro-services, APIs, Analytics, Data and Insight these digital IT assets as they grow in number and size enterprises lack an ecosystem to discover, use and govern these IT assets through rapid life-cycle changes Cloud Enablement: API Strategy allows to rapidly adopt and well integrate cloud based IT systems and data assets allowing to optimize overall cost Most Enterprises in the Digital era have a strong initiative to not only build differentiating application in cloud but also leverage SaaS for non-differentiating applications, PaaS for Cloud based Data and Analytics and IaaS for everything imaginable, but these enterprise lack the ability to normalize the integration of 3rd-party and external IT resources in an effective way to control scalability with usage and costs. Application Services and Modernization: APIs bring Agility in transforming and modernizing legacy IT systems for digital demand Most Enterprises not born in the digital era have some foot-print of legacy IT systems that still support mid-office or back-office Enterprise IT. These IT Systems that are non-differentiating are quickly replaced by SaaS and moved to cloud to optimize operations and cost. But those Legacy Enterprise systems that do not have a viable option in cloud or SaaS are in a dire need to be modernized and transformed to cater to the new Digital demands Data As A Service:
- A Mule message is composed of a payload and its attributes . Variables which hold arbitrary user information such as operation results, auxiliary values. In Mule 3, inbound properties stored additional information about a payload obtained through a Message Source, such as the query parameters coming through an HTTP listener. Attributes in Mule 4 replace inbound properties and have these advantages: They are strongly typed, so you can easily see what data is available. They can easily be stored in variables that you can access throughout your flow. Session properties are no longer needed and have been removed in Mule 4. ----------------------------------------------------------------------------------------------------------------------------- A Mule event contains the core information processed by the runtime. It travels through components inside your Mule app following the configured application logic. Note that the Mule event is immutable, so every change to an instance of a Mule event results in the creation of a new instance. A Mule Event is composed of these objects: A Mule Message contains a message payload and its associated attributes. Variables are Mule event metadata that you use in your flow ---------------------------------------------------------------------------------------------------------------------------------- In Mule 4, DataWeave is the default expression language where: Events can be routed based on payload data, without requiring conversion to Java objects. Binary data can easily be queried from an expression anywhere in your flow ------------------------------------------------------------------------------------------------------------------------------------ Mule 4 standardizes the latest model. The Mule 4 distribution ships with no connectors or modules. Instead, each application includes the modules it needs. -------------------------------------------------------------------------------------------------------------------------------------- Another important characteristic of error types is that they might have a parent type. For example, HTTP:UNAUTHORIZED has MULE:CLIENT_SECURITY as the parent, which, in turn, has MULE:SECURITY as the parent. This establishes error types as specifications of more global ones: an HTTP unauthorized error is a kind of client security error, which is a type of a more broad security issue. --------------------------------------------------------------------------------------------------------------------------------------- The error handler behaves as I have explained earlier. In the example above, any database connection errors are propagated, causing the try to fail and the flow’s error handler to execute. In this case, any other errors will be handled, and the Try scope will be considered successful which, in turn, means that the next processor in the flow, an HTTP request, will continue executing. ----------------------------------------------------------------------------------------------------------------------------------------
- When one component is struggling to keep-up, the system as a whole needs to respond in a sensible way. It is unacceptable for the component under stress to fail catastrophically or to drop messages in an uncontrolled fashion. Since it can’t cope, and it can’t fail it should communicate the fact that it is under stress to upstream components and so get them to reduce the load. This back-pressure is an important feedback mechanism that allows systems to gracefully respond to load rather than collapse under it. The back-pressure may cascade all the way up to the user, at which point responsiveness may degrade, but this mechanism will ensure that the system is resilient under load, and will provide information that may allow the system itself to apply other resources to help distribute the its load.
- Anypoint platform is main offering that has 2 main components: Management plane, and runtime plane. While creating individual container while deploying application in RTF, it keeps runtime independent from others and same follows for continuous deployments. As it builds independent runtime container for each application which makes it to handle multi runtime version deployment. And discussing about resource scaling, it supports both horizontal and vertical scaling by simple configuration or easier command to add more resources to existing infrastructure with zero downtime. With its health monitoring and configuration persistence behavior, it adhere to escape from application failover. For instance, if any runtime goes out of service then it replicate another runtime instance for it to avoid platform failover.
- So where does RTF fit in? The name is kind of giving it up, it belongs to RUNTIME plane. It is designed to be running on-premise and in private cloud environments. Simply speaking, runtime fabric runs in customer’s data center. So if the customer favors in an on-prem solution, Runtime fabric should be in the recommendation. Starting with it , you can now set the request and limit vCPU values directly in Runtime Manager. This enables you to configure CPU bursting by setting the vCPU limit value higher than the request (or reserved) vCPU value. The vCPU request amount is guaranteed to the app. The vCPU limit amount is the max the app can use. This allows better use of idle resource to improve start time for application As states earlier, RTF allows 1 app per container. No resource competition. It permits burstable mode to allows user to opt-in the share or compete for resources.
- Although there are various deployment options to deploy applications on Mule Anypoint runtime, there are several factors to consider when choosing your deployment options. Mulesoft provides four deployment options to deploy an application on Anypoint runtime — CloudHub, Runtime Fabric, On-Premise, and Hybrid (CloudHub and On-premise) — one of the options should suit your organizational needs. CloudHub is widely used in the financial and healthcare industries successfully, where data is sent back and forth for countless transactions. CloudHub is an iPaaS where one can deploy applications from the runtime manager console without any configuration to a hosting environment. Mule On-Premise will require additional cost for load balancers, firewalls, and all the other network components that might be necessary to make your application compliant with your organizational and departmental standards. We have complete control over the Mule instance when applications are deployed On-premise, enabling us to take advantage of the following features. Anypoint Runtime Fabric is a container service for multiple-cloud deployments of Mule runtimes. With Anypoint Runtime Fabric, it’s easy to deploy Mule applications and APIs to their managed infrastructure such as an organization’s on-premises data centers or private IaaS while maintaining centralized control through MuleSoft-hosted and development environments. Anypoint Runtime Fabric allows teams to implement capabilities like trustworthy isolation between applications, scaling, application deployments with zero downtime much faster using out-of-the-box components. In short, Anypoint Runtime Fabric bridges the gap between multiple clouds and on-premises resources to help enterprises meet changing business requirements in a quick and efficient manner.
- Customer who: 1. Wants to deploy runtimes on their own premises (Data center, private IaaS) Allow new customers to deploy in the simplest manner Deployment and management are provided OOTB. For existing customers, removes the pain from managing several mule applications on-premises. RTF will automate upgrade, increase scalability (1app/runtime vs multiple apps/runtime) 2. Can afford at least 6 servers for Anypoint Runtime Fabric For a highly available configuration for production deployments 3 servers for running RTF itself, 3 for Mule applications Licensing is enforced by the total number of cores allocated for application deployments -- not the total number of cores available to Runtime Fabric. 3. Wants on alternative to deploying on AWS Retail customer and cannot use Amazon They have credits they want to use for their cloud provider They have internal deployment standardization they must follow
- This separation of responsibilities enables scaling of the worker nodes based on the number of Mule applications. It also enables scaling the controller nodes based on the frequency of deployments, changes in application state, and amount of inbound traffic. To ensure resources are available to re-schedule and re-deploy applications in the event of a hardware failure, MuleSoft recommends over-provisioning the number of worker nodes. Only controllers run the internal load balancer and agents used to connect to Anypoint Platform. Agents can run on any controller. Agent communication is always outbound. The minimum requirements are 3 controller and 3 worker nodes. 3 controllers enable a fault-tolerance of losing 1 controller. To improve fault-tolerance to lose 2 controllers, a total of 5 controllers should be configured. Mule applications run on workers. Multiple replicas of applications can run across workers.
- Important Note: RTF allows 1 app per container. No resource competition. In the recent version, burstable mode allows user to opt-in the share/compete for resource. Anypoint Runtime Fabric uses a set of technologies, including Docker and Kubernetes, which are tuned to operate well with Mule runtimes. Knowledge of these technologies is not required to deploy or manage Mules on Runtime Fabric. Managing Runtime Fabric requires the operational and infrastructure-level experience needed to support any system at scale. We recommend following best practices and running fire drill scenarios in controlled environments to help prepare for unexpected failures. Each application instance runs in its own Virtual as an isolation container, so domain-based shared resources are not required. It provides internal load balancer. It supports to avoid vertical scaling and downtime are not required for the changes.
- This is RTF infrastructure screenshot with details of instance created and configured on Azure cloud.
- RTF installation process on any cloud platform is similar (Think of it as if you were going to install RTF manually) The differences lie in how the infrastructure is built and is it supported by Mulesoft Currently Mulesoft supports automation for AWS and Azure. For any other cloud providers, treat as manual installation
- This is RTF infrastructure screenshot with details of instance created and configured on AWS. Do’s Begin with a checklist and planning. It improves significantly the quality of the solution Do stick to the Terraform scripts - if you must change something ask for advice. Make sure the hardware requirements from your vendor are compliant with requirements (especially Disk/Network I/O) Do consult platform experts with regard to security and network. Dont’s Don’t change the scripts (1500 Lines of Terraform, a lot of dependencies and things to break) Open Security Groups for convenience Play around in the pod/docker shells
- Starting with it we can now set the request and limit vCPU values directly in Runtime Manager. This enables you to configure CPU bursting by setting the vCPU limit value higher than the request (or reserved) vCPU value. The vCPU request amount is guaranteed to the app. The vCPU limit amount is the max the app can use. This allows better use of idle resource to improve start time for application
- These are analytical points which need to be taken care while defining RTF as deployment infrastructure. For instance for resource Scaling these points are critical. Vertical scaling Assign more resources (vCores) to a Runtime Fabric node. Assign more resources (memory) to a stand-alone Mule runtime (or JVM). Assign more resources (vCores) to a CloudHub worker Horizontal scaling Add more Runtime Fabric nodes. Add more Runtime Fabric pod replicas. Add more Mule runtimes. Either clustered or with a load balancer in round robin configuration – Add more CloudHub workers.
- In Runtime Fabric, log can be forwarded to Anypoint Monitoring or to any external logging system. Few below scenarios can be taken care like : Enable and configure Runtime fabric using Runtime Manager to send logs to Splunk, ELK, Azure. Enable to send logs to Anypoint Monitoring using Runtime Fabric control plane. Runtime Fabric features a built-in log forwarder that can send data to rsyslogd server via TCP or UDP. Logs are available for accesses through OPS Center as well. We will see in Demo.