The last thing the market needs is another Knative company. The first rule of Knative is don’t talk about Knative. Do we need serverless infrastructures built on top of Kubernetes? Absolutely. But technologies like Knative should really be implementation details, not company plays. With those axioms in mind I was encouraged and happy to see the new positioning and investment news from Triggermesh. Does the world need an event-driven serverless integration bus? Sure – that absolutely makes sense.
This week Sebastian Sebastien Goasguen and Mark Hinkle announced a $3m seed investment for Triggermesh, led by Index Ventures and Crane Venture Partners. I really like the story they’re telling:
TriggerMesh’s platform and serverless cloud bus facilitate application flow orchestration to consume events from any data center application or cloud event source and trigger serverless functions. As cloud-native applications use a greater number of serverless offerings in the cloud, TriggerMesh provides a declarative API and a set of tools to define event flows and functions that compose modern applications. TriggerMesh provides the following features and benefits to today’s modern enterprises.
Initial supported event sources include IBM MQ event source, VMware vSphere event source, and the Azure Event hub Channel controller. The MQ support really triggered my interest, if you’ll excuse the awful pun. As we increasingly move into a hybrid, multi-cloud, multi-SaaS world we’re going to need to bring together the new world of container-based functions and the kind of legacy event sources that IBM has long supported with MQSeries. What is old is new again, but of course also still old.
Back in March 2018 in a post about Kubecon Europe I argued Kubernetes needed to “establish a strong narrative for event-driven computing/serverless”. This has yet to happen.
What I am most interested in are overlaps between serverless and container-based approaches, and ways to integrate the two. As mentioned above there are some interesting function-as-a-service platforms being built on top of Kubernetes. Arguably these platforms are not “proper serverless” because they’re not built on a web scale infrastructure, don’t include per function billing as standard, and require some configuration to set up. But as in my comments about ops above, there will be a world of triggers and events outside AWS Lambda. We’re going to need choreography across platforms, on prem and off.
But the action at Kubecon, I felt at the time, wasn’t necessarily about Kubernetes and Istio anyway. Rather I was most excited by the CloudEvents spec. Now to be fair, the spec has yet to make an impact either, and yet the promise of it maps really well to TriggerMesh. In that post I also called out some ideas from 2017 – Lambda Kicks in in a world made of messages.
It could be time to resurface message oriented middleware concepts as a way to think about managing apps based on independent functions and microservices. Guaranteed delivery, fan outs, publish and subscribe etc. Step functions with retries, a world made of messages and active points. Think of Kafka, for example, a distributed commit log, used by Salesforce to bridge the gap between Force.com and Heroku services, and now offered as a managed service on Heroku. Kafka isn’t a message bus, but boundaries are fluid. Message buses will definitely be part of the new world. Note Pivotal is getting serious about RabbitMQ, a 10 year old project that deserves some love.
Serverless is going to be huge, but I suspect we’ll see AWS delivering some MoM style functionality to help manage functions and triggers, above and beyond the monitoring and API Gateway functionality so far. Especially as we move into multicloud serverless apps messaging is going to prove its worth.
TriggerMesh is building message oriented middleware for the serverless era, and enterprises using both on premises and cloud applications (which essentially means all enterprises) are likely to find the approach resonates. It will be interesting to see if TriggerMesh can build out a programming model that allows enterprises to take advantage of the service oriented architecture work they have already done with platforms like MQ. If services are well described and managed they can become accessible to cloud services. Some low code concepts map to this pretty well. Arguably the Triggermesh plays maps into the world Google plans to define through its recent AppSheet acquisition, where services exposed using the Apigee API Gateway can be accessed to build new applications using a spreadsheet metaphor.
I will be watching TriggerMesh closely.
disclosure statement: IBM and Google Cloud are both RedMonk clients, but this is an independent, un-commissioned piece of analysis.
No Comments