Une petite équipe doit pouvoir exploiter son infrastructure
Évaluez aussi qui gère les mises à jour, les incidents et la restauration. Un petit portail illustre les cas où davantage d’orchestration peut aider.
Le choix d’infrastructure d’une petite équipe devrait commencer par l’exploitation : qui peut remettre l’application en service après une mise à jour ratée, et que se passe-t-il si un serveur tombe en panne ? Une plateforme supplémentaire se justifie lorsqu’elle rend ces tâches plus maîtrisables dans vos conditions réelles.
Un portail à la structure limitée
Une équipe fictive de trois développeurs gère un portail client, une base de données et un traitement en arrière-plan qui transfère les commandes. Dans cet exemple, la charge est prévisible. La répartition automatique sur de nombreuses machines n’est pas encore une exigence. Des objectifs de reprise sont convenus pour les pannes ; l’équipe doit encore démontrer qu’elle peut les respecter.
Les options comparées sont une exploitation documentée de conteneurs sur un serveur et un cluster Kubernetes exploité par l’équipe elle-même. Cette évaluation porte sur cet exemple, sans établir de classement universel.
Question d’exploitation | Un serveur avec des conteneurs | Un cluster autogéré |
|---|---|---|
Que faut-il mettre à jour ? | Système d’exploitation, moteur de conteneurs et applications | En plus, les composants du cluster et leur configuration |
Que se passe-t-il si une machine tombe en panne ? | Le portail s’arrête ; remplacement et restauration sont nécessaires | La répartition peut aider si suffisamment de nœuds indépendants et une configuration adaptée sont disponibles |
Comment récupérer les données ? | Sauvegarde testée et restauration documentée | Un plan distinct pour les données applicatives et leur restauration reste nécessaire |
La solution la plus simple pourrait convenir si la procédure de reprise démontrée respecte les objectifs d’exploitation. Un serveur unique n’assure pas la haute disponibilité. Si cette interruption est inacceptable pour l’activité, cette option est écartée sous cette forme.
L’automatisation déplace les tâches
Kubernetes peut redémarrer des conteneurs défaillants et répartir les applications sur les nœuds disponibles. Un processus de nouveau actif ne prouve toutefois pas que les commandes et leurs pièces jointes sont complètes. La restauration des données et la vérification des fonctions métier restent à organiser.
Un service managé exige aussi un partage clair des responsabilités : le prestataire prend-il en charge uniquement le plan de contrôle, également les nœuds ou d’autres tâches ? Les erreurs applicatives et la capacité à restaurer vos données ne disparaissent pas automatiquement.
Quand la décision change
Si l’entreprise dispose déjà d’une plateforme maintenue par une équipe d’exploitation responsable, y héberger le petit portail peut être pertinent. Pour les trois développeurs, un serveur supplémentaire pourrait alors nécessiter davantage de traitement particulier. Une charge très variable ou des exigences de disponibilité contraignantes peuvent aussi imposer une autre architecture.
Avant de choisir, demandez une démonstration en environnement de test d’une mise en production ratée et d’un scénario de restauration. Notez qui intervient et quelle fonction métier est vérifiée ensuite. Ces preuves expliquent mieux la pertinence d’une infrastructure que son nombre de composants.
Sources
À lire aussi
Tous les articles
Cloud & exploitation avec ASES
Hébergement, déploiement, maintenance et suivi