TriggerMesh Overview & Architecture

IntVerse.io
6 min readJun 18, 2023

--

TriggerMesh is a cloud-native integration platform that allows developers to build event-driven applications.

Here are some of the key features of TriggerMesh:

  1. Serverless Eventing: TriggerMesh enables you to create and consume serverless events using a simple and intuitive API. You can use these events to trigger serverless functions, containerized applications, or any other system that supports HTTP or messaging protocols.
  2. Multi-Cloud Integration: TriggerMesh provides a unified interface for integrating applications across multiple cloud providers and on-premise systems. This allows you to create hybrid and multi-cloud architectures with ease.
  3. Event-Driven Automation: With TriggerMesh, you can automate workflows and business processes by connecting event-driven applications and services. You can use the platform to trigger actions in response to events, such as sending a Slack message or creating a ticket at a service desk.
  4. Kubernetes Native: TriggerMesh is built on top of Kubernetes, the popular container orchestration platform. This means that it integrates seamlessly with Kubernetes clusters and can be deployed as a native Kubernetes application.
  5. Easy to Use: TriggerMesh provides a command-line interface (CLI) tmctl and Kubernetes manifests for us to do deployments programmatically.

TriggerMesh Architecture

TriggerMesh Components

TriggerMesh is built on top of Kubernetes and leverages its capabilities to create a cloud-native integration platform. Here’s a high-level overview of the TriggerMesh architecture:

  1. Event Sources: TriggerMesh allows you to create event sources that generate events in response to a specific trigger. These event sources can be anything from a simple HTTP endpoint to a cloud provider-specific event source, like an AWS S3 bucket or a Google Cloud Pub/Sub topic.
  2. Event Brokers: Once an event is generated by an event source,
  3. an Event is described using a common format that defines the structure and metadata description of events. The format is based on a subset of the CloudEvents specification. TriggerMesh supports the JSON format of CloudEvents and uses the HTTP protocol binding to transport CloudEvents over HTTP.
  4. TriggerMesh uses event brokers as intermediary persistence between producers and consumers. Producers and consumers are decoupled and the broker provides the delivery guarantees.
  5. TriggerMesh provides Memory and Redis-based Brokers. The memory-based has no persistence, whereas the Redis-based broker is able to recover from failure scenarios without losing events.
  6. Triggers are used to determine which events go to which targets. A Trigger is attached to a Broker and contains a Filter which specifies which events should cause the Trigger to fire. These filters are based on event metadata. If a Trigger fires, it sends the event to the Target defined in the Trigger.
  7. Targets: The final stage in the TriggerMesh architecture is the target. Targets are the applications or services that receive events and take some action in response to them. Targets can be any system that supports HTTP or messaging protocols, including serverless functions, containerized applications, and external services.
  8. Kubernetes: TriggerMesh is built on top of Kubernetes and can be deployed as a native Kubernetes application. This means that it integrates seamlessly with Kubernetes clusters and can take advantage of its features, such as auto-scaling, monitoring, and service discovery.
  9. Custom Resources: TriggerMesh extends Kubernetes with custom resources that allow you to define event sources, event bridges, and targets using a declarative YAML syntax. This makes it easy to define and manage your event-driven architecture using familiar Kubernetes tools.

Sources & Targets

TriggerMesh supports a wide range of sources and targets that can be used to build event-driven applications and integrations. Here’s a list of some of the most popular sources and targets that TriggerMesh supports: https://www.triggermesh.com/connectors

Sources:

  1. Cloud Provider Events: TriggerMesh supports event sources for multiple cloud providers, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. These sources allow you to trigger functions or other services in response to events generated by cloud provider services, such as S3, DynamoDB, or Cloud Pub/Sub.
  2. Webhooks: TriggerMesh can receive events via webhooks, allowing you to trigger functions or other services in response to HTTP requests.
  3. Streaming platforms: TriggerMesh supports streaming data from and to Kafka, Redpanda, Azure Event Hub, and Google Pub-Sub.

Targets:

  1. Serverless Functions: TriggerMesh can trigger serverless functions on multiple cloud platforms, including AWS Lambda, Google Cloud Functions, and Azure Functions.
  2. Containerized Applications: TriggerMesh can trigger containerized applications running on Kubernetes clusters or other container platforms, such as Docker Swarm or OpenShift.
  3. Messaging Services: TriggerMesh can publish messages to messaging services, such as IBM MQ, Apache Kafka or RabbitMQ.
  4. Databases: TriggerMesh can trigger actions in databases, such as inserting or updating records in response to events.
  5. REST APIs: TriggerMesh can trigger actions in external REST APIs, allowing you to integrate with external systems and services.

Use Cases

  1. Serverless Workflows: TriggerMesh can be used to create serverless workflows that automate business processes by connecting event-driven applications and services. For example, you could use TriggerMesh to trigger a function that automatically generates a purchase order in response to a customer order event.
  2. Cloud Integration: TriggerMesh provides a unified interface for integrating applications across multiple cloud providers and on-premise systems. This makes it easy to create hybrid and multi-cloud architectures that can leverage the strengths of different cloud providers. For example, you could use TriggerMesh to trigger an AWS Lambda function in response to an event generated by a Google Cloud Pub/Sub topic.
  3. Real-time Data Processing: TriggerMesh can be used to process real-time data streams and generate alerts or take action in response to specific events. For example, you could use TriggerMesh to trigger a function that analyzes IoT sensor data in real-time and alerts maintenance personnel when a machine needs servicing.
  4. Container Orchestration: TriggerMesh can be used to trigger containerized applications and microservices in response to events. For example, you could use TriggerMesh to trigger a Kubernetes Job that performs batch processing of data in response to an event.
  5. ChatOps: TriggerMesh can be used to enable ChatOps by triggering actions in response to messages sent in a chat application like Slack or Microsoft Teams. For example, you could use TriggerMesh to trigger a function that automatically deploys a new version of your application when a developer sends a message in a specific Slack channel.

Deployment Models

TriggerMesh provides a range of deployment models to fit different use cases and infrastructure requirements. Whether you want to deploy TriggerMesh in the cloud, on-premise, or on your own Kubernetes cluster, TriggerMesh provides a flexible and scalable architecture for building event-driven applications and integrations.

TriggerMesh provides a community edition that can be deployed on any Kubernetes cluster, EKS / AKS / GKE / OpenShift / Kind / Minikube / Vanilla / etc…

Observability -

TriggerMesh provides observability support to help you monitor and troubleshoot your event-driven architecture. Here are some of the observability features that TriggerMesh provides:

  1. Metrics: TriggerMesh provides built-in metrics that allow you to monitor the performance of your event-driven architecture. These metrics include the number of events processed, the number of errors, and the latency of event processing.
  2. Logs: TriggerMesh provides detailed logs that allow you to trace the flow of events through your event-driven architecture. These logs include information such as the event source, event type, event payload, and the time of event processing.
  3. Alerting: TriggerMesh supports alerting through integration with external monitoring tools such as Prometheus. This allows you to receive alerts when certain events or metrics exceed predefined thresholds.

TriggerMesh provides the raw information (metrics and logs) that can be used to build custom observability solution.

Gitops -

TriggerMesh is compatible with GitOps approach, with GitOps, you can manage your entire event-driven architecture as code, which provides several benefits such as version control, code review, and auditability.

Here are some of the GitOps features that you can implement for TriggerMesh :

  1. Declarative YAML syntax: TriggerMesh uses a declarative YAML syntax to define your event sources, bridges, and targets. This YAML code can be version-controlled in Git, which allows you to manage your event-driven architecture as code.
  2. Continuous delivery: TriggerMesh integrates with your GitOps pipeline to enable continuous delivery of your event-driven applications and integrations. This ensures that changes to your event-driven architecture are automatically deployed to your environment.
  3. Rollbacks: TriggerMesh provides support for rollbacks, which allows you to revert changes to your event-driven architecture in case of issues or errors.
  4. Approval workflows: TriggerMesh provides support for approval workflows, which allows you to enforce code review and approval processes before changes are deployed to your environment.

At IntVerse.io, we are excited to offer services for TriggerMesh, a cloud-native integration platform that allows developers to build event-driven applications.

Our team of experts can help your organization implement, manage, and optimize TriggerMesh to achieve maximum value and performance across any cloud providers and On-premises.

--

--

IntVerse.io
IntVerse.io

Written by IntVerse.io

We Solve Platform & Integration Problems in the UniVerse

No responses yet