Serverless is taking off: a recent Cloud Native Computing Foundation (CNCF) survey found that 41% of respondents are currently using serverless technologies, and another 20% are planning to in the next 12 to 18 months. Also known as Functions-as-a-Service (FaaS), serverless allows cloud native application development teams to shift the operational burden of running and shipping code to their cloud providers — reducing overhead costs, boosting scalability, and simplifying the DevOps cycle.
Serverless is already perceived to be the next evolution in application infrastructure, but there are still some hurdles to overcome — specifically standardization.
Standardization has long been a unifying force for the computing world. If you’re old enough to remember the early days of the internet (back when it was still called the World Wide Web), you may remember the browser wars between Internet Explorer and Netscape. In their fight for dominance, each browser was pushing their own updates to HTML that was largely incompatible with the other browser.
It quickly escalated to the point where websites built for one browser would not work well on the other browser, fragmenting the internet and raising the costs of web development. Developers had to effectively create two websites or miss out on the audience using the other browser.
This changed with the Web Standards Project, a grassroots coalition that in 2001 successfully persuaded Internet Explorer, Netscape, and other browsers to adopt standards established by the World Wide Web Consortium. The result is the internet we know and love today: an open, collaborative, and universal platform connecting people around the world online, making life significantly easier for web developers.
Today, the serverless ecosystem is still fragmented, much like the early internet. Between AWS Lambda, Microsoft Azure Functions, Google Cloud Functions, and the myriad other platforms, many serverless functions are proprietary, which makes migrating an application from one platform to another a challenge. The lack of portability and interoperability between platforms is hindering serverless adoption, as developers fear vendor lock-in.
With the serverless market still relatively new, developers don’t want to get stuck with a serverless provider if there could be a better option down the road. And with the coronavirus laying waste to the economy, the serverless market could be primed for rapid consolidation, making the ability to migrate serverless applications across platforms more important than ever.
The lack of serverless standardization also presents security challenges. While serverless can streamline operations by cutting out server management, developers lose visibility into the workloads they run on serverless platforms. That means that security threats like data exfiltration, misconfigurations, overprovisioning of access privileges can go unnoticed. In effect, that leaves developers reliant on API’s provided by the serverless provider to observe possible security threats. Without a standardized serverless framework, there can be no standardized security tools or best practices that work across the serverless ecosystem.
Momentum for standardization is already underway. At the center of the cloud native world, the CNCF has recognized the urgency for standardization, noting a “need for quality documentation, best practices, and more importantly, tools and utilities. Mostly, there is a need to bring different players together under the same roof to drive innovation through collaboration.” In the spirit of collaboration, the CNCF has brought serverless platform providers and third-party library developers together in the Serverless Working Group to advance standardization.
Kubernetes has emerged as another promising solution. The container ecosystem is already consolidated around Kubernetes, making it the perfect platform to unite the serverless ecosystem as well. In 2018, a Google-led initiative in partnership with Pivotal, IBM, Red Hat and SAP launched Knative, an open source framework for running serverless application components on top of Kubernetes and Istio. The platform provides all the API machinery and backing resources to build, ship, scale and run serverless workloads.
Interoperability and portability aside, Knative also has security advantages. Knative allows you to use security tools already developed for Kubernetes, where the security paradigm is more mature. With Knative, you can achieve greater observability into security threats by embedding security agents into serverless workloads and functions in Kubernetes, rather than using the infrastructure plug-ins provided by the serverless platform. If your team already has investments in Kubernetes security, these security investments can extend to serverless security.
It remains to be seen whether Knative will be the winner for serverless standardization. As of March, Knative adoption sits at 17%, meaning there is still plenty of room for maturity and growth. Knative itself builds on Kubeless, a previous effort to standardize serverless around Kubernetes. But in a sign of early industry acceptance, Google built its next-generation, fully managed serverless platform, Cloud Run, around Knative, meaning other serverless platforms may soon follow suit.
Serverless gives developers the freedom to focus on building functionality into their code, rather than managing the servers on which those functions run. This liberation from mundane yet vital operational responsibility has the potential to unlock significant innovation and business value for application developers, but the lack of standardization risks fragmenting the serverless ecosystem and creating winners and losers. With standardization comes the power of open source collaboration that has fueled innovation since the dawn of the computing era.
Amazon Web Services, the Cloud Native Computing Foundation, and Red Hat are sponsors of The New Stack.
Feature image: CloudEvents.