Découverte d’Alibaba Cloud

Le Cloud est aujourd’hui incontournable. En revanche, même si nous connaissons souvent les offres proposées par les acteurs majeurs du secteur que sont Amazon, Azure et Google Cloud, il en existe beaucoup d’autres. Dans cette série d’articles, nous vous proposons un aperçu sans prétention de quelques Cloud Providers moins connus et des services qu’ils proposent.

Le premier sur lequel nous avons choisi d’expérimenter est Alibaba Cloud.

Introduction

L’objectif de l’exercice consiste à nous forger une opinion sur l’expérience générale proposée par le fournisseur en se limitant volontairement à cette première approche qui nous donnera envie (ou non) de poursuivre notre utilisation.

L’article sera ainsi composé d’une brève présentation du fournisseur Cloud et de son offre, de ce qui peut déjà à ce niveau le distinguer des autres. Ensuite nous déploierons quelques solutions correspondant à des cas d’usage courant. Enfin nous ferons un bilan de cette expérimentation en prenant en compte : la richesse de l’offre, l’expérience utilisateur, le coût et éventuellement d’autres éléments notables.

Présentation d’Alibaba Cloud

La société Alibaba Cloud (Aliyun en chinois), fondée en 2009, est une filiale du groupe Alibaba connu principalement pour la vente en ligne sur le territoire chinois et à l’international. La société est membre platinum de la CNCF (Cloud Native Computing Foundation) et membre Gold de la Linux Foundation depuis 2017, s’inscrivant ainsi dans l’utilisation et la collaboration autour de la communauté Open Source Cloud Native.

Le fournisseur propose d’héberger ses services dans 25 régions, sur le territoire chinois (12 régions), mais également à l’internationale (13 régions), Francfort et Londres en Europe.

Au niveau des services disponibles, nous retrouvons les services habituels :

• Du IaaS (Elastic Compute Service)
• Des bases de données managées (PolarDB et ApsaraDB) compatibles avec MySQL, PostgreSQL et Oracle
• Du Kubernetes managé (ACK)
• Du stockage objet
• Du réseau privé, load-balancers et CDN…

En tout, ce sont plus de 100 services différents qui sont proposés sur la plateforme, dont un qu’on ne retrouve pas souvent : du Bare Metal.

Passons maintenant au test de quelques-uns de ces services.

Quelle architecture a été montée ?

Nous avons voulu mettre en place une architecture traditionnelle type 3 tiers : 

• Front hébergé sur un service managé
• Back à base de VM puis de CaaS
• Base de données Postgresql en service managé

Pour se faire la main, nous avons utilisé exclusivement la console web pour naviguer à travers les options afin d’appréhender le vocabulaire et de découvrir les différentes possibilités.

C’est l’approche que nous faisons tous pour découvrir un service avant de passer à une version industrialisée et/ou automatisée avec des outils d’IAC.

Pierre-Yves Aillet et votre serviteur ont réalisé cette expérimentation début Janvier 2022.

Détails des différents services utilisés

Création de compte

La création de compte fait apparaître une notion de particulier ou d’entreprise que l’on retrouvera également dans plusieurs services pour offrir un niveau de service plus ou moins élevé. Nous avons choisi “Individual Account”.

Une fois la carte de crédit enregistrée, c’est parti ! Comme pour la majorité des cloud providers, même si une calculette est disponible (en partie en chinois) nous n’avons aucune idée des coûts engendrés a priori, on verra la surprise en fin de mois 🙂

Elastic Compute Service

Le service Elastic Compute Service, ECS, permet de gérer toute la stack réseau, des VMs, du stockage et des LoadBalancers notamment.

Nous avons commencé par lancer une simple VM via l’assistant de lancement qui nous guide dans tous les processus. Les informations demandées ne nous sont pas étrangères : 

• Choix du type d’instance (vCPU, Ram, réseau) à partir du catalogue
• Région
• Stockage associé
• Image d’OS à booter
• Réseau sur lequel brancher la VM

Le vocabulaire utilisé est très proche des leaders du marché, nous retrouvons vite les significations ou implications de la majorité des paramètres demandés.

Une fois la VM démarrée, nous retrouvons ses caractéristiques dans l’interface ci-dessous : 

Une connexion ssh plus tard, nous nous retrouvons avec un dérivé d’une centos :

Server Load balancer

Nous avons voulu essayer de mettre en place un load balancer devant notre VM qui expose un service whoami à l’aide d’un ALB (Load Balancer de niveau 7 permettant d’interpréter les entêtes HTTP comme ‘Host’ ou le path demandé). 

Le vocabulaire utilisé pour instancier une instance est proche des autres providers : target group, resource group… Néanmoins, le champ “Edition” n’est pas compréhensible sans la documentation : 

ApsaraDB RDS

L’étape suivante est d’instancier une base de données via le service managé ApsaraDB RDS. Les moteurs les plus populaires disponibles sont PostgreSQL, MySQL, MariaDB…

L’assistant de création nous permet de choisir entre ces différents moteurs et de choisir une édition : le mot “Enterprise” revient et il faut fouiller la doc pour comprendre les subtilités entre “High-availability”, “Enterprise” et “Basic” : il s’agit principalement du nombre de réplicats en lecture / écriture ou lecture seule.

Lors de la sélection de la région, nous avons eu un message d’erreur indiquant le manque de capacité en termes de matériel : et oui, le Cloud n’est que l’ordinateur de quelqu’un d’autre, les ressources ne sont pas infinies…

Après avoir attendu quelques minutes, nous avons pu passer cet écran et valider notre panier !

La notion de paiement, panier, type de souscription ainsi que le montant dû sont beaucoup plus affichés que ce que nous avons l’habitude de voir.

Une fois la base créée, nous avons pu nous y connecter depuis notre VM sans soucis. Un équivalent à phpmyadmin est également disponible pour parcourir la base.

Par contre, il faut attendre entre 20 secondes et 1 minute pour obtenir le résultat d’une quelconque requête. Nous ne connaissons pas l’origine de ce comportement.

Pour détruire une ressource, le vocabulaire employé est un peu déroutant : il faut “release” une instance et non “destroy” ou “terminate”.

Object Storage Service

Nous avons continué notre expérimentation en explorant les solutions de stockage managée à l’instar des buckets type S3 d’AWS ou GCP.

L’assistant de création nous propose comme à l’accoutumée le choix de la région, du type de stockage, droits d’accès, chiffrement…

Nous avons ensuite activé l’exposition en HTTP, déposé un fichier index.html et tenté d’y accéder directement avec un navigateur : l’entête HTTP ‘Content-Disposition’ est valorisé à ‘attachment’ provoquant l’affichage coté navigateur d’une fenêtre de téléchargement et non un affichage du site. Ce n’est pas un bug mais une feature pour inciter très fortement l’achat d’un nom de domaine à associer.

IAM

La gestion des droits est extrêmement proche de ce que nous connaissons déjà : utilisateur, groupe, ressources, droits…

Par exemple, lors de l’exposition du bucket créé précédemment, nous avons paramétré les droits afin d’autoriser les accès publics à l’aide d’un fichier json de permissions au format bien connu :

Une fonctionnalité très intéressante est l’affichage d’assistant lors de la création de ressources pour ajouter les droits manquant à ajouter côté utilisateur plutôt que d’afficher un message d’erreur sur la première permission manquante uniquement. L’écran ci dessous s’est affiché lorsque nous avons joué avec le service de conteneur managé pour ajuster les permissions de mon utilisateur :

CaaS

Notre expérimentation s’est terminée sur l’un des services d’exécution de conteneur : Elastic Container Instance. Nous avons fait le choix d’utiliser ce service pour son aspect serverless plutôt que de passer par un Kubernetes managé.

Encore une fois, les écrans de création nous conduisent très vite au lancement d’une image httpd avec ici par exemple le choix des versions :

Le lancement se passe bien et le conteneur est accessible :

L’interface propose l’affichage des logs et les détails sur l’image utilisée ainsi que les paramètres de lancement comme ‘docker inspect’ nous l’offre.

Developer eXperience

Nous allons maintenant nous concentrer sur l’expérience proposée aux développeurs pour interagir avec la plateforme.

En premier lieu, les interactions avec la plateforme se font au travers d’API. Un portail dédié permet l’exploration de la documentation de ces API et l’expérimentation directe.

Sur ce portail, vous retrouverez la description des différentes ressources disponibles, des exemples de code dans les différents langages des SDK disponibles. Un exemple de commande utilisant la CLI aliyun disponible pour interagir avec les services.

Une nouvelle version de ce portail est en cours de déploiement, mais l’internationalisation n’est pas encore terminée :

Nous avons la possibilité d’avoir une machine virtuelle pré-paramétrée proposant une expérience similaire à ce que propose Google Cloud avec Cloud Shell :

• Éditeur de code intégré
• Outil de CLI aliyun pré-paramétré
• De nombreux outils déjà disponibles (terraform, vim, jq, …)

En revanche, une différence notable par rapport à ce qui est proposé ailleurs est qu’il n’est pas possible de personnaliser cet environnement. Par exemple, sur Cloud Shell il est possible d’utiliser un espace persistant de 5Go pour le /home de la machine afin de la personnaliser.

En complément de ces éléments, il existe également 2 solutions permettant d’orchestrer ses déploiements en utilisant les principes de l’IaC (Infrastructure as Code) :

• Ressource Orchestration Service (ROS) : un équivalent aux outils Cloud Formation d’AWS et Deployment Manager de Google Cloud
• Un provider Terraform : https://github.com/aliyun/terraform-provider-alicloud

Globalement, nous ne sommes pas perdus, les outils habituels sont là, l’organisation de la console est assez similaire à ce qu’on retrouve ailleurs. En revanche, nous avons rencontré quelques difficultés d’usage.

L’interface de la console manque de réactivité, une différence de rapidité d’affichage est constatée entre les contenus “statique” type documentation et les pages plus lourdes comme les assistants de création de ressources. Nous avons même rencontré des freezes de certaines pages. Dans la copie d’écran ci dessous, un masque noir s’est ajouté sur l’interface et aucune action n’est possible. Un rechargement de la page nous ramène au début de l’assistant et il faut tout re-saisir.

Nous avons également constaté que certains exemples donnés par la documentation n’étaient pas fonctionnels (voir les captures ci-après).

I18n

Comme présenté précédemment, il reste des traductions absentes sur des popups de confirmation comme l’exemple ci-dessous. Difficile de savoir ce qui va être validé :

Ou celui-ci qui est apparu suite à une création de ressources : 

(le QRcode a été changé par mesure de confidentialité)

Bilan

La première approche de cet acteur du marché s’est avérée fructueuse : nous avons pu créer les éléments de base de notre architecture. La suite naturelle serait de tester la résilience de tous les composants afin d’assurer la survie d’une application.

Il faut tout de même être vigilant sur les traductions manquantes ou le manque de clarté de certains attributs dans les écrans de création ou gestion des ressources.

La dernière question est “mais Guillaume, de quel montant ton compte bancaire a-t-il été prélevé ? ”

La réponse en image : 0.15 $ mais j’ai bénéficié d’une réduction en tant que nouveau compte, donc 0 $.

Merci à Pierre-yves, Eric et Arthur pour leur relecture.