Comparer les principaux fournisseurs cloud : AWS, Azure, Google Cloud et les autres

Partez des tâches que vous devez exécuter. Comparez le travail d’exploitation, le coût et les possibilités de passer à un autre fournisseur avant de choisir où les héberger.

Supposons qu’une petite entreprise souhaite disposer d’un site présentant des photographies de produits et une liste de commandes clients. Il lui faut un endroit où exécuter l’application, un autre où conserver les fichiers image et une base de données permettant de consulter et de mettre à jour les commandes. Partez de ces trois fonctions. Elles permettent de comparer les fournisseurs cloud bien plus facilement qu’une liste de parts de marché.

Des noms différents pour des fonctions reconnaissables

Une machine virtuelle est un ordinateur que vous configurez et exploitez à distance. Le stockage objet conserve des fichiers, comme des images. Une base de données relationnelle gérée stocke des enregistrements structurés, tandis que le fournisseur prend en charge une partie du travail d’exploitation. Le tableau suivant présente des exemples tirés du catalogue de chaque fournisseur ; il ne s’agit ni de produits identiques ni d’un classement.

Les noms et les catégories de produits proviennent du comparatif des services de différents fournisseurs publié par Google, de la présentation de RDS par Alibaba et du catalogue de produits de Tencent. Les moteurs de bases de données, les configurations disponibles et les fonctionnalités prises en charge diffèrent ; un service MySQL ne peut pas remplacer sans adaptation la base d’une application utilisant PostgreSQL.

Comparez le travail que votre équipe aurait réellement à faire

Pour le site de notre exemple, une possibilité consiste à louer des machines virtuelles et à installer vous-même l’application et la base de données. Une autre consiste à utiliser une base de données gérée et un service d’hébergement d’applications. Cette seconde option peut supprimer certaines tâches d’exploitation, mais vous devez toujours comprendre la configuration, les accès, la reprise et les fonctionnalités dont dépend l’application.

Partez du système dont vous disposez déjà. Quel moteur de base de données utilise-t-il ? Comment est-il déployé ? Quels outils l’équipe peut-elle maintenir ? Une configuration familière peut réduire le travail ; un service moins connu peut néanmoins valoir la peine s’il résout un problème concret. Formulez clairement ce bénéfice.

Déterminez ensuite les lieux où l’application doit fonctionner. Testez les temps de réponse depuis les endroits où les utilisateurs se connectent réellement et vérifiez que les services et fonctionnalités précis dont vous avez besoin sont disponibles ensemble dans la région choisie. Le nombre de régions dont un fournisseur dispose dans le monde ne répond à aucune de ces deux questions.

Chiffrez un mois complet d’utilisation

Appliquez les mêmes hypothèses à chaque fournisseur envisagé : visites attendues, heures de calcul, fichiers stockés, taille de la base de données, sauvegardes et données envoyées aux utilisateurs. Incluez l’assistance si l’équipe en a besoin. Une machine virtuelle bon marché ne représente qu’une ligne de cette estimation.

Le guide d’AWS Pricing Calculator, par exemple, explique comment établir une estimation à partir des régions, des services et des hypothèses d’utilisation, en permettant d’ajouter l’assistance. Une estimation dépend de ces paramètres ; elle ne constitue pas une promesse sur le montant de votre facture. Conservez les hypothèses avec le chiffre pour pouvoir comparer sur une même base.

Pour un site riche en photographies, l’envoi d’images aux visiteurs peut peser davantage que pour un petit formulaire interne. Pour un système qui doit pouvoir être rétabli rapidement, la capacité supplémentaire de la base de données et les dispositifs de reprise comptent également. Testez votre propre profil d’utilisation au lieu de chercher un fournisseur qui serait le moins cher dans tous les cas.

Essayez le chemin du retour avant de vous engager

Faites fonctionner une version réduite de la même application chez les fournisseurs de votre sélection. Importez des images d’exemple, créez des commandes de test, exportez les enregistrements et restaurez-les dans un environnement de test distinct. Vérifiez comment vous remplaceriez les services propres à un fournisseur. Copier les fichiers ne constitue qu’une partie du déplacement d’une application.

Consignez trois éléments : le travail nécessaire à la mise en service, le coût selon des hypothèses d’utilisation identiques et ce qu’exige une migration ou une reprise. Un essai concluant donne à une petite équipe une meilleure base de décision que la place d’une marque dans un classement.

Gardez votre objectif au cœur du choix

Vous n’avez pas besoin de répartir votre système entre plusieurs clouds simplement pour démontrer votre indépendance. Un service unique, bien maîtrisé, peut être le point de départ le plus pratique. L’essentiel est de savoir quelles responsabilités vous avez confiées à autrui et si une autre organisation reste possible.

L’article sur les modèles de services cloud explique cette répartition du travail. Celui consacré à l’informatique en périphérie et au cloud examine ensuite où exécuter les différentes tâches. Répartir les machines entre plusieurs lieux et répartir le pouvoir de décision sont deux questions distinctes ; un choix d’infrastructure pertinent permet de mieux les comprendre toutes les deux.