The proliferation of serverless platforms has raised a very real specter of siloes and lockin for early adopters Credit: Thinkstock Standards are essential when any practice has become widespread and many disparate approaches for addressing it have gained traction. That situation applies in spades to today’s serverless computing market. In platform-as-a-service (PaaS) contexts, serverless computing is well-suited to event-driven, potentially volatile workloads that are on-demand, scalable, efficient, and pay-per-use. Developers can deploy functions quickly with no infrastructure configuration. They can define triggers that initiate autoscaled functions. And they can automatically shut down functions when the work is complete. Serverless computing’s amazing momentum Serverless computing has amazing momentum in cloud-native computing these days. As noted in RightScale’s 2018 State of the Cloud report, this approach for building event-driven, stateless cloud applications is now the fastest-growing microservices model, expanding in enterprise adoption at an annual rate of 75 percent. The advantages of serverless computing for lightweight cloud functions have sparked a proliferation of commercial and open-source serverless platforms. Many serverless environments are native to public clouds. Serverless computing has already invaded public cloud services in a big way, as can be seen through the uptake of especially AWS Lambda, Azure Functions, Google Functions, IBM Cloud Functions, Oracle Functions, and other commercial function-as-a-service offerings. But serverless computing is also beginning to deeply penetrate private clouds. The past few years have seen the emergence of a dizzying range of alternative serverless platforms for on-premises, hybrid cloud, and multicloud deployments. These include OpenWhisk, Fission, Gestalt, IronFunctions, Nuclio, Fn Project, Funktion, Fission, Kubeless, Funcatron, OpenFaaS, and Webtask.io. This proliferation of serverless platforms has raised a very real specter of siloes and lockin for early adopters. Currently, most serverless development tools support building functions for specific siloes—most notably, AWS’s Lambda offering. Nevertheless, there is a growing range of serverless IDEs—such as HashiCorp’s Terraform, Serverless.com’s Serverless Framework, and Solo.io’s Gloo—that integrate with several major back ends and provide an abstraction for programming functions in various languages, including Node.js, Python, Java, and Go. Hybrid serverless multiclouds are slowly but surely emerging in enterprise application environments. However, the outlook for cross-platform serverless standards remains fuzzy at best. A true standard is a formal, documented, open specification that establishes uniform practices and is governed through consensual processes by a community of providers, users, and other interested parties. Knative may one day be the serverless standard Some industry observers point to the open-source Knative project as the foundation for serverless standardization, but that would be jumping the gun. Released last year under the auspices of the Cloud Native Computing Foundation (CNCF), the Knative project’s goal is to simplify the building of container-based, serverless applications that can deploy and run on any cloud: public, private, hybrid, and otherwise. The separate Project Riff extends Knative with developer and operator tools to simplify its installation and add key user experience components. As it gains commercial traction, Knative may someday enable multilanguage “write once run anywhere” programming of serverless functions, but that day is still far off. Like so many projects under CNCF, Knative has a long row to hoe before it can harvest the fruits of true standardization and widespread adoption. I should note that CNCF, before taking Knative under its wing, had already defined the CloudEvents specifications, a standard set of event triggers for ensuring multicloud serverless application portability and reuse that has gained only spotty traction. Currently in Version 0.2, Knative was developed by Google in collaboration with IBM’s Red Hat unit, Pivotal, and SAP. One glaring deficit right now in Knative’s prospects is that it doesn’t yet consume functions from such leading public serverless platforms as AWS Lambda, nor from from a wide range of serverless environments geared to on-premises, hybrid, and multicloud deployments. Which vendors support Knative Nevertheless, each of Knative’s principal developers has recently made significant announcements to incorporate it into their respective solution portfolios: Google has made Knative available to users in July 2018 via a serverless add-on to its Google Kubernetes Engine (GKE). Knative lets developers build, serve, and manage container-based serverless applications that can be easily moved between cloud providers. IBM lets enterprises install Knative in their IBM Cloud Kubernetes Service deployments. Also, IBM’s Red Hat unit is adding support for Knative in its OpenShift Kubernetes platform to help customers build and run serverless applications and integrate with the company’s OpenShift Server Mesh based on the Istio and Kiali projects. Pivotal recently announced the alpha version of its Pivotal Function Service (PFS), a Kubernetes-based multicloud serverless platform. It is a multicloud packaging of Knative and can be installed on any Kubernetes environment. It includes “build packs” that securely package functions, keeps prior versions of function instances to support transparent rollback, and automates function resource scaling and performance optimization nondisruptively across loosely coupled, streaming, and other distributed environments. SAP is making Knative available in its SAP Cloud Platform and as part of its Project Kyma for enterprise software extensibility. The project addresses developer needs for agile, open source tools to connect, customize and extend any API-enabled application. It provides a consistent service consumption layer that blurs the boundaries between legacy enterprise software and diverse providers’ cloud services. It uses Knative on a standard Kubernetes service catalog and expands it by using the Open Service Broker standard. There are other pockets of industry support for Knative. For example, GitLab and TriggerMesh recently announced GitLab Serverless, which lets enterprises run serverless workloads on any cloud or on-premises infrastructure using Knative by deploying serverless functions and applications straight from the GitLab UI. What could slow Knative’s adoption Even though Knative has substantial backers and some marketplace traction, several countervailing trends may slow its adoption among serverless providers, developers, and users: Cloud providers are evolving their respective proprietary serverless platforms: To attract more usage on their public clouds and thereby short-circuit the need for heterogeneous serverless (via Knative and other interfaces), each major public-cloud providers will continue to investin maturing their respective function-as-a-service platforms. Each will continue to evolve its serverless programming languages, embed serverless interfaces across its cloud IaaS and PaaS portfolios, and enhance the serverless APIs in its cloud integrated development environments. For example, AWS recently announced Firecracker, a lightweight, open sourcevirtual machine monitor that enables creation and management of secure multitenant containers and AWS Lambda functions in serverless clouds. Development tools are providing alternative abstractions for bridging siloed serverless platforms: Back-end serverless code is fairly sticky and will continue to be written to efficiently access cloud-specific services such as messaging and databases. Already, several open-source projects—including Fn Project, Funktion, Fission, Kubeless, Virtual Kubelets, Funcatron, and OpenFaaS—provide serverless abstractions on top of Kubernetes, Docker, and other container schedulers to facilitate consumption of functions across siloed clusters. These abstractions spare enterprise IT professionals from the onerous task of porting containerized functions among the disparate serverless back ends that are popping up in their enterprise multicloud environments. I expect that more cloud-native development tools will add abstractions that use these and other APIs to enable consumption of microservices running on heterogeneous back-end serverless environments. This may preempt the need for open-standard cross-serverless APIs such as Knative. Serverless vulnerabilities require abstractions beyond the current scope of standards frameworks: Serverless computing tends to lull developers into an “out of sight, out of mind” mentality in which physical and network security is the province of cloud service providers. But that’s a dangerous attitude, as a recent study shows. An audit of 1,000 serverless applications showed that 20 percent contain acute application vulnerabilities. These stemmed largely from poor development practices, lack of serverless security education, and posting of insecure sample code, API keys, and credentials into real-world projects. As hybrid deployments grow, these vulnerabilities will become more acute unless cloud-native tools enforces safe practices into the serverless development abstraction. Until Knative or other industry-standard multicloud abstractions incorporate strong guardrails to nip these vulnerabilities in function code, serverless app developers may rely on whatever proprietary security tools are built into their preferred cloud-native APIs. Beyond security, there is a wide range of other capabilities that need to be incorporated into whatever multicloud abstractions make hybrid serverless a marketplace reality. These include standard APIs for cross-cloud function parallelization, load balancing, event correlation, data-access abstraction, orchestration, telemetry, performance tracking, event correlation, usage monitoring, anomaly detection, log analysis, interactive diagnostics, incident-driven alerting, and debugging. For developers, the bottom line in all this ferment is that they’ll need to choose whatever cloud-native tool helps them build and deploy serverless, containerized, virtualized, and other code as simply and efficiently as possible. If your tool incorporates standard APIs for writing function code once and porting it to any serverless back end, that would be the way to go.