J'ai eu l'occasion de me rendre à Londres la semaine dernière pour assister à l'AWS Enterprise Summit (6 juillet) et à l'AWS Summit (7 juillet). En tant qu'ancien d'Amazon (pré-AWS) et de Microsoft Azure, j'ai été fasciné de prendre du recul et de constater l'évolution de cette histoire du « cloud ». Voici quelques points clés que j'ai retenus de ce salon exceptionnel.

#1) Passer au cloud (correctement) signifie adopter une culture DevOps
J'ai vraiment aimé ça Stephen Orban (Responsable de la stratégie d'entreprise mondiale et qui a ouvert le premier jour du Sommet des entreprises avec son discours d'ouverture) a immédiatement insisté sur ce point : votre équipe d'infrastructure DOIT devenir un centre d'excellence Cloud et commencer à distribuer la responsabilité opérationnelle de haut en bas aux é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 chaque jour) dans mes propres conférences, et cela m'a fait réfléchir au fait que c'est maintenant plus de 10 ans depuis qu'il a prononcé dans une interview avec Jim Gray la célèbre (infâme ?) phrase : « vous le construisez, vous le dirigez ». 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 vraiment 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 entreprises de logiciels (c'est-à-dire vous toutes, d'ailleurs) migrent massivement vers le cloud
Cela va au-delà de la phrase impertinente, 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 définit comme une « entreprise technologique » ou une « entreprise de logiciels et d'analyse ») ne se contentent pas de continuer à exploiter des 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 fruits. J'ai particulièrement apprécié tous les plans directeurs, applications et projets de référence que Steven et Werner ont évoqués à différents moments de leurs discours. C'est plutôt encourageant de voir ce changement d'attitude dans le secteur.

Cela a des implications très intéressantes sur la réponse aux incidents. Lors d'une conférence, le directeur technique de FanDuel a souligné que, même si son équipe opérationnelle ne comptait qu'une dizaine de personnes, elle s'appuyait sur le support AWS Enterprise pour assurer le bon fonctionnement de l'entreprise. Restez à l'écoute pour découvrir comment PagerDuty pourrait contribuer à gérer ce type de cas à l'avenir (astuce : utilisez 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, mais le « sans serveur » était un sujet récurrent lors de la conférence. Selon Travelex, le « sans serveur » est « comme jouer avec des lasers et des aimants – tout simplement magique ». Ne vous méprenez pas, chez PagerDuty , nous avons bien plus que des essais : nous avons développé notre nouveau Transformateur d'événements personnalisé Héberger des extraits JS avec AWS Lambda. Mais ne vous laissez pas tromper en pensant que cela revient à investir moins dans l'opérabilité globale, ou que cela permet le fameux #NoOps.

Globalement, inciter vos ingénieurs à consacrer plus de temps à votre activité principale (par exemple, les services générateurs de revenus) était un thème récurrent. Ainsi, une fois que vous avez investi plus de la moitié de vos effectifs dans votre infrastructure, la prochaine étape consiste à développer les bons outils, et non plus à les concevoir correctement. Compte tenu du vaste portefeuille d'AWS, je serai curieux de voir si Amazon envisage d'investir dans la boucle de développement avec des outils de gestion de produits à l'avenir. (Mon collègue a écrit un excellent article de blog sur le sujet et en parle.) être chef de produit dans un monde DevOps . Vous devriez le lire !)

#4) Vos services peuvent avoir besoin d'évoluer : de SOA vers Microservices
Werner a partagé de précieux enseignements sur la première incursion d'Amazon dans l'architecture orientée services (SOA) au début des années 2000. Il a notamment évoqué une organisation trop largement basée sur des ensembles de données (clients, catalogue, etc.) et non sur des caractéristiques fonctionnelles ou de fiabilité/évolutivité. Avec le passage aux microservices, il a également partagé un excellent résumé de « Signs 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 à l'orientation et à l'organisation de votre réponse, c'est pourquoi nous continuons d'investir dans leur mise en place. le bon concept de service dans PagerDuty N'oubliez pas loi de Gall lorsque vous investissez dans vos services :

« On constate invariablement qu'un système complexe qui fonctionne est issu d'un système simple qui fonctionnait. Un système complexe conçu de toutes pièces ne fonctionne jamais et ne peut être corrigé pour fonctionner. Il faut repartir de zéro avec un système simple et fonctionnel.

Mettre un arc dessus
C'est chez Amazon que j'ai commencé mon parcours d'astreinte, j'ai donc presque l'impression de rentrer chez moi (ou plutôt de retourner dans une maison de vacances à 4 800 kilomètres). Le portefeuille AWS est vaste, et pourtant, ils continuent d'innover et de révolutionner le secteur.