Knative-powered TriggerMesh Makes Modern Apps Serverless and Event-driven

TriggerMesh is built on Kubernetes and Knative, so we allow you to build your application integration with our declarative API then deploy and manage your integrations the same way that you manage your Kubernetes workload using your GitOps workflow.

We are seeing that more and more components of cloud native applications are serverless. Users want to see less of the infrastructure that is required to scale and manage apps. They just want to deploy and get autoscaling for free. This is what you get with one side of Knative. When applications are not being used, the containers making up these apps are not running, meaning that they scale to zero and can wake up on-demand. The service is still defined, or declared, but there are no pods running when they are not needed. Therefore, you save a lot of resources.

This is very, very nice when you're a big enterprise that maybe has what I call the “thousand Java application” problem. You may have to keep Java applications running forever. And then you realize that you have a total sprawl of apps that are not updated, that are consuming resources, but that you have to keep running. With Knative, those apps can scale to zero, reducing the amount of resources required and you can create new revisions easily.

Where it gets extremely interesting, and we get to the next step in application modernization, is when that entire application becomes event-driven. When every bit is much more loosely coupled, much more autonomous. And then everything reacts to events in real time. 

This gives you the ability to develop and deploy every bit separately, independently. And then it's just events that bridge each component together when needed. You just have to declare which service gets called when a specific event happens. This is the core vision of TriggerMesh, we see modern apps as a composition of event triggers, a mesh of triggers hence our name: TriggerMesh.

Event-driven systems—or messaging systems—have been used for a while, but not in the context of a very modern application where you have services that can scale to zero, where you have cloud APIs that are being used in the mix and so on. Putting it another way, event driven architectures have not been thought about for the Cloud Native era where the applications are a composition of services either on-premises or in the Cloud. That’s when serverless becomes an integration challenge and is set to replace enterprise integration solutions like MuleSoft or Dell Boomi. As soon as you standardize on events as the lingua franca for integration, you can bring together every Kubernetes service, every legacy app, every SaaS app, every cloud service, every API, in a flexible, real-time, scale-to-zero way.   

So when you look at it in that context, what you're actually building is a serviceful application. It's an app that's event-driven, that has components that scale to zero, and that has components that are multi-cloud, on premises, external cloud. That's what we mean by going serviceful and this is really an integration challenge.

Is this how you are running things? Anything you’d add? Which parts of this, if any, have you found to be particularly challenging, and why?