Traditionnellement, afin de pouvoir afficher un site web à un utilisateur, il faut d'abord posséder un serveur. Ce serveur héberge alors le contenu du site web et est constamment allumé. Dès qu'un utilisateur en fait la requête, le serveur envoie le contenu du site web. Ceci implique une gestion complexe pour le développeur, qui doit s'assurer que le serveur soit assez performant pour répondre à toutes les requêtes. Si le nombre de requêtes émises par les différents utilisateurs devient trop important, il faut alors mobiliser de nouveaux serveurs, en espérant répondre à ce flux d'utilisateurs. Lorsque le flux diminue à nouveau, les serveurs mobilisés seront alors excédentaires et seront allumés pour rien. Pendant ce temps là, ils continuent de consommer de l'électricité et à coûter de l'argent. Il n'est d'ailleurs pas rare dans ce cas de figure que le site utilise du code qui s'exécute du côté du serveur (PHP, par exemple). Ceci signifie que le serveur ne se contente pas d'envoyer le site à l'utilisateur, il doit en plus travailler pour le rendre opérationnel. Une charge supplémentaire pour le serveur, qui sera rapidement débordé en cas d'augmentation de la quantité de visiteurs.
Faire tourner un serveur tout le temps, qu'il reçoive du traffic ou non, consomme de l'électricté. Ceci peut avoir des implications sévères en termes d'impact écologique, avec une consommation d'électricité qui sert uniquement à attendre que des utilisateurs arrivent sur le site. Comme évoqué auparavant, lorsqu'un site est hébergé de façon traditionnelle et que ce dernier enregistre un pic de visiteurs, il est très probable que tous les visiteurs n'auront pas accès au site internet, car le serveur n'arrive pas à suivre. Le temps que le développeur ou l'administrateur réseau alloue plus de resources (plus de serveurs ou plus de capacité), le pic sera passé et les utilisateurs quittent le site, bredouille.
Comment fonctionne alors le serverless et en quoi répond-t-il à ces problèmes ? Quand on parle du "nuage" et du "sans serveur", on nous donne facilement l'impression que tout ça provient d'un lieu mystique quelque part dans le ciel. Malgré son nom, le "serverless" (ou le "cloud") fonctionne bien à base de serveurs, dans des datacenters, bien ancrés au sol. On donne ce faux nom à cette façon de faire parce que le développeur se débarasse entièrement de la gestion des serveurs pour faire fonctionner son application ou son site web. En effet, un site web hébergé entièrement dans le cloud, repose sur le BaaS et les FaaS (cf. définitions en haut de la page). Ainsi, dès qu'un utilisateur fait une requête, ce n'est pas un serveur dédié (qui tournait déjà) qui va lui répondre, mais le "cloud" va répondre directement. C'est comme si le cloud allumait un serveur dédié pour l'utilisateur, uniquement lorsque ce dernier en a besoin. Le tout à une vitesse bien supérieure au serveur traditionnel et à la demande. Par conséquent, un site hébergé dans le cloud peut accueillir et servir sans souci tous les utilisateurs, et le reste du temps, il ne fait et ne consomme rien.
Nous mobilisons très largement le cloud pour propulser les sites de nos clients. Nous assurons alors que votre site a une accessiblité de 99,999%. Mais nous ne nous arrêtons pas là. Parfois, distribuer des sites internet depuis le cloud peut présenter des désavantages. Lorsqu'un moteur de recherche ou un réseau social veut visiter un site dans le cloud, ils le font de façon "fainéante". En clair, ils n'acceptent qu'un format de site très spécifique et ignorent tout le reste. Pour palier à cette fainéantise, nous présentons le site de façon adaptée pour ces requêtes très spécifiques. De cette façon, votre site tire tous les bénéfices du cloud, tout en restant parfaitement présentable pour ces visiteurs fainéants.