TriggerMesh cloud-native automation goes open source

Serverless computing is getting a kick in the pants as TriggerMesh goes open source under the Apache license.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

You can call what TriggerMesh does a lot of things. It's cloud-native integration, event-driven cloud automation, Function-as-a-Service (FaaS), or, of course, serverless computing. No matter what name you use -- TriggerMesh's creators like "serviceful" -- the game is to enable you to easily hook, deploy and manage cloud functions into powerful programs. Personally, I find it handy to think that TriggerMesh takes the DevOps concepts of such programs as Ansible, Chef, and Puppet and moves them from the operating system level to the cloud layer. Now, TriggerMesh has taken a major step forward by becoming an open-source program.

As TriggerMesh co-founder Sebastien Goasguen put it, with TriggerMesh, developers can modernize "their applications by taking advantage of cloud services wherever they are and from whoever the provider is." It does this by taking advantage of FaaS offerings that auto-scale and provide a finer billing mechanism. 

If that sounds to you a lot like AWS Lambda, congratulations, you're right. But while Lambda is tied to AWS, TriggerMesh's field is wide open to any cloud supporting Kubernetes.  Which, of course, these days, means all clouds essentially. But, Goasguen thinks that we make a mistake if we focus too much on functions. Instead, he said, we should keep in mind that serverless offerings like AWS Lambda are actually about events: ingesting, storing, emitting, and processing events."

What TriggerMesh brings to the table, said Goasguen is it enables you to integrate all kinds of services together. "Whether it is an on-premises application or a cloud service; whether it is containerized or not; whether it is called serverless or not; you are building applications that leverage many systems." Of course, the problem with integrating so many different systems is avoiding  building a "'bowl of spaghetti,' which might be delicious but would be unmaintainable." 

TriggerMesh Cloud-Native Integration Platform managed this by giving every user a set of application programming interfaces (API)s. You can use these to define the beginning and end of integration or, in TiggerMesh jargon, sources and targets. To this work, the APIs also offer event transformation, event routing components, and a FaaS offering. These APIs are defined using the OpenAPI spec and implemented with Kubernetes.

TriggerMesh is a Kubernetes controller with all its APIs defined as Custom Resource Definitions from an engineering perspective. This means that if you're already a Kubernetes pro, you already know many of the programs it calls upon to get work done. These include Prometheus for monitoring, Fluentd for logging, and GitOps for deployment.

In its open-source release, besides the program itself, it also provides the sources you need to work with most AWS services like SQS, S3, and Kinesis, sources for Google Cloud Storage, Pub/Sub, and Cloud Audit Logs. In addition, it's also releasing Azure sources for Azure Blob Storage and Azure Audit logs. Put it all together, and Goasguen claims TriggerMesh provides you with the capability of Google EventArc and AWS EventBridge combined and on-premises. In addition, targets such as AWS SQS, Google Storage, Google Sheets, ElasticSearch, and Splunk are supported.

So what does all this mean? Goasguen gives a laundry list of multi-cloud examples of what you can do with it. These include: "Building a data pipeline to fill your data lake, storing all your Git commits or all your Salesforce events in an ElasticSearch cluster. You can grab all your logs from Azure and store them in Splunk after filtering and annotating them. You can grab metrics from anywhere and store them in Datadog. You can run an AWS comprehend analysis on objects stored in Google Storage. You can sync your IBM-MQ and your AWS SQS as you are developing new products in the Cloud; you can stream DB2 changes to the Cloud to build a read-only Cloud replica. You can manage your Kafka connectors whether you use AWS MSK or Confluent Cloud, no need for a Kafka connect cluster anymore, and welcome to a GitOps workflow to manage your product and consume messages into Kafka." In short, you can "build any event-driven application and define it with our Kubernetes-backed declarative API."

That's quite a claim, but TriggerMesh supporters, which include Cisco and VMware, think they have the goods. 

Graham Siener, VMware Tanzu's VP for Product, said, "As event-driven systems become more popular, developers are realizing that integrating events across sources and environments is a big challenge. This is exacerbated by hybrid and multi-cloud topologies that lead to more disparate sources of all shapes. So when we looked at our options to provide Cloud Native Runtimes users with a single API for automating how events are consumed, regardless of the event source, TriggerMesh was the clear partner. The integration with TriggerMesh makes it easy for Knative eventing resources to consume external events across all the clouds,"

TriggerMesh co-founder Mark Hinkle added, "When Sebastien and I started TriggerMesh, we had a long history with open source. We had seen plenty of success but also seen plenty of failures. That's why we wanted to make sure we did everything in our power to make sure we had the same kind of success that we saw from HashiCorp, Confluent, Kong Inc., and Ansible by Red Hat." In other words, TriggerMesh has experienced people at the helm who know what's what with both open-source and cloud-native programming.  

Want to know more? Check out the TriggerMesh repository and TriggerMesh's docs. You can also talk with the development team on Slack.

Related Stories:

Editorial standards