Cloud iconIf you follow IT news, and particularly the innovations in Cloud Computing, you probably saw one of many references to the latest buzzwword: “serverless”. What really hides behind this term? Is it a revolution or just window dressing?


Until recently, a service provided on the Internet was deployed in a classic way: servers, services on these servers, code executed or interpreted by these services on these servers.

Let us take the usual example of a website programmed in PHP: when a request is sent to the web server, the latter has to have the code interpreted by a dedicated PHP module. It can be a web server module (mod_php), or a full interpreter (PHP-fpm, a server solely dedicated to PHP interpretation). Once interpreted, the code is sent to the HTTP service (Apache, NGINX, …), which sends it to the web browser.

This operating applies to any hosting type, whether the machines are physical or virtual. It is also the case for containers (like Docker), even though in this case the services are as isolated from each other as possible, in order to only manipulate small units or micro-services.

In any case, these services are part of the website’s infrastructure, and all the corresponding servers thus have to be maintained by its hosting provider, just like the webserver of the site itself. These elements  thus must be taken into account during the creation or migration of a website.

There lies the weakness of this model: it relies solely on the presence of servers. Even if their creation is automatized, they still need to be installed, watched over, maintained, and to evolve… Yes, even for you, who likes Docker and believes that you containers do not need administration: without taking care of the underlying components, your architectures will be populated by zombies in the making if you do not watch out.

Serverless: code and only code

AWS logo

However, the main companies providing public Cloud, and Amazon among them, opened a breach in the Internet service building. In 2014, during the great event Re:Invent, Amazon announced the availability of Lambda, an on-demand code execution service. When it was launched, few people already imagined the incredible power of such a service; as is often the case with AWS, the product targets their gigantic client Netflix.

The latter needed to resize a large number of good quality images to turn them into thumbnails; however, the renting of instances (virtual machines) to do this meant significant expenses, even if they are “spot” instances. Using the servers also takes some time, if only to create and start a machine… To overcome this, Amazon offered Netflix to use Lambda to resize their images.

How then does Amazon Lambda work ? It needs two distinct elements:

Serverless service Lambda
  • The Lambda function: it is a piece of code (Javascript/node, Java or Python). It is declared, with a unique name, by a website administrator on the interface of the service. Let us go back to our example: Netflix declared a function, which we will call “resize”, containing code that transforms a picture into a thumbnail.
  • Events: an event is triggered when a data changes state. For instance, on an Amazon S3 storage space, any modification of an object can trigger an event; that was used by Netflix, as we will see. These elements can only be placed by AWS, which progressively implements it on their products.

In order to function in “serverless” mode, one has to link these elements to one another ! To do that, the event has to be associated to a Lambda function: every time it is triggered, the code of the function is executed. Netflix thus used S3 storage space, and linked the corresponding event to their “resize” function. When an image is added to the storage space, the event is triggered, the function is called, and the code is executed.

There lies the strenght of the product: triggering on-demand code execution. Of course, this service and its code are hosted on servers, instances, containers, etc… but only the service provider (in this case, Amazon) can and has to keep these equipments working for the service to be available and ready to be used. It is no longer your problem (or Netflix’s one).

An analogy can be made, for instance, with a laundromat: you use this service to do your laundry, but you don’t need to worry about the installation, maintenance or replacement of the washing machines. If all the machines are broken, you will not be able to use the service, but the only thing you have to (and can) do is wait until it is available again.

Pico service ?

We set the bases necessary to completely do without the administration of an environment, server or container. You probably will have understood by now that the key element of this new kind of service is the event. In the previous example, the manipulation of a file in S3 triggers a Lambda function, but other triggers are available, and particularly the famous API Gateway. It enables to expose a REST API to link endpoints to Lambda functions, and thus to use the “serverless” technology for http requests.

Serverless serviceExplanation: with the API Gateway, you can expose (make available) URLs. By registering an URL in this API (like this one, you benefit from a endoint, an “empty” URL. The second step is to link this URL to a Lambda function: any call of the URL will trigger the execution of the function’s code. This function can be written in Javascript (node), Java or Python: you thus benefit from all the capacities of your favorite language, and have the opportunity to use its many available libraries. These are the only prerequisites to create a dynamic website without a server.

Concretely, how does it work?

Let us take the example of a dynamic website. Its static structure is composed of HTML code. The difference lies in the treatment of the dynamic part of the website.

Scenario 1: classic architecture

The dynamic part of the website is handled, for instance, by Python in the case of a website with a server. The HTML part of the requested page is sent by the web server, while the Python part is transmitted to the matching interpreter before being sent back. Thus, there are at least 2 services (potentially 2 servers): one for the web server, one for the interpreter.

Scenario 2: serverless architecture

First, you have to declare a Lambda function (for instance “RSS”, to get and display a RSS feed), and an endpoint (for instance “RSS_URL”). In addition, you only need a static page stored on an Amazon S3 space. The static content is still written in HTML, but the dynamix part is handled by Javascript / jQuery code. In addition, you can declare that when the HTML tag “page_bloc” loads (or any other Javascript event), the RSS_URL will be called. The RSS function will then be called too, and the RSS feed will be displayed in the space defined by the tag, dedicated to displaying the dynamic result.


Possibilities are legion: you can declare a whole module as a Lambda function! You will thus be able to create a complex, scalable and efficient website that is entirely structured around Amazon services. The provider alone will deal with the service and its size, and make sure that the resources are only started when needed. You thus only pay for the number of requests for your functions and the time your code executes!

Still day one

Even if the world “serverless” is buzzing right now, this is only the beginning. However, the democratization of this technique raises questions, especially about the survival of certain kinds of companies of the IT sector.

Serverless quel futur

In a world without servers, what becomes of the ecosystem around datacenters? Are hosting providers still useful? Do hardware makers see their sales decrease, and their client pool be reduced to a handfull of service providers? Does consulting become the spearhead of the IT industry? In any case, independent developers should be more solicited than ever: without any “monolithic” sites, they could well replace development agencies to maintain, punctually and case by case, these functions, which are “independent” from one another.

Yet, many pioneers have already invested the breach for a few months. Among the most famous solutions are the plainly called, Zappa or even chalice, three open source project aiming at making the integration of these serverless services easier.

Like Dr. Werner Vogels, Amazon’s CTO, clearly stated, this revolution is only starting and with the cleverness of the developpers, no doubt there are surprises in store in a… quite close future.

Written by Emile Heitor & Lucie Saunois

Emile Heitor
Emile Heitor
After being NBS System’s CTO, Emile now guides our clients in their most complex projects, especially on the AWS public Cloud. A renown expert in IT, always at the forefront of technology, he understand and makes understand the stakes and evolutions of the field.