Comment choisir un fournisseur de cloud

Lorsque vous choisissez un fournisseur de cloud, vous pouvez examiner les fonctionnalités de reconnaissance de la marque, de sécurité et de stockage et d'autres éléments. Mais les fournisseurs de cloud dépendent des réseaux comme le reste d'entre nous, et ils ne sont pas tous créés ou configurés de la même manière.

En général, pour ceux qui envisagent le cloud, il est important de faire correspondre l'emplacement de vos utilisateurs finaux et l'emplacement du cloud qui les desservira. Vous devez également viser à établir en permanence les performances de référence lorsque vous démarrez pour la première fois avec un fournisseur de cloud, ce qui vous aidera par la suite en cas de problèmes de performances.

Étant donné que chacun des principaux fournisseurs de cloud a plusieurs points de présence, il est essentiel que vous preniez en compte l'impact sur le réseau du déplacement de vos données ou applications de vos bureaux vers le cloud. Pour illustrer cet impact, nous avons mis en place une comparaison rapide des trois principaux fournisseurs.

Test, test

Pour jeter un coup d'œil sous les couvertures des trois grands fournisseurs, nous avons fait quelques tests. Nous avons mis en place un système de démonstration SaaS CRM dans le point de présence nord-ouest (les emplacements exacts varient selon le fournisseur) pour les trois plus grands fournisseurs de cloud public :AWS, Azure et Google Cloud. Ensuite, nous avons attendu les résultats, et ils ont certainement été intéressants.

Test depuis Los Angeles

Ce graphique ci-dessous montre le trafic réseau de Los Angeles à l'emplacement le plus proche des principaux fournisseurs de la région du nord-ouest. Avec notre CRM basé au nord-ouest, il n'y a vraiment pas de gagnant distinct. Google et AWS sont situés dans l'Oregon voisin, tandis qu'Azure est à une courte distance d'eux dans le nord de la Californie. Ici, AWS peut juste gagner, mais tous montrent une variabilité extrême au cours d'un mois (plus bas est meilleur ici). La différence de distance physique ne se manifeste pas pleinement sous forme de temps réseau supplémentaire pour les requêtes Web (à titre de référence, cela prend 40 ms pour le trafic international). Ce qui se passe très probablement, ce sont des changements de routage.

Los Angeles → Région du Nord-Ouest  | AWS | Azur  | Google

Test depuis Atlanta

L'exemple suivant montre les routes réseau des trois fournisseurs de notre moniteur basé à Atlanta aux points de présence ou aux zones de disponibilité du nord-ouest. AWS est le fournisseur de cloud le plus lent, bien que tous les trois connaissent une variabilité tout au long de la fenêtre d'un mois. Avec une séparation physique beaucoup plus longue entre l'utilisateur synthétique et le serveur, nous pouvons ignorer les petites variations de vitesse du réseau. Cependant, force est de constater qu'AWS souffre en moyenne de 1,5 seconde de latence supplémentaire. La cause peut varier, mais avec jusqu'à deux secondes de temps supplémentaire pour les requêtes Web, cela pourrait entraîner des niveaux plus élevés de frustration pour les utilisateurs. Nous pouvons également voir une certaine cohérence dans les pics observés, indiquant que le trafic peut partager des itinéraires et des problèmes de congestion quotidiens.

Il est important de se rappeler que notre déploiement basé à Seattle n'est probablement pas le choix idéal ni courant pour une entreprise basée à Atlanta. Mais avec autant de startups issues de la Silicon Valley, il y a de fortes chances que de nombreuses applications SaaS que vous utilisez tous les jours fassent cet aller-retour longue distance.

Atlanta → Région du Nord-Ouest  | AWS | Azur  | Google

Test depuis New York

Notre dernier exemple ci-dessous montre les performances du réseau le long du chemin du réseau de la zone de New York à notre CRM basé au nord-ouest. AWS affiche toujours les temps de réponse les plus lents des trois fournisseurs. Google et Azure sont systématiquement plus rapides, à l'exception d'un problème de congestion observé fin janvier. Parce que nous pouvons supposer qu'au fil du temps, Internet acheminera une grande partie de ce trafic de la même manière à travers le pays, il y a une bonne indication que le routage derrière le pare-feu d'AWS pourrait être la cause de la latence supplémentaire.

New York → Région du Nord-Ouest  | AWS | Azur  | Google

Ce que nos tests cloud ont trouvé

Nous n'avons pas une grande taille d'échantillon et notre déploiement de test n'est pas adapté à la complexité de la plupart des applications modernes, mais nos résultats nous ont rappelé à quel point il est important d'effectuer une recherche de localisation lorsque vous planifiez vos déploiements cloud. Sortez la carte pour voir où vos services et applications seront situés lorsqu'ils seront dans le cloud. Ensuite, associez-les à l'endroit où se trouvent les utilisateurs de ces applications et services.

Il existe un certain nombre de raisons qui pourraient contribuer à ce qui ressemble à un échec de la part d'AWS à fournir des réponses rapides, telles que des accords de peering au milieu du pays ou un routage supplémentaire derrière leur pare-feu. Ce qui est clair, c'est que les performances diffèrent selon l'endroit où se trouvent vos utilisateurs finaux. Être conscient de ce fait conduira à de meilleures décisions en matière de performance.

Tester les fournisseurs de cloud n'est pas notre seul objectif, mais vous pouvez obtenir la visibilité que nous avons (et dont vous avez besoin) avec les outils d'AppNeta pour n'importe laquelle de vos applications cloud. Ce type d'informations sur le réseau peut sauver la journée lorsque les utilisateurs se plaignent de ralentissements ou de pannes et que vous devez identifier la cause première de la dégradation des performances.