Serverless computing, to the very end of the Cloud logic

Serverless computing is a principle that has recently appeared on the IT scene. It is a kind of quest for the absolute on the part of CIOs, and perhaps even more so on the part of CFOs. It seeks to answer the most primitive question of the Cloud: can we do without servers?

When Cloud Computing was born, it was all about lowering the cost of investment in IT infrastructures. And by extension, to gradually free ourselves from all the constraints imposed by these infrastructures.

Let's take a closer look at serverless: how is it defined? What are the most tangible and demonstrable benefits, and above all, what are the drawbacks and risks? As you will see from the answers we provide below, there is nothing magical about serverless. But there is an effective mix of technologies and business models to respond as closely as possible to the changing demands of businesses.

See all software Virtualization

Serverless: the definition of serverless computing

What is serverless?

The term " serverless" refers to the execution of an application's code without the need for a server.There is no local or Cloud infrastructure dedicated specifically to a given organisation or application.

In other words, in a serverless architecture, not only the execution of the code, but also the maintenance of the servers, is managed by the cloud provider.

The advent of FaaS, Function as a Service

A word of clarification is in order: behind this eye-catching name are, despite appearances... servers.

Because the technology is not yet at the stage where computing will become totally virtual, impalpable, free of all physical constraints. There are, of course, resources and servers on which the code will run.

This approach is quite similar to that of microservices. The difference is that serverless architecture is naturally linked to a Cloud Service Provider (CSP). Whereas microservices are based on containers that can be deployed on different hostings.

The term FaaS, or Function As A Service, is often used. The idea is to execute a function on demand, each time it is needed, by requesting a remote Cloud provider:

1. The developer simply needs to provide his code;
2. the provider will return the result each time it is requested.

So, first and foremost, we're looking to reduce infrastructure costs, and be highly adaptable.

Advantages and limitations of serverless

Financial advantages... but not only

The invoicing model is most often a " pay-as-you-go" model: the company pays for the memory, storage and computing power used during execution, according to its use, and therefore according to the server time used:

• serverless makes it possible to reduce the costs of a service that is used very little;
• in any case, billing is a kind of culmination of the Cloud Computing concept: it is a strict reflection of the use made of the remote server;
• if a function or code is not executed, the cost may be zero.

Another advantage is the speed of development. To go from project to production, you no longer need to worry about the infrastructure: the computing power will inevitably be available, as and when you need it.

Flexibility is also a definite advantage. If you don't want to spend time sizing up or testing hardware resources, transfer the load to the CSP. It will always be able to provide you with the power you need, when you need it: that's part of the contract.

Serverless, but not without constraints

Despite appearances, this architecture imposes certain rules.

One of these is the reduced number of suppliers. The 3 largest are :

• AWS (Amazon Web Service), and in particular AWS Lambda, which is the historic player,
• Microsoft Azure Functions,
• and Google Functions.

The billing method means that you need to design code that doesn't consume a lot of computing time:

• in any case, the execution time allocated to the function is generally limited;
• you cannot exceed it, or it will be overcharged.

👉 For example, AWS, which launched this concept in 2014, gives the following figures:

• the median execution time for a function on its servers is 800 ms,
• only a quarter exceed 3 seconds
• and 12% run for more than 10 seconds.

In general, coding is constrained by the languages (or language) supported by the Cloud Service Provider. Billing is also based on the memory required to execute your code.

So, while serverless architecture is highly flexible and can cope with large increases in workload, it must be kept under control in terms of cost. It can even be more expensive than a traditional on-premise or cloud architecture.

Serverless also means a specific approach to security

Because of its very specific nature, the serverless paradigm stands out in a number of respects when it comes to security:

• cloud providers manage the operating system, runtime security and patches. This is a guarantee, given the scale of today's providers;
• the ephemeral and stateless nature of serverless computing makes life more difficult for attackers. The fact that serverless functions come and go, without memory, reduces the risk of long-term attacks;
• the small size of the code blocks makes them easier to analyse by CSP security tools.

On the other hand, this architecture also creates vulnerabilities. Every function becomes a potential point of attack, making it harder for providers to monitor their servers. It is also more complicated, for both the CSP and the coder, to observe multiple processes and multiple input/output points.

Traditional applications have a clearer perimeter, with the outside and inside clearly distinct. Traditional security features such as WAF, firewall and IDS can be installed.

Finally, it should be noted that native cloud applications can use numerous modules and libraries with code from various third-party sources. Potential attackers could then try to include malicious code in common projects.

See all software Virtualization

Serverless, an architecture to be adopted as a matter of urgency?

As is often the case with emerging technologies and concepts, we need to take a step back before deciding whether to adopt or reject them. It only makes sense in a given context.

Beyond the simple technical aspect, its use can also have an impact on your organisation's human resources. It requires you to rely on a solid team of coders, which you may need to strengthen.

At the same time, it can lead to a reduction in the resources dedicated to infrastructure and its management.

So, in fact, even if it seems designed to allow you to make one-off choices, by boosting certain projects, it can profoundly transform your IT Department and the services linked to it.