Migrating to the Hybrid Cloud? Leave Your Legacy Messaging Behind

The future of information technology is in the cloud. Your data and applications workloads might end up in a public cloud, private cloud or more likely both, but the advantages of cloud computing are clear, making the migration inevitable.

Hybrid cloud architectures include today’s datacenter and both private and public clouds. Today the datacenter houses the majority of your workloads, but most new workloads will be cloud-first, so the balance of power will quickly shift until datacenters are the lonely realm of legacy holdouts.

That makes it important to ask yourself this question: Does the messaging you rely on in your datacenter today make sense in the cloud?

Enterprise messaging products like IBM MQ and TIBCO EMS were created back when “full stack” mentality was all the rage. They were designed to move messages within a datacenter, mostly between elements of that vendor’s own tool set. They relied on proprietary protocols and made direct optimizations to underlying operating systems, all of which makes them poorly suited to virtualization in the cloud.

As you migrate to the cloud and plan for next generation applications that mix best-of-breed open source code with tools from many vendors, it makes sense to leave behind those closed, proprietary, datacenter-centric messaging products and look toward open, standards-based messaging that runs natively in all of the popular IaaS and PaaS platforms in private and public clouds.

What does “open” mean in hybrid cloud messaging?

• It means a preference for standardized protocols like AMQP and MQTT, and open source APIs like Qpid and Paho. If you’ve chosen tools that support REST, JMS, AMQP via QPID APIs, or MQTT via Paho APIs, those products should be able to connect directly into the data backbone and start sharing immediately. No shims, no bridging, just modern integration via standard APIs.
• It means being free to mix those open protocols as best fitting each task. For example, your IoT device-to-datacenter needs are best met with MQTT, while JMS or AMQP can give you more power for your core data systems. REST is an easy way to make web and mobile connections. You should be free to use them all without having to bridge traffic between protocols yourself.
• It means being free to choose and migrate between public clouds, like Amazon, Google and Azure, and popular IaaS and PaaS environments like OpenShift, Pivotal Cloud Foundry, OpenStack and VMware.

These are the principles behind Solace’s next-gen, cloud-ready messaging, and they’re not properties the prior generation of products like MQ and EMS will be able to retrofit into their aging products.

With support for open, standard protocols like JMS, REST, MQTT, JCA and soon AMQP, plus the ability to run in public clouds, private clouds and datacenters, Solace offers the flexibility and portability you’ll need to gracefully migrate assets and information to the cloud on your own schedule. Solace supports all the messaging features you need to build enterprise-ready offerings in cloud and on-premise, all easily integrated with your legacy systems. Solace also handles all the protocol switching between endpoints, so a REST or MQTT client can publish data that is received by a JMS or AMQP connected application.

A few years ago participants in an Open Source Think Tank event came up with a definition for “open” that I like: “Open refers to a process that generates trust, permitting positive interdependence”. Yesterday’s vendors still focus on guiding you towards their tools stack, leaving you with not so positive dependence on them (lock in). With Solace, you can achieve positive interdependence with all of your datacenter and cloud environments across all of your applications as you plan and implement your future IT architecture.