FAST FACTS

488% return on investment (ROI) over three years
51.5% more applications integrated per year
Fully integrated messaging service (Red Hat AMQ) compared to connectors for third-party vendors with Mulesoft
JMS 1.1-compliant messaging, with multiple language and protocol support, including REST, STOMP, XMPP, and AMQP
Unlimited servers in cluster topologies
Automatic load-balancing based on protocol
Included container images for rapid, repeatable, Red Hat OpenShift or Docker deployments
Simpler pricing and subscription model than MuleSoft

FEATURE COMPARISON

	RED HAT FUSE	MULESOFT MULE ESB ENTERPRISE
Core integration technology	Camel, the defacto standard for defining integration solutions	Proprietary
Integration messaging	Includes Red Hat^® AMQ, a multiprotocol messaging platform with support for JMS, AMQP, MQTT, and more with multilanguage client support	Separate licensing may be required for integration messaging
Clustering	Robust technology for reliable and consistent definition, deployment, and management of clustering environments using either text-based or graphical user interface tools; no fixed limit on cluster size	Graphical environment for clustering management but lacking advanced productivity and consistency features like profiles; size of cluster is limited to eight server instances
Cloud	Consistent cloud environment for public, private, and hybrid clouds using Red Hat OpenShift that leverages open technologies such as Docker and Kubernetes	Public cloud offering only; limited use of container technology for on-premise installation
Access to software for evaluation and development	All Red Hat Middleware products available for subscription, easily downloadable for evaluation and development	Limited trial period for full functionality
Pricing	Available to the public; positive ROI data based on research by IDC available	No public pricing available
Technology source	Open source	Limited open source; significant functionality only covered by commercial agreement

INTRODUCTION

This competitive review compares system integration technology from Red Hat and MuleSoft. The comparison focuses on the features of Red Hat Fuse 6.2 and MuleSoft ESB Mule Enterprise 3.8 that allow messages to be received, processed, and delivered to target systems. The way in which each product accomplishes these tasks varies, and in the case of integration patterns, varies significantly.

Seeing the greater differences between Red Hat and MuleSoft technologies for system integration requires a broader perspective. Red Hat Fuse includes AMQ for messaging, while MuleSoft requires that third-party messaging products be licensed separately. In production environments, reliability, manageability, and scalability differences are important to understand. For cloud deployments, Red Hat offers consistent private, public, and hybrid cloud capabilities, which differ significantly from MuleSoft.

Beyond product features and capabilities, Red Hat makes it easy to acquire fully functional products for evaluation and developer use. This open nature extends to Red Hat’s subscription pricing, rather than licensing. Red Hat’s pricing model was evaluated by IDC and was determined to provide customers a compelling ROI.

Finally, no discussion of how Red Hat compares to other companies would be complete without talking about open source. Open source is core to all Red Hat products and offers distinct advantages over competitors like MuleSoft. Rather than true open source, MuleSoft arguably offers open core technology, where all source code is not available to the general public.

INTEGRATION OVERVIEW

Enterprises need to integrate their systems and applications to share data between them. Without this ability, the effectiveness of any given system is realized only by users of that system. When integrated, systems can exchange data and increase the cumulative value of that data throughout the enterprise.

Unfortunately, most commercial application software does not offer prebuilt system integrations. Those that do may only integrate systems from the same vendor. Application integration is a large and common enough challenge for enterprises that several software companies offer products that include integration technology in their product portfolios.

Multiple issues can complicate systems integration. However, open standards can help simplify interoperability, as they commonly use messages formatted using one or more open standards for inter-system communication. But for messages to get from point to point, a messaging system is needed—ideally, a platform that can communicate using multiple protocols with a choice of synchronous and asynchronous messaging. The more communications protocols supported by the messaging platform, the better.

For communication endpoints, application programming interface (API) management can help dictate the formats of messages and what action they will take when accessed.

Systems receiving integration messages must be reliable and scalable. Received messages are processed in a logical sequence, often requiring the transformation of messages from one format to another. Applying business rules can help assure that message payloads are properly formatted and routed to their proper destinations. Data possibly needs to be added to messages, thereby enriching the content when passed to other systems. Business processes may execute to coordinate activities across systems and even integrate human tasks. To assure data consistency and integrity, integrations may require cross-system coordinated (XA) transactions.

Ultimately, for every message received, one or more messages must go out to systems being integrated using a predetermined messaging protocol.

Messaging technology is a core system integration often referred to as an enterprise service bus (ESB).

ECOSYSTEM COMPARISONS

Red Hat Fuse core capabilities can be complemented by multiple Red Hat Middleware products. For example, Red Hat Data Virtualization provides access to disparate data formats and sources without the need for data replication—saving storage space and eliminating potential replica sync issues. Red Hat Data Grid can cache data in memory that might be too time-consuming to repeatedly retrieve due to performance bottlenecks at systems of record. Red Hat Decision Manager provides business rules that can help validate message payloads and make complex routing or decisions based on message payload data. When business processes must be consistently executed as a result of integration messages, Red Hat Process Automation Manager supports business process definition and execution based on Business Process Model and Notation (BPMN) 2.0.

MuleSoft does not have products in its portfolio that can be mapped to Red Hat Middleware products for direct comparison. Instead, MuleSoft offers connectors to certain third-party products that provide some of the supplemental integration technology Red Hat provides. For example, MuleSoft Mule ESB Enterprise does not include Java™ Messaging Service (JMS) as part of the product packaging. To use JMS with MuleSoft Mule ESB Enterprise, you need to already have a supported JMS provider. This could result in additional maintenance and support costs plus license fees.

In other cases, MuleSoft embeds open source versions of products that may not be current. For example, MuleSoft Mule ESB Enterprise provides business rules and complex event processing using the Drools Rules Engine from the JBoss community. However, the MuleSoft Mule ESB Enterprise distribution includes the older Drools 5.0.1 libraries—not the current version, 6.0. Significant differences between Drools 6.0 and 5.0 are detailed in the Drools 6.0 documentation.

MuleSoft Mule ESB Enterprise provides business process management functionality using jBPM from the JBoss community. However, MuleSoft bundles the jBPM 4.4.3 libraries—not the current version, 6.0—with the MuleSoft Mule ESB Enterprise distribution. One of many significant differences between these versions is support of the BPMN 2.0 business process modeling standard. JBPM 4.4 process designs are based on jBPM process definition language (jPDL) and do not support BPMN 2.0.

RELIABLE, MULTILANGUAGE MESSAGING

Every Red Hat Fuse subscription includes the ability to also use Red Hat AMQ for messaging. Messaging is used to transport data between integrated systems.

Red Hat AMQ provides reliable out-of-the-box messaging capabilities for Red Hat Fuse. The product is a standards-based, open source messaging platform that deploys with a very small footprint. Key features include:

JMS 1.1-compliant messaging.
High-performance delivery of information.
Connectivity options for multiple languages.
Transactions protected against failures.

MuleSoft Mule ESB Enterprise does not include technology to provide an independently executed on-premise messaging platform. Instead, on-premise messaging is added to a MuleSoft topology via a third-party vendor. For example, Red Hat AMQ (the community project is Active MQ) is certified for use with MuleSoft Mule ESB Enterprise, as well as other JMS providers such as Oracle WebLogic JMS.

The JMS 1.1 specification includes many crucial features and are available from any JMScompliant provider:

Point-to-point messaging
Publish and subscribe messaging
Request/reply messaging
Persistent and nonpersistent messages
JMS transactions
XA transactions

However, any vendor that just implements the JMS 1.1 specification will not provide the features that are found in Red Hat AMQ, including:

The ability to access the messaging system using C, C++, and .NET.
Streaming Text Oriented Messaging Protocol (STOMP), a platform-neutral protocol that supports client access to messaging written in scripting languages (Perl, PHP, Python, and Ruby) in addition to clients written in Java, .NET, C, and C++.
Advanced Message Queuing Protocol (AMQP) 1.0.
IP multicast, which provides one-to-many communications over an IP network, enables brokers to discover other brokers in setting up a network of brokers, and enables clients to discover and establish connections with brokers.

Using an external JMS provider for MuleSoft Mule ESB Enterprise may incur additional maintenance and support costs along with license fees. There are no additional costs for Red Hat Fuse customers who are using the included Red Hat AMQ messaging platform within the terms of their subscription.

Red Hat AMQ supports multiple protocols that can be used either for straightforward clientto-broker connections (transport connector) or broker-to-broker connections (network connector). For each wire protocol, Red Hat AMQ supports one or more associated transport protocols:

OpenWire, the default protocol, which is fully-featured, JMS-compliant, and high-performance.
STOMP.
Representational State Transfer (REST), a simple HTTP-based protocol also popular for mobile devices.
Extensible Messaging and Presence Protocol (XMPP).
VM, a protocol allowing clients to connect inside the Java Virtual Machine without the overhead of network communication.
Advanced Message Queuing Protocol (AMQP) 1.0, an open internet protocol standard for message-queuing communications supported by many institutions and technology providers. Because it is an open standard, one of the project goals is to allow all AMQP clients to interoperate with all AMQP servers.

MuleSoft does offer a cloud-only asynchronous messaging service known as Anypoint MQ. Services interact with Anypoint MQ over REST APIs or in MuleSoft Mule ESB Enterprise using a connector. MuleSoft has not announced plans to support JMS, MQTT, AMQP, or any additional protocol.

CLUSTERING

System scalability and reliability is critical for production integration solutions. Put simply, there must be enough processing capacity available to handle integration messages, meet service-level agreements, help minimize response times, and improve system reliability. However, clustering for on-premise and cloud environments often differs.

TOPOLOGY

The most basic form of on-premise clustering is when server instances are configured to operate in a master-slave configuration. When configured this way, a single server acts as the master, processes integration messages, and one or more slave servers stand by, ready to pick up work should the master server fail. Both Red Hat Fuse and MuleSoft Mule ESB Enterprise support this type of clustering. However, a significant downside for a master-slave cluster is that processing power is capped by the size of the individual servers used.

A more scalable cluster configuration involves using the combined capacity of multiple server instances to meet processing demands, and both Red Hat Fuse and MuleSoft Mule ESB Enterprise support this configuration.

However, MuleSoft Mule ESB Enterprise has a documented eight-server limit for an active-active cluster. If the processing power of eight servers is insufficient to concurrently process all integration flows, MuleSoft Mule ESB Enterprise users are forced to determine the subset of message processing volume possible within the cluster. This means the customer must create additional clusters to handle the remaining load.

Additionally, MuleSoft recommends that integration flows be designed using specific best practices that optimize message processing within cluster limitations. MuleSoft documentation recommends the following:

“You can set up a VM queue explicitly to load balance across nodes. Thus, if your entire application flow contains a sequence of child flows, Mule can assign each successive child flow to whichever node happens to be available at the time. Potentially, Mule can process a single message on multiple nodes as it passes through the entire application flow…”.

This requires MuleSoft Mule ESB Enterprise developers to design and implement integration solutions specifically with clustering in mind—rather than in a way that makes sense overall. This can impact both developer efficiency and long-term maintenance costs for integration solutions spread over multiple flows.

While there are practical limits that can vary by customer on the size of Red Hat Fuse active-active clusters, there are no defined limits within the software.

LOAD BALANCING

Once you have a cluster established, consider how messages will reach that cluster for processing. Messages should be capable of reaching any of the clustered servers, and each server should receive a balanced load. Red Hat Fuse provides more out-of-the-box functionality to balance load across servers than you will find in MuleSoft Mule ESB Enterprise 3.8, including:

The Fabric Gateway within Red Hat Fuse, which provides dynamic discovery, load balancing, and failover of services. It also supports Transmission Control Protocol (TCP) communications using OpenWire, STOMP, MQTT, AMQP, and WebSockets.
The use of standard URLs with web applications or web services that communicate using HTTPS and still achieve load balancing.
Monitoring and detection of any changes in the server deployment topology and dynamic application of mapping rules that expose those deployed services through TCP or HTTP.

As a result, Red Hat Fuse can load-balance messages for most communication protocols.

MuleSoft Mule ESB Enterprise does not provide any functionality to dynamically load balance delivery of integration message traffic to server instances for any communication protocol. MuleSoft Mule ESB Enterprise documentation states that when Mule clusters are used to serve TCP requests, some load balancing is needed to distribute the requests among the clustered instances. Without load balancing, MuleSoft Mule ESB Enterprise clients can only connect to a specific, single server to send messages for processing.

While a single server could be specified to accept all incoming integration messages, it is likely that the communications endpoint will eventually become saturated, or the server load will be exceeded.

CLUSTER MANAGEMENT

How clusters are defined, managed, and deployed is very different between Red Hat Fuse and MuleSoft Mule ESB Enterprise.

Red Hat Fuse has a set of robust functionality for managing its deployment topologies, known as Fabric. Of the Fabric features, the ability to create profiles—descriptions of how to provision a logical group of containers (servers)—is one of the most important. Profiles can have hierarchies and be versioned, which allows you to upgrade or roll back containers by changing the version of the profiles they use.

Within a profile is everything you need to deploy a topology. Profiles allow users to deploy topologies as needed through environments such as testing, production, and disaster recovery. And Fabric supports profiles for both Red Hat Fuse and Red Hat AMQ (for messaging).

MuleSoft Mule ESB Enterprise does not include similar functionalities. Instead, it provides a management console for creating servers and then associating them with a cluster.

Definition of both servers and clusters is a graphical, but manual, process. There is no concept found in MuleSoft Mule ESB Enterprise administration tools similar to Red Hat Fuse Fabric profiles. To replicate cluster environments, MuleSoft Mule ESB Enterprise administrators must take special care to perform the same steps repeatedly without error. Then, once a MuleSoft Mule ESB Enterprise cluster is defined, the administrator must define the resources used and integration solutions deployed.

CLOUD ENVIRONMENTS

Deploying integration solutions in cloud environments continues to grow in popularity. An integration platform that only works on dedicated servers and virtual environments may soon become obsolete.

PUBLIC CLOUD DEPLOYMENT

While Red Hat Fuse and MuleSoft Mule ESB Enterprise functionality are both available for use in public clouds, only Red Hat Fuse is available on a variety of cloud providers. Red Hat Fuse is offered via Red Hat OpenShift Online, or subscribers can potentially deploy from over 50 Red Hat Certified Cloud Service Providers, including Microsoft Azure and Amazon Web Services.

Red Hat Fuse subscriptions can be used on-premise or in cloud environments, with all subscriptions transferring to the public cloud—including access to Red Hat’s award-winning support.

Access to MuleSoft CloudHub cloud services is currently only available from MuleSoft as a subscription service. Multiple news articles discuss how MuleSoft uses Amazon Web Services to host the CloudHub server. However, there are no indications that MuleSoft is building its cloud services using an open technology to promote portability between cloud providers.

PRIVATE CLOUD DEPLOYMENT

Customers using Red Hat OpenShift Container Platform can install, self-manage, and take advantage of all product features in a private cloud deployment. Red Hat Fuse is fully supported on OpenShift Container Platform, and subscribers can even mix usage with Red Hat Fuse running on OpenShift Online to create a hybrid cloud environment. Customers like Amadeus, FICO, T-Systems, and Boeing are using OpenShift Container Platform for cloud deployment.

While MuleSoft does offer a product for connecting datacenters and on-premise applications to cloud environments, MuleSoft’s documentation does not indicate the company supports MuleSoft Mule ESB Enterprise running in a private cloud.

CLOUD OPERATING SYSTEMS

OpenShift uses Red Hat Enterprise Linux^®, the largest Linux distribution worldwide, as its base operating system. Each OpenShift Container Platform subscription includes full support for Red Hat Enterprise Linux.

Red Hat Enterprise Linux 7 is supported by MuleSoft Mule ESB Enterprise 3.8 when deploying on-premise. However, there is no documentation available indicating which operating system is used for MuleSoft CloudHub running on Amazon Web Services.

CONTAINER TECHNOLOGIES

Deploying containers in cloud environments is becoming a popular choice. OpenShift uses the Red Hat Atomic container image, which is compatible with docker-formatted container images, as its standard container format. This image format includes an API to interact with the container. Red Hat Fuse is distributed on OpenShift 3 as a Red Hat Atomic container image.

Red Hat Enterprise Linux forms the base of the Fuse Atomic container image, which provides seamless interaction with the underlying kernel of the host operating system. The kernel provides system calls that containers use to run, and once running, the operating system functionality is layered on top of the host kernel functionality.

MuleSoft offers support for Docker via the Anypoint Platform On-Premises Version only. Docker version 1.8.x. is required and is not the most current release. There is no evidence in MuleSoft product documentation or press releases that its CloudHub service uses Docker container technology. While technology from Docker can run on Amazon Web Services using Elastic Compute Cloud (EC2), there is no indication that MuleSoft is using it.

SCALABILITY, ORCHESTRATION, AND KUBERNETES

Using containers is a good first step for mixing the use of integration and cloud technology. Developers and testing personnel are often only working with a small number of containers. However, deploying containers at production scale brings new challenges—such as starting containers on multiple hosts without having to log into each separately or starting multiple containers with complementary technology on multiple hosts. These challenges are addressed by a technology for orchestrating and managing container deployment.

Kubernetes orchestrates integration solutions deployed on Red Hat Fuse within an OpenShift environment. Kubernetes is an open source project based on Google’s experience running its own applications at scale. With the launch of Kubernetes for container orchestration and management, Red Hat saw an opportunity to collaborate and help standardization efforts in support of container adoption. Red Hat developers are among the leading contributors for both the Kubernetes and Docker projects. According to Stackalytics, Red Hat is the second-largest company contributor to the Kubernetes project, behind only Google itself and the third-largest for Docker.

Kubernetes relies on technology from the Docker project to package, instantiate, and run application containers. Kubernetes then implements a declarative model for managing containerized application deployments, allowing the user to state the desired end state. Once this state is established, Kubernetes applies automated, self-healing mechanisms that can restart and replicate containers, reschedule them on different hosts, and even replicate them for auto-scaling. It is the key component in OpenShift for web scaling, managing, and ensuring the reliability of cloud deployments, including that of Red Hat Fuse.

MuleSoft CloudHub on Amazon Web Services does not use Kubernetes. It uses an undisclosed process to create servers and group or cluster servers and to ensure scalable deployments.

MuleSoft Anypoint Platform On-Premises Version uses Docker Compose to define the deployment topology of Docker images and Rancher to deploy, manage, and load balance the topology. There are several differences in the MuleSoft approach to container management and scalability compared to Red Hat Fuse running on OpenShift.

The MuleSoft environment does not provide a Platform-as-a-Service (PaaS) or Container-as-aService (CaaS) cloud like OpenShift. Such a cloud allows users to create instances of services, like Red Hat Fuse, as needed.
MuleSoft supports use of cloud technology components to deploy individual installations of MuleSoft Anypoint Platform On-Premises Version.
Installation instructions are rigid right down to requiring software to be installed in specific directories on any server used in the deployment topology.

In contrast, OpenShift uses centralized application templates that allow Fuse to dynamically run on any pods in the cloud topology.

PORTABILITY BETWEEN ENVIRONMENTS

All Red Hat Middleware container images used with OpenShift are based on a combination of Red Hat Enterprise Linux and Red Hat Enterprise Linux Atomic Host. This gives the container portability between physical and virtual servers and public and private cloud environments. Portability gives enterprises flexibility. Many customers still prefer running Red Hat Atomic container images within OpenShift Container Platform, using Docker and Kubernetes, with all the benefits of a fully scalable and manageable cloud environment.

SUBSCRIPTION REQUIREMENTS

While Red Hat AMQ is bundled with Red Hat Fuse, production deployment of the other Red Hat technologies requires additional Red Hat Middleware product subscriptions. However, additional subscriptions may not be required for development purposes. A Red Hat Fuse subscription includes development rights to all Red Hat JBoss Middleware platforms. For every 16 cores of a Red Hat Middleware subscription, 25 developers gain development rights for all Red Hat Middleware platforms. As a result, developers can easily explore how products such as Red Hat Data Virtualization, Red Hat Data Grid, Red Hat Decision Manager, Red Hat Process Automation Manager, and others complement Red Hat AMQ. Plus, subscribers get access to patches and bug fixes for these products.

MuleSoft does not offer as broad a portfolio of middleware products, nor the scope of technology Red Hat provides its subscribers. However, MuleSoft customers can augment their product portfolio with Red Hat Middleware products. A good first step towards this is evaluating Red Hat Middleware through the Red Hat Developer Program. The program allows you to deploy, free of charge, certain Red Hat subscriptions for development purposes. Red Hat subscriptions offered through this program are unsupported and may be used for development purposes only. They also may not include all of the latest patches and bug fixes.

PRICE AND SUPPORT

Whenever possible, Red Hat includes a price comparison section in competitive reviews. In this case we were unable to do so since MuleSoft does not make product pricing available to the public. MuleSoft states on its website that MuleSoft Mule ESB Enterprise pricing is based on a combination of core count, subscription tier level, and answers to some deployment questions, such as:

What business processes will MuleSoft Mule ESB Enterprise be supporting?
Which endpoints will MuleSoft Mule ESB Enterprise be connecting?
Is this a mission-critical application?
What throughput do you estimate for the integration? Will it change over time?
How do MuleSoft Mule ESB Enterprise prices compare to the competition?

Red Hat Fuse pricing is less complex and is based on two factors: the number of cores needed and the subscription service-level agreement. For core counts, all Red Hat Middleware subscriptions are available in increments of 16 or 64 cores. Combinations of those increments are used whenever larger core counts are needed and all product functionality is included with every subscription.

Standard subscription service offers coverage during standard business hours. Premium offers 24x7 support for severity I and II requests. Both levels provide unlimited support cases, phone and email support, access to software maintenance releases through the Red Hat Customer Portal, and more. The relationship between Red Hat and its customers is collaborative and consultative—not just when there’s a problem, but during all phases of planning, testing, deploying, maintaining, and upgrading your infrastructure.

Red Hat commissioned IDC to document the many companies that have benefited from Red Hat Fuse. IDC interviewed six organizations that achieved significant business value using Red Hat Fuse by making their application integration and development efforts more efficient and productive. IDC calculates that these organizations are achieving a three-year average return on investment (ROI) of 488%, and earning back their investments in Fuse in 8.2 months by:

Streamlining application integration and development efforts to save staff time.
Integrating and developing more business applications.
Driving higher user productivity levels through quicker access to applications and improved application performance.
Regaining productivity lost to application downtime.
Reducing spend on application subscriptions and hardware costs.

IDC also determined business value benefits of:

51.5% more applications integrated per year.
40.8% fewer full-time employees per application integration.
62.8% less application downtime related to integration.
18.1% improved middleware integration solution performance.
34.2% less cost than previous middleware integration solution.

ADDITIONAL CONSIDERATIONS

OPEN SOURCE LICENSING

Red Hat Fuse and MuleSoft MuleSoft Mule ESB Enterprise both have open source licensing terms associated with products.

Red Hat’s middleware platforms are licensed under the terms of the GNU General Public License (GPL) and GNU Lesser General Public License (LGPL), with the acquired FuseSource products covered under the Apache Software License (ASL). Each of these licenses are used by other open source projects.

MuleSoft Mule ESB Enterprise licensing varies among editions. MuleSoft Mule Community is licensed under the Common Public Attribution License (CPAL), while MuleSoft Mule ESB Enterprise is licensed using a proprietary MuleSoft license. Mule Studio, which is used for MuleSoft Mule ESB Enterprise development, is also licensed using the proprietary MuleSoft license.

CONSISTENT COMMUNITY-TO-ENTERPRISE FEATURES

Both Red Hat and MuleSoft community open source projects are the basis for their enterprise versions. Software-hardening code changes made to enterprise versions are included with a subscription from each company. For example, MuleSoft Mule ESB Enterprise comprises community features covered by CPAL as well as additional functions covered by the proprietary MuleSoft license.

Red Hat Fuse functionality is also submitted to the upstream community projects. This helps simplify the transition to Fuse for customers using upstream community projects. Transitioning from community to Fuse has other benefits such as bug and security fixes and platform certification.

MuleSoft has a significant amount of functionality available in its enterprise edition that is not available in its community edition. For example, all security, performance monitoring, transaction support, operational control functionality, and multiple connectors available in MuleSoft Mule ESB Enterprise are missing from the community edition. Reliability and performance features like high availability and caching are also available only in the enterprise edition.

CONSISTENT ADMINISTRATION AND MONITORING

Both Red Hat Fuse and Red Hat AMQ use the same infrastructure for administration and monitoring. The Fuse management console provides a central interface to manage and configure Fuse entities. You can also use the Fuse management console to configure and deploy containers, Red Hat AMQ brokers, and fabrics. You can also monitor Red Hat Fuse and system resources, perform updates, and start or stop services.

MuleSoft also has a graphical administration and monitoring environment for the MuleSoft Mule ESB Enterprise product. However, this MuleSoft product does not include capabilities for administering any third-party messaging technology. Also, no third party has licensed the MuleSoft administration and monitoring technology, which means MuleSoft customers will have different administration and monitoring experiences with the MuleSoft Mule ESB Enterprise and the messaging platform in use.

SUMMARY

One of the strongest differentiators between Red Hat Fuse and MuleSoft Mule is the close coupling between the integration system (Fuse) and a messaging system (AMQP). This allows much more control and visibility over integration patterns, messaging flows, and the overall system topology. It also provides a broader range of language and application support.

Red Hat Fuse is fully open source and offers more functionality than MuleSoft Mule ESB Enterprise. And when the time comes to find additional middleware to complement your integration technology, Red Hat Middleware offers a rich portfolio of products that can’t be matched by MuleSoft.

For cloud deployments, only Red Hat Fuse is available for use in public, private, and hybrid topologies using Red Hat OpenShift Container Platform—a cloud product based on multiple popular and current industry standard technologies such as OpenStack^®, docker-formatted images, and Kubernetes. Plus, the operating system at the base of OpenShift is Red Hat Enterprise Linux, allowing you to use the same operating system for both on-premise and cloud environments.

All Red Hat Middleware subscriptions include unlimited incident support, version updates, and bug fixes, plus access to the Red Hat Customer Portal, for the full life cycle of your subscription. Should you require on-site assistance, our associates in professional services can be contracted to help with your projects.

Red Hat Fuse is available in 16- and 64-core entitlements at a price point that can potentially provide a rapid return on investment, as reported by IDC. Our subscribers can use the savings that can be realized by choosing Red Hat Fuse and other Red Hat Middleware products to start more projects, deploy more middleware throughout the enterprise, and apply more time and budget toward innovation.

Seleccionar idioma