Dynamically and instantly scalable services
Serverless, presented as one of the evolutions of the cloud, this solution means that developers are no longer constrained by the management of servers, including virtual ones. The result is a scalable platform tailored to their specific needs.
Once again, are the Anglo-Saxons ahead of us? While Severless computing has been widely discussed and addressed in the United States for some years (Amazon's offer dates back to late 2014), it remains little-known in France.
A large majority (79%) of zdnet.fr readers claim to know nothing about the concept! Admittedly, this survey is not very "scientific", but it is nonetheless based on nearly 440 responses.
Let's start by answering that famous question: what is a serverless architecture? Contrary to what the term "serverless" might suggest, servers don't just magically disappear. They're always there! The difference lies in their implementation and management.
As we all know, traditional servers rely on fixed resources, run all the time and need administrators. In short, they're time-consuming and not really cost-effective.
and now... FaaS
With Serverless computing, they are executed in event-driven computing instances, according to demand or specific business needs.
Serverless can, for example, meet the requirements of e-commerce sites whose traffic can increase sharply during certain events such as sales or Black Friday.
Services are dynamically and instantly scalable. Ideal for the development of microservices modules.
Hence the acronym FaaS (Functions as a Service). Your bill depends on your use of "functions". Logically, the best-known FaaS services are Amazon Web Service Lambda (but which also has a "serverless" version of its eponymous relational database called Aurora Serveless since late 2017 and Fargate, a container solution), Microsoft Azure Functions, Google Cloud Functions, IBM Bluemix OpenWhisk or hook.io microservices.
The benefits of Serverless
The first advantage for developers is obvious: they no longer have to worry about configuring and adjusting the virtual servers on which the microservices and functions making up their applications run.
They can better concentrate on the functionality and code of their application. It's the provider's systems that take care of managing the resources required by the function. This means that when the request is served, the report is automatically stopped.
But some providers offer another advantage. Even if the cloud avoids massive investment in infrastructure, it's not uncommon for virtual machines to continue operating without being "productive"... Not to mention unused Amazon Elastic Block Storage (EBS) file systems.
According to a study by Cloudyn (an Israeli-born vendor specializing in cloud services cost management and acquired in July 2017 by Microsoft) many virtual machine instances are running at less than 20% load.
To avoid this aberration, AWS Lambda allows code to be executed only when needed. It is triggered by an event representing a computation request.
For example, Amazon's Lambda service tariff is based on 100 milliseconds, whereas VM tariffs are usually calculated in hours or minutes.
Finally, in the case of FaaS, functions can be executed among other functions in a pool of shared resources. Scaling is performed automatically.
This can be a decisive point when deciding between FaaS and PaaS. PaaS requires you to estimate the amount of resources required. This means there's a risk of over- or underestimating the real need.
The limits of Serverless
Not everything is perfect. The main concern is the multiplication of suppliers with different implementations of their serverless architectures. Porting code from one vendor to another can sometimes prove costly.
Another grey area is the confidentiality of sensitive information. "For Serverless, the management of cross-border data flows, and therefore their localization, is crucial, since it is the sole responsibility of the service provider.
Insofar as the Serverless service provider is the sole decision-maker on the resources allocated to processing, it would be legitimate to reflect on the qualification of joint data controller," explains Éric Le Quellenec, of Lexing Alain Bensoussan Avocats.
Three clauses need to be addressed in this type of contract:
- Guaranteed scalability and upgradability, as well as performance and availability;
- Collaboration with the partner: it must be structured and explicit;
- The price clause: this metric must be very clear and precise (for example, a code that runs every 15 minutes to clean up a database table according to a customized business logic). Using an easily accessible supervision tool, the customer must be able to check, in real time, what is being consumed.
These solutions are well suited to web, mobile backend (authentication, BD request, API call) and IOT applications. But here too, you should not be too hasty. Because if the code is badly done, the bill could be much higher than with a traditional architecture...
