• Home
  • About
    • Ahmed DAMMAK photo

      Ahmed DAMMAK

      Full Stack Developer

    • Learn More
    • Twitter
    • LinkedIn
    • Github
  • All Posts
  • All Tags
  • Projects

AWS vs GCP vs Azure

29 Sep 2021

Reading time ~6 minutes

AWS vs GCP vs Azure

Talk de Laurent Grangeau @Laurentgrangeau, Tony Jarriault @jarriaulttony et Olivier Dupré @olivierdupretec.

Description

Tout le monde connaît ces 3 clouders publics majeurs. Mais… qu’ont-ils réellement en commun ? Quelles sont leurs différences profondes ? Le choix pour l’un des 3 est-il une question de coeur, de compétences disponibles ou capacités techniques ? Faire le tour complet de chacune de ces plateformes prend déjà plus d’une journée. Alors faire le tour des 3 de manière exhaustive lors d’un talk est utopique. Nous irons donc droit au but et nous focaliserons sur les services majeurs, les plus utilisés et ceux pour lesquels la comparaison est la plus intéressante.

Notes

Les Clouds représentent 61% des parts de marchés. L’idée du talk est donner un overview global des différence entre les clouds.

Il 4 types de service :

  • IAAS : Couche infra sur laquelle on déploie
  • CAAS : Gestions des applications en tant que micro-service conteneurs
  • PAAS : Permet de gérer l’auto scaling
  • FAAS : Logique métier sans se soucier de l’infra pour exécuter le workload

IAAS :

Dans ce cas, il faut penser à

  • La localisation
  • La réglementation
  • Les types de calcul (data / Machine learning / compression / cryptage …)
  • Network :
    • AWS : VPC regional
    • GPC : VPC is global
    • AZURE : HUB & SPOKE
  • Availability (SLA des VM)
    • GCP 99,99
    • AWS 99,5 => SLA sur les AZ uniquement au début, après ils ont rajouté des SLA sur les VMs
    • AZURE 99,5
    • Chaque loader met des loader dans la région. On trouve 3 AZ (data center). Si un data center (AZ), tombe, le traffic est transféré sur l’autre AZ

Si des VM tombent, le provider s’engage à faire les restant & le scaling. Point fort d’azure sur l’availability set (il faut le coder pour les autres).

SLO & SLA

Le cloud ne garantit par la perte du CA. Le client du cloud définit son RTO & RPO pour autoriser l’indispo / la perte des datas. Il faut trouver un équilibre entre la haute dispo et la tolérence aux pannes.

Auto shutdown

  • AWS : instance scheduler
  • AZURE : Build-in every VM
  • GCP : instance scheduler on every VM

IAAC Azure (Infra as Code)

  • Azure Resource Manager qui permet de décrire l’infra & la déployer
  • Define blueprint
  • Azure bicep template : syntax particulière d’Azure ARM pour un code avec une meilleure syntaxe
  • AWS :
    • Cloudformation pour créer son cluster / Stack applicative
    • AWS Cloud development Kit qui permet du taper le code pour créer de l’infra

GCP : Cloud deployment manager (template YML) avec des stocks python

OpenShift : K8s encapsulé par redHat

L’IAAC génère un fichier json qui décrit toute l’infra. La taille du fichier peut aller jusqu’a 10K lignes de Json.

IAAC Terraform de Hashicorp

  • Fonctionne avec tous les clouds providers
  • 4 commandes : int, plan, apply, destroy
  • 1 seul langage pour tous les providers (y compris on-premise)

Pulumi

  • Voir Pulumi
  • Langage infra-as-code
  • Open surouce
  • Permet de céder l’infra en Java / JS / go …
  • Permet de piloter l’infra à partir du code
  • Service EC2 : création de machine sur AWS

IAAS in a nutshell

  • On ne fait pas la même chose on-premise & sur cloud
  • Faire la micro-segmentation
  • CI/CD pour créer les images avec le patch
  • Lift&shift : a ne pas faire (prendre l’appli telle qu’elle est et la mettre sur le cloud)
  • On ne peut pas comparer le legacy (acheté il y a plusieurs années) & le cloud
  • Nouveaux outils & Nouveaux usages

CAAS

AWS

  • Use ECS & Fargate (micro-VM)
  • EKS (K8S) est récent et limité en terme de noeud
  • Model (pay as you GO)

Comparatif :

  • Azure : Active directory est le point fort (non présents chez AWS / GCP)
  • GCP :
    • Multi-pools (15K nodes)
    • integration native sur les métrique K8S
    • CloudRun : a destination des développeurs (version Bêta) : Accès vers une API K8S & google gère
    • gitlab.com est bien branché avec le GCP

GCP est la meilleure solution pour faire du K8S (Google est le créateur de K8S)

Service Mesh

Micro service lead to Death Star Architecture

Comparatif

  • GCP : Anthos service Mesh : Le leader
  • GCP : CloudRun
  • Azure : Service Fabric Mesh

Les speakers on publié une Web-paper : All as Code

Le temps d’apprivionning & installation de la machine met bq de temps.

Pour le cas d’AWS, il y a cas qui existe qui est le Chaos engineering.check tool : Spinnaker

CAAS

  • Grosse tendance pour les flounders
  • Lead by K8S
  • Il faut rajouter du tooling

PAAS

  • Elastic Beanstalk peut être utilisé pour le déploiement des applications sur AWS
  • Le Clouders fait le travail des OPS sur le on-premise, et les OPS travaillent sur l’automatisation

Le métier de l’OPS est en train changer pout déléguer bq de choses aux clouders :

  • Creer l’env
  • Démarrer la stack
  • Meetre en place le VPC, Firewall …
  • Pas de config à faire
  • Load balancer en frontal
  • Rajouter les variables d’env sans recompiler le code

Le PAAS permet :

  • La configuration de l’env
  • Deploiement Slot -> créer un nouvel env
  • Mettre du monitoring, scalabilité manuelle ou auto

Sur AWS, l’application tourne sur le port 5000 (par défaut) AZURE propose des serveurs WEB pour déployer sur cette chaine de serveur Resource Group est propre qu’AZURE. Le plugin maven permet de faire le déploiement

Bleu-Green Deployment :

Faire en sorte de l’url de la prod pointe vers un autre env (garder la prod & next-prod up en même temps) sans faire le déploiement automatiser

Quel est le niveau service que je vais prendre :

  • 1 seul déploiement
  • Premium : 20 slots de déploiements de 20 versions de l’application

GCP

  • AppEngine est en place depuis 2008
  • Pas de Docker pour AppEngine
  • Plugin maven qui va tout piloter / créer / déployer

PAAS in a nutshell

  • Pas de gestion de réseau / infra -> c’est le CP qui s’occupe
  • Ca coute plus cher, mais on réduit l’OPS capex
  • On shift left sur l’infra

Serverless

Nouveau Paradigme mis en avant par les Cloud Providers : Déployer du code application sans se soucier de l’infra

  • facturé qu’a sa consommation
  • Scaling automatique
  • Scaling to 0
  • Pas de management d’infra

Sur le marché :

  • AWS Lambda
  • Azure Cloud fonction
  • GCP Cloud functions

Il y a des BDD serverless

  • BigQuery
  • Azure SQL server Serverless
  • AWS Arora Serverless

Arora existe aussi en mode PAAS

GraphQL :

  • Released on 2015
  • Avantage GreenIT
  • Consomme que ce qu’on a besoin pour un use case donné
  • Seul AWS propose ce type de service (amplify / appSync)

Résumé

  • Plus on monte dans les couches,
    • plus les Cloud Providers s’occupent de l’infra
    • plus on est agile/rapide dans ce qu’on va mettre en place -> TTM bas
  • Déploiement plusieurs fois par jour
  • Quand on fait des cloud, on fait différemment sur le code / deploy on-premise


Devoxx21CloudAWSAZUREGCP