OpenWhisk Serverless Graduates Apache, Looks Ahead to Knative, Envoy and More
This week, the open source serverless project Apache OpenWhisk has graduated from an incubating project with the Apache Software Foundation (ASF) to become a Top-Level Project. IBM first created the project just over three years ago before donating the project to the ASF as an incubating project later that same year.
In the years since joining the ASF, OpenWhisk has expanded its functionality and met a number of stringent requirements to graduate and finally become a fully self-governed member, as detailed in a project maturity matrix on the OpenWhisk Wiki, showing the ways in which the project has met the requirements of the Apache Project Maturity Model and its codified framework. In an interview with The New Stack, Matt Rutkowski, Chief Technology Officer of Serverless Technologies and Advocacy at IBM, explained that these requirements are what make companies trust projects that have graduated from incubation at the ASF.
“When corporations turn to Apache for software and open source, they know that the processes and policies they have in place guarantee that the provenance of the code is without question. In terms of incubation, we have to prove that we can govern with the project with a project management committee and that we can work openly with our community, and be inviting and be open to all ideas, and accept contributions from wherever they come from. All those things are scrutinized by the incubation board,” he said.
As far as improvements in features and functionality since first joining the ASF, Rutkowski lays out the numerous advancements in a blog post announcing the graduation. It now runs on containerd and Kubernetes with Helm charts. The Apache Mesos framework is also supported. The OpenWhisk platform can also serve as a runtime for GoLang, Java, .NET, PHP, Ruby, Rust, Ballerina and even a special Python3 for Artificial Intelligence (AI).
Those languages, of course, are on top of the latest versions of NodeJS, Python and Swift, which OpenWhisk has supported from the beginning. Rutkowski also impressed the importance of OpenWhisk’s “slew of service provider interfaces (SPIs) that allow operators to ‘plug-in’ their favorite logging, monitoring, or datastore” and “provide your own scheduler to allow providers to optimize for their cloud’s workloads.” OpenWhisk, Rutkowski says, has become the project of choice for companies that want to run serverless without relying on a managed service.
“It’s highly available — all parts of our backend architecture are highly available. If you want to be a provider of serverless, general service computing, this is your go-to code. Everything else wants to be like OpenWhisk,” said Rutkowski. “You can implement serverless in many different ways, but in terms of highly available, large scale serverless, OpenWhisk is the premier choice for open source software. OpenWhisk offers something that is unique, in that we offer people who want to host a serverless platform the end to end solution.”
According to Rutkowski, the exposure OpenWhisk has had to different environments and use cases have advanced it beyond other open source serverless solutions.
“One of the strengths of OpenWhisk is that, being an open source project for so long under Apache and being exposed to different companies and use cases, we handle everything,” said Rutkowski. “We handle container as a workload and function as a workload. We’ve been responsive to different functions, different memory sizes, a different number of connections. We’ve been exposed to a lot of things in production settings across multiple companies, and that sets us apart from a lot of other open source projects.”
Now, after the ASF vote last week to graduate OpenWhisk, Rutkowski says the project can finally begin moving at a faster pace and solving all the problems it has only experimented with up until this point — such as “integrating with the latest, open serverless technologies such as Knative, Tekton CI/CD pipelines, and Kubernetes Event-Driven Autoscaling (KEDA) and exploring use cases to allow new protocols with finer-grained access control to functions using edge service proxies like Envoy.”
“There are a lot of time delays, between wanting to produce new software releases specifically. We’re scrutinized at multiple levels before we can produce a release. I think that [graduation] will increase our ability to put out new releases. A lot of the things we’re going to be doing is a lot of consolidation and cleanup to try and streamline some of our releases,” said Rutkowski. “When we started the project, I think we had maybe a couple dozen repositories and we didn’t know what the premiere use cases were. Now that we’ve got a better feeling of where we’re at, how we’re being used and where we want to go, I think we’re going to consolidate a lot of our repos that were once experimental into our main repository and prepare for an expansion again to do some of this exploratory work with Knative and other technologies.”
Feature Image by Steve Buissinne from Pixabay.