Petit REX après 1 an d'utilisation d'AWS

Cela fait 1 an que j’ai intégré la DSI d’octo pour refaire nos sites publics, ayant des compétences d’ops on m’a laissé la main pour jouer avec le provider de la boîte, AWS. Je connaissais déjà, mais je n’avais pas réellement joué avec depuis plusieurs années.

J’ai baigné dans le cloud pendant plus de 5 ans et baigné, c’est peu de le dire. J’ai participé à la création de 2 cloud (chez SFR et chez Numergy 💀), c’est là que j’ai découvert ce qu’est réellement l’ops et on avait poussé le principe très très loin.

Je vous propose un petit tour d’horizon des services AWS que j’utilise avec les trucs cools et moins cools pour chacun d’eux.

Le stockage : S3

C’est le service que j’utilise depuis le plus longtemps. S3, c’est ce qu’on appelle du stockage objet. Alors non pas des objets du quotidien comme une tasse. Pour faire simple, le stockage classique (dit fichier) fonctionne avec une arborescence de dossiers dans des dossiers qui contiennent des fichiers. En soit ça marche bien, mais si on a trop de dossiers ou des sous-dossiers dans tous les sens alors la recherche de fichier va être très complexe et donc longue.

Le stockage objet va avoir une structure plate. Chaque fichier à un identifiant et des métadonnées et tout ça est au même niveau. La recherche est donc grandement facilitée. PS: pas de souci pour avoir des dossiers, c’est dans les métadonnées 😉

En plus d’avoir un stockage rapide et à faible coût, on a la possibilité d’utiliser un “glacier”. C’est un stockage dans S3 qui sert d’archive. Le coût est extrêmement faible sauf en cas d’accès fréquent, et oui, c’est uniquement pour de l’archivage.

Le seul petit bémol que je vois, c’est lié à la partie stockage, et oui il faut bien un inconvénient à chaque technologie. Je vous ai parlé de métadonnées, concrètement va se cacher derrière le “dossier” de stockage, mais aussi certains éléments plus importants pour une utilisation web. On peut avoir par exemple le type de fichier en spécifiant son contenu avec le “content-type: text/css” pour dire que c’est un fichier de style css ou encore comment on veut que notre fichier soit gérer. Sur les pdf, c’est intéressant de dire par exemple “Content-Disposition: inline” ce qui va indiquer au navigateur d’afficher le pdf plutôt que le télécharger.

C’est gérable, mais ça peut donner quelques nœuds au cerveau pour comprendre comment résoudre certains problèmes.

L’exécution de code : Lambda

Sûrement mon service préféré. Il permet de lancer du code en mode serverless. C’est du code qui est lancé sans serveur.

Par exemple, cet article de code est généré grâce à une lambda. On a pas de serveur qui tourne h24 dans l’attente de la précieuse demande. De ce côté, au moment où la lambda reçoit la requête, elle va monter un micro serveur qui va exécuter le code et ensuite se supprimer.

C’est franchement hyper cool, fini les serveurs qui tournent sans rien faire.

En vrai, je n’ai pas grand-chose d’autre en positif. Je trouve ça déjà tellement énorme. Alors par contre la gestion du code en lui-même c’est pas la fête… Ça se passe uniquement via l’interface ou via l’upload de zip. J’ai parfois l’impression d’être de retour à l’époque des ftp. Alors oui, avec un bon système de déploiement, ça se fait, mais je pense vraiment qu’il y aurait des trucs plus cools à faire (branchement sur des repos, …).

Un peu de container docker : ECS ou EKS

Docker ça permet d’avoir ce qu’on appelle un container qui contient un service que l’on souhaite faire tourner. Par exemple, nginx pour un serveur web, coupler avec un mysql pour la base donnée et un petit dernier pour notre code à nous. Comme ça, chaque service est bien cloisonné pour faire des upgrades simplifiés et surtout pour avoir des environnements iso entre le dev et l’infra de prod.

Et bien AWS nous simplifie la vie avec 2 services ECS et EKS auxquels on va indiquer quels services lancer.

Pour faire simple la différence entre les 2 reposent sur l’architecture de base ECS :

• Créé et géré par Amazon
• Plus simple à intégrer avec les autres services
• Plus scalable
• Par contre faut apprendre à utiliser sa façon de gérer les containers et leurs dépendances

EKS :

• Basé sur Kubernetes
• Plus simple pour rentrer dans son utilisation, car il y a des milliards de tuto sur Kubernetes, voir des configs toutes prêtes

La gestion web : Cloudfront et Api gateway

Ce sont les 2 services que j’utilise qui servent pour que l’on puisse appeler mes sites et services.

Cloudfront, c’est globalement le serveur web d’AWS. On lui dit qu’elle est l’url de notre site et où il doit aller chercher les infos et c’est parti. Ce blog par exemple à un cloudfront qui va chercher les données à afficher sur s3.

On peut aussi lui dire de lancer une lambda sur certaines urls, par exemple pour gérer les redirections. Et c’est là où c’est potentiellement le bazar… À chaque fois qu’on met à jour le code, il faut attendre entre 5 et 10 minutes pour qu’il soit accessible. Ça, peut-être, critique en fonction de ce que l’on souhaite faire. Par exemple, résoudre un gros bug, c’est pas immédiat…

Maintenant, que j’écris ces lignes, je me dis qu’il est possible de faire une lambda tampon qui ne bouge jamais et qui appelle une autre lambda qui elle peut bouger plus facilement, car elle n’est pas directement reliée à cloudfront 🤔 Ça résoudrait mon principal problème avec cloudfront… Je vais testé ça assez vite je pense 😀

L’autre service, c’est Api gateway qui permet de créer une api branchée à des services d’AWS (lambda, S3, …). Cette fois-ci, il faut tout configurer à la main. C’est quoi mon url, comment je peux l’appeler, quels sont les paramètres attendus, je lance quoi, je réponds quoi. Oui, c’est long… Mais une fois tout bien fait, ça marche tout seul, ça se met à jour ultra facilement et on peut gérer plusieurs environnements directement.

Le reste

Il y a encore beaucoup de choses, mais le reste est plus global et splitté sur plusieurs services et je ne peux pas parler de tout sinon il faudrait plusieurs jours.

• L’infra réseau est entièrement gérable comme si un avait tout en physique. On peut séparer les éléments de notre infra sur plusieurs réseaux, indiquer qui peut parler avec qui, … La gestion des LBs est aussi gérée pour permettre une scalabilité ou du déploiement blue/green.
• La sécurité est vraiment au cœur des services. De base à la création d’un service, il n’a accès à rien et aucun autre système n’y a accès. Il faut préciser qui peut y accéder et surtout qu’est-ce qu’il peut faire dessus, par exemple de la lecture seule, …
• On commence aussi à voir l'arrivée de plus en plus de services 100% intégrés et gérés par AWS. J’utilise déjà grafana et prometheus, ce sont des éléments que l’on ne peut pas couper et mettre sur du serverless. Et plutôt que de gérer de mon côté avec mes petites mains, autant profiter un truc clé en main avec des petits plus.

La transparence de la gestion d’Amazon

C’est là mon vrai problème… On vient de voir qu’il y a plein d’éléments intéressants sur AWS, des moyens de réduire notre impact sur l’environnement en passant sur du serverless, en profitant d’un stockage léger, …

Par contre qu’en est-il vraiment ? J’avoue que c’est uniquement mon ressenti personnel et un peu de logique. Même si l’exécution d’une lambda sur le temps de son exécution est plus importante qu’un micro serveur qui tournerait sur la même durée, sur le long terme lambda gagne (tout dépend bien évidemment du nombre d’appels…)

Par contre j’aimerais plus de transparence sur ce qui se cache réellement derrière, quel est le coût environnemental à un cloudfront, à un api gateway, etc. Pour faire des comparaisons, savoir quoi privilégier, peut-être même changer mon infra. Mais côté AWS la transparence n’est pas de mise, on pourrait se dire : “Ils ont mis un super outil pour calculer notre impact avec un résultat en MTCO2e (Metric tons of carbon dioxide equivalent)”. C’est vrai que l'outil existe, par contre, faudrait-il encore qu’il fonctionne… En un an d’utilisation de mon tenant AWS je suis encore et toujours à 0. Alors j’aimerais vraiment y croire, me dire qu’aussi de mon côté que du leur en fait un excellent taff, mais je n’y crois pas un seul instant… C’est dommage…

Pour conclure

AWS c’est, je pense, une première bonne étape pour aller vers quelque chose de plus propre. J’aime bien jouer avec, y’a vraiment des trucs cool, mais je commence sérieusement à regarder ailleurs pour voir si d’autres, sûrement plus petits, acteurs sont plus transparents voir semble plus “vert”. Après, je pense que c’est une étape temporaire, facilité par la documentation et le nombre d'utilisateurs.

Je vais aussi me pencher sur les outils d'analyse de cloud, ça commence à être de mieux en mieux et ça servira pour bien choisir le futur provider.

Un peu de teasing pour le prochain article ? Mais comment je fais pour maintenir mon infra facilement, vous allez me dire ? Et bien, je fais de l’infra as code avec terraform. C’est puissant et ça permet de gérer, presque, complètement l’infra. Comme ça plus de soucis de synchro, de différence entre environnements, … Bref rdv très vite pour vous en parler plus longuement.