Comment AWS développe elle-même des logiciels •

re: Inventer Comment AWS développe-t-il des logiciels ? Il s’agit de petites équipes, selon une session discrète mais révélatrice de la conférence re:Invent en cours à Las Vegas.

Sous le titre “La culture DevOps d’Amazon”, Leo Zhadanovsky, qui est Chief Technologist, Education, et Alyssa Lee, Customer Success Lead for AI and ML, ont décrit ce que l’entreprise considère comme ses meilleures pratiques pour créer, tester, déployer et maintenir “des applications modernes”. .”

Ce que j’ai entendu, c’est que notre panier était un script Perl de 40 000 lignes

“De toute évidence, Amazon étant de sa taille, il y aura des éléments qui ne s’appliqueront pas à votre entreprise… nous ne disons en aucun cas, c’est comme ça que vous le faites, c’est juste ce que nous faisons”, a déclaré Lee.

Qu’est-ce qu’une application moderne ? Zhadanovsky a décrit à quoi ressemblait le site de commerce électronique Amazon.com à l’époque pré-AWS. “À la fin des années 90, c’était une application monolithique avec des équipes monolithiques qui la soutenaient. Ce que j’ai entendu, c’est que notre panier était un script Perl de 40 000 lignes.” Quelqu’un appelé Greg était le développeur du logiciel, a déclaré Zhadanovsky, et il s’appelait GregPOS.cgi, pour Greg Point of Sale. “Puis Greg est parti et quelqu’un d’autre a maintenu ce script Perl de 40 000 lignes et la signification de POS a changé.”

“Ce que nous avons appris, c’est de décomposer la fragilité, de décomposer les services monolithiques en microservices et d’ajuster la taille des équipes pour prendre en charge ces services plus petits.”

L’automatisation est également essentielle. “Pour vraiment évoluer, vous devez tout automatiser. Cela inclut votre infrastructure”, a-t-il déclaré, faisant référence à l’importance de définir l’infrastructure en tant que code. Maintenir l’infrastructure en tant que code demande de la discipline. Si des modifications d’urgence sont effectuées manuellement, de sorte que le déploiement ne correspond plus à la définition, “maintenant, nous avons peur de mettre à jour notre pile car cela pourrait tout casser”, a déclaré Zhadanovsky. “Nous voulons éviter cela.”

Une équipe est généralement composée de 6 à 15 personnes, ont déclaré Lee et Zhadanovsky, également connues sous le nom de “deux équipes de pizza”, et dispose d’une grande autonomie, par exemple, sur le langage de programmation à utiliser. “Mais nous avons des outils standard pour l’intégration continue, la livraison continue, le contrôle de version, car nous avons constaté qu’il n’y a pas beaucoup de valeur à avoir différents outils pour cela”, a ajouté Zhadanovsky.

Il existe également une bibliothèque de modèles pour les types d’applications courants afin qu'”un développeur puisse itérer à partir de cela [best practice] au lieu de partir de zéro », a-t-il déclaré.

Comment Amazon a-t-il procédé pour décomposer ses applications en microservices ? “Nous avons décidé de les décomposer en fonction de facteurs d’échelle et non de fonctions”, a déclaré Zhadanovsky. Les facteurs de mise à l’échelle sont des éléments tels que la quantité de stockage utilisée, le débit du réseau ou la demande de processeur. La logique est que si un service devient un goulot d’étranglement, il peut facilement être étendu.

“Même si je construis un service interne, vous devez réfléchir à la façon dont je peux le faire évoluer ?” dit Jadanovski. “Il pourrait soit être largement adopté en interne, soit devenir un service externe. Un grand nombre de nos services désormais exposés étaient auparavant des services internes.”

Chaque service doit fonctionner de manière indépendante. “Il y a un e-mail que Jeff Bezos a envoyé disant qu’à cette date, tous les services doivent communiquer entre eux via des API”, a déclaré Zhadanovsky. Si un service a besoin de données d’un autre service, “Je ne suis pas autorisé à exécuter une requête sur ces données. C’est incontrôlé. Vous pouvez avoir toutes sortes de problèmes de disponibilité, des problèmes de sécurité à partir de là. Ce que je dois faire, c’est parler à ce service API.”

L’API est un contrat, a-t-il dit, qui doit respecter son seuil de performance. “Si ce n’est pas le cas, cela déclenche des alarmes.”

Cela signifie également que le service cible peut remplacer une base de données par une autre ou utiliser un autre système de file d’attente. “Cela n’a pas d’importance parce que je parle juste via l’API.”

Lee a décrit comment les équipes sont formées. L’objectif est d’éviter la paralysie décisionnelle causée par trop de personnes ayant des responsabilités qui se chevauchent, a-t-elle déclaré. “Ce que nous faisons chez Amazon, c’est supprimer ce problème en créant ce que nous appelons des” propriétaires à un seul thread “… chaque équipe a un expert dans chaque domaine.” Cela signifie que “lorsque vous avez un problème dans l’un de ces domaines, vous savez exactement à qui vous adresser”.

Les équipes possèdent tout ce qui est construit en interne chez AWS

Amazon publie ses principes de leadership et “nous vivons et respirons selon ces principes de leadership”, a déclaré Lee.

Une personne n’est affectée qu’à une seule équipe, mais “nous avons des petites communautés internes de personnes passionnées par certains domaines… J’aurais peut-être besoin de quelqu’un pour m’aider avec la sécurité mais je n’ai pas mon contact de sécurité disponible, je vais envoyer un message comme dans Slack et j’aurai quelqu’un qui ne fait pas partie de notre équipe qui viendra m’aider », a déclaré Lee.

Qu’en est-il de toutes les dépendances entre les services ? Que se passe-t-il si une API change ? “De par leur conception, nous n’apportons pas de modifications radicales à nos API”, a déclaré Zhadanovsky. “Nous ajoutons seulement.” C’est similaire à la façon dont les services publics sont gérés. “Je peux probablement compter sur une main le nombre de fois où nous avons déprécié une API”, a-t-il déclaré.

Qu’arrive-t-il aux petites équipes à mesure que les produits et services deviennent plus gros et plus complexes ? “Au fur et à mesure que vous ajoutez des choses, vous ne voulez pas que votre équipe devienne trop grande”, a déclaré Zhadanovsky. “Alors tu le brises.”

Prenez S3 (Simple Storage Service), par exemple, qui a ajouté un grand nombre de fonctionnalités depuis sa première apparition il y a des décennies. “Si vous regardez quelles sont les différentes fonctionnalités de S3, il y a probablement une équipe à deux pizzas dans toutes les principales catégories de fonctionnalités.”

Comment la qualité, la sécurité et la cohérence des services sont-elles maintenues compte tenu de l’autonomie de chaque équipe ? Avant qu’un service ou une fonctionnalité ne soit lancé, il doit passer par un processus d’examen, ont été informés les participants. “Nous avons des ingénieurs principaux qui forment une petite communauté d’ingénieurs logiciels très expérimentés, et leur travail consiste à conseiller d’autres équipes et à diffuser les meilleures pratiques”, a déclaré Zhadanovsky. “Ils font un examen de l’architecture pendant la planification et avant le lancement pour s’assurer qu’ils suivent les meilleures pratiques.

“Nous avons une application obligatoire [security] avis… s’ils ont des résultats avec votre service, il n’est pas lancé tant que les résultats ne sont pas corrigés.

Il existe également une revue des opérations (OR). “Il évolue en fonction des problèmes que nous avons rencontrés. Nous cataloguons les enseignements tirés des problèmes que nous avons rencontrés et développons OU afin que la prochaine fois nous puissions les éviter.”

Si nous avons un problème avec Java, nous pouvons demander à James Gosling

Les ingénieurs principaux sont également disponibles pour aider avec des questions spécialisées et incluent quelques grands noms. “Nous avons James Gosling, le créateur de Java. C’est un ingénieur distingué, qui est un niveau au-dessus du principal. Vous allez vers lui si vous avez des questions sur Java.”

Les revues hebdomadaires des opérations inter-équipes explorent tous les problèmes opérationnels de la semaine précédente, et s’il n’y en a pas de gros, analysez les journaux du service d’une équipe aléatoire pour voir ce qui pourrait être amélioré.

Lee et Zhadanovsky ont déclaré qu’il existe un parti pris pour le sans serveur chez AWS. “Vous ne voulez pas gérer le système d’exploitation”, a déclaré Zhadanovsky. Le déploiement continu est un objectif. “En 2019, nous avons effectué 60 millions de déploiements dans toute l’entreprise… un déploiement peut être une ligne de code qui a changé.” Les déploiements peuvent échouer et cela est compris. “Nous ralentissons intentionnellement le déploiement”, a-t-il déclaré. Il y a des déploiements “canaris”, pour les tests initiaux, puis une région, puis une autre région. “À tout moment, vous pouvez vous arrêter et reculer”, a-t-il déclaré.

Un autre objectif est d’éviter ce que Zhadanovsky a appelé la sécurité de la coquille d’œuf. “J’ai vu beaucoup de clients chez qui ils ont une sécurité de niveau coquille d’œuf, un extérieur dur et un intérieur doux. Si vous passez à travers le pare-feu, vous pouvez vous déplacer n’importe où. Nous ne voulons pas cela. Une application moderne signifie que vous avez sécurité intégrée à chaque niveau, et chaque microservice gère sa propre sécurité. Nous n’avons plus besoin de choses comme les VPN, nous n’avons aucune confiance.

Ce sont des principes qui fonctionnent pour Amazon, et il était rafraîchissant d’entendre l’entreprise plaider en faveur des microservices à un moment où l’approche monolithique fait un retour en force. Le géant du cloud présente cependant certains avantages, notamment l’accès interne à ses propres services sans que chaque fonctionnalité ne s’ajoute à la facture mensuelle. Et Gosling à portée de main pour répondre aux requêtes Java. ®