Français
In 2026, French companies’ cloud bill topped €27 billion according to the latest estimates from the consulting firm Markess. Yet many technical decision‑makers remain confused: serverless computing versus cloud, what is the real difference? Isn’t serverless, by definition, cloud? Technically, yes. But the two terms encompass very different philosophies, economic models, and responsibilities. Confusing the two is like putting a long‑term rental apartment and a hotel room charged per night in the same basket. Both give you a roof, but the commitments, costs, and flexibility have nothing to do with each other. This article breaks down the concrete distinctions to help you choose the architecture that best fits your projects.
Fundamentals of Cloud Computing and Serverless
Definition of Traditional Cloud (IaaS, PaaS, SaaS)
Cloud computing relies on the provision of computing resources via the Internet, without the user physically owning the servers. Three main layers are distinguished. IaaS (Infrastructure as a Service) provides virtual machines, storage and networking: this is the case of OVHcloud, AWS EC2 or Azure Virtual Machines. You rent the raw infrastructure and manage everything else, from the operating system to the applications.
PaaS (Platform as a Service) moves one step up in abstraction. Services like Heroku, Google App Engine or Scalingo take care of the operating system and the middleware. You deploy your code, the platform handles the rest. SaaS (Software as a Service), on the other hand, is the model most familiar to the general public: Gmail, Salesforce, Microsoft 365. The user consumes a ready‑to‑use software without worrying about the underlying infrastructure.
What characterises classic cloud is that you reserve resources, whether you consume them or not. You provision an instance with 8 GB of RAM and 4 vCPU, you pay for that capacity 24 h/24, even if your application sleeps at 3 a.m.
The emergence of Serverless and the FaaS concept
Serverless computing appeared as a response to this waste. The term is misleading: there are indeed servers, but you no longer have to worry about them. The cloud provider fully manages the infrastructure, the allocation of resources and the scaling. Your only responsibility: write code. For organisations asking “What is serverless computing?”, it is a execution model where resources are automatically provisioned and billed only when they are used.
The central concept of serverless is FaaS (Function as a Service). You split your application into independent functions that run in response to events: an HTTP request, a message in a queue, a file dropped in a bucket. AWS Lambda, launched in 2014, popularised this model. Since then, Azure Functions, Google Cloud Functions and open‑source alternatives like OpenFaaS or Knative have enriched the ecosystem.
Serverless is not limited to FaaS. It also encompasses serverless databases (DynamoDB, Neon, PlanetScale), managed API gateways and orchestration services such as AWS Step Functions. The common point: zero server management, billing to the actual usage. The serverless technology: everything you need to know relies precisely on this ability to abstract the infrastructure so that teams focus on application development rather than resource administration.
Infrastructure management and abstraction
Manual server control vs total automation
With a classic IaaS cloud, your DevOps team configures virtual machines, installs dependencies, manages SSL certificates, sets firewalls and monitors system metrics. This granular control is an asset for complex architectures that require specific configurations: precise Linux kernel choice, GPU drivers for machine learning, or regulatory constraints imposing a certain type of encryption.
Serverless removes that layer. You do not choose either the operating system nor the amount of RAM allocated to your function (except a maximum ceiling). The provider decides how and where to run your code. For a startup that wants to deliver fast, this is liberating. For an IT department used to controlling every parameter, it can be destabilising.
A concrete example: an e‑commerce company based in Lyon processing 500 orders per day probably does not need to manage its own servers. In contrast, a medical‑software publisher subject to HDS (Health Data Host) certification may need the control offered by a cloud IaaS to prove compliance to auditors.
Responsibility for maintenance and updates
On a traditional cloud, security updates of the operating system are your burden. When a critical flaw like Log4Shell appears, it is your team that must patch the servers, sometimes urgently on a Friday night. Application patches, runtime version upgrades, certificate rotation: all of this consumes engineering time.
In serverless, the provider applies security patches to the underlying infrastructure transparently. You remain responsible for your code and its dependencies, but the OS‑related attack surface disappears from your perimeter. For small teams, this is a strong argument: less maintenance means more time devoted to developing business‑value features.
The flip side is the dependency on the provider for runtime updates. When AWS decides to deprecate support for Node.js 16 on Lambda, you must migrate according to its schedule, not yours.
Comparison of billing models
Paying for allocated resources (classic cloud)
The economic model of traditional cloud rests on capacity reservation. You rent an EC2 instance of type m6i.large, you pay roughly $0.096 per hour, i.e., about $70 per month, whether your CPU runs at 2 % or 100 %. Providers offer discounts via reserved instances (1‑ or 3‑year commitments) or spot instances (excess capacity at reduced price but interruptible).
This model is predictable. Your CFO can budget cloud costs with a reasonable margin of error. But it generates structural waste. According to a Flexera study published early 2026, companies waste on average 28 % of their cloud spend on under‑utilised resources. Development servers running on weekends, forgotten staging environments, oversized instances “just in case”: all are phantom expense lines.
For stable and predictable workloads, a dedicated server or a reserved instance often remains more economical than a serverless approach. A service that consumes 100 % CPU continuously will cost less on a well‑sized VM.
Paying per execution and actual consumption (Serverless)
Serverless bills only what you consume: the number of invocations and the execution duration of each function, measured in milliseconds. In 2026, AWS Lambda’s rate is about $0.20 per million requests and $0.0000166667 per GB‑second of compute. If your function does not run, you pay nothing. This approach perfectly illustrates serverless in modern cloud computing, where enterprises aim to optimise costs while benefiting from infrastructure that automatically adapts to load variations.
This model is deadly for irregular workloads. Take a Parisian restaurant‑booking site: traffic spikes between 11 am–1 pm and 6 pm–9 pm, then falls to near zero at night. In serverless, the bill reflects exactly that curve. In classic cloud, you pay for servers sized for the peak, even during idle hours.
The trap is cost unpredictability at scale. A badly coded function that calls itself in a loop can generate millions of invocations in minutes. Without well‑configured billing alerts, the invoice can climb very quickly. Several French companies shared experience on this topic during the latest AWS Summit Paris, some mentioning surprise bills exceeding €10 000 in a single month.
Scalability and operational performance
Native auto‑scaling vs configuring elasticity
One of the most tangible advantages of serverless is its ability to scale instantly. If your function receives 10 requests per second then suddenly 10 000, the provider automatically allocates the necessary resources. You have nothing to configure. This native elasticity is especially valuable for unpredictable events: a press mention, a traffic spike linked to sales, or a viral marketing campaign.
In classic cloud, auto‑scaling exists but requires configuration. You define rules: “If CPU > 70 % for 5 minutes, add an instance.” You set up a load balancer, auto‑scaling groups, alarm thresholds. This configuration takes time and expertise. A bad setting can lead either to under‑provisioning (your site crashes) or over‑provisioning (your bill explodes).
Fundamentally: in serverless, scaling is a default behaviour. In traditional cloud, it is a feature you must implement and test.
The cold‑start challenge
Cold start is the Achilles’ heel of serverless. When a function has not been invoked for a while, the provider must initialise a new execution environment: load the runtime, the dependencies, then run your code. This delay can range from a few tens of milliseconds (for a lightweight Python function) to several seconds (for a Java function with a heavy framework).
For an API that must respond in under 100 ms, this latency is problematic. Providers have built mitigations: AWS offers Provisioned Concurrency, which keeps “warm” instances permanently, but this partially returns to the classic billing model. Google Cloud Run, which runs containers in a serverless mode, offers an interesting compromise with generally shorter cold starts.
On a traditional cloud, this problem does not exist. Your server runs continuously, ready to answer. This is a decisive argument for real‑time applications: high‑frequency trading, online gaming, video conferencing.
Criteria for choosing your architecture
Ideal use‑cases for traditional cloud
IaaS or PaaS remains the pertinent choice in several precise situations:
- Existing monolithic applications that work well and whose rewrite into micro‑services is not economically justified
- Stable, predictable workloads with an average CPU utilisation above 60 %
- Systems needing fine‑grained infrastructure control for compliance reasons (HDS, SecNumCloud, GDPR with strict localisation)
- Applications requiring long‑lived connections: WebSockets, video streaming, relational databases with complex connection pooling
- Continuous, compute‑intensive workloads: AI model training, 3D rendering, scientific simulations
A mid‑size industrial SME running a bespoke ERP for ten years has no interest in migrating to serverless. The rewrite cost would far outweigh the potential savings.
When to favour a Serverless approach
Serverless shines in well‑identified contexts. Event‑driven applications are the textbook case: image processing after upload, notification dispatch, data synchronisation between systems. Variable‑traffic back‑end APIs are also excellent candidates, as are scheduled tasks (cron jobs) that run a few minutes per day. This evolution confirms the growing place of serverless in modern cloud computing, especially for organisations that want to accelerate digital transformation without adding infrastructure overhead.
Start‑ups in a proof‑of‑concept phase reap immediate benefits from serverless. No fixed costs, no servers to manage, rapid production rollout. If the product does not find its market, infrastructure costs stay near zero. If traffic takes off, scaling is automatic.
Hybrid architectures are increasingly common in 2026. The core application runs on Kubernetes containers (classic cloud), while peripheral functions (image processing, webhooks, asynchronous jobs) are deployed serverlessly. This approach combines the stability of traditional cloud with the flexibility of serverless where it adds the most value. Many companies also prefer open‑source services to limit vendor lock‑in and strengthen digital sovereignty.
Synthesis of advantages and limits for the enterprise
The choice between classic cloud and serverless is not binary. It depends on your context: team size, workload nature, regulatory constraints, budget and internal skills. Traditional cloud offers control, predictability and maturity. Serverless brings agility, cost reduction on variable loads and eliminates operational server management.
The trend observed among French companies moves toward mixed architectures. The most effective IT departments do not pick a single side: they place each component on the model that best fits. The real risk is not choosing the wrong model, but locking yourself into a single provider without a reversibility strategy. As organisations seek agility and cost optimisation, understanding how serverless computing works? becomes essential for making the right technological choices. This knowledge allows you to identify the most relevant use‑cases and fully leverage the benefits of modern cloud while maintaining efficient infrastructure governance.
If you are looking for a partner capable of guiding you through these architectural choices with an open‑source approach that preserves your technological independence, LINAGORA offers cloud solutions and free tools designed for French enterprises. Thanks to its expertise and technical support, the company helps organisations design, deploy and operate performant, scalable and sovereign infrastructures. Discovering their solutions can be a good starting point to build an infrastructure adapted to the current challenges of cloud and serverless.
