AWS (re:Invent) 2022 : notre bilan
AWS re:Invent 2022 est désormais terminé, et avec lui son lot habituel d'annonces de nouveaux produits, de keynotes et de sessions en petits groupes. Parmi tout cela, qu’est-ce qui ressort ? Que faut-il retenir ?
(Contexte: ce blog post écrit dans mon poste précédent)
Aujourd’hui, je partage mon bilan personnel de la re:Invent et, plus largement, mon point de vue sur la feuille de route AWS.
Principales annonces de re:Invent du point de vue d'un responsable du développement logiciel
Mon rôle actuel, dans une entreprise relativement nouvelle dans le Cloud (avec seulement un an et demi d’expérience), m’amène à me concentrer sur l’architecture sans serveur, car ma principale préoccupation est que mon équipe de développement soit capable de livrer en continu. solutions sur une infrastructure fiable et évolutive, avec peu ou pas de gestion par l’équipe d’infrastructure.
Lambda SnapStart
Il ne s’agit pas officiellement d’une annonce de produit, mais le défi technique, en termes d’infrastructure sous-jacente, pour se débarrasser des démarrages à froid Lambda est une telle avancée majeure que je ne peux pas commencer sans mentionner cette évolution du service Lambda. Rien que pour celui-là, je reviendrai peut-être sur Java/SpringBoot (qui démarre désormais dans 100ms ^^)
La keynote de Peter DeSantis sur les progrès réalisés sur les composants de bas niveau du Cloud (puces, CPU et protocoles) est à regarder absolument.
EventBridge Pipes
Une capacité essentielle pour fournir des solutions évolutives et évolutives est la capacité à concevoir des solutions qui fonctionnent de manière asynchrone. En effet, les modèles synchrones conduisent à des goulots d’étranglement de surcharge, à un couplage fort (qui rendent les mises à niveau pénibles) et à des applications utilisateur qui attendent désespérément une réponse du backend.
Avant EventBridge, l’intégration de service à service nécessitait beaucoup de code de colle utilisant Lambda pour appeler des systèmes tiers, gérer les tentatives en cas d’échec, etc. EventBridge le fait pour nous. Depuis son lancement en juillet 2019, de nouvelles fonctionnalités utiles ont été ajoutées au service (comme la possibilité d’appeler une API tierce et la gestion des informations d’identification OAuth dans ce scénario).
Mais dans tous les cas d’utilisation que j’ai pu voir, j’ai toujours pensé qu’il manquait de capacité à enrichir un événement. Imaginez le cas où un client passe une commande : pour la livraison, vous aurez besoin de l’adresse du client. Si le OrderFrontService qui transmet la commande ne la fournit pas, alors le OrderProcessingService qui traite la commande doit obtenir l’adresse du client auprès du CustomerService. Cela implique un certain couplage entre OrderProcessingService et CustomerService. Pour vous débarrasser de cela, vous souhaitez que l’événement « order » soit enrichi par le CustomerService avant d’être consommé par le OrderProcessingService. Voici EventBridge Pipes.
Verified Permissions: les permissions applicatives managées
Une application sans serveur typique implique une application frontale (stockée sur S3, fournie par CloudFront), une passerelle API et un fournisseur d’identité tel que Cognito. L’utilisateur est authentifié sur Cognito afin que l’API Gateway sache qui l’appelle.
Mais l’API Gateway ne sait pas en détail ce que cette personne est autorisée à faire (les claims OAuth permettent de donner des permissions haut-niveau, mais pas au niveau d’objets en particulier. Ainsi, la première étape de tout traitement derrière API Gateway implique actuellement un code personnalisé dans un Lambda pour vérifier si l’utilisateur est autorisé, avant d’exécuter une logique métier. Avec les Verified Permissions, AWS a l’intention de nous aider à nous débarrasser de ce code personnalisé. Je vais m’inscrire pour l’avant-première 🙂
Application Composer : un outil sympa pour les architectes et les développeurs pour discuter plus efficacement
Ce service fournit le chaînon manquant entre les diagrammes d’architecture (que vous utilisiez draw.io, des diagrammes Python ou simplement votre tableau blanc) et l’EDI du développeur
Un gros regret cependant… au moment du lancement, ce service n’est pas compatible avec Terraform. Espérons qu’AWS corrige cette grosse erreur très bientôt. D’ici là, je ne demanderai pas d’accès en avant-première ^^
CodeCatalyst : un anneau pour les gouverner tous ?
Imaginez pouvoir démarrer un projet, y compris la configuration de l’environnement de développement, du référentiel Git, des pipelines CI/CD et des outils de gestion de projet… en quelques minutes ? C’est la promesse derrière CodeCatalyst.
Je ne sais pas à quel point la courbe d’adoption de la famille de codes AWS (CodeCommit, CodePipeline, etc.) a été abrupte jusqu’à présent. AWS n’a pas la réputation d’une excellente interface utilisateur (ils se contentent plutôt de fournir des briques de construction avec lesquelles jouer comme Lego) et la concurrence (à savoir GitHub, c’est-à-dire Microsoft) est féroce.
Presque tous les développeurs de la planète craignent une dépendance vis-à-vis des fournisseurs des Big 2 (désolé Google, mais je crois que vous êtes hors de cette course depuis un certain temps), comme le reflète ma remarque sur Application Composer.
Mais AWS n’est pas habitué à être un challenger sur le terrain de jeu et semble placer l’intégration tierce (jusqu’à présent avec Jira, Github, les fournisseurs IDE) au cœur du produit. Si le produit permet de gérer un environnement de développement hébergé sur un docker local, j’y jetterai un œil. Sinon, je passerai mon tour
Quelques outils intéressants pour la gestion inter-comptes 🙂
Si vous travaillez pour une entreprise suffisamment grande pour avoir plusieurs équipes de développement, ou avec plusieurs unités commerciales comme moi, il est probable que vous utilisiez une zone d’atterrissage multi-comptes classique, avec des comptes de développement/stade/prod pour chaque unité organisationnelle (UO).
Si tel est le cas, eh bien, vous êtes probablement confronté à des limitations vraiment douloureuses lorsque vous travaillez entre comptes.
- Cloudwatch. J’adore CloudWatch. Depuis que je l’utilise, je n’ai jamais voulu utiliser Datadog ou la stack ELK. Mais bon sang, AWS, pourquoi vous a-t-il fallu si longtemps pour pouvoir offrir une observabilité entre comptes ?
- Network Reachability Analyzer. L’analyseur est un excellent outil pour diagnostiquer les problèmes de connectivité réseau entre une source et une destination : pourquoi les analyses de journaux de flux VPC (ce qui peuvent être pénibles) alors que l’analyse statique peut vous orienter vers la règle ACL manquante ? Une limitation importante dans un contexte entre comptes est que l’analyseur avait des limites au niveau des pièces jointes Transit Gateway de chaque compte. Être capable de diagnostiquer via la passerelle sera un véritable gain de temps.
Une déception : DocumentDB Elastic
Mon équipe de développement s’intéresse de plus en plus à DynamoDB. Mais nous avons encore un certain nombre de charges de travail qui utilisent MongoDB et espérons une version sans serveur de DocumentDB (vous savez, tout comme Mongo Atlas propose 0,10 $/million de requêtes).
Le cluster élastique semble plutôt adapté aux clients qui ont besoin d’une échelle élevée et à évolution rapide. Une vraie déception ici.
Plus du point de vue du DSI/CTO
De nos jours, quelques sujets préoccupent fortement le DSI d’une entreprise de services publics de taille moyenne.
- Infrastructure privée et main-d’œuvre en télétravail. Toutes nos charges de travail ne sont pas dans le Cloud. Loin de là ! Et même certaines applications hébergées dans le cloud ne sont pas destinées à être exposées publiquement (ce qui implique de s’assurer qu’elles sont résistantes aux DDOS ou à d’autres attaques telles que l’injection SQL).
Entre-temps, nos propres collègues et les collaborateurs de nos partenaires, y compris les consultants informatiques, travaillent régulièrement à distance. Fournir un accès VPN ou demander une adresse IP fixe (ce qui déplace le fardeau de la fourniture d’un VPN à notre partenaire) pour la liste blanche est toujours fastidieux. À cet égard, AWS Verified Access pourrait changer la donne, en fournissant un accès public, basé sur une autorisation, aux applications privées. - Gestion des données / Analytics / ML. AWS propose un grand nombre d’excellents produits de données. Comme souvent avec AWS, ils se présentent sous forme de briques que vous assemblez plutôt que de produits fermés complets. Cela crée un environnement puissant (et sûr également, puisque les principes de confiance zéro sont partout), mais aussi plus difficile à exploiter que, disons, SnowFlake.
Nous pensons avoir clairement besoin d’un produit unifiant toutes ces solutions individuelles, aidant notre équipe informatique non spécialisée à mettre en place une bonne gouvernance des données et à créer des solutions centrées sur les données. Lors de re:Invent, AWS a annoncé Datazone d’une manière inhabituelle : un communiqué de presse, pas un article de blog sur le service AWS What’s New. Datazone répondra-t-il à nos attentes ?
Prise de recul sur la feuille de route 2022 d’AWS.
Techcrunch a clôturé la re:Invent en titrant « l’ère de l’innovation constante chez Amazon est peut-être révolue ». Même si j’ai eu la même réaction après le re:Invent de l’année dernière, je ne suis plus d’accord.
Oui, peut-être qu’il n’y aura pas beaucoup de concepts radicalement nouveaux dans un avenir proche. Après tout, les applications ne sont que des services et des bases de données, n’est-ce pas ? Se faire passer pour un visionnaire peut convenir à Zuckerberg (et remplir Techcrunch.com de 52 000 résultats de recherche Google sur le « métaverse ») ou à Elon Musk, mais ce n’est pas une garantie de succès. Je préfère être le client d’une entreprise obsédée par mes besoins de changements progressifs 🙂
AWS est un mélange d’IaaS, PaaS et SaaS.
Je pense que le discours d’ouverture de DeSantis susmentionné démontre à quel point AWS est en avance en matière d’IaaS. Les annonces que j’ai mentionnées dans cet article de blog témoignent de leur engagement à construire un excellent PaaS. Quant au SaaS, je trouve assez rassurant qu’aucune entreprise ne puisse être le principal innovateur dans chaque solution spécifique à un secteur… cela laisse du travail pour le reste d’entre nous 🙂
Néanmoins, je suis heureux qu’AWS ait lancé Amazon Omics, une solution dédiée aux chercheurs en génomique. Je peux dire de première main que de nombreuses personnes dans ce domaine, même dans des instituts de recherche célèbres, utilisent toujours NotePad comme IDE.
Où AWS a-t-il déployé ses efforts en 2022 ? Est-ce que re:Invent est un échantillon représentatif ?
Pour avoir une certaine perspective, j’ai récupéré les données du blog Quoi de neuf d’AWS et, pour chaque produit, j’ai comparé le nombre d’annonces faites pendant re:Invent et hors de re:Invent.
Sans surprise, EC2 (avec les nombreuses annonces matérielles) et les produits de données/IA, SageMaker en particulier, sont en tête dans les deux courses. Mais ce qui est plus surprenant, c’est que certains produits ont été totalement sous-couverts lors de re:Invent. Je n’en citerai que 3.
- RDS et Aurora : n’ai-je pas dit avant qu’une application, après tout, n’est que des services qui écrivent et lisent des données à partir d’une base de données ? 🙂 RDS était totalement absent lors de re:Invent. C’est quand même le produit n°3 en termes de nouveautés en 2022 !
- Amazon Connect : la suite de relation client est n°4 avec plus de 60 annonces de fonctionnalités en 2022 rien que pour elle (et cela n’inclut pas les produits associés, comme Lex), mais aucune pendant re:Invent. C’est probablement le signe qu’Amazon estime que la bataille pour l’automatisation du marketing et du contact client peut encore être gagnée.
C’est certainement un domaine que je souhaite approfondir au cours des prochaines années, car je pense que la solution AWS peut être une source de perturbations pour les entreprises qui les adopteront. - EKS/ECS sont #5 sur le podium. Ici, AWS se bat pour conquérir les clients qui n’opteront pas pour le sans serveur par crainte d’une dépendance vis-à-vis d’un fournisseur ou parce qu’ils ont pris la décision stratégique, par souci de simplicité, de tout mettre dans Docker et K8.
Celles-ci confirment, selon moi, le fait qu’AWS renforce les bases de sa pyramide (IaaS et PaaS) et ne se lance dans le SaaS que lorsque les socles techniques sont importants et nécessitent des compétences diversifiées (ex. pour Connect : télécoms, gestion de données et machine learning). ).
C’est tout pour 2022 ! J’ai hâte de voir comment les choses évolueront en 2023 !