The Situation You Face
In order to create a single data movement fabric that allows you to deploy applications in any cloud, you need to cover three types of connectivity:
- Messaging within each cloud – between distributed applications or microservices in each target cloud
- Hybrid Cloud data movement – between your existing on-premise apps and your new cloud apps
- Cloud-to-cloud data movement – so applications running in different clouds can share information
Most enterprises have in place some form of on-premise message bus like IBM MQ or JMS, which can be based on open source or provided by a vendor.
When it comes to deploying new applications in a public cloud, many enterprises will inevitably use multiple regions and/or have a strategy that involves more than one public cloud – either for commercial, technical or lockin reasons. Many will also have a private cloud, which could be an IaaS running VMWare or OpenStack, or a PaaS running Pivotal Cloud Foundry (PCF), OpenShift or Kubernetes (which of course you can also run in public clouds too). In any event, you’re talking about an environment that’s just grown from a simple on-premise deployment to one that spans multiple cloud technologies and locations.
Since the applications you deploy into the cloud will likely be 12 factor applications or microservices, you will need messaging in each of these clouds to connect these components. Most people have decided, for good reason, that they are not going to use their legacy messaging in the cloud. The path of least resistance out of the gate is to use a given cloud’s own messaging solution –SQS or SNS in AWS, Service Bus in Azure, Google Cloud Messaging in Google Cloud Platform, RabbitMQ in Pivotal Cloud Foundry and ActiveMQ in OpenShift.
In a three-cloud architecture, you end up with three new and different cloud technologies, each with its own API which complicates development and prevents you from easily moving applications from one cloud to another. It also means complexity in governance and management, and even “as a service” offerings require that you establish governance. But using the cloud native services is a fast way to get up and running, so let’s assume we go with that and see what happens next.
Legacy to Cloud – Hybrid Cloud
Applications don’t exist in a vacuum – they consume and produce data that comes from or goes to other applications, most of which live on-premise since that is the bulk of the IT base for enterprises today. So you want to have a distributed application span your existing IT assets and your new multi-cloud environment. How do you connect these legacy applications to the cloud to create a hybrid architecture?
If you have chosen 3 different messaging technologies in your 3 different clouds, then you need 3 different ways to move data from your enterprise architecture to the cloud. Since the data you chose to move to the cloud is always changing and the applications in the cloud are evolving, how do you administer the dynamic data movement requirements of these disparate components in a coordinated way? If you currently have both JMS and MQ messaging, for example, you’ll need six different interconnects (JMS x3 clouds; MQ x3 clouds). Such integrations don’t come “out of the box” for the cloud-based messaging services, so you’ll need to build each one, and make sure they are fast, manageable, secure, fault tolerant, etc. – all the properties you expect of data movement infrastructure.
This is starting to look complicated…
Cloud to Cloud – Multi-Cloud
If you run applications in multiple clouds, you will likely need to connect those applications so they can share data. Again, if you have 3 different cloud messaging technologies then you need 3 different ways to connect them and you have to build, scale, secure and administer that yourself too.
This looks like the pairwise integration architectures of old that were too fragile and complex and were replaced with messaging – only now instead of interconnecting applications we are connecting messaging technologies. More complexity.
In this approach, what other things are there to consider?
- Application Portability. For many of you, the freedom and flexibility of running applications in the cloud is very important as you don’t want to get locked in to one cloud – you’ve been there before. Even if you aren’t worried about using a single cloud, the ability to develop apps in the cloud and deploy them on-premise remains an attractive way to do development. In general, application portability is valuable in a world so difficult to predict. Most cloud services either offer proprietary APIs built on a RESTful messaging protocol that is custom to that cloud, or they offer a limited JMS API that also uses HTTP under the hood. That means in most cases, applications are developed to the API and capabilities of one cloud offering, which means they are not portable from one cloud to another without development effort.
- Enterprise Grade Features. Many application developers today are used to sophisticated messaging functionality and exchange patterns, and expect those features to exist in this new and improved cloud world. Features like pub/sub and queues from the same API, asynchronous I/O, wildcard subscriptions, session-based transactions, message priority, message selectors, dead message queues, time-to-live, and message rate limiting to name a few. They expect messaging to support their chosen application runtimes such as JEE and more modern tools like Spring Cloud, and Spring Boot, and they’re disappointed to learn that such features and integrations are often not supported by cloud-based messaging services.
- WAN Performance & Bandwidth Costs. Many cloud-specific messaging services use HTTP to send/receive messages. This doesn’t allow for streaming, so you have to send one message at a time and wait for a response before sending the next message. Some let you batch messages together but your application needs to do that, which means more complexity. In any event, message rate is limited by round trip time, which introduces high, inconsistent latency. Most public clouds also charge for outgoing bandwidth so intelligent message routing and filtering is needed to avoid surprisingly high monthly bandwidth charges. Capabilities like WAN optimization and compression are almost always missing from messaging services, too, even though they are critical in a hybrid/multi-cloud architecture.
- Management / Monitoring. You will typically care about the performance of your applications and you can get some visibility of that from your data movement infrastructure, but in this case, you will have one such monitoring and management system for every cloud you are using. Also, in this type of a hybrid/multi-cloud environment, there are communication paths that fall outside the scope of any one cloud provider’s service, so you’ll need to build custom monitoring solutions that will each need to be configured, monitored, engineered and managed on an ongoing basis. Creating these adds to your development and maintenance costs but they are critical to the proper operation of your system.
- Simplicity & Robustness. The more heterogeneous an environment, the more complex it is and the more fragile it is. In this case, there are many different technologies with many different connectors that lead to ongoing operational challenges.
- Custom development and integration. The cloud is supposed to make things easier, to let you spend less time and money on infrastructure thanks to more “turn on and go” capabilities. The use of multiple messaging solutions introduces the need for significantly more custom development, integration and operations work to integrate these disparate systems.
The question is: what is my alternative?
Let’s Talk About a Better Way:
Open Data Movement
Solace Open Data Movement technology has been designed specifically to create this hybrid and multi cloud Digital River by addressing the challenges of hybrid cloud and multi-cloud connectivity.
Solace technology is integrated with and can be “one click“ deployed in all leading public clouds such as AWS, Azure and Google, leading private Infrastructure as a Service technologies such as VMWare and OpenStack and leading Platform as a Service offerings such as Pivotal Cloud Foundry and OpenShift. That means your applications can make use of the same messaging services and APIs no matter what cloud they run in, so you have a uniform messaging service that spans clouds. It also means you can move your applications between any public and/or private clouds without any code changes. This also means all your DevOps for provisioning, monitoring, alerting and security are the same in each of your clouds. So if a policy changes to favor a new cloud, or you find benefit in going to some other cloud, we’ve got you covered. Just bring your data movement technology with you.
Legacy to Cloud – Hybrid Cloud
Solace has successfully underpinned some of the world’s most demanding use cases and deployments for years now, and many of our customers are moving to various forms of cloud. We provide four out-of-the-box ways to extend your current applications to a multi-cloud architecture:
- For Solace customers this multi-cloud fabric just “drops in”: your on-premise Solace enterprise message bus seamlessly connects to your Solace cloud-based bus without any additional components. The static and dynamic message routing and integrated WAN optimization capabilities you are probably using today work the same way when extending to the cloud.
- To access data flow without changing existing applications, our technology lets you tap into your existing IBM MQ or JMS enterprise message bus and transfer information to your new application(s) in the cloud(s) without any changes to your on-premise applications. Data produced by cloud applications can also be streamed to your existing enterprise bus for delivery to existing applications. Streaming messaging over a secure connection ensures fast, reliable, WAN-optimized movement of your real-time data either to or from any cloud.
- Existing enterprise applications or 3rd party applications that use JMS or runtimes such as application servers or Spring frameworks can connect directly to Solace messaging on-premise to move their data to the cloud.
- We provide a variety of open APIs for new on-premise applications to connect directly to a Solace data movement fabric if that’s the direction you want to go. We support JMS, JCA, REST, MQTT and soon AMQP 1.0 as open interfaces and APIs in many languages. That way you can take advantage of new data movement technology in your non-cloud apps to modernize and simplify your on-premise architecture.
Most enterprises have applications developed in many different languages and frameworks, and the cost and time to change them is massive. Being able to connect these applications to the cloud or migrate them to a simpler on-premise architecture to connect them to the cloud is a big win.
Cloud to Cloud – Multi Cloud
Solace technology reliably and securely routes messages between cloud providers, and between regions of the same cloud without needing any adapters. We support non-persistent quality of service for use cases that demand high speed streaming and request/reply; as well persistent delivery to ensure that there is no message loss for your critical messages that need to be delivered between clouds regardless of WAN fragility, lack of bandwidth, etc. We also support streaming compression (up to 80%) and de-duplication over these cloud links to significantly reduce your bandwidth usage. Since most public clouds charge you for the bandwidth that leaves the cloud, this data compression translates to serious savings every month – who wouldn’t like that?
Here are some of the other advantages of Solace’s solution.
- Application Portability. Using Solace Open Data Movement in all your public and private clouds means the same messaging services are uniformly available to your applications in all these clouds, so you can easily move applications from one cloud to another. Solace provides many open APIs (JMS, JCA, MQTT, REST, OpenMAMA and soon AMQP1.0) and integrates with many cloud runtimes (like Spring Cloud, Spring Boot) to also avoid application lockin to our technology. We believe in open interfaces and freedom of choice.
- Enterprise Grade Features. Solace supports all the key enterprise features you are used to in designing your applications, along with features that are specific to applications like price/odds distribution, asynchronous web push, IoT connectivity and more so you can build sophisticated applications with diverse communication needs all on a single platform.
- WAN Performance & Cost. The WAN optimization capabilities we support can dramatically reduce the cost of bandwidth leaving the public clouds, which is an important consideration as you watch your savings accrue month after month. This same transport compression is not only available for use between Solace messaging nodes, but if you use our APIs, you can also benefit from this bandwidth reduction for applications connected from outside the cloud.
- Management / Monitoring. We provide rich management capabilities that include statistics and status about message rates, queue depths, buffer usage and lots more at the level of a virtual broker, specific queue and even individual connections. You can set thresholds so you’re alerted about conditions such as slow consumers or consumer apps you need to scale, slow links between clouds and on-premise disk full and much more. Solace technology works with a wide range of enterprise and cloud-based monitoring systems, and can be integrated with your firm’s existing authentication and authorization systems.
- Simplicity & Robustness. It has always been our goal to provide a single messaging solution for all of your data movement needs. That’s why we’ve integrated all the functionality for hybrid and multi-cloud deployments into a single technology stack for ease of deployment and a simple, robust architecture with fewer moving pieces and points of failure. Solace technology includes features like high availability, replication for disaster recovery, congestion control mechanisms – all to provide a robust data movement platform you can rely on.
- Out of the Box. The beauty is that all this hybrid and multi-cloud connectivity works right out of the box. No need for any custom development for integration or monitoring – its all ready for you to use.
Its tempting when moving to the cloud to take the path of least resistance and use technology that is native to that cloud. Makes you feel like you are moving fast. But you could end up with buyer`s remorse. The problem is that over time, your architecture becomes very complex, fragile and restrictive. Soon you are no longer moving fast. Getting the data movement piece right can save you the large hidden costs associated with heterogeneity and simultaneously enable future options for application evolution. Its important to focus on the big picture rather than the tactical – a better solution is readily available.
Providing this type of simple hybrid and multi cloud data movement fabric is what we at Solace are committed to doing – so you can focus on and be efficient at developing and deploying your applications – wherever you want to develop or deploy them.
We are honored to be working with some of the most prestigious brands in the world to help them with their on-premise data movement needs and to now be helping them with their transition to the cloud. For one customer, we provide elastic capacity for odds distribution to mobile applications; for another we provide IoT connectivity to vehicles; for another we provide hybrid connectivity for end of day risk calculations. All of these are awesome applications that are changing their business.
Exciting times ahead!