Google Eventarc Alternatives for Event-Driven Architectures: Comparing Hookdeck, Amazon EventBridge, Azure Event Grid, and Confluent Kafka
If you're building an event-driven architecture in Google Cloud then you've probably already taken a look at Google Eventarc. But before you commit, it's worth considering some of the alternatives to Google Eventarc to see if they are more flexible and offer a more complete solution.
In this comparison article, we'll look at four Google Eventarc alternatives and consider how well they:
- Integrate with data sources and data destinations
- Transform and enrich data in-flight
- Handle failure
- Ease the developer experience
The alternatives we'll consider are Hookdeck, Amazon EventBridge, Azure Event Grid, and Confluent's managed Kafka.
So, before you decide on Google Eventarc, read on to make sure you're making the right choice.
Comparing Google Eventarc alternatives
At the heart of every event-driven architecture is an event gateway tool that ingests events and then delivers them to a destination. But beyond that basic functionality, there's a huge variety in the approaches that different event gateway tools take.
Some, like Eventarc, focus on moving events from one place to another and rely on additional tools for anything more complex. While others, such as Hookdeck, offer a more complete solution in one tool. The scope for variety is so big that even within the Google Cloud ecosystem, Eventarc sits alongside Google Pub/Sub, which takes a different approach.
So, to make our comparison manageable, we need a common set of criteria:
- Integrations with event sources and destinations: Does it work with your existing tooling? How easy is it to set-up new integrations?
- Does it offer rich in-flight processing? Or do you need to integrate other tools to transform and enrich events?
- Can it store events? Almost every event gateway can store events long enough to retry delivery but what if you need something longer-term?
- What auth options does it offer? Authenticating, authorizing, and signing data sources and destinations is part and parcel of running an event gateway. Does it offer common standards and integrations or does the tool lean too heavily on the cloud vendor's own IAM system?
- Is observability built-in? Most event gateways integrate with third-party tools like Datadog, whereas some also provide their own monitoring dashboard and tooling.
- Does it offer a good developer and operator experience? Each of the tools we're considering is a managed service but they each make different demands of you. We'll look at what that means for each alternative to Eventarc.
What is Google Eventarc
Google Eventarc is a tool for ingesting events and delivering them to destinations. For example, let's say you have a Google Cloud Function that performs currency conversions as part of an e-commerce system. Your frontend calls an API endpoint managed by Google API Gateway and that emits an event into Eventarc. According to rules you've already defined, Eventarc then delivers the request to your currency converting Cloud Function.
In a typical environment, that would be just one of many scenarios where Eventarc acts as the communication layer between different systems within your event-driven architecture. Ideally, Eventarc would sit at the center of each part of your application's tech stack and manage the communication between them.
To understand whether Eventarc is up to the job, we'll first need to understand more about the approach it takes.
Google Eventarc key features
Let's start with a quick summary of what makes Google Eventarc tick:
- Event pattern: When events come into Eventarc, it checks them against predefined rules. If there is a match, Eventarc sends the event on to the destination defined in the rule.
- Event format: Supports the CNCF's CloudEvents standard.
- Event integrations: Eventarc consumes events from many Google Cloud services, such as BigQuery, Firebase, and API Gateway. It can integrate directly with a limited number of external sources, such as Datadog and Lacework. Eventarc is more limited when it comes to delivery, though, integrating with just a few systems including Google Cloud Functions, Google Cloud Run, and Google Kubernetes Engine. Eventarc does not integrate directly with arbitrary external data destinations.
- Processing: Eventarc doesn't make any changes to events, meaning you'll need to route events to other tools for transformations and enrichment.
- Storage: Other than storing failed events to retry them, Eventarc doesn't offer event persistence.
- Routing: Eventarc can route events to different destinations according to where they come from, their data, and their metadata.
- Observability: Eventarc doesn't have its own monitoring but it does integrate with both Google Cloud Logging and Google Cloud.
- Error management and recovery: Eventarc retries events for up to 24 hours and can route failures to a dead-letter topic, but this must be configured manually in Google Pub/Sub.
- Operational impact: Eventarc is serverless, meaning it should have a low impact on your operations team.
Those are the fundamentals of Eventarc, so what does it do well and where is it lacking?
Google Eventarc advantages
- Relative simplicity: If you don't need complex routing or rich in-flight processing, Eventarc's simplicity might mean that it's easier to work with than a more complex alternative.
- Supports a standard event format: The CNCF CloudEvents standard could simplify integrating with external sources that also support that format, even though you'll need an intermediate tool such as API Gateway to make the actual connection.
- Scales on demand: Event Grid scales as and when you need it to, within some limits.
Google Eventarc disadvantages
- Heavy focus on Google integrations: Eventarc is suitable if you only integrate with Google Cloud products. However, Eventarc might be less suitable if you need to integrate with non-Google systems. Consuming events from external sources is possible if you can first route them to another Google tool such as Pub/Sub or API Gateway. However, Google Eventarc does not integrate directly with external data destinations. One way around that would be to write a Cloud Function that handles the final delivery on your behalf, but that somewhat reduces the benefit of a multipurpose event gateway tool.
- It doesn't transform or enrich events: If you need to process events before they reach their destination, Eventarc asks that you direct them to another tool and then back into Eventarc for subsequent delivery. That added complexity makes it harder to set-up and maintain event routing.
- Events are effectively ephemeral: Beyond storing events to enable retries, Eventarc disposes of them once they've passed through the system. To store events, you'll need to route them to another tool.
Google Eventarc alternatives
Now that we've seen just how narrow a focus Eventarc has, we should find out whether the four alternatives we're considering offer a better solution. Of course, the final answer will depend on the needs of your project, but we can get a clearer picture by looking in detail at:
- Hookdeck: An end-to-end event gateway solution that works primarily with webhooks, making it easy to integrate with a wide variety of sources and destinations. Hookdeck also offers complex in-flight processing using JavaScript, plus observability tools, and it boasts support for a wide variety of auth methods.
- Amazon EventBridge: Point-to-point event delivery with some limited in-flight processing. However, thanks to its custom event format and reliance on a custom API for integrations, it can be somewhat more difficult to work with than Hookdeck, for example.
- Azure Event Grid: Publish-subscribe event routing tool that can ingest events using both HTTP and MQTT but lacks event processing.
- Confluent Kafka: Powerful yet complex pub-sub event streaming platform. Kafka offers flexibility with customizable retention policies, event replay, and real-time data transformations. However, this requires significant operational and development effort.
Hookdeck
Hookdeck is an all-in-one event gateway solution. That means it can integrate with a wide variety of external data sources and destinations, offers complex inflight processing, and provides a range of supplemental tools that make it easier to work with.
Hookdeck key features
- Ingests common data sources: Hookdeck slots into your existing infrastructure, thanks to its support for webhooks and inbound API calls. That means Hookdeck can ingest events from a broad variety of sources without the need for custom integration work. For event delivery, Hookdeck uses outbound HTTP requests to integrate with any event destination, including your own endpoints and other external API services.
- JavaScript-based in-flight event processing: By creating your own JavaScript event processing scripts, you can enrich and transform events as they pass through Hookdeck. That reduces your reliance on additional processing tools.
- Tunable event retries: If event delivery fails, Hookdeck lets you decide whether and how often to retry delivery.
- Build event pipelines visually: Hookdeck's dashboard makes it simple to create and manage event pipelines.
- Event and integration auth and verification: Hookdeck offers basic auth, API key auth, and integration with various auth providers. For verification, you can use generic signing methods to verify webhooks at the set-up stage and HMAC for payload verification.
- Observability: When an issue arises, such as a delivery error, you can monitor and discuss them as a team using Hookdeck's issue tracking dashboard. Similarly, you can view the end-to-end health of your event-driven architecture with Hookdeck's observability tools.
How does Hookdeck shape up against Google Eventarc?
On the surface, Hookdeck and Eventarc perform similar roles. However, they both do that in very different ways.
The most noticeable difference is that Hookdeck is an all-in-one tool. Whereas Eventarc is only useful as part of a larger group of Google products, Hookdeck gives you everything you need to ingest, route, process, and deliver events.
Hookdeck's integrations and ability to process events in-flight has the potential to greatly simplify your event-driven architecture. Rather than needing multiple tools and stages in your event pipeline, Hookdeck lets you learn and use just one serverless platform.
Feature | Hookdeck | Google Eventarc |
---|---|---|
Simple to set up and manage | ✅ | ℹ️ If you need external data destinations, Eventarc is not simple to set up or manage |
Consume external event sources without custom development | ✅ | ❌ |
Deliver to any HTTP destination | ✅ | ❌ |
Multiple forms of auth | ✅ | ✅ |
Complex in-flight processing | ✅ | ❌ |
Configurable data storage | ✅ | ❌ |
Error handling and recovery | Configurable retries for up to 30 days, depending on plan, as well as rate limiting | Retries for up to 24 hours, followed by dead letter topic |
Built-in observability tooling | ✅ | ℹ️ Integration with Google Cloud monitoring tools |
Amazon EventBridge
Amazon's offering in this space is EventBridge. EventBridge comes in three versions, each tailored to specific use cases:
- Event Bus: This is the closest to Google Eventarc, offering point-to-point routing between multiple sources and destinations.
- Pipes: Designed for ETL-like workloads, Pipes provides fixed connections between sources and destinations with more sophisticated in-flight processing.
- Scheduler: Allows you to time the delivery of events in a cron-like fashion, ideal for scheduled tasks.
Amazon EventBridge key features
- Point-to-point event delivery: Connect sources and destinations directly, using rules to decide which events get delivered where.
- Event format: Unlike Eventarc, which relies on the CloudEvents standard, EventBridge has its own event format.
- Consuming events: When it comes to the AWS ecosystem, EventBridge's data source support is roughly equivalent to Eventarc's in the Google ecosystem. However, EventBridge offers some more flexibility for external event sources through the PutEvents API, Java SDK, and CLI.
- Event consumers: EventArc's major failing is its lack of support for external destinations. EventBridge does a much better job in this regard, supporting webhooks and third-party APIs, as well as delivery to AWS products.
- Lightweight processing: EventBridge offers simple in-flight text transformations. For more complex processing, you'll need to integrate with your own Lambda functions or other systems.
- Archival storage: Like all the options we're comparing, EventBridge stores failed events so that it can attempt re-delivery. It also offers event archival so you can replay events later.
How does Amazon EventBridge compare to Google Eventarc?
Choosing between Amazon EventBridge and Google Eventarc is mostly down to whether you're already committed to the AWS or GCP ecosystem. However, if you haven't yet decided on one public cloud over another then is there a good case for choosing EventBridge rather than Eventarc?
Let's put them side-by-side.
Feature | Amazon EventBridge | Google Eventarc | |
---|---|---|---|
Simple to set up and manage | ℹ️ Requires custom development to integrate external data sources | ℹ️ If you need external data destinations, Eventarc is not simple to set up or manage | |
Consume external event sources without custom development | ✅ | ❌ | |
Deliver to any HTTP destination | ✅ | ❌ | |
Multiple forms of auth | ❌ | ❌ | |
Complex in-flight processing | ❌ | ❌ | |
Configurable data storage | ❌ | ❌ | |
Error handling and recovery | Retries for up to 24 hours, followed by dead letter queue | Retries for up to 24 hours, followed by dead letter topic | |
Built-in observability tooling | ℹ️ Integration with Amazon CloudWatch | ℹ️ Integration with Google Cloud monitoring tools |
Azure Event Grid
Just like Google Eventarc and Amazon EventBridge, Azure Event Grid will be of most interest if you are already working with its parent cloud platform. However, Event Grid has much more to offer than its Google and Amazon counterparts.
Event Grid uses a pub-sub model, where event consumers subscribe to named topics rather than specifying each destination for a trigger or rule. This model simplifies management as your system grows. It streamlines handling multiple destinations, making scalability and maintenance easier.
Another standout feature is that Event Grid provides two ways to consume external events: MQTT and HTTP pull delivery. This gives you more options for integrating with different systems with minimal need for custom development.
Azure Event Grid key features
- Publish-subscribe: As your event-driven architecture grows, with more integrations and a greater flow of events, Event Grid's pub-sub model could be easier to scale thanks to decoupling event producers from event consumers.
- Ingests MQTT and webhooks: Like Eventarc, Event Grid integrates directly with products from its own cloud ecosystem. But what makes Event Grid particularly interesting is that it reduces the work of integrating with external data sources through its support for MQTT, webhooks, and the CNCF CloudEvents standard.
- No rich in-flight processing: If you want to transform or enrich events, then you'll need to route them out to another tool.
- Lacks storage: Similar to Eventarc, Event Grid only stores events when it needs to retry a failed operation.
How does Azure Event Grid shape up against Google Eventarc?
Event Grid and Eventarc have some key differences, especially in terms of integrations. If your use case involves consuming external events and sending events to external destinations, Azure Event Grid is the stronger option.
But what about the pub-sub model? Does it really matter? Again, it depends on your use case. It simplifies the process of adding or removing event consumers because you can unsubscribe the relevant consumers from the topic instead of needing to amend a rule or trigger. However, if you want to centralize control of your event routing, then Eventarc's approach of configuring destinations using triggers and rules might be more suitable.
Feature | Azure Event Grid | Google Eventarc | |
---|---|---|---|
Simple to set up and manage | ✅ | ℹ️ If you need external data destinations, Eventarc is not simple to set up or manage | |
Consume external event sources without custom development | ✅ | ❌ | |
Deliver to any HTTP destination | ✅ | ❌ | |
Multiple forms of auth | ✅ | ❌ | |
Complex in-flight processing | ✅ | ❌ | |
Configurable data storage | ❌ | ❌ | |
Error handling and recovery | Retries for up to 24 hours, followed by dead letter topic | Retries for up to 24 hours, followed by dead letter topic | |
Built-in observability tooling | ℹ️ Integration with Azure Dashboard | ℹ️ Integration with Google Cloud monitoring tools |
Confluent Kafka
Kafka is the most versatile and complex of the alternatives. It offers great flexibility, but that comes at the cost of operational and development complexity.
Confluent's managed service simplifies running Kafka, but its operational footprint will inevitably be larger compared to Eventarc, Hookdeck, Event Grid, or EventBridge.
Whether you should use Kafka comes down to three questions:
- Do you need control over every aspect of the event's life cycle within your system?
- Do you need long-term event storage with the option for playback?
- Do you have the development and operational expertise to make the most of Kafka's potential?
Confluent Kafka key features
- It can do a lot but at a price: Kafka started as a solution for LinkedIn to handle large data volumes. It has since evolved into a sophisticated event processing and streaming platform that integrates with diverse systems. However, Kafka's extensive capabilities come at a cost. Be prepared to allocate significant time for development and operational maintenance.
- Learning curve: If you don't already have Kafka skills on your team, you'll either need to hire individuals with these skills or allocate time for learning and development.
- Pub/Sub: Kafka's data model is built around an append-only log and the pub/sub model. Event consumers subscribe to topics, while producers publish events to them.
- Open ended storage: Kafka stores every event, and you can choose how long you want to keep them. That's ideal if you need the ability to replay events or bring new consumers up to speed.
- Lots of integrations: As well as Confluent's REST proxy for ingesting events via HTTP requests, Kafka boasts direct integrations with many different tools. That includes kSQL, which allows you to query and transform Kafka data using SQL, and a Java real-time stream processing tool in the form of Kafka Streams.
How does Confluent Kafka shape up against Google Eventarc?
Comparing Kafka with almost any other tool is tricky because it almost exists in a category of its own. Even its closest rival, Amazon Kinesis, lacks the ecosystem that Kafka offers. However, the biggest difference between Kafka and Eventarc is that no version of Kafka is serverless. You'll need to devote more of your team's time to running Kafka than any of the other products we've considered here.
So, unless you have a use case that can be served only by Kafka, then you might find it demands more of your team than the value it can offer in return.
If you need greater functionality than Eventarc can offer, with the flexibility of a cloud-neutral tool, Hookdeck is a better choice as an event gateway solution.
Feature | Confluent Kafka | Google Eventarc | |
---|---|---|---|
Simple to set up and manage | ❌ | ℹ️ If you need external data destinations, Eventarc is not simple to set up or manage | |
Consume external event sources without custom development | ✅ Some custom code may be required if a data source connector does not already exist. | ❌ | |
Deliver to any HTTP destination | ✅ Requires REST API addon | ❌ | |
Multiple forms of auth | ✅ | ❌ | |
Complex in-flight processing | ℹ️ Requires Kafka Streams or kSQL integration | ❌ | |
Configurable data storage | ✅ | ❌ | |
Error handling and recovery | Highly configurable, limited by available storage | Retries for up to 24 hours, followed by dead letter topic | |
Built-in observability tooling | ✅ | ℹ️ Integration with Google Cloud monitoring tools |
Reviewing Google Eventarc alternatives
Your choice of event gateway tooling significantly impacts your ability to deliver reliable functionality, minimize operational costs, and meet deadlines.
If you're not already committed to the Google Cloud ecosystem, Eventarc doesn't offer significant advantages over its alternatives. Even if you plan to build your entire application on GCP, Eventarc's limitations might lead you to use additional tools to fill in the gaps.
In choosing your event gateway tooling, you should consider:
- How easy it is to work with, both from a development and operational viewpoint.
- Does it have the integrations you need? If it doesn't, how easy is it to add them? Is it likely to keep pace in the future as you need to integrate with new tools?
- Does it give you the control you need over filtering, routing, transforming, and enriching events?
- Can you feel confident that you understand what's going on under the hood, thanks to its monitoring tooling?
- How does it cope when things go wrong?
For a deeper review of the options available, see our in-depth comparison of five of the most popular event gateway tools.
Try Hookdeck for free or share your EDA requirements and book a demo
A reliable backbone for your Event-Driven Architecture