La semaine dernière, j’ai eu l’occasion de me rendre à Londres pour assister à l’AWS Enterprise Summit (6 juillet) et à l’AWS Summit (7 juillet). En tant qu’ancien élève d’Amazon (pré-AWS) et de Microsoft Azure, c’était fascinant de prendre du recul et de voir à quel point cette histoire du « cloud » a évolué. Voici quelques points clés que j’ai retenus de ce grand salon.

#1) Passer au cloud (correctement) signifie adopter une culture DevOps
J'ai vraiment aimé ça Stephen Orban (Directeur de la stratégie d'entreprise mondiale et qui a ouvert le discours d'ouverture du premier jour de l'Enterprise Summit) a immédiatement souligné ce point : votre équipe d'infrastructure DOIT devenir un centre d'excellence Cloud et commencer à répartir la responsabilité opérationnelle de haut en bas entre les équipes Produits/Services, l'équipe informatique interne et l'équipe de support de bureau.

Je cite souvent Dr Werner Wogels (CTO d'Amazon.com et qui a prononcé un discours par jour) dans mes propres conférences, et cela m'a fait réfléchir au fait que c'est maintenant plus de 10 ans puisqu'il a dit dans une interview avec Jim Gray la célèbre (infâme ?) phrase : « vous le construisez, vous le gérez ». Mais je toujours préfacer cela avec ce qu’il a dit juste avant cela (c’est moi qui souligne) : « Offrir aux développeurs responsabilités opérationnelles a considérablement amélioré la QUALITÉ des services, tant du point de vue client que technologique. « Je crois sincèrement que c'est la raison pour laquelle Amazon.com et AWS continuent de connaître autant de succès, et c'est le cœur de ce que représente la culture DevOps.

#2) Les sociétés de logiciels (c'est-à-dire vous toutes, d'ailleurs) migrent en masse vers le cloud
Cela va au-delà de la phrase effrontée souvent citée lors des conférences « Les amis ne laissent pas leurs amis construire des centres de données ». Des entreprises comme GE (qui se considèrent comme une « entreprise technologique » ou une « entreprise de logiciels et d’analyse ») ne se contentent pas de continuer à exploiter les systèmes Mode 1 comme elles l’ont toujours fait, elles ferment activement des centres de données (30 sur 34 dans le monde) et commencent à en récolter les bénéfices. J’ai particulièrement aimé tous les plans directeurs/applications et projets de référence que Steven et Werner ont soulignés à différents moments de leurs discours. C’est plutôt cool de voir ce changement d’attitude dans l’industrie.

Cela a des implications vraiment intéressantes sur la réponse aux incidents. Dans un discours, le CTO de FanDuel a souligné que même si leur équipe opérationnelle ne comptait qu'environ 10 personnes, ils comptaient sur AWS Enterprise Support pour les aider à faire fonctionner les choses. Restez à l'écoute pour savoir comment PagerDuty pourrait vous aider à gérer ce type de cas à l'avenir (indice : utiliser le Mobilisateur de réponse ).

#3) Il est temps d’aller au-delà des infrastructures
C'est facile à dire et beaucoup plus difficile à réaliser, le passage au « sans serveur » était certainement un sujet fréquent lors de la conférence. Selon Travelex, le sans serveur, c'est « comme jouer avec des lasers et des aimants – juste de la magie ». Ne vous méprenez pas, chez PagerDuty, nous avons plus que simplement essayé : nous avons construit notre nouveau Transformateur d'événements personnalisé pour héberger des extraits JS à l'aide d'AWS Lambda. Mais ne vous laissez pas tromper en pensant que cela signifie moins d'investissement dans l'opérabilité globale, ou que cela permet en quelque sorte le légendaire #NoOps.

Dans l'ensemble, amener vos ingénieurs à consacrer plus de temps à votre activité réelle (par exemple, les services qui génèrent des revenus) était un thème récurrent. Ainsi, une fois que vous avez dépassé la moitié de votre personnel investi dans votre infrastructure, la prochaine étape consiste à savoir comment construire le bon matériel, et non comment le construire correctement. Avec le vaste portefeuille d'AWS, je serai curieux de voir si Amazon envisage d'investir dans la fermeture de cette boucle de développement avec certains outils de gestion de produits à l'avenir. (Mon collègue a un excellent article de blog connexe et parle de Être chef de produit dans un monde DevOps . Tu devrais le lire !)

#4) Vos services peuvent avoir besoin d'évoluer : du SOA aux microservices
Werner a partagé un ensemble d’enseignements intéressants sur la première incursion d’Amazon dans l’architecture orientée services (SOA) au début des années 2000. Il a notamment mentionné une organisation trop fortement basée sur des ensembles de données (clients, catalogue, etc.) et non sur des caractéristiques de fonction ou de fiabilité/évolutivité. Avec le passage aux microservices, il a également partagé un fantastique résumé de « Certains signes indiquant que vous n’êtes pas encore au niveau des microservices » :

Photo avec l'aimable autorisation de Denise Yu : https://twitter.com/deniseyu21/status/750993932591521793 .

Cette évolution des services a également un impact profond sur votre flux de travail de réponse aux incidents. Ils sont essentiels à la manière dont vous orientez et organisez votre réponse, c'est pourquoi nous continuons à investir dans la mise en place le bon concept de service dans PagerDuty N'oubliez pas Loi de Gall lorsque vous investissez dans vos services :

« « Un système complexe qui fonctionne est invariablement le résultat d’une évolution d’un système simple qui fonctionnait. Un système complexe conçu de toutes pièces ne fonctionne jamais et ne peut pas être réparé pour le faire fonctionner. Il faut repartir à zéro avec un système simple qui fonctionne. »

Mettre un arc dessus
C'est sur Amazon que mon parcours de travail d'astreinte a commencé, j'ai donc presque l'impression de rentrer chez moi (ou plutôt de retourner dans une maison de vacances à 3 000 miles de là). Le portefeuille AWS est vaste, et pourtant, ils continuent d'innover et de changer le visage de l'industrie.