Serverless computing, to the very end of Cloud logic

Serverless computing is a principle that has only recently appeared on the IT horizon. It's 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'll see from the answers below, there's nothing magical about serverless. But an effective mix of technologies and business models to meet the evolving needs 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 in the absence of a server.application code in the absence of any local or Cloud infrastructure dedicated specifically to a given organization 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 attention-grabbing name are, despite appearances... servers.

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

This approach is quite similar to 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 hosts.

The term FaaS, or Function As A Service, is frequently used. In effect, it's a matter of executing a function on demand, each time it's needed, by requesting a remote Cloud provider:

1. All the developer has to do is supply 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 to be highly adaptable.

Advantages and limitations of serverless

Financial advantages... but not only

The invoicing model is generally 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:

• with serverless, it's possible to reduce the costs of a service that's used very little;
• in any case, invoicing is a kind of culmination of the Cloud Computing concept: 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 development speed. To go from project to production, there's no need to worry about infrastructure: computing power is always available, at will.

Elasticity is also a definite plus. If you don't want to spend time sizing or testing hardware resources, transfer the load to the CSP. He'll always be able to provide you with the power you need, when you need it: it's part of the contract.

Serverless, but not without constraints

Despite appearances, this architecture imposes certain rules.

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

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

The billing method implies designing code that doesn't consume a lot of computing time:

• in any case, the execution time allocated to the function is generally limited;
• you can't 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% go beyond 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 significant scalability, it needs to 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 many respects when it comes to security:

• cloud providers manage the operating system, runtime security and patching. This is a guarantee, given the scale of today's providers;
• the ephemeral, 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 code bricks makes them easier to analyze 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's also more complicated, for both CSPs and coders, to observe multiple processes and multiple input/output points.

Classic applications have a clearer perimeter, with the outside and inside clearly separated. Classic security features such as WAF, firewalls and IDS can also be installed.

Finally, it should be noted that native cloud applications can use numerous modules and libraries with code from a variety of third-party sources. Potential attackers could then strive 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 or not to adopt them. It only makes sense in a given context.

Beyond the mere technical aspect, its use can also have an impact on your organization's human resources. It requires the support of a solid team of coders, who may need to be reinforced.

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

So, in fact, even if it seems destined to enable one-off choices, by boosting certain projects, it can profoundly transform your IT department and the services linked to it.