Reason 5: Infrastructure and application consolidation

This is part 5 in a 10 part series: 10 reasons for the growth in middleware appliances. The series summarizes what we’ve learned from our clients about what they value in appliances and why they selected Solace.

Five or ten years ago it was relatively easy to figure out messaging middleware requirements. If you needed messaging between data-oriented applications, you would (most likely) buy MQ Series from IBM. If you were into open systems like Sun or HP, needed more throughput than MQ, or valued vendor choice, you probably bought JMS.  If you had some applications that used high-volume publish subscribe, like market data, you probably chose TIBCO Rendezvous. Messaging over the WAN was always possible, but none of the commercial products did it very well, since it was usually just the LAN version deployed over a low-bandwidth, high-latency link. So applications with WAN data sharing requirements still tend to use export -> ftp -> import scripts or homegrown software.

Companies with all of these requirements (i.e. most companies) usually have five or more messaging products deployed, from multiple vendors, each with their own datacenter footprint, different skillsets and learning curves, and of course, a series of bridges and gateways to get traffic between messaging platforms. No company sets out to have a jumble of incompatible technologies, but it happens because each technology was the best choice for the niche problem it addressed at the time.  Things have only gotten more complicated with recent innovations supporting ultra-low latency use cases, and appliances like Solace’s turning the table on some longstanding messaging assumptions.

Wasted Time, Wasted Money

Buying and maintaining multiple middleware products is wasteful in so many ways:

• Multiple commercials, contracts and licenses – Each product requires its own technical evaluation, commercial negotiations, buying process, and license agreement.
• Multiple upgrade cycles – Each product has its own release cycle, and every upgrade entails its own product and O/S patches to perform, followed by regression testing to make sure a newly upgraded platform still plays well with its host hardware, client applications and fellow message platforms.
• More education and operational effort – Each product introduces the need to train architects, developers and administrators on a new, unique API and environment.
• Lots of bridges and gateways – Each type of middleware often acts as an island. When you need to get between islands, you have to build a bridge! Many enterprises build and maintain their own middleware bridges or gateways, which must have a scaling strategy to assure the link between the messaging clouds does not become a bottleneck, and of course, are subject to having to be reworked each time either of the products changes.
• Server sprawl – Different messaging backbones are usually deployed and scaled independently on non-overlapping hardware.

Consolidating the Myriad of Middleware

Solace’s message router is the first product to implement all of the major kinds of messaging in a single, easy to manage appliance. There’s no “jack of all trades” sacrifice though…for each type of messaging middleware, our goal is to achieve at least an order of magnitude improvement over the best-in-breed software. So a given application that needs to consume or publish information in a variety of ways (e.g. low latency market data, persistent messaging for back office applications, and efficient WAN communications) no longer needs to use a variety of APIs to tap into multiple platforms  Solace delivers a turnkey product, that’s better and faster at each type of messaging, and it’s all integrated and ready to roll right out of the box so developers can focus on coding core functionality with the confidence they can use Solace’s API to access whatever messaging functionality they need.

Consolidating Infrastructure Under Applications

Today, if you have 10 MQ-based applications, chances are you run them on 10 separate MQ footprints to make sure their traffic doesn’t overlap. The primary reason is because the capacity of a given broker (say 1, 000 messages a second for MQ) makes it impractical to run multiple apps. Solace’s peak rate for equivalent guaranteed messaging is 150, 000 messages per second, so you can deploy dozens of applications on the same appliance without fear of the river of data overflowing its banks.

There’s one more driver of software messaging sprawl to more and more applications: good old fashioned politics. For example, at a bank the equities team doesn’t want to risk problems that may arise if the foreign exchange or fixed income teams mess something up. Even if there is no technical reason for the division, there may be perceived risk of security or other issues causing problems across divisions. Solace has implemented hardware based virtualization – the ability to divide one Solace installation into multiple Virtual Private (middleware) Networks so groups of connected applications are completely segregated from each other (security, topic space, etc.). Traffic from one virtual layer cannot find its way to another layer – and each layer can be configured with its own quality of service including limitation of the percent of overall resources its allowed to consume.

Faster, Cheaper, Easier Redux

Many of the reasons customers we hear are variants of the first three covered in this top 10 list. Each type of messaging gets a performance boost, consolidation saves lots of money, and the turnkey appliance makes everything easier. In this case it’s the combination of attributes that makes consolidation rise into the top 10 on its own.

This is a pattern we’ll see a couple more times in the final five items on our list.

On to Reason #6…