En un peu moins de 20 ans, l’hébergement de serveurs a connu plusieurs révolutions. Au démarrage de l’internet grand public, les deux principales offres d’hébergement étaient les serveurs dédiés et les serveurs mutualisés – partagés entre plusieurs clients. Sur ces VPS (Virtual Private Server), des centaines de serveurs web sont hébergés, ils partagent les ressources de la machine hôte ce qui permet d’avoir un coût d’hébergement très attractif. L’offre de service reste basique, avec très peu de possibilité de personnalisation et des ressources limitées.

Depuis, le cloud est apparu avec la promesse d’infrastructures plus flexibles et plus résilientes, réparties dans de nombreuses régions avec la possibilité de démarrer des centaines de serveurs à la demande en fonction des besoins de calculs, ou de tout simplement remplacer absolument tous ses serveurs on premise (sur site). Chaque fournisseur propose dans son écosystème des centaines de services complémentaires, du réseau (DNS, Load Balancing) aux solutions de sauvegardes (instantanées de disque, stockage, réplication), de gestion de logs, de monitoring.

On a commencé à parler d’Infrastructure-as-a-Service (IaaS), de Platform-as-a-Service (PaaS) et de Software-as-a-Service. En passant de l’un à l’autre, vous avez de moins en moins de choses à gérer.

  • IaaS : vous louez vos instances à la demande, ce sont des machines virtuelles qui tournent sur une infrastructure. Vous définissez les ressources dont vous avez besoin (CPU, RAM, Disques) et l’OS à préinstallé et c’est tout. En quelques minutes votre serveur est prêt (comme Compute Engine)
  • PaaS : vous ne vous occupez plus des systèmes d’exploitation et applicatifs. Par exemple un service de base de données Mysql ou SQL Server sans rien installer ou mettre à jour (comme Cloud SQL)
  • SaaS : vous louez et utilisez un service en ligne (comme Google Workspace ou Zendesk).

Cette évolution s’est accompagnée d’une autre tendance : une plus grande modularité des applications, tant en termes de conception que d’infrastructure technique qu’elles exploitent, avec des micro-services, des API REST, des containers orchestrés avec Kubernetes et évolutifs (scalables) à la demande en temps réel. Le concept du multi-cloud pouvait apparaitre , dès lors qu’on pouvait transférer simplement ses applications d’un service à l’autre ou de les exécuter sur plusieurs environnements selon les besoins (on premise, cloud A, cloud B).

C’est ce qui a aussi donné naissance au Serverless, ou Function-as-a-Service (FaaS) : le développeur ne s’occupe désormais que de publier son code qui sera exécuté à la demande, sur un ensemble de machines plus ou moins puissantes, avec facturation au nombre d’appel, temps d’exécution par tranches de 100 ms et mémoire mobilisé à la seconde. (comme Cloud Functions)

Cloud Functions en pratique

Lancé il y a 4 ans, Google Cloud Functions offre une expérience de développement simple et intuitive. Il vous suffit de rédiger votre code, et Google Cloud s’occupe de gérer l’infrastructure opérationnelle. Ainsi vous développez vos solutions rapidement en créant et en exécutant des petits bouts de code qui répondent à des événements, des déclencheurs permettent de se connecter à des services cloud tiers ou à Google Cloud.

On commence par accéder à la console de Google Cloud Platform puis au service Cloud Functions, et on clique sur le bouton CREER UNE FONCTION

On va ensuite donner un nom à notre fonction et choisir dans quelle région elle va s’exécuter. On choisira la région la plus proche des utilisateurs. On définit aussi son déclencheur. Pour notre exemple, on choisit HTTP ce qui signifie que la fonction répondra à des requêtes HTTP, non authentifiée dans ce cas.

On choisit ensuite son environnement (Node.js, .NET, Python ou Java) et on édite son code. La fonction par défaut est la suivante :

exports.helloWorld = (req, res) => {
  let message = req.query.message || req.body.message || 'Hello World!';
  res.status(200).send(message);
};

Il s’agit d’une fonction helloWorld plutôt simple, renvoyant une page web avec le statut HTTP 200 ce qui indique que tout s’est bien passé, et affiche donc le fameux « Hello World! ». On pourrait bien sûr adapté ce code pour passer des paramètres, des données JSON et agir selon le chemin entré dans l’URL. On peut aussi imaginer un service qui récupèrerait une image pour la redimensionner puis la renvoyer, interrogerait une base de données, etc.

Une fois que le code est prêt, il faut déployer la fonction, ce qui prends quelques dizaines de secondes. Ensuite, l’activation du script se fait via l’URL qui en est le point d’entrée, de la forme https:\\région-projet.cloudfunctions.net/exemple-de-fonction. On peut y accéder depuis un navigateur ou lancer un curl. La plateforme va automatiquement activer une ou plusieurs instances et répondre aux appels en affichant le body Hello World! attendu.

Sur la console GCP, on peut visualiser en temps réel, le nombre d’appels, les ressources allouées ainsi que les éventuelles erreurs :