Serveurs, systèmes d’exploitation, machines virtuelles, conteneurs et services cloud

Un serveur n’est qu’un ordinateur qui sert

Un serveur est un ordinateur dont le travail consiste à attendre des requêtes et à y répondre : pages web, appels d’API, requêtes de base de données, fichiers. Le mot désigne un rôle, pas un type particulier de machine. Un ordinateur portable qui fait tourner une petite application web est un serveur tant qu’il répond à des requêtes ; une machine montée en baie dans un centre de données est un serveur parce qu’elle ne fait jamais rien d’autre. Le même mot désigne aussi le programme qui sert (un « serveur web » comme nginx) : le contexte compte donc.

Le matériel d’un serveur comporte les mêmes éléments que n’importe quel ordinateur (voir ce qu’est un logiciel) : processeurs, mémoire, stockage et cartes réseau. La différence tient aux priorités. Les serveurs ont généralement de nombreux cœurs de processeur, beaucoup de mémoire, des alimentations et des disques redondants pour qu’une pièce défaillante n’arrête pas la machine, une administration à distance pour que personne n’ait besoin d’être dans la salle, et ni écran ni clavier. Ils sont conçus pour fonctionner pendant des années sans être éteints.

La plupart des serveurs d’internet fonctionnent sous Linux ou un autre système d’exploitation de type Unix ; Windows Server est courant dans les organisations qui s’appuient sur les produits Microsoft. Un système d’exploitation de serveur remplit les mêmes tâches que celui de votre ordinateur portable (exécuter des processus, gérer la mémoire et les fichiers, communiquer avec le réseau), mais il est généralement administré en ligne de commande, par une connexion à distance, et configuré pour pouvoir être reconstruit automatiquement plutôt qu’à la main.

Les centres de données : là où vivent les serveurs

Les serveurs sont installés dans un centre de données : un bâtiment conçu autour de leurs besoins. Des milliers de machines y sont rangées dans des baies, refroidies par air ou par liquide, car elles transforment presque toute leur électricité en chaleur. Le courant arrive par plusieurs alimentations, secourues par des batteries pendant les premières secondes d’une coupure, puis par des groupes électrogènes diesel. Les connexions réseau proviennent de plusieurs opérateurs. Les portes exigent un badge, et souvent une empreinte digitale.

Une organisation peut exploiter son propre centre de données ou louer de l’espace en baie dans celui de quelqu’un d’autre (on parle de colocation) ; avant 2006 environ, c’était presque le seul choix possible. Exploiter soi-même ses serveurs (sur site) signifie acheter des machines des mois avant d’en avoir besoin, deviner combien il en faudra, les payer qu’elles soient occupées ou inactives, et employer des personnes pour remplacer les disques en panne en pleine nuit. Ce coût et ce manque de souplesse sont le problème que le cloud a voulu résoudre.

Les machines virtuelles : plusieurs ordinateurs dans un seul

Un serveur typique reste la plupart du temps inactif s’il ne fait tourner qu’une seule application. Une machine virtuelle (VM) permet à une machine physique de se faire passer pour plusieurs. Chaque VM se croit un ordinateur complet, avec ses propres processeurs, sa mémoire, son disque et sa carte réseau, et exécute son propre système d’exploitation, appelé invité. Une couche logicielle appelée hyperviseur répartit le matériel réel entre les VM et les tient séparées, de sorte qu’un plantage ou une attaque dans l’une n’atteint pas les autres. Certains hyperviseurs s’exécutent directement sur le matériel (VMware ESXi, Microsoft Hyper-V, KVM, qui fait partie de Linux) ; d’autres s’exécutent comme une application sur un système d’exploitation ordinaire (VirtualBox).

La virtualisation a changé l’économie des serveurs. Une seule machine peut accueillir de nombreuses VM appartenant à différentes équipes ou à différents clients. Une VM est un ensemble de fichiers : on peut donc la copier, la sauvegarder, la déplacer vers une autre machine et la créer en quelques minutes, au lieu de la commander et d’attendre sa livraison. Notez qu’il s’agit d’un autre sens de « machine virtuelle » que les VM de langage, comme la Java Virtual Machine évoquée dans ce qu’est un logiciel : les VM de langage exécutent des programmes, celles dont nous parlons ici imitent des ordinateurs entiers.

Les conteneurs : livrer l’application avec tout ce dont elle a besoin

Tout développeur a déjà entendu « ça marche sur ma machine ». Le programme dépend d’une version précise du langage, de bibliothèques précises et de réglages précis, et le serveur en a de légèrement différents. Un conteneur résout ce problème en emballant une application avec tout ce dont elle a besoin pour s’exécuter (son environnement d’exécution, ses bibliothèques, sa configuration) dans une unité standard qui fonctionne de la même façon sur un ordinateur portable, sur un serveur de test ou dans le cloud. Le nom vient des conteneurs maritimes : des boîtes standard que n’importe quelle grue, n’importe quel navire ou camion peut manipuler sans savoir ce qu’elles contiennent.

Le paquet est une image de conteneur : un fichier en lecture seule et versionné, construit à partir d’une courte recette (avec Docker, un Dockerfile). Une copie en cours d’exécution d’une image est un conteneur. Docker, sorti en 2013, a rendu cela praticable pour les développeurs au quotidien, et son format d’image est aujourd’hui un standard ouvert maintenu par l’Open Container Initiative, si bien que d’autres outils peuvent construire et exécuter les mêmes images.

La différence essentielle avec une VM tient à ce qui est partagé. Une VM imite du matériel et exécute un système d’exploitation invité complet. Un conteneur est un processus isolé : il partage avec d’autres conteneurs le noyau du système d’exploitation de l’hôte (le cœur du système d’exploitation, qui contrôle le matériel, la mémoire et les processus), et les fonctions d’isolation du noyau lui donnent sa propre vue des fichiers, des processus et du réseau. Les conteneurs démarrent donc en quelques secondes ou moins et occupent des mégaoctets plutôt que des gigaoctets : des dizaines peuvent tourner là où quelques VM tiendraient. La contrepartie est une isolation plus faible, car tous les conteneurs dépendent d’un seul noyau partagé ; c’est pourquoi les fournisseurs de cloud font couramment tourner les conteneurs de leurs clients à l’intérieur de VM, combinant ainsi les deux.

# Start from an image that already has Python installed
FROM python:3.12-slim
WORKDIR /app
# Bake the libraries into the image
COPY requirements.txt .
RUN pip install -r requirements.txt
# Add the application code
COPY . .
EXPOSE 8000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Faire tourner un conteneur est facile. En faire tourner des centaines sur des dizaines de machines, redémarrer ceux qui plantent, ajouter des copies quand le trafic augmente et déployer de nouvelles versions sans interruption de service ne l’est pas. Ce travail revient à un orchestrateur, dont Kubernetes est le plus connu ; il est traité dans conteneurs et orchestration.

Le cloud : louer de la puissance de calcul à la minute

Le cloud computing (informatique en nuage) consiste à louer des ressources informatiques via internet, à la demande, auprès d’un fournisseur qui exploite d’immenses centres de données : Amazon Web Services (AWS), Microsoft Azure et Google Cloud sont les plus grands, parmi beaucoup d’autres. Le National Institute of Standards and Technology (NIST) américain a publié en 2011 la définition que la plupart des gens citent, la Special Publication 800-145. Elle énumère cinq caractéristiques essentielles : le libre-service à la demande (vous créez vous-même les ressources, via un site web ou une API, sans téléphoner à personne), un large accès par le réseau, la mutualisation des ressources (de nombreux clients partagent le matériel du fournisseur), l’élasticité rapide (la capacité augmente et diminue vite) et le service mesuré (vous payez ce que vous utilisez).

L’analogie, c’est l’électricité. Autrefois, les usines faisaient tourner leurs propres générateurs ; aujourd’hui, elles se branchent sur le réseau et paient au kilowattheure. Avec le cloud, une start-up peut louer cent serveurs pour un après-midi afin de tester un lancement, et cesser de payer dès qu’elle les rend. C’est le paiement à l’usage (pay-as-you-go). Il transforme un gros achat initial en coût de fonctionnement, et il récompense les systèmes capables d’éteindre de la capacité quand elle n’est pas nécessaire. Il crée aussi un nouveau risque : des coûts qui grimpent sans bruit, car rien n’empêche quiconque de créer des ressources puis de les oublier.

IaaS, PaaS, SaaS et serverless : quelle part gérez-vous ?

Les services cloud se distinguent surtout par la part de la pile que le fournisseur gère pour vous. Le NIST a défini trois modèles de service ; un quatrième, le serverless, s’est répandu après le lancement du service Lambda d’AWS en 2014. Une façon courante de les retenir passe par la pizza : vous pouvez la faire maison, en acheter une toute prête à cuire, vous en faire livrer une ou aller au restaurant. Chaque étape confie davantage de travail à quelqu’un d’autre, et vous retire une partie de vos choix.

« Serverless » ne veut pas dire qu’il n’y a pas de serveurs ; cela veut dire que vous ne les voyez et ne les gérez jamais. Vous envoyez une fonction, vous indiquez quels événements la déclenchent (une requête HTTP, l’arrivée d’un fichier, un message dans une file) et le fournisseur exécute autant de copies que nécessaire, en facturant à l’exécution et à la milliseconde. C’est bon marché pour un trafic faible ou en pics, et cela ne demande presque aucun travail d’exploitation. Ses coûts apparaissent ailleurs : le premier appel après une période calme peut être lent, le temps que le fournisseur démarre la fonction (un démarrage à froid, ou cold start), la durée d’exécution d’une fonction est limitée, et les coûts peuvent dépasser ceux d’un simple serveur pour un trafic important et régulier. Le chapitre 6 traite en profondeur des architectures serverless.

Entre ces modèles se trouvent les services managés : bases de données, files de messages, caches, stockage objet, moteurs de recherche et bien d’autres, que le fournisseur installe, exploite, corrige, sauvegarde et met à l’échelle. Utiliser une base de données managée au lieu d’en installer une sur une VM transfère une grande partie du travail d’exploitation au fournisseur. Le compromis, abordé dans FinOps et dépendance au fournisseur, est que plus un système utilise de services propres à un fournisseur, plus il est difficile à déplacer.

Régions, zones de disponibilité et réseaux de diffusion de contenu

Les fournisseurs de cloud regroupent leurs centres de données par zone géographique. Une région est une zone géographique (comme l’Irlande, Francfort ou la Virginie) dotée de son propre ensemble distinct de centres de données, isolé des autres régions. Chaque région est divisée en plusieurs zones de disponibilité : des groupes physiquement séparés d’un ou plusieurs centres de données, chacun avec son alimentation, son refroidissement et son réseau indépendants, généralement distants de plusieurs kilomètres mais assez proches pour être reliés par des connexions rapides. Un incendie, une inondation ou une panne de courant ne devrait mettre hors service qu’une zone au plus.

Cela offre aux architectes tout un éventail de protections. Faire tourner des copies d’une application dans deux ou trois zones d’une même région permet de survivre à la perte d’un centre de données pour un faible surcoût de latence ; les faire tourner dans deux régions permet de survivre à la perte d’une région entière, mais rend bien plus difficile la synchronisation des données. Les régions comptent aussi pour le droit et pour la latence : les règles de protection des données peuvent exiger que les données personnelles restent dans une juridiction donnée, et les utilisateurs sont servis plus vite depuis une région proche d’eux, car aucun réseau ne peut battre la vitesse de la lumière (voir comment les ordinateurs communiquent).

Un réseau de diffusion de contenu (CDN) va plus loin pour le contenu qui ne change pas d’un utilisateur à l’autre, comme les images, les feuilles de style, les scripts et la vidéo. Il en conserve des copies sur des serveurs situés dans des centaines d’endroits, appelés emplacements en périphérie (edge locations), de sorte qu’un utilisateur à Nairobi récupère les photos de produits de la boutique depuis une ville proche plutôt que depuis un centre de données en Europe. La page se charge plus vite, et les serveurs de la boutique traitent bien moins de requêtes. De nombreux CDN absorbent aussi le trafic d’attaque et peuvent exécuter de petits morceaux de code en périphérie.

Scalabilité verticale et scalabilité horizontale

Quand un système doit traiter davantage de travail, il existe deux réponses de base. La scalabilité verticale (scaling up) consiste à prendre une machine plus grosse : plus de cœurs, plus de mémoire. Elle n’exige aucune modification du logiciel, ce qui est son grand avantage, mais on ne peut pas acheter plus gros que la plus grosse machine du marché, le prix grimpe de façon disproportionnée vers le haut de gamme, et une seule machine reste un point unique de défaillance. La scalabilité horizontale (scaling out) consiste à répartir le travail sur davantage de machines, généralement derrière un équilibreur de charge (load balancer) qui distribue les requêtes entre elles et cesse d’en envoyer à celles qui tombent en panne. Elle permet d’aller bien plus loin et de survivre aux pannes de machines, mais seulement si le logiciel est conçu pour cela : par exemple, un serveur ne doit pas conserver la session d’un utilisateur uniquement dans sa propre mémoire, ni enregistrer les fichiers envoyés uniquement sur son propre disque, si la requête suivante de cet utilisateur risque d’aboutir sur un autre serveur.

Le cloud rend la scalabilité horizontale attrayante, car ajouter une machine se résume à un appel d’API, et l’autoscaling peut ajouter et retirer des copies automatiquement selon la charge. Les bases de données sont généralement la partie la plus difficile à faire passer à l’échelle horizontalement, c’est pourquoi le chapitre 7 consacre une section à la réplication et au partitionnement.

Pourquoi c’est important pour l’architecture

L’endroit où s’exécute un logiciel est désormais une décision d’architecture, et non un détail réglé après coup. Le choix entre VM, conteneurs, plateformes et fonctions façonne le coût, la rapidité avec laquelle l’équipe peut livrer, la manière dont le système passe à l’échelle et ce qui se passe quand un centre de données tombe en panne. Les régions et les zones transforment les objectifs de disponibilité en plans de déploiement concrets ; les services managés échangent du travail d’exploitation contre une dépendance à un fournisseur. Le chapitre 9 développe les stratégies de scalabilité, et le chapitre 10 traite des modèles de service et de déploiement cloud, des conteneurs et de l’infrastructure de manière approfondie, au niveau professionnel.