🚀 Le modèle *aaS
L’émergence du modèle “as a Service” date de la fin des années 90, avec l’idée que l’éditeur de logiciel pourrait non plus vendre son logiciel sous forme de disquette ou de CD à installer, mais sous la forme d’une interface accessible par les utilisateurs, au travers de laquelle ils peuvent utiliser le logiciel “à la demande”. Le monde du SaaS est né.
Cette approche sera par la suite généralisée, au-delà du logiciel, à la puissance de calcul et de stockage. C’est notamment la réflexion derrière la naissance des Amazon Web Services.
🍕 Pizza As A Service
Pour représenter les différents modèles de déploiement, j’ai l’habitude depuis plusieurs années de représenter cela avec le Pizza As A Service. Lors de formations professionnelles ou de cours en école, je parcours souvent le Web à la recherche de la bonne image. Finalement, j’ai créé celle-ci pour imager exactement ce que j’ai l’habitude de présenter.
Ce que j’aime expliquer avec ce schéma, c’est que nous avons le choix dans les modèles de déploiement. Nous parlons aussi de responsabilité partagée : en fonction du modèle sélectionné, cela sera plus ou moins géré par le Cloud Provider.
1️⃣ Côté IaaS, l’idée est de créer soi-même sa pizza. Soit nous créons notre pâte à pizza nous-même (façon “OnPrem”) soit nous l’achetons directement en magasin (“IaaS”). Dans les 2 cas, nous sommes complètement libres de choisir la base (tomate ou crème) et d’y incorporer les ingrédients que l’on souhaite. Certes, cela prend du temps de tout faire soi-même mais cela est très pratique quand nous avons des intolérances alimentaires.
2️⃣ Côté CaaS, l’idée est d’avoir une partie déléguée au Cloud Provider : nous achetons notre pizza froide avec tous les ingrédients au supermarché. Reste plus qu’à faire les courses, la cuire et servir cela à nos invités.
3️⃣ Côté PaaS, l’idée est de ne pas avoir besoin de four : nous allons directement chercher la pizza au camion à pizza.
4️⃣ Côté FaaS, nous allons encore plus loin car nous n’avons plus besoin de nous déplacer… La pizza nous arrive chaude directement.
5️⃣ Enfin côté SaaS, nous n’avons plus à héberger l’outil nous-même : nous allons manger à la pizzeria avec nos amis. C’est plus simple et rapide, il suffit de payer la note en sortant.
⚙️ IaaS — Infrastructure as a Service
Le principe est de virtualiser les principaux composants d’infrastructure :
- Puissance de calcul
- Stockage
- Réseau
- Fonctions de sécurité, répartition de charge
L’idée est de reprendre les concepts d’un serveur physique en permettant de le composer avec différents services consommés. Évidemment, tout ça est piloté par des APIs : nous parlons de SDN (Software-Defined Networking) pour diriger le trafic sur le réseau et communiquer avec l’infrastructure matérielle sous-jacente.
Côté “Compute” quand nous parlons de IaaS, l’unité de déploiement est une VM. Nous allons choisir le type de CPU, la taille de la mémoire, le stockage à associer ainsi qu’une distribution (Linux ou Windows). Ensuite, c’est à nous de gérer la mise à jour cet OS, ainsi que la mise à jour de nos runtimes (java, python etc) et l’installation de notre application pour qu’elle fonctionne.
Le modèle de déploiement “IaaS” est idéal dans un monde Lift & Shift pour migrer rapidement ses charges de travail ou dans le cas où nous avons des traitements spécifiques que l’on ne souhaite pas “refactor”.
Plus d’informations sur les stratégies à adopter pour sa migration Cloud 👇
🐳 CaaS — Container as a Service
Le principe du CaaS est apparu plus récemment avec le développement de la conteneurisation et son orchestrateur phare : Kubernetes (K8S).
Les Cloud providers fournissent un orchestrateur K8S plus ou moins managé permettant de déployer et de gérer le cycle de vie d’applications “conteneurisées”. Cela s’accompagne souvent de fonctionnalités additionnelles (par exemple un “registry” pour stocker ces images de conteneurs).
L’idée est de répondre à la complexité à déployer, administrer et exploiter des clusters Kubernetes, en proposant des offres managées. Avec ce mécanisme, nous pouvons instancier des clusters Kubernetes et déployer dessus avec “kubectl” en restant dans la posture “utilisateur” Kubernetes et non comme un “administrateur” Kubernetes.
L’unité de déploiement est le ou les conteneurs regroupés dans un “pod” et toute la configuration Kubernetes associée (replicaset, service…).
Avec un orchestrateur, l’idée est de décrire l’état désiré, par exemple 3 instances de conteneurs “conteneurA”. L’orchestrateur se charge de réconcilier l’état actuel vers l’état désiré : si un nœud tombe ou si un pod ne répond plus, il va faire en sorte de revenir à 3 instances de “conteneurA”. Si nous désirons finalement que 2 instances et envoyons cette information, l’orchestrateur va arrêter une instance “conteneurA” etc.
Ce modèle de déploiement “CaaS” est très prisé avec l’adoption de Kubernetes par énormément d’entreprises que ce soit pour des workloads classiques ou pour des pipelines de traitement de données. D’ailleurs le CaaS pourrait se renommer en KaaS pour “Kubernetes as a Service”.
A noter que ce modèle évite également une forme de “vendor lock-in” dans le sens où la technologie des conteneurs est opensource comme l’est Kubernetes, tout cela regroupé dans la fondation CNCF (Cloud Native Computing Foundation) assurant une gouvernance saine et partagée de ces projets.
Plus d’infos sur la CNCF avec une présentation sur la fondation 👇
🧑💻 PaaS — Platform as a Service
Le principe du PaaS est relativement vieux : le concept de “Serverless” l’a remis au goût du jour. Initiée avec des solutions comme “Heroku” ou “Google App Engine” à destination des développeurs, le Cloud Provider permet aux développeurs d’uploader du code sans avoir à gérer la partie “runtime”.
L’idée est simple : en fonction du code et ce qu’on a indiqué, le Cloud Provider initie tout l’outillage nécessaire pour construire et déployer une application Web tout en ajoutant des fonctionnalités supplémentaires :
- Des bases de données (SQL/NoSQL)
- Du stockage objet
- Des systèmes de cache
- Du CDN (Content Delivery Network)
- Des noms de domaines personnalisés avec la gestion du HTTPS
- De l’autoscaling
- Des urls previews
Dans le monde du PaaS, l’unité de déploiement est “votre code” avec un petit peu de configuration selon le Cloud Provider. Cela vient avec quelques contraintes que nous qualifierons de “bonnes pratiques” :
- Limitation des runtimes et de leurs versions : il nous faut suivre les mises à jour de versions.
- Limitation niveau CPU, mémoire, temps d’exécution : il ne faut pas prendre 4 Go et 1 min pour répondre à un appel Web.
À noter que cela vient avec une notion de “vendor lock-in” (verrou technologique en français) dans le sens où certains appels “système” nécessitent des librairies fournies par le Cloud Provider. C’est de moins en moins en vrai avec les nouvelles technologies proposées sur étagère côté PaaS.
Ce modèle de déploiement “PaaS” permet au développeur d’avoir un feedback rapide sur son travail, en le déployant rapidement. Aujourd’hui avec les nouveaux “cool kids” comme Vercel ou Netlify cela nous paraît normal d’avoir ces “url previews”.
Côté outillage, pour être le plus “dev friendly”, les Cloud Providers sont très créatifs : du “git push” disponible pour déployer sur CleverCloud à du “Google Cloud Code” disponible dans son IDE préféré.
Pour aller plus loin, voici une vidéo expliquant comment déployer facilement des applications cloud depuis son IDE 👇
⚡️ FaaS — Function as a Service
Dernier modèle de déploiement vraiment intéressant pour les développeurs : le FaaS (Function as a Service). C’est une couche apparue plus récemment dont le principe est de permettre le déploiement de petites portions de codes.
Ce concept rentre dans la catégorie du Serverless avec le PaaS dans le sens où il n’y a pas de “server management” à effectuer.
L’unité de déploiement est donc là-aussi du code et plus précisément un morceau de code, comme une fonction, qui réagit à un événement (trigger sur le dépôt d’un fichier ou un appel http).
Ce modèle est intéressant dans le sens où une application peut être découpée en fonctionnalités, chaque fonctionnalité pouvant être mise à jour indépendamment. Très pratique pour faire de la “glue” entre différents services d’un Cloud Provider.
Pour plus d’informations sur le monde du Serverless, nous vous invitons à regarder cette vidéo 👇
☁️ SaaS — Software as a Service
Le SaaS reste toujours d’actualité avec la multiplication des devices.
Le principe est que le logiciel n’est plus “installé” : il est consommé au travers d’une interface (souvent web).
Les données manipulées sont stockées sur les serveurs de l’éditeur et c’est dans le monde SaaS que j’englobe tout le monde “No Code / Low Code”.
Pour illustrer cela avec un exemple bien connu, des développeurs, nous pouvons citer GitHub, Jira, Miro ou Workspace. Il suffit de payer l’abonnement et nous avons accès à leur service.
⭐️ Conclusion
Il est intéressant de comprendre que ces concepts ont été imaginés et apportés par les Cloud Providers de 2006 à aujourd’hui. Là où Google a commencé avec PaaS, AWS a proposé du IaaS. Et dès qu’une brique manque à l’appel, ces géants du web complètent leurs offres avec de nouveaux produits pour rattraper la concurrence. On le voit encore dernièrement avec l’arrivée de nouveaux produits GenAI.
Pour conclure, nous vous invitons à bien étudier le monde du Serverless pour être plus productif et éviter une période d’apprentissage trop longue (apprendre Kubernetes notamment). Pour chaque nouveau produit ou service, essayez de challenger le modèle de déploiement utilisé notamment avec de nouveaux produits qui associe le meilleur des mondes : la conteneurisation et le monde du Serverless :
Dans une démarche FinOps, il est important d’avoir en tête que chaque modèle de déploiement a son propre modèle de pricing. Ainsi, dans le monde Infrastructure “IaaS & CaaS” nous sommes souvent dans un modèle “Pay for what you allocate” alors que dans le monde Serverless “PaaS & FaaS” nous sommes dans un modèle “Pay for what you use”.
👉 Et vous, quel modèle de services Cloud utilisez-vous le plus ?
Pour aller plus loin, nous vous partageons 2️⃣ liens intéressants :
- Des ressources intéressantes partagées par le working group “Serverless” de la CNCF :
https://github.com/cncf/wg-serverless - Un bon site pour comparer les offres des Cloud Providers et vérifier qu’ils ont bien une gamme complète de produits : https://comparecloud.in/
