La différence entre le cloud et le sur site — hébergement mutualisé et périmètre de responsabilité

Cet article traite des trois formules possibles pour faire tourner une application : le sur site (on-premises), l'hébergement mutualisé et le cloud.

La différence tient à un seul point : qui possède le matériel serveur, et qui décide de ce qu'il y a dedans.

La place des principaux fournisseurs de cloud — AWS, Google Cloud et Azure — est traitée à la fin.

Le sur site est la seule formule où tu possèdes le matériel.

Les trois formules diffèrent par le propriétaire du matériel serveur et par qui décide de la configuration

Les trois diffèrent sur deux points : l'endroit où se trouve le matériel serveur, et qui décide de la configuration, c'est-à-dire l'OS (Operating System : le logiciel de base qui, entre le matériel et les programmes, gère les fichiers, le réseau et l'écran) et l'environnement d'exécution.

Le bâtiment du fournisseur où se trouve le matériel est un centre de données (data center : un bâtiment dédié qui héberge et fait tourner un grand nombre de serveurs),

et la partition qui, à l'intérieur d'une de ces machines, fonctionne comme un serveur indépendant est un serveur virtuel (virtual server, appelé aussi « instance » dans les guides).

Pouvoir choisir soi-même la configuration, c'est ce qui sépare l'hébergement mutualisé du cloud.

Tu ne peux agir que sur ta propre partition : ni la partition voisine ni le serveur physique lui-même ne te sont visibles.

Une seule inscription te permet de démarrer autant de serveurs que tu veux et de les arrêter une fois terminé.

Le prix dépend lui aussi de la quantité utilisée et de la durée.

Les livres d'introduction appellent aussi cette formule, ouverte à tous, le cloud public (public cloud).

La différence, c'est le propriétaire du matériel et celui qui décide du contenu

Les trois ne diffèrent que par la personne à qui appartient le matériel serveur et celle qui décide de ce qu'il y a dedans.

Le sur site, c'est quand le matériel et son contenu sont les tiens ; l'hébergement mutualisé, quand tu laisses les deux au fournisseur ; le cloud, quand le matériel appartient au fournisseur et que tu choisis la configuration.

Le périmètre de responsabilité — quelles couches le fournisseur gère, et où commence la tienne

Au moment de choisir, ce que tu regardes, c'est qui répare en cas de panne.

Un serveur est fait de cinq couches : le bâtiment avec son électricité et ses lignes réseau, le matériel, l'OS, l'environnement d'exécution, et l'application avec ses données.

La répartition de la gestion de chaque couche entre les deux parties, c'est le périmètre de responsabilité (les fournisseurs de cloud parlent de modèle de responsabilité partagée).

Avec le sur site, les cinq couches sont à ta charge ; avec l'hébergement mutualisé, seule celle du haut l'est.

Sur un serveur virtuel cloud, la frontière passe entre le matériel et l'OS.

Commander des pièces et les remplacer quand le matériel tombe en panne n'est à ta charge que dans le cas du sur site.

En hébergement mutualisé et dans le cloud, c'est le fournisseur qui remplace, et dans le cloud il suffit de redémarrer sur un autre matériel.

Vérifier que l'application et ses données fonctionnent comme avant reste toutefois à ta charge dans toutes les formules.

Le fournisseur ne fournit que jusqu'au matériel ; une fois l'OS choisi et démarré, la suite est à ta charge.

Le fournisseur ne corrige pas les bugs de ton application et ne restaure pas les données perdues.

Sous la frontière le fournisseur, au-dessus toi

Un serveur est fait de cinq couches : le fournisseur gère celles du bas, toi celles du haut.

Avec le sur site tout est à toi, avec l'hébergement mutualisé seule la couche du haut l'est, et sur un serveur virtuel cloud tout ce qui est au-dessus du matériel est à toi : le fournisseur ne répare que ce qui se trouve sous la frontière.

Dans le cloud, tu choisis où va chaque composant de l'application

Le cloud ne contient pas que des serveurs virtuels.

Quand tu choisis un service managé (managed service : un service dont le fournisseur assure l'installation, la mise à jour et le dépannage de l'OS et de l'environnement d'exécution, et où tu te contentes de configurer et d'utiliser), la frontière remonte.

Chaque composant va à un endroit différent, donc la frontière change elle aussi pour chacun.

Avec le stockage de fichiers et la base de données managée, la gestion de l'OS et de l'environnement d'exécution passe du côté du fournisseur.

Avec une base de données managée, tout ce que tu fais, c'est concevoir les tables et y écrire et lire les données.

Pour le backend, il existe aussi un emplacement qui ne fait tourner le traitement qu'à l'arrivée d'une requête.

Tout ce qui se trouve dans le cadre est du matériel du fournisseur : tu n'en possèdes aucun.

Malgré cela, l'OS et l'environnement d'exécution à l'intérieur du serveur virtuel, c'est toi qui les installes et les mets à jour.

Choisir où va un composant déplace la frontière du même coup

Plus tu laisses de choses au fournisseur en choisissant l'emplacement d'un composant, moins il te reste de travail.

Avec une base de données managée, tout ce que tu fais, c'est concevoir les tables et y écrire et lire les données, alors que pour le backend posé sur un serveur virtuel, tout ce qui est au-dessus de l'OS reste à ta charge.

AWS, Google Cloud et Azure — les catégories communes et les domaines forts de chacun

AWS, Google Cloud et Microsoft Azure sont les noms des clouds exploités par Amazon, Google et Microsoft.

Chacun est le nom que donne une entreprise à son cloud, et chacun contient un grand nombre de services.

L'unité géographique qui regroupe des centres de données est une région (region).

Choisir une région proche des personnes qui utilisent l'application réduit le temps d'aller-retour entre la requête et la réponse.

La catégorie de la colonne de gauche te dit à quoi sert un nom, même un nom que tu vois pour la première fois.

Ce que les trois entreprises ont en commun s'arrête à ces catégories.

Même quand les mêmes catégories sont couvertes, chaque fournisseur a développé plus fortement des domaines différents.

Tu n'es pas obligé de t'en tenir à une seule entreprise.

Utiliser plusieurs fournisseurs, chacun pour un usage différent, c'est le multi-cloud (multi-cloud : le fait d'utiliser plusieurs fournisseurs de cloud selon l'usage), et tu peux choisir pour chaque composant le fournisseur qui est fort dans ce domaine.

Les consoles et le vocabulaire diffèrent toutefois d'un fournisseur à l'autre : il y a donc plus à apprendre et plus à gérer.

Tant que l'application est petite, garde tout chez un seul fournisseur et envisage la répartition quand le besoin apparaît.

Catégories communes, domaines forts différents

AWS, Google Cloud et Azure sont respectivement les noms des clouds d'Amazon, de Google et de Microsoft, et les trois disposent des mêmes catégories de services : serveurs virtuels, bases de données managées et stockage de fichiers.

Comme les catégories sont communes, dès que tu en connais un, tu peux lire les autres en ramenant leurs noms aux catégories ; mais les domaines forts diffèrent selon le fournisseur, et il existe aussi le multi-cloud, qui consiste à répartir les usages entre plusieurs d'entre eux.