TriggerMesh has advanced its campaign to bridge serverless computing frameworks by making TriggerMesh Knative Lambda Sources (TriggerMesh KLASS) available as an open source project.
TriggerMesh KLASS makes it possible for organizations that have deployed the Google-developed Knative serverless computing framework on Kubernetes clusters to employ functions to invoke events that will be processed on the Lambda serverless computing service provided by Amazon Web Services (AWS).
Company co-founder Mark Hinkle says it’s only a matter of time before serverless computing frameworks are invoked across multiple clouds. AWS Lambda currently is the most widely employed serverless computing framework. But most other cloud service providers have thrown their support behind Knative, a set of middleware that Google developed to provide interoperability between Kubernetes and multiple backend serverless computing frameworks.
Hinkle says TriggerMesh expects IT organizations to employ TriggerMesh to invoked AWS Lambada events from both on-premises deployments of Kubernetes as well as across various distributions of Kubernetes running on public clouds.
Longer term, Hinkle says TriggerMesh envisions TriggerMess KLASS being employed by cloud service providers to expose a middleware service through which a variety of cross-cloud applications can be developed more practically. TriggerMesh soon will be launching its own cloud service, which Hinkle notes is available now to a select number of early adopters. The service will provide an application programming interface (API) management platform through which developers will be able to more easily reuse functions to access a variety of event-driven applications and processes, he says.
The arrival of the TriggerMesh KLASS project comes on the heels of a TriggerMesh Knative Lambda Runtimes project, which makes it possible to port functions developed for AWS Lambda to Kubernetes clusters that have been configured to support Knative. Serverless computing frameworks, also known as functions as a service (FaaS), make use of event-driven architectures to create a layer of abstraction based on containers that eliminates the need to know server constraints when building an application. When additional resources are required, a developer creates a function that calls a stateless set of compute functions, which then are made available. Each function is a self-contained module of code that accomplishes a specific task and, once written, can be reused multiple times. Most serverless computing frameworks are exposed as a cloud service, but they just as easily can be deployed in an on-premises IT environment.
Serverless computing frameworks are being adopted quickly because they reduce the amount of code developers need to include in their application. Instead of having to dedicate compute resources to a function that is seldom used, developers can invoke that capability running on a cloud service. The cost of processing events using functions on a serverless computing framework is measured in fractions of a penny, per million requests.
It’s unlikely large numbers of developers will build applications entirely using functions. But it’s clear serverless computing frameworks will play a larger role within the context of DevOps process. The challenge DevOps teams face now is determining what part of an application is best invoked using a function on a serverless computing framework versus within a containerized application.