We don’t mean this in the “unity” sense, though that might be what the world needs now.
No, we mean TriggerMesh Cloud Native Integration Platform is GA!
This number has a great ring to it, doesn’t it?
With TriggerMesh 1.0, all your apps and systems across the hybrid cloud can communicate in real-time and function as 1. I know I packed a lot into this sentence. Let’s unpack it, shall we?
Thanks to the hard work of the TriggerMesh team, and the pioneering spirit of our Beta customers, with GA we are confident in supporting production instances of TriggerMesh. Does it mean it’s done? No, not by a long shot. But it does mean we have robust end-to-end testing in place, along with security protocols, scalability testing, and every developer’s favorite, solid docs! More importantly, TriggerMesh represents a major step forward for businesses looking to scale up their use of event-driven architecture.
TriggerMesh Cloud Native Integration Platform 1.0 Features include:
Distributed systems are the norm today, and this means running different parts of your business on different “clouds.” I put clouds in parenthesis because usually when people see that, they think big public clouds. And yes, that’s part of it.
But the cloud is not the cloud is not the cloud. In other words, we are in a “multi-cloud” world. Many businesses run an on-premises Kubernetes-based cloud, maybe with Red Hat OpenShift, or Rancher, or VMware Tanzu.
Then there are specialized dedicated clouds for CRM (Salesforce), Data Analytics (Datadog), voice and SMS messaging (Twilio), Elastic, Confluent, and so on. And last, but certainly not least, we have the generic public clouds.
And all of this is great. It means we can – and DO – outsource the undifferentiated infrastructure to those who can do it best. But it does present a dilemma for those of us responsible for designing the applications – and application flows – our business needs.
The dilemma is – how do we exploit best-of-breed by outsourcing to the best possible cloud for each workload, on one hand, and still preserve the ability to connect these disparate services together?
And this is where Events come in. Events are the lingua franca of the new multi-cloud architecture. The really great news is that we already have the building blocks we need in order to have a common layer across all these clouds.
Events are the fabric of cloud computing. They provide a way for cloud services to share information and allow them to work together in synchronicity and in real-time.
Broke - Batch-based integration
Woke - Real-time event-driven integration
You may be able to relate to a recent experience I had with my doctor’s office that highlights the problem with batch based integration. They sent several electronic forms to me by email to be completed prior to my appointment. But of course I procrastinated and didn’t complete them until a couple hours before my visit. When I arrived, they had not been synced with the front office systems, which turned their well-oiled machine into a ten car traffic jam.
The nurses scrambled for a physical copy of the paperwork for me to sign. They manually overrode the carefully designed protocol and thirty minutes later the system resulted in a backlog and an unnecessary amount of extra work for them.
Let’s be clear - this is the opposite of the frictionless user experience every business we talk to has as their goal for digital transformation.
The TriggerMesh Cloud Native Integration Platform allows users to integrate services, automate workflows, and accelerate the movement of information and the digital transformation of an organization. TriggerMesh acts as a catalyst for digital transformation, enabling organizations to build event-driven applications out of any on-premises application or cloud service.
Going back to my hapless doctor’s visit, had an event-streaming system like Kafka been used to indicate that a document was signed, a process could have been kicked off to replicate the document into the healthcare system or at the very least checked a box saying I had signed the required paperwork.
The automation design pattern that has become very common is that of functions-as-a-service which are triggered by event producers. Next, the function does its work and scales up to accomplish this as quickly and efficiently as possible. Then when the work is complete it automatically scales back down to zero.
Once things are integrated and automated, the last step is to accelerate the speed at which these things happen. My initial flu shot example demonstrated that there was integration and there was automation but the system lacked acceleration. If the system had been designed to update based on real-time events, I would have sailed through the drive-thru rather than causing a backlog. In this case, the systems would have benefited from an event-driven architecture where the updates from one action immediately inform the inputs of the next action.
TriggerMesh enables event-driven architecture by providing a way to scale event-streams and make them actionable. For example, TriggerMesh can consume events from an OracleDB and use them to inform financial systems without connecting directly to the database for security reasons.
If you like the sound of all this, please get started with a free trial today.