Retour sur le Learning Day AWS à Lyon

Temps de lecture : 6 minutes

Si le Cloud est aujourd’hui une évidence pour les entreprises françaises qui sont de plus en plus nombreuses à passer le cap, il génère un fort besoin d’information et de formation. Le Cloud est en effet un nouveau modèle et représente pour l’entreprise un changement plus profond qu’une simple évolution technologique. Afin de donner les clés pour se lancer sur le Cloud AWS, D2SI a organisé à Lyon en décembre dernier le premier Learning Day AWS, une journée de formation gratuite.

Le voyage dans le Cloud

Nous avons pris l’habitude chez D2SI de parler de voyage dans le Cloud. Ce n’est pas qu’une formule : le Cloud est un territoire nouveau, avec de nouvelles règles et de nouvelles façons de faire. Pour démarrer le Learning Day, nous avons donc voulu commencer par un icebreaker qui illustre ces nouvelles façons de faire : le voyage vers le Cloud est avant tout collectif. Passer sur le Cloud implique de collaborer avec des personnes ou des services qu’on ne connaît pas à priori, de trouver les réponses à plusieurs, et de parfois découvrir qu’il n’y a pas qu’une seule bonne solution.

Culture Cloud

Un peu de contexte pour commencer : le Cloud est arrivé à un moment où les DSI étaient sous tension, avec l’objectif de faire moins avec plus, et plus rapidement.

Le Cloud, avec son modèle de facturation à l’usage, a permis aux DSI de passer d’un modèle CAPEX à l’OPEX, et donc le plus souvent de réduire les coûts. Cependant, on retiendra surtout que le Cloud a facilité l’innovation, en réduisant le coût subi et le périmètre impacté en cas d’échec. En d’autres termes, on peut expérimenter sans risques et sans engagement.

Formulé ainsi, tout a l’air très simple, mais le Cloud est une innovation de rupture, qui demande une approche plus globale, et pose de nouveaux enjeux. A ce titre, les bénéfices que l’on peut tirer du passage au Cloud n’apparaissent que si ce passage est accompagné de la mise en place d’une nouvelle approche, de nouvelles façons de faire à la fois techniques, fonctionnelles  et organisationnelles. Le passage au Cloud doit se faire dans le cadre d’une transformation à la fois de la DSI et des applications.

Par exemple, le Cloud a son propre vocabulaire :

“ J’ai déposé les fichiers dans le bucket S3, j’ai mis le rôle IAM sur l’EC2 pour pouvoir extraire les infos et les pousser dans une instance RDS ”

signifie “J’ai déposé les fichiers dans le répertoire, j’ai donné les droits sur le serveur pour pouvoir extraire les infos et les pousser dans la base de données.

Le Cloud change également la façon dont on opère les infrastructures, avec la généralisation du DevOps, de l’automatisation, du CI/CD et de l’agilité.

Comment réussir son passage sur le Cloud

Les chemins empruntés et les outils utilisés pendant ce voyage dans le cloud peuvent être différents d’une organisation à l’autre. Toutefois, deux éléments sont des impératifs pour réussir son virage cloud : l’automatisation et le Serverless.

Cela peut représenter un coût initialement, mais il s’agit de deux étapes de transformation obligatoires sur lesquelles l’organisation pourra capitaliser par la suite pour accélérer sa mutation. L’adoption de ces deux principes permettra également aux équipes IT de libérer de la disponibilité pour se rapprocher des métiers.

La sécurité sur le Cloud

Pourquoi faut-il sensibiliser le plus tôt possible au sujet de la sécurité sur le Cloud ? Encore un fois le Cloud change les règles du jeu et appelle à de nouvelles pratiques, y compris en termes de sécurité.

Security is job zero : le devsecops n’est pas un profil de super héros sécurité, qui connait tout à tout et prend sur ses épaules toute la charge de sécurisation de tous les environnements cloud et chaînes CI/CD. Le devsecops est une philosophie qui prône une responsabilisation de chaque intervenant, à tous les niveaux de la chaîne opérationnelle, pour permettre d’encadrer les risques associés aux déploiements des pratiques de self-service et à la décentralisation des pouvoirs.

Un passage réussi sur le Cloud demande de comprendre le modèle de responsabilité partagée : la sécurité du Cloud est assurée par AWS, la sécurité dans le Cloud est la responsabilité du client : il lui incombe de gérer les règles pour sécuriser son infrastructure, comme les firewalls, les security groups, etc.

La place de l’apprentissage

Nous croyons au « Learning by doing » : pour apprendre à faire du cloud, il faut … faire du cloud. Les formations et le partage d’expérience ont beaucoup de valeur et ne sont pas à négliger, loin de là. Bien qu’indispensables, ils ne représentent toutefois que 30% du travail d’acquisition de nouvelles connaissances. Le reste passe par la pratique : monter des projets pilote, tester des services, et se challenger lors d’exercices concrets.

Gameday : learning by doing

La deuxième partie de la journée est justement consacrée à la mise en pratique avec des Gameday et des hands-on. Le Gameday est un exercice de mise en conditions réelles, avec une infrastructure similaire à celle qu’on trouve en production, et sur laquelle on provoque des pannes. Les participants doivent alors identifier ces pannes et trouver rapidement des correctifs. Ce type d’exercice permet de comprendre rapidement le fonctionnement des services Cloud et d’identifier les points de vigilance.

Dans le cadre du Gameday sécurité, les participants ont notamment eut l’opportunité de résoudre des pannes et des problèmes de non-conformité qui tournaient autour des sujets suivants:

  • Les Security Group et des NACL (règles de filtrage permettant aux instances / subnets de communiquer)
  • Les politiques IAM appliquées aux bucket S3 et aux roles (gestion des « deny ») et des boundaries
  • La configuration du service d’Autoscaling Group
  • La gestion des clés KMS
  • La restauration des fichiers dans S3
  • La résolution des problèmes de configuration des instances
  • La visibilité internet de buckets S3
  • La configuration multi-régions d’AWS Cloudtrail (avec utilisation du principe d’assuremrole)

Les participants du Gameday Serverless ont rencontré d’autres types de pannes liées aux architectures sans serveurs :

  • Des bugs à corriger: spécification implémentée à moitié, erreur de syntaxe, fonctionnalité oubliée
  • Des problèmes réseau
  • Des erreurs de configuration des Lambda
  • Des erreurs de configuration dans les routes d’API
  • Une régression de code
  • Des soucis de permission d’accès
  • Des soucis de permission d’exécution

Pour les sujets Data, nos équipes ont proposé un lab pratique avec différentes taches à réaliser pour se familiariser avec les outils Data AWS :

  • Déploiement d’un Kinesis Firehose pour récupérer en temps réel un flux de données correspondant à des requêtes http faites sur un site internet fictif
  • Conversion des données au format parquet pour optimiser les requêtes SQL
  • Lancement d’un crawler Glue pour analyser le schéma des données et créer les tables correspondantes dans la Database
  • Analyse des données par requête SQL depuis Athena
  • Visualisation des données depuis Quicksight par projection sur une map des adresses IP (Geospatial Charts) ayant effectué des requêtes sur le site internet fictif

Prochains Learning Day

Suite au succès de cette première édition lyonnaise qui a rassemblé plus de 70 participants, et à l’engouement suscité par la formule qui mélange approche théorique, retours d’expérience et mise en pratique, nous proposerons en 2020 d’autres éditions du Learning Day.

Le prochain Learning Day AWS aura lieu à Nantes le 9 juin, inscrivez-vous dès maintenant !

Commentaires :

A lire également sur le sujet :