Note: In March 2020, VMware changed the name of Pivotal Cloud Foundry (PCF) to VMware Tanzu.
Is there a “best way” to enable various types of hybrid cloud architecture?
One of my favorite things about my role at Solace is listening to the daunting challenges many of our prospective customers face, helping them (if I can) find solutions to their questions, and of course hearing about the innovative ways they’ve applied those solutions.
Many of them are addressing challenges by leveraging microservices architectures and platforms as a service such as Pivotal Cloud Foundry (PCF), but they find themselves unable to innovate at the pace they expected.
The problem doesn’t lie with microservices in general or PCF in particular, but with the challenge of getting business events to the right application at the right time. This is where so many questions about hybrid cloud architecture arise. Sound familiar?
The challenge of hybrid cloud migration
Today, we as architects are faced with the challenge of creating more business capabilities faster, but with the added reality of reducing costs. These constraints have not only changed how we build new applications but also where we deploy them.
The shift to the cloud and predominance of microservices are examples of these changes. What is often not considered, however, is that most large businesses cannot simply “lift and shift” their enterprise to the cloud. Additionally, they often neglect to realize that their current hybrid cloud architecture is where they will be for the foreseeable future—and often as an end state.
Enterprises are living in a reality where systems and applications all behave differently; some workloads are static, others dynamic; some are real-time, others batch; some are microservices, others mainframes; the list goes on.
The challenge lies in the ability for systems to communicate and share business events while supporting their inherent differences and missions. That’s where Solace comes in.
Solace and PCF: a match made in hybrid cloud heaven
If you’re an architect who uses PCF, you may know that Solace produces a messaging and data movement platform which is available as a Tile from Pivnet. With this option, we wrap our Virtual Message Router (now referred to as Solace PubSub+) with a set of orchestration instructions which are in turn executed by BOSH.
It allows applications and microservices running inside the elastic runtime to easily communicate amongst themselves as well as communicate with the outside world via TCP-Routes. But what if:
- You want the SaaS model where messaging is managed and maintained for you?
- You need to support an application estate outside of PCF?
- You have real-time processing requirements?
In short, you’ll need more flexible communication options for your heterogeneous environment.
Solace provides the only implementation of a uniform messaging fabric which is available in three unique form factors:
- Hardware Appliance (3530 and 3560)
- Software; and,
- Cloud
What this enables you to do is pick the best option for a given use case and mix and match across the enterprise.
Take, for example, a business that has chosen Pivotal Cloud Foundry to run on-premise and also has mainframes which generate business events and performs analytics and machine learning in the Amazon cloud (an increasingly common hybrid cloud architecture).
The mainframe and some of the applications running in PCF are very static and process approximately the same workload every day but in near real-time. Conversely, other applications in PCF are very dynamic and change based off current “offers” or time of year but are less real-time (i.e., latency is driven by the human user).
Finally, all events generated out of these static and dynamic use cases need to flow from on-premise, across the WAN/Internet, to Amazon for analytics and machine learning.
Uniquely, we can connect applications and microservices, running in PCF with mainframes, all in real-time (with 99.999% availability) using our hardware appliances. Dynamic microservice use cases are perfect for our PCF Tile/Software offering because you can easily and dynamically add additional messaging instances for new offers and for development.
Finally, analytics and AI processing in the AWS cloud can leverage our cloud offering so that the business can focus on acquiring business value, not running the Solace product.
But wait, didn’t we just partition our system into three different messaging implementations, thus isolating them from each other?
We see this happen all too often in many large enterprises. The legacy/mainframe systems use their standard set legacy messaging implementations, microservices use modern queueing and/or streaming implementations, and the big data analytics team chooses yet another data movement solution.
This paradigm has proven to become an integration, cost, and management nightmare! Luckily, that is not at all what we are proposing. Rather, all our form factors have the same APIs and wirelines and can easily be federated together to seamlessly share and exchange business events.
This combination of deployment form factors, standard APIs and wirelines for system/application integration, data federation and WAN optimization is what makes Solace the no-brainer choice for the hybrid cloud architectural reality of enterprises today. Solving these types of challenges is exactly what puts Solace into a different league for data movement and is why I love my job!
If you’re interested in connecting either our Hardware Appliance or cloud form factors to your PCF applications, please read this post for a step-by-step tutorial of how to configure a user provisioned service.
Conversely, if you want to try out our Solace Messaging Tile for PCF visit our page on Pivnet.
See Also:
Explore other posts from categories: DevOps | For Architects