Amazon EventBridge vs TriggerMesh

Amazon EventBridge is a serverless event bus service for AWS users with a strong focus on routing events across services in the AWS ecosystem.

As an open-source alternative, TriggerMesh provides similar functionality but works across the three major cloud providers, enabling multicloud and hybrid cloud scenarios. Both provide very similar core capabilities which are to ingest events from various sources, define subscriptions with filters, and deliver events via push to event consumers. But there are major differences such as their operating models (managed vs self-hosted) and business models (usage-based pricing vs open source with optional support).

Let's compare the two feature-by-feature to enable you to make informed decisions on which platform aligns best with your specific needs.

Get started Reach out on Slack

Comparison

Amazon EventBridge

TriggerMesh

Connectivity

AWS connectors

AWS SQS, AWS S3, …

Google Cloud connectors

Google Pub/Sub, Google Cloud Storage, …

Azure connectors

Azure Service Bus, Azure Storage Blob, …

Kafka connectors

Read and write to and from Kafka topics

HTTP connectors

Receive events on HTTP and push events to targets over HTTP

SaaS connectors

Ingest events from external SaaS applications.

Requires the Amazon Partner event sources functionality.

Limited number of SaaS connectors.

Event Flow

Push-based delivery

Events are pushed to consumers, as opposed to consumers polling for events.

At-least-once guarantees

Events are delivered at least once to destinations, with a possibility of duplicates.

Retries

Define how many times a failed delivery should be retried.

Dead lettering

Events that weren’t delivered are sent to a dead letter queue or sink for later processing.

Pipes

Directly connect event producers to event consumers without creating and configuring a broker in between.

Event batching

Batch events before sending them to the destination in order to reduce load on the receiver.

Event Processing

Filters

Filter which specific events from the broker should be sent to destinations.

Transformation

Transform events as they pass through the system.

Replay

Replay past events according to their timestamps and contents.

Schema registry

Validate events against schemas, and deserialize binary data formats.

User Interface

GUI

Graphical console for management and monitoring

Declarative config

Describe configuration declaratively in files that can be versioned.

CLI

Developer-friendly way to use the product from the command line.

SDK

Use the product with dedicated libraries for your preferred programming languages.

REST API

Imperatively configure the product by making calls to a central management API.

Deployment Model

Managed by the vendor

Operations are fully handled by the vendor

Run it anywhere yourself

The solution provides the flexibility to run anywhere you want.

Open source

Source code is freely available and reusable for any purposes, external contributions are warmly encouraged.

Community support channels

There are places you can go to freely interact with users of the product.

Consuming events from within Amazon EKS

EKS is Amazon’s managed Kubernetes service. There are times when platform teams will want to run many of their workloads on EKS. But if you want to ingest AWS events (or others) into EKS to trigger workloads there, there is no immediate way to do this with EventBridge, particularly if EKS is running in a VPC and can’t expose an API endpoint for EventBridge to call into as an API destination. There are other workarounds though such as using a Lambda function as a relay, or going through SQS or Step Functions.

TriggerMesh can run natively on EKS from where it can pull events into the cluster from external sources or AWS services and easily trigger workloads on the cluster. Granted in some cases TriggerMesh needs an intermediary SQS queue to pass the notifications through, but you’re still avoiding adding EventBridge into the mix.

Creating a cloud-agnostic serverless platform

If you are heavily invested in the AWS ecosystem, and want a hosted solution that provides tight integrations with AWS services, EventBridge could be the preferred choice.

If you value multicloud portability, a Kubernetes-native workflow, and open-source, then TriggerMesh is worth taking a look at. By choosing to create a serverless integration platform on Kubernetes, you can benefit from being able to port your platform, and the applications that run on it, across any managed or self-hosted Kubernetes distribution.

FAQ

What is TriggerMesh’s positioning with respect to Amazon EventBridge?

TriggerMesh is an open-source, multicloud alternative to Amazon EventBridge.

Is it possible to use TriggerMesh in combination with Amazon EventBridge?

Yes, TriggerMesh can be used as a source of events into Amazon EventBridge through the partner integration. TriggerMesh can also be used as a destination for Amazon EventBridge, for instance by using the Amazon EventBridge API destination, and the TriggerMesh Webhook source.

Can EventBridge be used to trigger workloads that run in EKS or other Kubernetes clusters?

The answer is it depends. On its own, EventBridge cannot push events into an EKS cluster if the latter is running in a VPC. There are alternative ways to address this by using a relay Lambda function, or an intermediary SQS queue or Amazon Step Functions. Alternatively, TriggerMesh can pull events from AWS services like S3 and SQS into EKS (rather than have the events pushed into the cluster), and can transform, filter and route the events to trigger containerized workloads running on EKS.

Create your first event flow in under 5 minutes

Get Started

We use cookies (and other similar technologies) to improve your experience on our site. By using this website you agree to our Privacy & Cookies Policy

Got it