THE MULESOFT ACQUISITION AND THE IMPORTANCE OF CONTEXT PART II
A question we get quite often at AppBus is how we compare to a platform like MuleSoft. This is an understandable question given that MuleSoft is at its core an ESB and AppBus has “bus” in its name. The short answer is that there is some overlap in functionality, but the two companies are solving different problems. This post will focus on the areas where the technologies overlap. In some cases, these common features will be in direct competition. However, more often than not, the functionality overlap is a natural integration point between the two solutions.
It is important to start by stating that a bus simply facilitates a given architectural pattern. While a bus is an essential component to MuleSoft’s and AppBus’s respective products, the platforms they support can be quite different. A speedboat and a racecar both have internal combustion engines, but they have very different emergent properties when you consider the vehicle as a whole.
Bus-based architectures are a fundamentally sound approach to robust and scalable integrations. The first and most important area of overlap between the AppBus eXperience Platform and MuleSoft is the inclusion of a bus technology as a cornerstone component of each company’s respective platforms. Both buses support getting and setting values, along with the typical publish and subscribe behaviors you would expect from an ESB. Both support a horizontal scale-out architecture. For simple cases where you need some semi-centralized persistence layer to help facilitate a given integration, both solutions expose interfaces for using the provided bus in this way. It is when you examine the higher-level functionality provided by these platforms that the two solutions begin to diverge.
MuleSoft’s focus is on providing developers with a way to create an API economy. Schema definitions and API middleware functionality are important pieces of the MuleSoft platform that sit on top of the Mule ESB. If you are looking to rationalize existing API’s or create new ones from scratch backed by MuleSoft’s middleware capabilities, then MuleSoft’s solution may be a good fit. AppBus places less emphasis on API schema design, and greater focus on using the bus to facilitate integrations and extend the functionality of applications. AppBus provides the ability to create RESTful API’s on top of existing applications that lack a well-defined interface, but these interfaces typically map back to a given piece of the automation. These mounted API’s (and any pre-existing API) can publish and subscribe to AppBus’s bus.
Another area of overlap between the two solutions is that both provide middleware functionality. If data needs to be transformed in any way before being stored on the bus, both solutions provides ways to programmatically interact and transform the payload prior to setting it to a given value on the bus. So, basic data normalization use cases could be supported by either solution.
Any bus worth its salt is built with interoperability in mind. MuleSoft’s and AppBus’s respective bus technologies are no exception. Because AppBus also provides a containerized workspace all the way to the edge, there will be valuable data related to a user’s interaction with applications that might be relevant to both AppBus and Mulesoft. Sharing data between buses is a trivial task. The needs of your project will ultimately dictate whether you need one or both platforms. In part three of this series, we will explore some of the features that are unique to AppBus which should help clarify how and when to use the respective solutions.
Every architectural choice comes with a set of trade-offs. If your primary focus is on optimizing workflows and providing a greater level of integration between applications, then it may not make sense to overdesign the API layer used to support those interactions. That begs the question, when would it make sense to reach for a platform like MuleSoft? Does your project have sufficient resources, like a large in-house development team with deep experience designing and implementing API’s? Is the underlying data exposed through your applications and existing API’s more valuable outside the narrow context of how it is used today? Is there a business requirement for the project to build entirely new apps from scratch powered by these new API’s? If the answer is yes to all of those questions, then MuleSoft’s platform may be a good fit for your given project.
When would it make sense to leverage AppBus’s platform? Does your project include applications that lack well-defined programmatic interfaces where it is impractical to replace the application in a timely manner? Is your project’s scope primarily concerned with automating and integrating workflows while preserving as much of the existing value provided by your current applications? Do you lack a way to deliver all of these services to the edge? If so, AppBus’s platform may be a good fit for your project as it allows you to preserve the existing value delivered by your applications, incorporate new applications and ultimately generate value by allowing your applications to efficiently share data through AppBus’s distributed bus technology. For real-world projects, it is rarely an all or nothing choice between the platforms, and in part 3 of this series we’ll dive into some of the components of the AppBus eXperience Platform that make it so unique and valuable to organizations.