TriggerMesh announced it has integrated with Amazon Web Services' (AWS) EventBridge to allow users to connect existing on-premises applications or non-AWS software-as-a-service (SaaS) offerings with cloud infrastructure from AWS. This plays into the broader serverless standoff between vendor-specific platforms and options like the Knative project, which has made waves as a possible singularized platform to provide a Kubernetes-based interoperability layer across different serverless computing technologies.

“There's a lot of specialized services out there that would benefit from being integrated into Amazon,” said TriggerMesh CEO Mark Hinkle, on the company's latest AWS link. Integrating TriggerMesh Cloud with AWS EventBridge “democratizes the application event place and provides a conduit of sorts to create cloud-native mashups.”

Its namesake cloud platform leverages the Kubernetes-based Knative runtime environment and allows users to more easily run stateless workloads generated from on-premises or other cloud infrastructure. TriggerMesh has extended the capabilities of Knative to include support for AWS vendor-specific APIs.

EventBridge is a serverless event bus that allows users to connect applications together using data from their own applications, SaaS applications, and AWS services.

“I think Amazon EventBridge shows us there’s a real need for these kinds of solutions. The problem is it’s specific only to Amazon,” Hinkle said in a previous interview, adding that it ties developers that use Lambda-based serverless functions to AWS.

While this model is also used by other large cloud providers and their respective hosted serverless platforms, a Cloud Native Computing Foundation (CNCF) survey found that AWS Lambda – serverless computing’s poster-child – dominates the hosted platforms category as 53% of respondents selected it as their preferred serverless tool. 

Marriage to the most popular serverless framework provider is no problem for organizations that only use AWS, however, that’s not most organizations. And considering most companies have some combination of cloud and on-premises applications, vendor-specific platforms add an additional layer of complexity to serverless migration.

That being said, the need for integration and interoperability has never been greater. 

The portability gap between serverless platforms has been one of the main barriers to broader serverless adoption. Knative, in case you forgot, has slowly wedged itself into the serverless computing lexicon as a possible way to provide a Kubernetes-based interoperability layer across different serverless computing technologies.

However, Knative resides under Google’s rule and its recent Istio move failed to meet the community’s expectation for open governance that would have seen it walk a similar path to the rest of its cloud-native siblings at CNCF. 

“[Knative] lost some of its shine I would say but will accelerate the ecosystem of companies providing ways to take functions and events (such as AWS Lambda, Google Functions and Azure Cloud Functions) and run them on any cloud, or on premise environments, using Kubernetes and containers as a portability layer,” said William Fellows, research VP at 451 Research. 

Knative continues to hold interest as a tool to relieve serverless lock-in, explained Fellows, however, "the Istio kerfuffle has not helped it, given Knative relies on it." 

Google might have muddied the waters of community and collaboration, but “all software is drama,” Hinkle added. "I don't know that putting Istio into a trade organization like CNCF does it any better or worse service if what you're doing is open source.”