The future is serverless

Since the introduction of cloud computing, the field experienced a series of back-and-forth evolutions, partly driven by cost factors that repeated themselves in various guises. However, in recent years, a new motivating factor might help cement the next evolution of cloud computing. In this blog post, we make the case and paint a vision that serverless computing is the future of cloud computing. The argument centers around the following premises:

• Cloud computing is at the center of the modern interconnected world. Most modern applications use cloud compute applications for aggregating and processing data and for constructing information that edge devices need.
• Cloud computing demand is expected to grow annually by 15%.
• Cloud computing is projected to reach 50% of IT spending in key market segments
• Cloud computing already consumes 1-1.5% of global energy and its growth represents an actual threat to the environment.

We show that, in view of the growing demand, the more energy-efficient and cost-efficient serverless compute model is the next natural evolution of the current dominant cloud computing paradigm.

Introduction

Cloud computing is casting a vast shadow on the world. Indeed, it doesn't matter where you go, you cannot escape from seeing human beings that are tethered to their portable computers, accessing and processing vast amounts of information on the internet. The information that is gathered from edge devices is collected, processed, and produced by applications and services that are running on the cloud.

As individuals with years of experience in the field who help drive key open technologies that underpin modern IT, it's time to step back and ask the bigger question of where the cloud computing field is going. What's next for the current cloud computing model? Or more specifically, what's next for the current dominant cloud computing model that is driven by Kubernetes—the open operating system for hybrid cloud?

Serverless computing, as realized in the case of Kubernetes by Knative, is often mentioned as the natural evolution. But is it a step in the right direction? Will serverless help mitigate the growing cloud computing costs? Or the threat its continual growth has on our environment?

Motivation

In this post, we argue that the answer to these provocative questions is a resounding yes. We believe that the future of computing is serverless. This argument does not simply stem from the cost efficiencies that are achieved by users, but by the higher compute densities that are obtained by cloud providers. We argue that the need also stems from environmental considerations. All computational models must be "greener", which means more environmentally sustainable and friendlier to the existential climate crisis we are experiencing as a species.

Historical perspective

The rise of cloud computing as the dominant paradigm of the early 21st century can be seen as a revolution in the history of IT. With the rise of the cloud, anyone can reserve a slice of a cloud computer (usually in the form of a virtual machine [VM] or container) for pennies an hour. This ability for anyone, anywhere to effortlessly spin up "cloud scale" compute resources is arguably one of the biggest drivers of our current technological revolution.

A consequence of this revolution, where users are offered high availability of cheap compute units, is that the compute resources are allocated whether or not they are actively used. After the compute resources are reserved, cloud providers are expected to ensure that the resources are ready for use when users ask for them. At the same time, modern workloads that are run by users rarely use the allocated resources in continuum 24 hours a day, 7 days a week.

Many workloads tend to have event-driven characteristics, which means that besides a setup sequence, such workloads spend most of the compute time waiting for events. After an event arrives, the workload reacts and responds. Another common type of workload is working in batch mode, where the workload performs a certain computation and terminates. Such batch modes might be triggered by an external event or occur periodically.

Under the current, predominant, cloud computing paradigms, a user must predetermine the amount of compute resources to reserve for their workload. Such pre-determination of the amount of allocated resources typically results in significant waste. The wasted resources increase both costs and energy usage.

Serverless is the future

Serverless computing was created to solve the problem of allocating cloud compute resources. Serverless was built to tackle this problem by adding automation that eliminates the need for users to predetermine the amount of compute resources necessary for their workload. As an open source example, Knative added scaling automation on top of Kubernetes-based cloud platforms. Knative makes the scaling decisions of workload services in line with actual service demand. As requests come in, Knative adjusts the compute resources to the demand. Knative scales the number of service pods infinitely (assuming Kubernetes has the resources) and when requests dry out, it scales down (to zero pods eventually).

Consequently, Knative eliminates the need for users to pre-determine the resources that are allocated to each of their Kubernetes services or to determine where and when such resources are needed. The only requirement is to deploy a service on Knative-enhanced Kubernetes clusters, which by itself does not use any significant additional compute resources. Going forward, that service can serve requests on any of the clusters, anytime that it is needed.

The serverless model, as demonstrated by Knative, defines every service request as an event. Knative includes enhancements to better control the ability to consume and generate events (requests for services). These enhancements enable each service to be independently scale-controlled such that at any time, only the necessary number of service instances are running in any part of the cloud. Therefore, Knative improves cloud efficiencies by continuously fitting the cloud resources reserved per service to the actual service needs.

Knative became a way to improve Kubernetes—it covers many of the same use cases while adding simplification and automation for users and achieving better cloud efficiencies. (See Knative: An Opinionated Kubernetes.) Therefore, you should use Knative whenever possible, instead of only directly using the underlying Kubernetes platform.

Managing costs

One of the primary promises of serverless is the cost savings associated with running workloads in the cloud through efficient allocation and usage of cloud resources and services. Currently, running workloads on the cloud requires reservations and provisioning of cloud resources. Given that exact consumption is hard to know or predict, users overprovision, and therefore overpay, for these resources.

Further, most cloud computing services do not serve a constant demand. Instead, a typical service's demand fluctuates with time of day, day of week, along the year with seasonal effects, holidays, and local or global events. In most cases, trying to predict the actual demand is an impossible task. Instead, users provision and reserve surplus cloud resources on top of the anticipated peak demand to ensure that the service can handle such peak times. This means that, at most times, the service provisions and reserves more cloud resources than are actually needed. Even when users adequately analyze peak time and choose a surplus amount, the real demand might be lower, which results in financial waste. Or they choose an insufficient amount, which potentially leads to income loss. By automatically provisioning resources in real time to fit the demand, serverless avoids both waste and loss.

Serverless eliminates the requirement for cloud users to reserve compute resources when deploying services. With serverless, the deployed services are only activated when an event (a service request) requires processing. As a result, cloud users enjoy cost savings. As more events come in, each cloud service scales to meet the demand, and when no more requests exist, services can scale down to zero. In the optimal case, as offered by serverless, a service consumes only the resources that it needs to meet the demand it receives, nothing more and nothing less.

Cloud providers also have the potential for cost savings when they offer serverless services. Without serverless, users buy pre-provisioned compute resources. Each such resource is locally provisioned on a VM somewhere. The cloud provider must statistically ensure that when a provisioned service reaches peak demand, every VM that serves the service has sufficient local resources, as provisioned by the user. With serverless, as service demand grows, the cloud provider is only required to have sufficient resources somewhere in its cloud domain to serve the event.

With Knative, for example, if an event reaches a particular Kubernetes cluster, Knative must find resources for this event anywhere in the cluster and not in a specific worker node. If the entire Kubernetes cluster is fully utilized, nothing prevents the cloud provider from routing the event to a different cluster. It can use Istio for networking abstraction, along with a federated model of Kubernetes, which makes this use case even easier to realize. All that is required is for compute resources be available somewhere to serve the event. This removes the need for a local reservation of resources and can drastically improve cloud efficiency. Overall, serverless offers significant cost reductions to both cloud providers and users.

Environment

As we previously discussed, serverless improves the efficiency of cloud services. By removing the need for local pre-provisioning of resources on a per-worker node level, serverless creates an opportunity to use cloud resources that are available anywhere to serve service requests. Overall, fewer compute resources are needed across the cloud to serve the same set of cloud services. More importantly, the amount of energy that is spent per workload is reduced. For example, a workload that is scaled down to zero consumes fewer resources than if it keeps running. In turn, the amount of necessary energy is reduced.

Serverless can offer additional energy savings. For example, as more services move to a serverless compute model and cloud providers offer such services anywhere in a data center, future clouds can suspend worker nodes and physical machines when data center capacity is high enough to meet demand. (See Figure 2.) Since energy consumption is one of the top recurring costs of cloud providers, this scenario offers important cost savings.

This savings not only results in more efficient clouds, cost wise, but also in a greener cloud. As more workloads move to the cloud, the savings is not inconsequential. The challenges of climate change are not met by behavioral changes alone, but by being more efficient in how we utilize the energy we have and consume less of it. This is especially the case when this efficiency can be achieved without sacrifice. Naturally, not all workloads can be serverless and moving to serverless has challenges, which we discuss later. However, a serverless future for all cloud workloads means a greener environment.

Other use cases

Initially, serverless was a narrow-scoped, niche technology for functions as a service workloads, but more recently, its applicability was drastically broadened to meet the needs of almost any kind of workload. For example, batch and transaction processing are a natural fit for a serverless architecture since they inherently are the types of workloads that execute to achieve a result and then terminate. To facilitate batch and transaction processing use cases, features such as scheduling of events and failure-retries protocols should help.

Data and AI

Data and AI is an area that is ripe for serverless use. The canonical use case is running machine learning (ML) algorithms on large data sets and the ability to refine the algorithms and features, and rerun. Projects like Kubeflow packaged the necessary libraries and features around Knative to facilitate the execution of these use cases. However, we might make data and AI use cases even more natural by extending the current serverless solutions for different interaction patterns. For instance, allowing for fire-and-forget types of invocation. Adding the ability to call back on a provided endpoint for future results is a feature that might help even more.

Quantum computing

Finally, an important future use case for serverless architectures is to help make quantum computer usage mainstream. Quantum computers have benefits beyond anything that classical computers can provide. However, its usage requires specialized hardware and enclosures, and the programming restrictions on what a quantum computer can be used for is significant. The prohibitive financial cost of a quantum computer and the related energy cost of its cooling systems makes it a natural candidate for the cost and energy optimizations offered by the serverless model. With a quantum serverless model, as described in The Future of Quantum Computing with Superconducting Qubits, we can reduce the complexity of directly using a quantum computer by making access event-driven and by using classic, serverless-associated workloads. The IBM Quantum team is making quantum serverless a keystone to their strategy for the next 2–5 years.

Summary

In this blog post, we explained the motivations for serverless computing to be the future of all cloud computing workloads. We argued that this serverless-first future has various potential benefits for both cloud users and providers. The benefits go beyond cost savings for all parties to also include important energy efficiencies, which result in greener clouds and more environmentally conscious computing. Finally, we offered additional use cases that a serverless-first cloud offers, such as data and AI, and quantum computing. However, these benefits are not without challenges. In the second part of this series, we explore the challenges to realize a serverless-first cloud and efforts underway to address them.