La question que tout le monde se pose, jusqu’où on peut aller?

Dans ce troisième volet, on va essayer d’analyser les capacités en terme de mise à l’échelle de nos 3 concurrents, pour cela nous allons essayer de répondre à ces différentes questions/situations:

  1. Je veux scaler verticalement (machines plus grosses)?
  2. Je veux scaler horizontalement (machines plus nombreuses)?
  3. J’étends mon influence sur d’autre continent, est-ce un problème?
  4. J’ai beaucoup de projets d’évolution, mon fournisseur peut-il être un partenaire?
  5. A quel point le montage et maintenance des différentes infrastructure sont simple à monter?

Amazon Web Service

Chez AWS, la question 1 et 2 ont une seule et même réponse, l’Autoscaling Group (ASG). Qu’il soit utilisé pour EKS, ECS ou encore EC2 il permet de créer des instances sur la base d’une AMI où l’on va paramétrer l’ASG pour ajouter ou surprimer 1 ou plusieurs instances en précisant le ou les tailles voulues en fonction des métriques que l’on souhaite (à noter que si la taille change il faudra recycler manuellement les anciennes). De plus, on a la possibilité d’utiliser des instances spot (jusqu’à 90% de réduction) et avec le système d’instance fleet vous avez la possibilité de définir le nombre de CPU et/ou de mémoire avec une limite de prix horaire (bid price) et ce système se chargera de trouver les instances qui vont bien au meilleur prix… Dingue non?… Je l’ai déjà utilisé sur de la production avec des clusters avec plus de 4000 cpu et 15To de mémoire (AWS EMR) et ça marche super bien 🙂

A noter aussi que les DBs sont scalables en terme de stockage de façon automatique et que aurora permet de scaler les read replicas de façon automatique (ajout et suppression) en fonction du CPU ou du nombre de connexions.

En ce qui concerne la question 3, avec AWS pas de problème, c’est le fournisseur qui dispose du plus de datacenter dans le monde. Petit point a considérer, AWS a vraiment beaucoup de produit et avant de choisir une région du monde, je vous invite à consulté la page de disponibilité des services ainsi que la page des tarifs des services que vous utilisez car cela peut avoir un impact direct sur votre business, les régions les plus « complètes » sont North Virginia (us-east-1) et Irlande (eu-west-1), à noter que c’est aussi les plus anciennes ce qui implique qu’il y a aussi une gestion de l’obsolescence qui s’installe, par exemple en us-east-1 il y a une AZ où il n’y a pas d’instance de génération 5, et il n’y en aura jamais.

Pour la quatrième question, j’ai envie de dire que si AWS n’a pas ce que tu cherches, ils vont le sortir bientôt, attend un peu ^^… En effet, AWS est très proactif et est très bon dans l’anticipation des besoins de ses clients… Sans compter que les services proposés vont quand même de l’instance de base (EC2) à la location d’antenne de réception satellitaire entièrement géré donc bon…

Enfin, AWS est connu pour permettre pour faire beaucoup de choses et pour faire partie des précurceurs… Malheureusement, le revers de la médaille est que cela vient souvent avec des erreurs, de conception ou d’utilisation, et malheureusement cela peut rendre la mise en place ou la maintenance complexe.

exemple: Il n’est possible d’attacher que 5 sécurity group par instance sinon il faut baisser le nombre global de règles par sécurity group. En effet, ces nombres sont en relation direct de par la conception du système. Si on utilise les sécurity group comme identifiant d’accès cela peut devenir problèmatique très rapidement, imaginons un serveur d’administration qui doit accéder aux bases de données PG, les MySQL, les ECS, le SSH et un autre service comme LDAP par exemple et voilà on a dépasser les limites du système… Ce n’est pas un gros problème, mais il faut le savoir avant de concevoir son système sinon ça devient compliquer à gérer et difficile à faire évoluer.

Google Cloud Platform

Chez AWS, la question 2 (comme avec AWS) ont une seule et même réponse, l’Instance Group (IG). De la même manière, on IG est utilisé pour GKE, le service K8s managé de K8s, ainsi que pour des VMs « simple ». Le système d’autoscaling est similaire à celui d’AWS à  ceci près que GCP à prévu un petit bouton pour recycler doucement les machines existante automatiquement. De plus, on a la possibilité d’utiliser des instances préemptibles (permet de bénéficier de grosse réduction), je l’ai utilisé pour un projet de serveur web à trafic variable et ça marche très bien, je n’ai jamais eu de moment où je n’ai pas été capable d’avoir d’instance.

A noter ici aussi que les DBs scale automatiquement le stockage et que certain service sont capable scaler en focntion de la charge théoriquement (j’insiste sur le théoriquement ^^) à l’infini comme app engine standard ou encore firestore

En ce qui concerne la question 3, avec GCP pas de problème non plus, c’est le troisième fournisseur Iaas dans le monde. Petit point intéressant du côté de GCP, la plupart de leur service et particulièrement réseau sont conçu pour travailler de façon global. Par exemple, lorsque je crée un load balancer en europe avec un IG en belgique et un DB en belgique aussi, je peux en créant un copie de l’IG aux états unis le relier au même load balancer sans changer quoique ce soit et si mon client est au états unis il sera router automatiquement vers les US et la DB lui sera accessible via le réseau interne de GCP… incroyable non?… Il y a quelques mois nous avons effectué la migration de Usites depuis us-east1 (South Carolina) vers eu-west1 (Belgique) et ça m’a pris à peine quelques heures et aucun downtime. Personnellement j’ai été bluffé.

Pour la quatrième question, j’ai envie de dire que GCP a un catalogue plutôt fournit, même si il manque un certain nombre de chose que l’on retrouverais chez AWS mais par contre on va retrouver des outils très simple et tourné vers les développeurs comme app engine, firestore ou encore Cloud Run (que nous utilisons chez Umoove).

Enfin, pour la question de la simplicité, GCP doit être l’un des plus simple que j’ai eu l’opportunité de torturer ^^… L’activation du CDN se fait en une case à cocher, le réseau et les règles de routage se mettent en place dynamiquement et fonctionne de façon globale nativement et ses services NoOps comme App Engine en font un choix intéressant pour les développeurs. De plus, GCP fonctionne avec des projets isolés les uns des autres et on peut aussi y créer une hierarchie à l’instar des systèmes de fichier ce qui rend la gestion des différents service et projet très simple car on peut tout gérer à partir de son compte.

Scaleway

Chez Scaleway, la scalabilité, c’est pas encore ça… Pour scaler verticalement et donc augmenter la taille de notre instance il faut sauvegarder l’actuel, créer une nouvelle instance à partir de cette image et une la nouvelle instance disponible detacher l’ip de l’ancienne et l’attacher à la nouvelle… voir la documentation. Bon, le process est pas déconnant en soit, il n’y a pas de downtime mais avec les technologie disponible chez ses concurrents, ça fait un peu trop manuel à mon goût… Imaginez que vous ayez 50 serveurs à upgrader et qu’on puisse pas les regroupé parce qu’il doivent être isolé… ça peut être long…

De la même manière, scaler horizontalement est un processus manuel, on ajoute une machine basé sur la même image ou à partir d’une sauvegarde faite du disque et on l’attache au même load balancer. Ca veut dire qu’on doit avoir une intervention humaine pour intervenir, ça veut dire aussi qu’il faut être bon sur le monitoring et sur ses projections. A noter que la solution K8s de Scaleway vient avec ses capacités d’autoscaling verticale et horizontal, c’est donc le seul service qui en bénéficie.

Pour la présence, Scaleway ne dispose que de 4 centre de donnée, et ils sont tous situé en Europe. Ils viennent d’ailleurs d’ouvrir leur deuxième centre de donnée à Paris l’ouverture vers plusieurs AZ.

Scaleway est tout jeune et son catalogue est assez mince mais on y retrouve le nécessaire à la conception d’infrastructure de base, des VMS, des DBs, du K8s et du stockage Objets… Cependant si je devais me projetter et rêver de service, il va falloir encore un bon moment avant que Scaleway puisse fournir assez de service pour être envisagé comme un partenaire solide pour la croissance d’une société tech.

Scaleway a une interface plutôt sympa et ergonomique cependant, ses fonctionnalités sont encore limité et beaucoup d’opération nécessite de faire des choses manuel et cela rend l’utilisation, l’administration et la maintenance plus compliqué.

Conclusion du round 3 – la scalabilité

Duel encore serré entre nos deux géants américain encore une fois, la scalabilité est très similaires chez les deux rivaux mais on va noter tout de même que si on est pas accompagné par des ops qui touchent bien sur AWS ça peut devenir compliqué… Du moins la conception et la maintenance de son infra est en mon sens plus simple sur GCP que sous AWS.

Quant a Scaleway on notera son effort avec un service K8s managé qui semble fournir la scalabilité nécessaire à une application pour tourner mais ce n’est pas encore suffisant pour concurrencer nos deux monstres du monde de la tech.

1 – GCP

GCP raffle la mise sur AWS d’une courte tête pour la simplicité de mise en place de système complexe et ses systèmes très devops qui sont tourné vers les applications.

2 – AWS

AWS permet de faire BEAUCOUP de chose et beaucoup plus que tous les autres mais malheureusement cela viens avec son lot de problème et bien qu’il ai toutes les fonctionnalité et même plus que les autres c’est au détriment de la simplicité.

3 – Scaleway

Encore dernier sus ce round, pas d’acharnement, il est tout de même comparé au numéro 1 (AWS) et numéro 3 (GCP) des fournisseurs de cloud. Mais si je veux créer une application et la faire scaler, et que je ne suis pas sur K8s (tout ne peut pas être conteneurisé facilement) je ne serais pas en mesure d’être accompagné par Scaleway. Pas aujourd’hui en tout cas, mais j’ai confiance 🙂

L’auteur

Charles-Alban, en quelques mots:

Je suis passionné de technologie et tout particulièrement d’architecture de système cloud et de base de données. De formation ops, j’ai fait évoluer ma carrière en qualité de DevOps pour ensuite devenir Data engineer.

J’aime tout particulièrement les start-up, j’aime créer les choses de zéro ou presque et les concevoir de manière scalable, sûre et performante. C’est pour cela que j’adore mon rôle de consultant qui me permet de travailler en collaboration avec des start-up différentes et les aider à se développer et leur apprendre comment tirer parti des ressources qu’offre le cloud aujourd’hui !