TriggerMesh Vision for Cloud Native Integration
Hi everyone! I know it’s been a while since I posted here. 2020 has been nuts for everyone, between COVID, working from home in what is absolutely not normal working from home, social distancing and the like, I think everyone has been stressed and in somewhat of a funk. I am no stranger to this funk, but let’s try to get out of it :)
Things have been quite busy at TriggerMesh during COVID, we closed our seed round 4 months before the lock downs, despite of that we got going. I want to start posting again with an update on our vision and direction for cloud native integration.
At TriggerMesh, we are building what we call a cloud native integration platform. I admit that at first glance ‘cloud native integration platform’ is a bit of a mouthful. But if you’ll indulge me, it’s actually a very simple concept that I think will make sense to cloud native developers and people experienced with Kubernetes.
I’m going to start from the end — ‘Integration platform.’ This is no different than what we’ve been doing in the enterprise for quite a while — namely, integrating different applications together, usually through some type of messaging system, point A to point B, through a messaging channel. It goes back to some of the basic principles of service oriented architecture (SOA), enterprise service bus (ESB), and so on. The enterprise integration patterns are well known.
In many ways, enterprises today are doing exactly the same thing — building and integrating applications. The big difference is that now, we need to start doing it in a cloud native manner and leverage our entire Cloud migration/adoption initiatives.
What does this mean?
It means that the application building blocks are containerized and they frequently run on a platform like Kubernetes. Plus, being cloud native, it means that a lot of the end points we’re trying to integrate come from the cloud. They come from infrastructure clouds, or generic clouds like Google, Azure, AWS, etc. They come from ad hoc clouds like Salesforce, and Twilio, etc. So very much, the integrations we are now doing are multi-cloud.
That’s what we mean by cloud native. And this new mode of building apps creates a unique set of integration challenges to bring multiple clouds together with on-premises applications.
So, TriggerMesh focuses on integrating this multi-cloud and cloud native environment and, critically, we help AUTOMATE all these integration. Taken together, integration and automation can accelerate our customers’ time to market when you’re building a new app and bringing it to your customers. TriggerMesh gives our customers the platform they need to integrate, automate, and accelerate (the TriggerMesh moto by the way !)
I want to zoom in on the automation piece, because we believe this is critically important. Automation is key because we believe in building integration as code. We want integrations to be defined through a set of API objects, following the OpenAPI specification, and very friendly to the entire Kubernetes ecosystem. So you have to think about using Kubernetes API objects to declare integrations. And of course, when we talk about integration as code, this means that the integrations can be driven by your CI/CD system and continuously delivered to your setup.
Managing and deploying integrations with CI/CD means now all your integrations benefit from this powerful automation. You benefit from your CI/CD security, review process, testing, etc. It’s hard to overstate how significant this is. In our view, this makes it hard to justify an expensive and slow ESB-based integration approach. When the necessary controls are built into your CI/CD pipeline, adding TriggerMesh integration as code makes getting the integrations you need faster and easier without sacrificing the enterprise security you need.
To recap, Cloud Native Integration is defined by five core components:
- Declarative API
All integrations can be described by a set of API objects that follow the OpenAPI specification. These APIs are used to literally declare the application flow from service to service using messages that connect each application component. - Components are containerized
Event sources, sinks, brokers, event splitters, filters, transformers etc are all available as API and implemented with code that is packaged as containers. - Running in Kubernetes
All containers needed to implement the APIs that make up an integration are orchestrated by Kubernetes the de-facto standard for container orchestration. The APIs are Kubernetes CRDs. - CloudEvents specification
All events that connect services together follow the CloudEvent specification defined by the serverless working group of CNCF. - Auto-scaling
Components of an integration can benefit from out of the box auto-scaling. Event sources like Webhook and even sinks in particular are implemented as Knative services which are controlled by an auto-scaler that offers a scale to zero feature.
With all of this in mind, the TriggerMesh Cloud-Native integration platform allows people to describe integration as code and run those integrations in Kubernetes. As a sneak peek, we are trying to make this as simple as possible with our own language using HCL. For instance sending GitHub events to a Kinesis stream is starting to look like this
source “github” “git_source” {
owner_and_repository = “sebgoa/transform”
event_types = [“push”, “issues”]
tokens = secret_name(“github-secret”)to = target.my_stream
}target “aws_kinesis” “my_stream” {
arn = “arn:aws:kinesis:us-east-1:34653426:stream/confluent”
partition = “1”credentials = secret_name(“awscreds”)
}
I am very interested to hear your thoughts and I promise I am going to try to post more, in the meantime feel free to reach out @sebgoa or sebgoa@triggermesh.com