olly - Fotolia


Should bus technologies be used at all?

Should today's enterprises bother using bus technologies? Tom Nolle answers this question by examining the role of the bus, including the old enterprise service bus.

There was a time when an enterprise service bus (ESB) was considered the heart of enterprise IT. Today, not only are ESBs under attack as worse-than-obsolete, several development trends seem to argue against even simpler message busses. In this tip, we explore the critical question: Should you use bus technologies and, if not, what's the alternative?

To bus or not to bus? The answer to this question begins with an understanding of the types and values of busses, moves to what are the alternatives to busses for current distributed and Web applications, and finally addresses how you can both bus and not-bus at one time.

Bus technology in IT is designed as a way to decouple software elements that cooperate to process work in transaction or message form. Rather than sending work from a source to a specific set of destinations, bus architecture allow work to be put on the bus and removed by the correct process wherever it happens to be. This is more agile than a traditional design where components would call each other explicitly, and where seemingly simple changes then propagated throughout the structure of the application.

Bus technologies have evolved

If you've relied on bus technologies for these missions and you move away from the bus approach, you'll need to augment your application lifecycle management practices, or you risk compromising your information and business processes.

Arguably today's bus technologies have emerged from the basic message bus that provides a simple means of interfacing among distributed processes. Over time, more sophisticated features have been added to provide format control over information and registration of processes. There's also been a shift from simple bus approaches which generally have one destination per message, to a broker architecture that supports multiple ones, and also in many cases offers publish and subscribe dynamism. This evolution has created considerable confusion about just what to call a message system, and this was one driver behind a general concept of message-oriented middleware.

Today, we have products categorized as message or service busses, the latter including the ESB. All the current products have added considerably to the basic feature set of early busses, and it's more this feature growth (some would say bloat) that has created a kind of anti-bus backlash. Most busses are supplied as opaque products and those who use them may be unaware of the overhead associated with all the things they can do, which leads to tragic errors in design that result in performance problems.

The basic question for busses should be: Do you need the features? Bus architectures have evolved to support component coupling so loose as to be extemporaneous, and now often include transformation capabilities to harmonize interfaces and logic to steer messages. All of this is great if you want component registration and workflow harmonization to be done at runtime or to occur without software-architect mediation, but it does add to cost and overhead.

To assess busses, consider the alternative

Perhaps the best approach to assessing the value of busses is to address their alternative. If you don't have bus architecture, you'll need to manage work transfers among components through some other means. The best-known is the storefront design pattern. A single component acts as a "storefront" to broker multiple features that are accessible through it. Each storefront component knows its subordinate features, but these features are abstracted by the storefront and so they're invisible to the store user.

Storefront design patterns have become very popular for microservices; they represent a preferred way of implementing them. The use of a storefront lets a complex process be divided into simple tasks in any way that's reasonable, and those tasks are distributed wherever it's useful, without any impact on the user of the process.

The success of a storefront system depends on selecting the stores, meaning dividing functionality up so that high-level processes are represented by stores that are then decomposed into microservices. It's easy to define too many high-level processes and in doing so expose process details that could change as software design evolves or even through the use of things like virtualization or cloud computing.

A combination of modern Web and REST componentization and API designs, combined with the use of microservices and the storefront design pattern, could probably eliminate the use of busses for new applications in nearly all cases. The problem for the software architect is that there aren't many greenfield opportunities to test this theory. Most development today interworks with and augments existing designs, which are often bus-based.

Presume that you'll bus when you must

The best option overall is to presume that you'll bus when you must. Application evolution today is focused on functional evolution driven by mobility and Web access, and resource dynamism driven by virtualization and the cloud. Handle both and you'll probably handle the bus-or-not-bus question efficiently.

For Web and mobility functional evolution, you can build front-end elements to your existing applications that employ a storefront-microservice architecture, then feed the results to a traditional bus-based application back end for processing to preserve existing software. This is best handled by terminating your Web flow in a component that will manage state for the stateless front-end elements and insulate the bus-linked components from front end changes by supporting a static data structure.

For resource-dynamism evolution, expect that your issue will in most cases be to support scaling of component instances under load changes, or replacing instances in the event of failure. To address these, consider building a new bus-linked component that acts as a storefront to a microservice set that is designed for horizontal scalability and failover. Eventually, you may be able to replace the bus structure with a storefront of storefronts.

Service and message busses can, if used properly, improve security and compliance management. If you've relied on bus technologies for these missions and you move away from the bus approach, you'll need to augment your application lifecycle management practices as they relate to security and governance, or you risk compromising your information and business processes. Don't just jump on the everything-new bandwagon; busses have their benefits.

Next Steps

Learn more about moving from ESBs to microservices.

How to build an ESB.

Dig Deeper on Distributed application architecture