In Part I we took a close look at the term “serverless” as it is used in cloud computing. We spoke about a serverless application - where you do not have to write a software server. Instead, you focus only on writing a request handler. Let’s now spend some time talking about this programming model; easily creating serverless functions and serverless applications.

Your program is started when a request is received. The request object is passed into a function in your code. That function is expected to run to completion, possibly handing back a response. Once the function has been completed, the program exits.

There are three characteristics of this sort of program:

• It is short running, often running for only milliseconds.
• It is triggered by an event or a request.
• It is responsible merely for dealing with that request (often returning a response).

Hello World 👋

For the sake of clarity, let’s look at a simple example of this kind of program. We will use the world’s most popular programming language, JavaScript, for this example. But the pattern is similar across languages. Also, we will write an example of a serverless function that handles an HTTP request.

const encoder = new TextEncoder()

// Declare a function that handles a request (in this case, an HTTP request)
export async function handleRequest(request) {

    // Send back an object that describes a response (in this case, an HTTP response)
    return {
        status: 200,
        body: encoder.encode("I'm a Serverless Function").buffer
    }
}

There are three things to note about the example above:

1. We do not set up a server of any sort (we don't even import any libraries).
2. There is a function called handleRequest() that takes a request object. This function is called when an inbound HTTP request occurs.
3. The function returns a response. In this case, it's an HTTP response with a 200 response code (which means no error occurred) and the content that will be displayed in the web browser.

Here is the same example in Python

class IncomingHandler(http.IncomingHandler):
    def handle_request(self, request: Request) -> Response:
        return Response(
            200,
            {"content-type": "text/plain"},
            bytes("I'm a Serverless Function written in Python", "utf-8")
        )

We don't start a server, map ports, handle interrupts, declare SSL/TLS certificates, or anything like that. The serverless app platform does all that stuff on our behalf outside of our code. When a request comes in, this app is started, the handleRequest function is called, and then the app exits.

And how fast is this? Different Serverless platforms have different speeds. With Spin, the handler can be started in under a millisecond. That is why there is no reason to run a server. If we can start this fast, it's much more efficient (and much cheaper) to not be running idle servers.

The above is an example of a serverless function. And when we package that up and send it off to a server, we have built a simple serverless app.

More Definitions 😅

"Wait, i'm confused! If this is a Serverless function, what are Functions as a Service? How does it differ from an Edge Function?"

These are valid questions so let's clarify the two:

Functions as a Service (FaaS)

When AWS Lambda first hit the scene, cloud mavens were keen on collapsing all cloud service names into “as-a-Service”-isms. For example:

• core infrastructure services like compute and networking became “Infrastructure-as-a-Service (IaaS)”.
• serverless databases were called “DB-as-a-Service (DBaaS)” and so on.

In such an environment, it is no surprise that the first wave of serverless app platforms was given the unattractive monicker “Function-as-a-Service”.

Personally, I prefer using "Serverless functions" in favour of FaaS and here's why:

• The term FaaS is opaque. If you don’t know what it means, there are not many clues embedded in the term itself. As with all the “aaS”es, one finds oneself mentally listing words that start with F for clarification.
• The term itself refers to the service that runs. So what do you call an application that runs in a FaaS? A Function-as-a-Service Function? A Function-as-a-Service App? That just sounds confusing.
• Lastly, in English "FaaS" can be verbally hard to distinguish from "PaaS".

In contrast, an app run inside of a PaaS is usually called a server or a microservice. Thus, most people in the field refer to apps that run in a FaaS as serverless apps or serverless functions.

The most famous PaaS, Heroku, does not refer to itself as a PaaS, and for the same reason, we don’t use FaaS. Much of their documentation uses the term “cloud application platform.”

Cloud Functions and Edge Functions

The terms cloud functions and edge functions occasionally arise when talking about serverless applications. For example, Netlify uses these terms in its documentation. The distinction between these "cloud" and "edge" serverless functions does not concern the functions themselves but rather where the specific function is being executed.

• A cloud function executes "in the cloud," which usually means at one of the main hyperscalers such as AWS, Azure, or Google Cloud.

• An edge function executes on the edge, a concept we will cover more later. In a nutshell, "edge" refers to the proximity between the end user and the function which they are calling. The term edge also refers to the proximity of the function being executed and the data being processed. The ultimate goal is to obtain the most efficient round-trip between the user, the function and any data being processed.

Providers like Vercel and Netlify must make this distinction because the APIs they provide for the functions that run in the cloud are different from the APIs they provide for the functions that they run in edge providers like CloudFlare. This is an implementation-specific API difference that bubbles up to the developer.

Our view is that “edge functions” and “cloud functions” are varieties of serverless apps. Keep in mind, when we talk about cloud and edge computing later on that the term edge is niche and only relates to a subset of service providers.

Conclusion 😌

Thanks for staying with us thus far! In this post, we saw what the code for a Serverless function looks like and what happens when it is triggered by an event. In the upcoming posts we'll deep-dive in the characteristics of a Serverless App. We'll look at execution time, CPU & Memory, Statelessness, and more.

Let us know if you have come across any other terminology around Serverless Apps, and we'll try and compare and contrast it for you.