Dans ce tout premier chapitre, nous allons aborder la philosophie des services AWS. Je vous propose de remonter un peu le temps pour voir ensemble les différentes étapes de l’organisation chez Amazon.
Au début était le monolithe
Amazon a été créée en 1994, et jusqu’en 2001, l’organisation de ses services informatiques était encore basée sur un monolithe, c’est-à-dire une application conçue comme un seul bloc offrant les différentes fonctionnalités nécessaires à l’activité d’Amazon à l’époque : la vente en ligne.
En grandissant, Amazon s’est aperçue qu’une certaine inertie s’était emparée de sa structure, et freinait le processus d’innovation continue. Il fallait retrouver de la souplesse au sein des équipes IT, et par conséquent, réfléchir à quelque chose de différent d’une application de services monolithique, tout en continuant à répondre aux besoins métiers.
Découvrez l'approche microservices
L’idée de base consiste alors à découper le monolithe qui était le site de vente en ligne d’Amazon, en des dizaines de mini-applications ; par exemple :
livraison ;
gestion de la commande ;
facturation ;
recherche ;
affichage des produits.
C’est ce qu’on appelle une architecture orientée en services.
Aujourd’hui encore, sur le site de vente en ligne Amazon, chaque parcelle d’élément que vous visualisez est un microservice :
le bouton “Commande” ;
l’image du produit ;
la description du produit ;
les commentaires ; etc.
Cependant, pour pouvoir mettre en place une telle galaxie de microservices, il fallait que l’organisation des équipes évolue.
Microéquipes : redécoupage des organisations
Dans les années 2000, l’organisation même des équipes d’Amazon n’était pas adaptée à fonctionner avec des centaines d’applications. Pour permettre une fluidité des échanges, l’organisation des équipes devait donc évoluer.
C’est là qu'émerge le concept de Product team. Auparavant, les équipes étaient découpées dans un schéma assez classique :
équipes métiers ;
développeurs ;
testeurs ;
fonction support.
Dorénavant, une approche produit est mise en oeuvre, sur laquelle différents collaborateurs de ces équipes travaillent ensemble.
Une équipe par produit permet une vision horizontale des projets :
Chaque équipe comporte alors un nombre réduit de personnes, ce qu’Amazon appelle une two-pizza team, c’est-à-dire une équipe pouvant être nourrie avec deux pizzas (des grandes pizzas !).
Des équipes réduites et transverses permettent d’accélérer considérablement le temps entre la phase d’identification du besoin et la mise en production, ce qu’on appelle en développement le time to market. La communication est également facilitée.
Toutes les équipes se sont alors organisées comme des fournisseurs de services pour d’autres équipes, du développement du site web jusqu’à la gestion de l’infrastructure consommée par les développeurs.
Et soudain… Amazon Web Services
Petit à petit, l’idée de se mettre à vendre leur propre infrastructure de “service interne” comme un service que le public pourrait consommer, émerge ; tant et si bien qu’en 2006, Amazon lance publiquement la première version d’Amazon Web Services (aussi appelés AWS), avec des services de base comme :
le stockage illimité et à la demande avec S3 (pour Simple Storage Service) ;
les files d’attente de messages avec SQS (pour Simple Queue Service) ;
les machines à la demande avec EC2 (pour Elastic Compute Cloud).
Aujourd’hui encore, AWS améliore et lance de nouveaux services chaque année ; parmi les principaux on retrouvera :
les bases de données à la demande avec RDS (Relational Database Service) ;
le réseau avec les VPC (Virtual Private Cloud) ;
l’équilibrage de charge avec les ELB (Elastic Load Balancer), ALB (Application Load Balancer) et NLB (Network Load Balancer) ;
la surveillance de l’infrastructure avec CloudWatch ;
la gestion des accès à votre infrastructure et entre les services, avec IAM (Identity and Access Management).
Découvrez les services AWS, reflets de l’organisation interne d’Amazon
Vous le constaterez tout au long de vos différentes expériences avec AWS : les composants y sont souvent très hétérogènes. C’est tout à fait normal. Nous l’avons vu, les équipes d’Amazon travaillent en petits groupes, et les choix que ces groupes font sont nécessairement différents.
Chaque composant chez AWS est donc complètement autonome, et géré par une équipe dédiée qui possède sa propre roadmap et ses propres objectifs, fournissant un “service” consommé par d’autres composants AWS, ou bien par le public.
Cela veut-il dire que les services ne fonctionnent pas du tout ensemble ?
Si, bien sûr ! Les services AWS sont tous connectables, car tous exposent ce qu’on appelle une API, pour Application Programming Interface ou Interface de Programmation Applicative. Chaque service présente aux autres services un ensemble de fonctionnalités utilisables entre eux. Lorsqu’une équipe veut utiliser les fonctions d’un autre service, il lui suffit de lire la documentation de l’API correspondante, et d’effectuer des appels à l’API de l’autre service pour l’utiliser.
Configurez des services AWS : un buffet à volonté (ou presque)
Parce qu’il y a désormais énormément de services AWS, vous avez la possibilité de faire des infrastructures sur mesure, piochant à votre guise ce dont vous avez besoin. Par design, tous ces services AWS sont pilotables par API, et vous aurez la possibilité d’exploiter un outil puissant : la programmation.
Vous pouvez donc vous servir du super pouvoir de la programmation pour piloter les différents services de manière complètement automatique, et ce n’est pas le seul avantage de la programmation appliquée à l’infrastructure. Je vous propose de voir la suite dans le chapitre suivant.
En résumé
La flexibilité est mise à l’honneur pour des évolutions plus rapides et efficaces, grâce à des méthodologies comme les microservices, les équipes “two-pizza team” et l’infrastructure à la demande ;
les services AWS peuvent être très différents, car chaque équipe est indépendante ;
les différents services AWS communiquent ensemble à l’aide d’API ;
vous avez la possibilité d’exploiter les API d’Amazon Web Services pour automatiser votre infrastructure.
Maintenant que vous en savez un peu plus sur la philosophie et le fonctionnement de l’architecture Amazon Web Services, je vous propose de rentrer en détail dans le système des API et les avantages de cette automatisation, dans le chapitre suivant.
