Serverless & Functions — Not One And The Same

When you see or hear the word “serverless,” which of the following comes to mind:

1. AWS Lambda@Edge
2. Cloudflare Workers
3. Physical servers whimsically flying out of a data center

If you picked (3), you may be on the wrong website. If you picked (1) or (2), you’re part of the problem: You are conflating serverless and functions.

As Faizan Bashir wrote in a recent Hackernoon article, “Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers.”

To date, the one technology trend that has adopted the serverless paradigm is “Functions.” Functions are usually event-driven code snippets written in JavaScript, C# and other languages, which may be deployed as handlers for HTTP calls received by an HTTP gateway. For example, when a request is received, a registered handler can be called to modify the request header or body in order to to augment the feature set exposed by the application.

Given the footprint for a Function and their interactions with end users, packaging them alongside CDN infrastructure makes a lot of sense, which is why launched , and launched . CDNs are finely tuned for the delivery of static content that can be cached across a CDN’s global data centers. CDN customers can improve the end user experience by implementing useful, static, simple logic as Functions, and run them closer to users — which is where CDNs already have footprint.

But as applications get more interactive and evolve to deliver hyper personalized experiences, and as application developers explore how to move larger portions of their applications closer to end users, the utility of Functions becomes limited. A number of large, tech savvy companies such as Netflix, Youtube, Facebook and Uber have built out specialized infrastructure to solve this problem for their containerized applications. And now the need is arising within developer circles more broadly. But it doesn’t make sense for all companies to build out their own complex infrastructure along with the ability to build out pipelines to deploy and manage applications running all over the place.

Specifically, there is growing demand from developers to run their containerized microservices close to end users without having to worry about allocation and provisioning of servers near end users. This is essentially a “serverless for containers” model, where a developer can focus on application logic and rely on the service provider to take care of hardware and software infrastructure whenever and wherever it is needed.

So if a “serverless for containers” platform existed, is there need for a “serverless for functions” type platform? Absolutely. Depending on the application’s level of interactivity and personalization, developers may deploy:

1. A majority of their application logic in 1 to 3 public cloud regions
2. Microservices responsible for delivering interactive/personalized experiences close to end users, and
3. Functions to offload specific actions from the core app that run in the CDN context.

As an industry, we went from (1) to (3) because CDNs were able to easily deliver (3). (2) has, to date, been a club of less than 20 companies that have benefited from their investments in distributed infrastructure, the right tools to simplify application distribution, etc.

This must change.

Anyone should be able to deploy microservices closer to end users. Team Rafay has strong ideas around how this should work. Interested in learning more? or .