Where are all the servers in a serverless world?

Lambda, Google functions, Azure functions; the joys of going serverless…

Serverless computing removes the notion of a server from the use of a computing resource. Technology has evolved from physical servers to virtualisation and abstraction of hardware. Later moving to containers and abstracting the operating system. Serverless takes it one step further and abstracts the language runtime. It means that users provide their code and their data, and the cloud platform’s Serverless engine dynamically provisions resources as needed. We no longer need to worry about how much CPU, RAM and storage our application will require; the Cloud provider will take care of that for us. We will not have to manage the operating systems, high availability and other features such as load balancing. Those will be provided dynamically by the cloud provider and hence the term Serverless; i.e. we have no servers to manage.

The Serverless architecture is based on two fundamental concepts;

  1. Events or Triggers: Any event that triggers the running of our code. These events could be sent directly to our code (diagram 2) or could use API calls to our code (diagram 3)
  2. Codes/Functions: The actual code.

The ability to fire off functions in certain order and sequence to basically meet the exact needs of the application is a core part of Serverless computing.


The benefits of this model are;

  1. No servers to manage: we allocate the functions, and then the operating system within the cloud and the cloud platform itself, will gain access to the resources we need to support those functions.
  2. Continuous scaling: instead of you having to spin up new machine instances, the cloud platform does that for you
  3. Avoid over-allocation of resources: we only pay for the services that are needed to support for that function


There are some limitations with the Serverless architecture;

  1. They are tightly integrated to the public cloud which they are based on. i.e. vendor lock-in
  2. They are not portable to other platforms
  3. No real open-standards in this space

When to go Serverless ?

Serverless is primarily for new applications and not legacy applications that are being migrated into a cloud platform. To plan for the deployment of a Serverless application we need to know;

  • A list of functions our application will have
  • A list of event sources
  • Links and interactions required for when the application is running


Three current cloud providers that provide Serverless functions;

  • AWS Lambda
  • Microsoft Azure Functions
  • Google Cloud Functions (still in Beta)


There are two core components to AWS’s Serverless offering;

  1. API Gateway: a service for creating and managing APIs. Clients integrate with the APIs using standard HTTPS requests. Depending on your application and use-case, this functionality may not be required (as per diagram 1)
  2. AWS Lambda: a service for running arbitrary code functions written in Node.js (JavaScript), Python, Java (Java 8 compatible), and C# (.NET Core) and Go.

Amazon API Gateway’s integration with AWS Lambda enables user defined code functions to be triggered directly via a user-defined HTTPS request. Regardless of the request volume required, both the API Gateway and Lambda will scale automatically to support exactly the needs of the application. Recently, AWS has announced the ability to create Lambda functions that execute within clients’ Amazon Virtual Private Cloud (Amazon VPC). This feature extends the benefits of Serverless applications to include a variety of use cases where network privacy is required. You also have fine grain control over who can call your functions.

When building Serverless applications on Lambda, the core components are Lambda functions and event sources.

  • Functions: basically code that’s going to carry out some important of behaviour, typically with data bound to those behaviours
    • Event sources: event sources that invoke a function

AWS Lambda billing is based on the number of requests for your functions and the duration, the time it takes for your code to execute. AWS API Gateway billing is based on the number of API calls you receive and the amount of data transferred out. You can also opt for data caching, which is charged at an hourly rate and varies based on the cache size you select.


Azure Functions is Microsoft’s answer to AWS Lambda.

It has many of the same functions as Lambda and leverages many of the same kind of terminology but it is well integrated with Microsoft’s ecosystem. The diagram below gives an example of this integration;

Microsoft Azure Functions use C sharp (C#), F sharp (F#) and JavaScript (Python, PHP, Batch and PowerShell are experimental at the moment) and is considered to be more open than AWS Lambda. In fact, the Functions runtime is open-source and is available on GitHub.

Microsoft provides two billing plans, the Consumption plan and the App Servoces Plan. On the consumption plan users are billed based on per-second resource consumption and executions. Consumption plan pricing includes a monthly free grant of 1 million requests. On the App Services Plan, if you are already using App Service for your other applications, you can run your functions on the same plan at no additional cost.


Cloud Functions (still in Beta) is another Serverless platform that supports JavaScript and executes codes in a standard Node.js runtime environment.

The Google Cloud Functions pricing is based on number of triggers (Google calls them Invocations) and per 100 millisecond code execution. You also get 2 million free triggers per month (double that of Microsoft).