1. Container-Based Serverless Cannot Support the Next Generation of Applications

As the figure above shows, we are going through a change in runtime form.

From bare metal to virtual machines, applications are no longer limited by the number of local servers or the stability of the data center, and gain better elasticity and availability.

From virtual machines to containers, applications are no longer limited by the operating system or configuration drift, and gain better portability and scalability.

What is the next runtime form? Many articles say Serverless, but Serverless itself is not a runtime form — it is a way of using a runtime form, a software architecture. Below is the traffic diagram of a typical Serverless system:

When Container Serverless receives traffic, there are two cases:

• Active: there is already a Ready container, so traffic is forwarded directly to the container
• Inactive: there is no Ready container, so traffic must first be forwarded to the Activator, which cold-starts a container and then forwards traffic to it

This is the same traffic-forwarding approach as Kubernetes Pod, Service, and Ingress; the only addition is the concept of an Activator carrying cold-start traffic.

As for its elasticity, it also relies on Kubernetes’ capabilities, supplemented by autoscaling policies such as HPA, KPA, and KEDA.

Kubernetes has three modes of use:

• Fully managed: both master and worker are handed to the vendor
• Semi-managed: master is handed to the vendor, workers are maintained by yourself
• Self-built: build your own Kubernetes cluster on top of IaaS

With fully managed Kubernetes such as EKS, it is easy to achieve Serverless elasticity.

This form of Serverless is not revolutionary; it is merely a change in how the runtime is used.

The other is FaaS-form Serverless, whose granularity is the function rather than the container, and which usually still needs external BaaS services to support its state storage.

As the figure above shows, there are two forms of FaaS Serverless:

• Container
• Native Runtime

Container-form FaaS leverages Kubernetes’ capabilities, whereas Native Runtime FaaS supports only a limited set of languages, generally interpreted languages such as TypeScript, JavaScript, and Python.

More critically, FaaS-form Serverless is too heavily customized. It is either vendor-locked to a vendor’s FaaS service or tied to a platform’s application framework, allowing only the specified languages, frameworks, and components — a very narrow scope. In certain niche areas there may be some opportunities, such as offline computing, data processing, and data analysis.

Overall, Container Serverless is not disruptive, and FaaS Serverless is not general-purpose; neither is enough to support the next transformation in application form.

2. WebAssembly Will Be the Next King

WebAssembly is a new runtime form. It is a binary format that can run in environments such as browsers, Node.js, Deno, and WASI.

In fact, as long as a runtime and system interface for WebAssembly are implemented, WebAssembly can run on it. If an operating system integrates a WebAssembly runtime, then WebAssembly can run on that operating system. WebAssembly has a chance to become the new delivery format after Container.

The figure above is the traffic diagram of WebAssembly Serverless. WebAssembly Serverless has no scale-to-zero or cold-start problems, giving it a large advantage in both cost and performance.

With WAGI, HTTP requests can be converted into WebAssembly calls. At this point the runtime is no longer directly a Container but a WebAssembly Runtime. Whether the underlying layer is Container, VM, or bare metal no longer matters — WebAssembly has shed these constraints and can even be an IoT device. All that is needed is for these devices to form a huge pool of compute and storage.

WebAssembly Serverless has no vendor lock-in; code written in any language can run on WebAssembly Serverless as long as it is compiled to WebAssembly.

3. The Frontend Becomes Backend-Like, the Backend Becomes Lightweight

Today the bulk of compute power is concentrated in the backend; the frontend is a simple UI layer with very little compute power, handling only simple rendering, event handling, and so on.

But in recent years there have been some changes:

• Frontend compute power is growing stronger, and the performance of phones and computers keeps improving
• Frontend engineering capability is growing stronger and can replace the backend for a lot of work, such as document rendering, image processing (Photoshop, CAD), and video processing (uploading videos to Bilibili)
• Backend compute costs keep rising, requiring more machines
• Backend labor is expensive; backend salaries are generally much higher than frontend ones

So I drew the figure below:

Compute and storage are pushed down to the frontend, where “frontend” here includes IoT devices, phones, computers, browsers, and other terminals close to the user. The backend trend is toward becoming lightweight, providing only some basic BaaS services.

This is consistent with the idea Serverless = FaaS + BaaS, except that FaaS is on the frontend and BaaS is on the backend. This is what I mean by the frontend becoming backend-like and the backend becoming lightweight.

The frontend starts to become heavy, providing runtime compute; the backend becomes lightweight, providing only basic services, or even just static file distribution.

As the figure above shows, the backend provides only an access entry point. Once the frontend has finished loading and downloaded the WebAssembly, it no longer has anything to do with the backend. You may not even need to develop a separate backend — a CDN network alone will do.

4. Distributed Applications Will Be Easier to Develop

I mentioned the form of next-generation applications earlier, so what exactly is that form? Distributed applications.

There is a good example in the blockchain space: DApp applications. DApps have two characteristics:

• Decentralized
• Distributed

Decentralized means there is no centralized server; distributed means the application’s data is spread across multiple nodes.

The biggest problem in today’s networked world is centralization. Traffic, attention, and data on the internet are all concentrated in a handful of companies, and wealth is concentrated in the hands of a few people along with it. This is the source of many conflicts.

The emergence of distributed applications can solve these problems.

As the figure above shows, every device is both a consumer and a producer. Every device can provide compute, storage, and network, and can also consume compute, storage, and network.

Only then does the data truly belong to the user, rather than being controlled by a centralized server.

With enough such nodes, an entirely new distributed network can be formed, and applications built on it are the ones facing the future.