Software Engineer
18 févr. 2023·4 min

Hébergement - Partie 2 : Les différents types

Illustration article hébergement 2

Maintenant que nous y voyons un peu plus clair dans notre parcours d’hébergement, un peu de vocabulaire s’impose ! On l’a vu dans le précédent article, nous sommes passés par plusieurs niveaux d’hébergement et ils ont tous leurs petits acronymes.

Le IaaS (Infrastructure as a Service)

Vous vous rappelez quand j’ai pris ma machine et que je suis allé la mettre chez un hébergeur, ou bien que je lui ai loué une machine ? Et bien c’était du IaaS. Dans ce contexte, l’hébergeur prend en charge l’infrastructure, c’est-à-dire le bâtiment, l’électricité, le réseau. Ça peut aller jusqu’à la mise en place de la machine et l’installation du système d’exploitation mais pas plus. C’est ensuite à moi d’installer tout le reste pour que mon backend fonctionne correctement. Si j’ai besoin d’une base de données, ou de stockage, c’est à moi d’installer et configurer tout ça idéalement sur d’autres machines. En cas de défaillance hardware c’est aussi à moi de réclamer des interventions auprès du fournisseur pour qu’ils changent un disque ou la mémoire par exemple.

OVH, Scaleway etc sont principalement des hébergeurs de type IaaS. Ils évoluent doucement vers le niveau suivant mais ils ont beaucoup de retard comparé à Google, Amazon ou Microsoft.

PaaS (Platform as a Service)

Historiquement c’est sur ce niveau que se positionne le Cloud. Même s’il fait aussi indirectement du IaaS, il va plus loin en offrant des composants logiciels et des outils prêts à l’emploi ainsi que des API pour pouvoir outiller tout ça. Nous ne sommes plus obligés d’opérer pour la gestion de la base de données, du stockage de fichier ou l’envoi des mails. Nous utilisons les services fournis et nous pouvons nous concentrer sur les fonctionnalités de notre logiciel.

SaaS (Software as a Service)

C’est le plus connu du grand public. Quand vous utilisez Gmail, Drive etc. Vous utilisez du SaaS. Là où le PaaS va vous apporter juste des composants logiciel, le SaaS va vous apporter le logiciel tout entier avec ses différentes règles métier. Vous ne vous occupez pas de savoir comment il fonctionne en interne, où il est hébergé, comment il scale etc. Juste, il fonctionne et vous pouvez l’utiliser directement.

Et plus récemment 2 nouveaux ont fait leur apparition

CaaS (Containeur as a Service)

On l’a vu, pour pouvoir optimiser l’occupation des machines physiques, les fournisseurs proposent généralement des machines virtuelles. En termes d’exécution si on prend l’ensemble du flux d’exécution, le serveur va allouer des slots de temps à chaque machine virtuelle pour qu’elles puissent accomplir leurs tâches. Et dans les machines virtuelles elles-mêmes, on va retrouver un système d’exploitation qui va lui aussi allouer du temps pour mon back-end mais aussi pour d’autres choses annexes. Il en est de même pour l’accès aux ressources. Il y a comme une redondance dans tout ça qui ajoute de la charge de travail pas vraiment utile pour nous. C’est là qu’intervient ce qu’on appelle des Containers ou plus particulièrement, Docker. Ça permet, d’une façon assez obscure à première vue, de cloisonner nos backend comme on le ferait avec les machines virtuelles mais sans la surcharge liée au système d’exploitation intermédiaire. C’est le système de la machine physique qui opère directement l’allocation des ressources de chaque backend à travers les conteneurs.

Le gros avantage de cette approche c’est que ça a standardisé la façon de packager une application. Peu importe le type d’application (php, java, node, …) nous la packagons dans un conteneur.

Et bien il y a des fournisseurs qui permettent de déployer directement des conteneurs sans se soucier de la machine en dessous. C’est notamment ce que fait AWS avec son service ECS Fargate.

FaaS (Function as a Service)

Lorsque vous faites vos courses au Drive, Carrefour va vous donner un créneau horaire et vous envoyer un mail pour vous dire que vos courses sont disponibles. Là vous y allez et occupez une place de parking quelques minutes puis vos courses arrivent et vous pouvez partir. S’il n’y avait pas ce mail pour vous prévenir, et que le créneau était fourni par La Poste, vous devriez arriver très tôt le matin, et monopoliser longtemps la place de parking à attendre la préparation de la commande, empêchant quelqu’un d’autre de venir chercher la sienne. Un backend traditionnel c’est la même chose. C’est quelque chose qu’on démarre et qui attend patiemment que des applications lui envoient des requêtes. Pendant ce temps il monopolise une machine qu’on paie. En FaaS, c’est le fournisseur qui se charge d’attendre et d’écouter les requêtes de plusieurs applications. Lorsqu’il va recevoir une requête de votre application, il va charger votre backend et lui transmettre la requête. Une fois celle-ci traitée, il va libérer les ressources occupées par votre backend pour les utiliser pour un autre backend. En gros en mode FaaS, vous êtes la “Function” et Carrefour est le fournisseur. Chez AWS, ce service est possible avec AWS-Lambda couplé avec API-Gateway.

Conclusion

Ça y est, on en a fini des acronymes rébarbatifs. Ça nous a tout de même permis de comprendre qu’il y avait plusieurs niveaux d’abstraction dans le Cloud, du plus proche, du matériel aux plus éloignés. Maintenant que nous avons une meilleure idée de ces différents niveaux, je vous propose de voir cela plus concrètement sur une architecture type dans l'article Hébergement - Partie 3.

4 min

Merci d’avoir pris le temps de lire.

Notre site utilise des cookies
Notre site utilise des cookies pour mesurer notre audience, suivre les performances lors de campagnes publicitaires et vous proposer la meilleure expérience possible.