Osones à l'AWS RE:invent 2017 : Jours 1 & 2

Publié le
par Kevin Messy
dans Amazon Web Services
⭠ Retour à la liste des articles
thumbernail Amazon Web Services


Troisième Re:Invent pour Osones, l'occasion de vous dévoiler de l'intérieur les nombreuses nouveautés et la roadmap d'Amazon Web Services !

Retrouvez également la première Keynote et la deuximee Keynote.



Osones de retour pour la 3ème année consécutive à l’AWS Re:Invent !

La Grand Messe Amazon Web Services se tient tous les ans à Las Vegas et est plus connue sous son petit nom : c’est le re:Invent.

Chaque année, le Re:Invent est la plus grande conférence au monde dans l'univers du Cloud Computing, avec plus de 40 000 personnes attendues pour cette édition 2017.

L'enjeu en tant que partenaire AWS est stratégique : le re:Invent est l’occasion pour les équipes Cloud d’Amazon de présenter toutes les nouveautés qui vont composer la Roadmap AWS pour l’année à venir. C'est en partie cette présence qui permet à nos Experts de vous proposer les services de pointe du Cloud d'Amazon.

L’an passé, ce sont par exemple près de 20 annonces “majeures” qui ont été dévoilées !



Journées bootcamps techniques, hackathons et labs se succéderont du lundi au vendredi, le tout entre deux tables de black jack.

Les premiers jours du Re:Invent 2017 !

Si le dimanche est le moment parfait pour se re-mettre sur le bon créneau horaire et faire du tourisme, c’est aussi un nouveau RDV : le “Midnight Madness”.

De 22H30 à 1H, cette soirée “dans les coulisses” du summit propose de se mettre dans le bain avec un aperçu de la semaine, des interventions des executives AWS, et une mini soirée. Avec 3500 places pour 40000 personnes, autant dire que la lutte était sévère pour entrer.

Deux choses que nous retiendrons de ce mini-évenement :





Le lundi est donc plutôt orienté Bootcamp et Partners, avec notamment le Global Partner Summit le soir même au MGM.



L’AWS Summit, toute une organisation.

Cette année, l’AWS Summit accueille plus de 40 000 participants. Même si Las Vegas est capable d’accueillir des événements de plus de 150 000 personnes, les centres de conférence des hôtels sont bien trop petits pour accueillir à eux seuls les centaines de conférences qui se déroulent tout au long de la semaine. Cette année, AWS a donc décidé de séparer les conférences par thème dans différents hôtels parfois séparés de plus de 2 kms.



Il faut donc faire très attention lorsque l’on programme ses conférences de la journée, il est préférable de sélectionner les conférences qui se déroulent dans un même hôtel, quitte à manquer des conférences intéressantes.

Un service de navette est mis à disposition entre les hôtels, mais en pratique celui-ci se révèle inutilisable, avec des files d’attente pour accéder aux bus de plusieurs centaines de personnes, avec des temps d’attente de l’ordre de la demi-heure. Un budget taxi est à prévoir !

La première journée de lundi nous aura donc servi de leçon, la plupart d’entre nous n’ont pas pu accéder aux conférences qu’ils avaient programmé.

Le cache

Nous avons suivi deux conférences sur le sujet du cache. Au sens large. Nous ne rentrerons donc pas ici dans les détails techniques, ce n’est pas ça le plus important.

La principale conclusion que l’on peut tirer est la suivante : il faut toujours faire du cache. Toujours, et à tous les niveaux, mais que ce n’est pas un sujet trivial, et que le mieux est que le développeur ait ce sujet en tête dès le début de la conception de son projet.

Edge Cache : CloudFront

On connaît tous CloudFront, le CDN d’AWS. Bien souvent, et c’est une très bonne chose, on s’en sert pour mettre en cache des ressources statiques (html, css, js, etc.). Mais on peut également mettre en cache du contenu dynamique, sous certaines conditions.

Mais, le vrai secret de CloudFront, est que l’on peut également s’en servir… même lorsqu’il n’y a rien à cacher ! En effet, le simple fait d’utiliser CloudFront, même avec un TTL de 0 provoque une diminution des latences réseau, par le simple fait que CloudFront s’appuie sur le réseau optimisé d’AWS.

Application Cache

On peut, et on devrait tout cacher. Les configurations, les résultats, les agrégations, les sessions, les environnements, etc. Que ce soit localement sur les serveurs frontaux via les mécanismes de cache du langage (ACPu pour PHP par exemple), ou, quand ce n’est pas suffisant sur un cache distribué, Redis ou Memecached via Amazon ElastiCache.

Pensez-vous vraiment connaître EC2 ? (And you thought you knew EC2 ?)

Beaucoup de participants se demandaient effectivement s’ils connaissaient EC2, à tel point qu’il était rapidement impossible d’accéder à la salle de conférence. Une file de plusieurs centaines de personnes parcourait les couloirs du convention center.

Qu’à cela ne tienne, AWS étant prévoyant, une seconde salle transmettait la conférence, permettant à tous les participants d’accéder à celle-ci. Casque sur les oreilles, nous avons pu suivre cette conférence s’annoncant passionnante.

And you thought you knew EC2 ?

Cette conférence était l’occasion de faire le point sur toutes les fonctionnalités EC2 récentes et les services associés, comme ECS, EBS ou CloudWatch.

Ben Whaley nous a fait un rappel sur l’étendu de l’offre des types d’instance et leurs spécificités :

  • C5, optimisés pour les CPU,
  • P3, instances GPU,
  • R4, optimisés pour la mémoire,
  • I3, optimisés pour les IO,
  • X1, optimisés pour les bases de données in-memory,
  • D2, pour les instances demandant de très gros volumes de stockage.

Le service EBS a lui aussi différents types de volumes, comme les gp2, st1, sc1 avec pour chacunes des usages optimisés.

Ben Whaley est également revenu sur les nouveautés d’EC2 ces 6 derniers mois :

  • Intégration de l’IPV6,
  • Les “Elastic Network Adapter”,
  • Les “Elastic GPU”,
  • L'utilisation de KVM remplaçant Xen sur les nouveaux types d’instance,
  • La facturation à la seconde.

Mais bien sûr, vous savez déjà tout cela en tant que lecteur régulier du blog Osones ;)

Dans la seconde partie de la présentation, Ben Whaley a réalisé une démonstration de l’outil pssh de Kountable.

Cet outil permet de gérer en ligne de commande et très simplement les EC2 Parameter Store. Ce dernier permet de gérer les secrets et les configurations EC2. L’utilisation de cette fonctionnalité étant laborieuse par l’interface graphique, de nombreux outils ont vu le jour pour les gérer plus simplement.

Pour la démonstration, un cas d’utilisation non technique a été utilisé : la gestion des personnages de la série Game Of Thrones. Afin de mieux comprendre, le mieux est de visionner la conférence à partir de la 26ème minute.

Global Partner Summit (GPS) : How American Eagle Innovates with AWS

Nous nous sommes risqué à aller voir un retour d’expérience lors du Global Partner Summit. Nous donnons par défaut priorité aux conférences techniques, voir très techniques. Mais il est important aussi d’avoir des retours d’expérience de géants comme Amercian Eagle Outfiters (6600 salariés, 3,6 milliards de chiffre).

American Eagle

Collin Bodell, CTO d’American Eagle, revient sur ses expériences de migrations vers le cloud, dans sa société actuelle mais également dans les précédentes. Il nous précise qu’un projet aussi stratégique que la migration dans le cloud doit passer par le changement de CTO. En effet, il est difficile de donner un tel projet de migration qui ne porte pas le projet, surtout quand celui-ci n’y croit pas vraiment. Un CTO faisant du datacenter traditionnel depuis 20 ans n’est pas la bonne personne pour entamer un programme aussi critique qu’une migration vers le cloud.

Outre le fait que la migration demande des investissements significatifs, elle est également vécue comme une menace, avec une résistance forte des équipes opérationnelles du datacenter, les leaders et opérationnels. La peur est le frein majeur des migrations vers le cloud.

S’ajoute à cela la perte du temps pour le CTO de gérer toutes les sollicitations externes, les “solutions digitales”, les outils magiques qui aident à la transformation. Collin nous indique que 95% des contacts dans ce genre de projet sont non sollicités.

Il faut donc s’appuyer sur les retours utilisateurs, les références, afin de faire les bons choix. C’est une ressource très précieuse.

Précision encore, les différents CTOs doivent être sollicités, avant de commencer le projet. En effet les consultations, même courtes, amènent de la confiance et de la crédibilité.

Pour conclure, Collin indique que les priorités dans ce genre de projet sont la sécurité, la disponibilité, et enfin la latence, dans cet ordre.

Network load balancer

Après un bref récapitulatif des différents ELB, dont les classic load balancer sorti en 2009, Pratibha Suryadevara, “General Manager Load Balancing” chez AWS entre dans le vif du sujet.

Présentés au début du mois de septembre 2017, les NLB sont destinés à remplacer les ELB classiques, ces derniers agissent au niveau de la couche 4 du modèle OSI, et utilisent le protocole TCP.

Ici, l’accent est mis sur :

  • L’intégration des NLB avec les différents services AWS comme l’AutoScaling, WAF, CloudFormation et CloudWatch, qui permet notamment un monitoring très détaillé des différentes requêtes.

  • La compatibilité des NLB avec EC2 mais aussi avec les technologies de conteneurs comme ECS mais aussi LXC, Kubernetes, ou encore Docker Swarm.

  • Les performances. On apprend que les NLB sont bien plus performants que les ELB classiques, et qu’ils sont capables de tenir des millions de requêtes par secondes. Les NLB sont notamment aptes à supporter 100 000 connections actives, tout en maintenant un haut débit et une très faible latence.

  • La possibilité de cibler une adresse IP statique: chaque NLB fournit une adresse IP statique par zone de disponibilité. Il est aussi possible d’utiliser une Elastic IP si besoin. Le comportement de l’EIP en cas de suppression de du NLB est identique à une EIP classique sur une instance EC2.

Autre point important, on apprend que les NLB sont fait pour encaisser une montée en charge très soudaine, plus besoin de préchauffer les ELB.

Niveau fonctionnement, les NLB utilisent le trio classique “listener, target group et target”, tout comme les ALB.
Petit plus des NLB, et afin d’éviter de perdre les IP statiques attribuées aux AZ, Pratibha Suryadevara nous explique qu’ils ont jugé nécessaire d’ajouter une protection lorsque l'on souhaite supprimer un NLB, ils nous sera maintenant demandé deux confirmations avant suppression définitive d’un NLB.

Niveau tarification, les NLB sont facturés à l’utilisation, ainsi qu’au LCU (Load Balancer Capacity Unit) par heure.

0.0225$ par NLB, pour la région us-east-1
0.006$ par LCU

En soit, les NLB reviennent 10% moins cher que les ELB classiques, et le coût de l’échange de data revient également moins cher. La partie migration est rapidement évoquée en fin de conférence, il est possible de migrer d’un ELB classique vers un NLB via l’outil “Migration Wizard”, mais aussi via “l’Elastic Load Balancing Tools”, et Pratibha Suryadevara conseille vivement à l’auditoire de passer aux NLB / ALB en remplacement des ELB classiques.

SID303 : Les services d’identité d’AWS

Les services d’AWS sont désormais très nombreux. Ils sont aussi, à y regarder de plus près, la plupart du temps destinés à être consommés par d’autres services AWS ou des applications.

Les utilisateurs humains ne sont ainsi plus les seuls à devoir posséder une identité dans l’écosystème AWS.

Dans cette présentation, l’orateur a rappelé les trois cas d’utilisation des services d’identité avec Amazon :

  • L’authentification d’utilisateurs aux services Amazon : par exemple un SysAdmin qui se connecte à la console pour démarrer des instances EC2
  • L'authentification d’un service Amazon auprès d’un autre service Amazon : le cas classique est d’autoriser une instance EC2 à accéder à un bucket S3
  • L’authentification d’utilisateurs au sein d’une application : il s’agit ici d’utiliser un service AWS pour gérer des identités d’une application cloud native.

Les deux premiers cas d’utilisations sont gérés par IAM, tandis que le second est du ressors d'Amazon Cognito.

Amazon propose également un service de Microsoft Active Directory managé du nom de Directory Service.

A demain pour le prochain article !



L’équipe Osones

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way