TriggerMesh has introduced an integration with AWS EventBridge, now in preview, that enables virtually any application, on-premises or elsewhere, to fire events in the service for automated workflows.
The way EventBridge works is that it receives events, processes them according to rules the developer defines, and then forwards them to targets such as functions running in AWS Lambda, logs in AWS CloudWatch, or a queue in AWS Simple Queue Service (SQS). The source of the event is either another AWS service, with many predefined events such as calls to the S3 (Simple Storage Service API), or an integration with a third-party service such as Datadog, MongoDB, or Zendesk. EventBridge also has a PutEvents API that developers can call from custom code.
TriggerMesh, launched in November 2018, is an independent cloud service which is in concept somewhat similar to EventBridge, but instead of being restricted to target only AWS services, it can target multiple platforms including Azure Functions, Google Cloud Run, Kubernetes, Apache Kafka, OpenShift, as well as AWS services such as Lambda. TriggerMesh itself is built on Kubernetes, Knative and Istio.
In AWS EventBridge, the list of pre-configured third-party services which can serve as sources for events is relatively short. TriggerMesh has introduced a new integration with its own cloud service, which means that any event source TriggerMesh supports can now be forwarded to EventBridge. This also means that existing TriggerMesh users can now target any AWS service which EventBridge supports.
Why use TriggerMesh, when developers can already call the PutEvents API from any application? "We do believe that many folks end up doing just what you suggest, adding the integration to each piece of code you are executing," TriggerMesh co-founder and CEO Mark Hinkle told The Register.
"We believe this is redundant and only allows for a hard-coded integration to a single service, in this case EventBridge. However, by using TriggerMesh it would give you the option to trigger workloads on any cloud native architecture: Azure Functions, Google Cloud Functions, OpenShift Serverless, or the Kubernetes flavour of your choice including Rancher, OpenShift Container Engine, Google Kubernetes Engine, and/or Amazon EKS. Or you could create application flows to other services that aren't part of AWS for example, populating Confluent with event data or triggering a function on Twilio without a rewrite to your code."
TriggerMesh has particular value if you are working across multiple clouds or diverse services. "For example, a new line added to a database may trigger an ETL [Extract, Transform, Load] function on Amazon and output the results to S3," said Hinkle. "However, it could be used to notify a supply chain every time a new record is entered in the database. Or it could do both simultaneously."
That said, hooking up event sources to TriggerMesh will not always be straightforward. As with EventBridge, there is a list of pre-baked integrations, as well as the ability to connect to on-premises event buses like IBM MQ. In some cases TriggerMesh is still working on "event transformation to make those events into a recognized format so Amazon EventBridge can consume them," said Hinkle. There is also an offer to create one-off integrations for "users who may not have the expertise to extract and transform events on their own".
Redmonk analyst James Governor wrote of "the coming SMOKEstack", a term invented by Hinkle to describe composable services which are "Serviceful, Mashable, Open, K(C)composable, Event-driven."
Businesses that embrace the idea of using an event-driven, serverless model for multi-cloud integration need some kind of cloud broker, and TriggerMesh is aiming to be that broker, though it is early days. ®