On attend toujours avec impatience le moment où se déroule peut-être la keynote la plus intéressante d’AWS re:Invent : celle de Werner Vogels, CTO d’Amazon. Lors de l’édition 2024, il est monté sur scène vêtu d’un T-shirt de Linkin Park.
Au cours de sa présentation, M. Vogels s’est penché sur un problème courant dans le domaine de la technologie : comment gérer la complexité croissante des systèmes tout en préservant la facilité d’utilisation pour l’utilisateur final ? Le thème de son discours était la « simplexité », a-t-il expliqué.
Une simplicité difficile
« La simplicité n’est pas simple », a déclaré M. Vogels. Alors que des services comme Amazon S3 et DynamoDB tiennent la promesse de la simplicité pour les utilisateurs, sous le capot, ces systèmes se sont transformés en écosystèmes extrêmement complexes. M. Vogels appelle ce phénomène la « simplexité » : il s’agit de construire des systèmes complexes qui restent simples malgré leur complexité.
Il illustre son propos par un exemple : Le service S3 d’Amazon, lancé en 2006, était à l’origine un service de stockage assez simple. Aujourd’hui, S3 traite des milliards de requêtes par jour, a une forte cohérence et utilise des architectures microservices qui fonctionnent ensemble de manière transparente. Conclusion ? La complexité est inévitable, mais elle doit être délibérée.
Dans les oiseaux, il fait référence à la « loi du filin », c’est-à-dire à l’idée que la complexité ne peut être évitée, mais qu’elle peut être déplacée. Chez AWS, cette loi est appliquée en concentrant la complexité là où elle a le plus de valeur, par exemple dans le back-end de S3 pour assurer une forte cohérence. Cela allège le fardeau des clients et leur évite d’avoir à gérer eux-mêmes cette complexité.
L’évolutivité est le premier critère
« Faites de l’évolutivité une exigence dès le premier jour », souligne M. Vogels. Lors de la conception d’un logiciel, les organisations doivent tenir compte de l’évolutivité et de l’évolution des besoins. M. Vogels définit l’évolutivité comme « la capacité d’un système à supporter facilement les changements futurs ».
Le passage des architectures monolithiques aux microservices en est un exemple. Dans les premières années d’AWS, les applications étaient constituées de grands systèmes intégrés. Aujourd’hui, des milliers de microservices fonctionnent indépendamment les uns des autres, ce qui accélère l’innovation. « Tout changement d’échelle nécessite une refonte de votre architecture », explique M. Vogels.
lire aussi
Re:Invent 2024 : AWS se concentre entièrement sur l’IA
Deux pizzas et des architectures cellulaires
L’une des innovations les plus emblématiques d’Amazon est la « règle des deux pizzas » : les équipes doivent être suffisamment petites pour ne recevoir que deux pizzas. Ce concept a donné naissance à des équipes autonomes capables d’innover rapidement sans dépendre d’autres équipes ou de supérieurs.
La deuxième innovation emblématique d’AWS est l’architecture cellulaire, où les systèmes sont divisés en cellules indépendantes. Cela permet de limiter l’impact des défaillances à une seule cellule, ce qui rend le système dans son ensemble plus résistant à ces défaillances. Des cas clients tels que Route 53 et CloudFront montrent comment AWS répartit les demandes des clients entre les cellules grâce à des algorithmes intelligents.
Leçons pour l’avenir
Le Dr Vogels conclut par six leçons clés : il faut garder les systèmes simples :
- Construisez des systèmes capables d’évoluer. Rester immobile, c’est reculer.
- Décomposer la complexité en éléments plus petits. De petits composants gérables facilitent la gestion.
- Adapter les systèmes aux besoins de l’entreprise. Pour ce faire, utilisez des principes tels que la règle KISS (« Keep It Simple, Stupid »).
- Organiser le travail en cellules. Les architectures cellulaires permettent d’isoler les défaillances.
- Anticipez la complexité involontaire. Veillez à ce que les systèmes soient prévisibles, flexibles et compréhensibles. Cela réduit la marge d’erreur.
- Automatisez. L’automatisation devrait être la norme, au moins dans les cas où aucune capacité humaine importante n’est requise.