Companies are leveraging TriggerMesh to build software that is more event-driven, automatable, and integratable than previous generations. There are loads of integration platforms on the market, but not many cater to the needs of companies building software or software platforms for which event-driven integration is a core requirement. 

Modern software is event-driven. Is yours?

TriggerMesh 1.18 is the latest release of our open source, cloud native integration platform. In response to user demand, we’re making it easier to get started with TriggerMesh with loads of new and improved documentation. For DevOps teams, it is easier to get useful telemetry from TriggerMesh into your monitoring stack, and to leverage Kong solutions for cluster ingress and service mesh. Last but not least, we’ve improved TriggerMesh’s multi-cluster and multi-cloud capabilities by enabling cross-cluster communication through CloudEvents, and integrating Amazon EventBridge as a new source. 

TriggerMesh 1.18

Multi-cluster CloudEvents

Larger organizations are multi-cluster, where clusters are allocated to different teams, projects, and environments depending on the organization’s topology. But having applications and teams operating on different clusters, sometimes across clouds, shouldn’t mean they can’t establish event-driven integrations with each other. 

TriggerMesh clusters can now communicate by exchanging CloudEvents by means of our CloudEvents Source and CloudEvents Target. This takes the platform one step towards enabling an enterprise-wide event mesh. To learn more, take a look at our new user guide on the topic that illustrates how to implement the cross-cluster integration shown in the diagram below.

Amazon EventBridge

Since AWS released Lambda a decade ago, we’ve seen strong adoption of the serverless computing philosophy, in which developers focus more on writing business logic and connecting high-level services together through APIs and events, as opposed to operating infrastructure. The release of Amazon EventBridge in 2019 has only accelerated this trend and is a good illustration of the paradigm shift brought upon by serverless: serverless is event-driven. 90+ Amazon service now emit events that are ingested by EventBridge and can be consumed by other Amazon services or functions through a highly decoupled pub/sub model. 

With the new TriggerMesh EventBridge Source, any software developer running on any cloud can leverage the full breadth of valuable events provided by AWS applications and infrastructure to make their software more event-driven and integrated.

Improved telemetry

No DevOps or SRE wants to run a production system blind to what is happening under the hood. As more organizations include TriggerMesh in their environments, they asked for guidance and increased visibility into the system’s telemetry. We’ve delivered on this by improving the way components expose metrics and producing new documentation to help get you up and running fast with the Prometheus and Grafana stack. Upcoming product releases will continue to standardize and improve the way TriggerMesh components expose metrics. 

Using Kong with TriggerMesh

If you’re a Kong shop and would rather use Kong’s Kubernetes ingress and Kuma service mesh for networking in your cluster, we’ve got you covered. We’ve tested TriggerMesh with these cutting edge open source solutions and published new guides to get you up and running fast.

Enhanced documentation

We’ve published a ton of new guides and documentation pages, covering everything from monitoring, to networking, error handling and debugging, and more. There is still a lot that TriggerMesh is capable of but that isn’t clearly documented and we’ll continue to improve our documentation’s content and structure in upcoming releases. 

What’s coming next

The TriggerMesh open source integration platform releases minor updates every month. Here is a sneak peak at some of the topics we’ll be working on for upcoming releases.

Test automation. One of the challenges with event-driven architectures is testing. As the number of mission critical TriggerMesh bridges grows in a system, so does the need for testing. And the more automated tests are, the more comfortable an organization will be to make regular changes to the system and thereby become more agile and improve time-to-market. This is one of our most requested features and we’re happy to be working with our community to find the approach that brings the most value across the spectrum of possible testing approaches, from unit testing through to integration and E2E testing. This isn’t a small topic and will require multiple iterations. 

Kafka authentication. Kafka is one of the most popular message brokers in the industry at large, and we’re noticing the same trend across the TriggerMesh user community. But each Kafka distribution has its idiosyncrasies and authentication and authorization is one of them. We’re working to improve and simplify authentication for Kafka when used as a source, a target, and as a TriggerMesh Broker, across distributions including open source Kafka, Confluent, and RedPanda. 

Try TriggerMesh 1.18 today

To try TriggerMesh or update to the new version you’ll find the entire open source platform on our GitHub repository. 

If you’d like to get in touch with our founding team to discuss how TriggerMesh can help improve the way your organization develops and integrates modern software, schedule some time with us here.

‍