Construire des systèmes logiciels évolutifs est une stratégie, pas une religion. Et revisiter vos architectures avec un esprit ouvert s’impose.
Les architectures logicielles ne ressemblent pas aux architectures des ponts et des maisons. Une fois qu’un pont est construit, il est difficile, voire impossible, de modifier la façon dont il a été construit. Le logiciel est assez différent : une fois que nous exécutons notre logiciel, nous pouvons obtenir des informations sur nos charges de travail que nous n’avions pas lors de sa conception. Et si nous l’avions compris dès le départ et choisi une architecture évolutive, nous pourrions changer de composants sans impacter l’expérience client. Ma règle générale est qu’à chaque ordre de grandeur de croissance, vous devez revoir votre architecture et déterminer si elle peut toujours prendre en charge le niveau de croissance suivant.
Un bon exemple peut être trouvé dans deux articles de blog perspicaces rédigés par les équipes d’ingénierie de Prime Video. Le décrit pour la première fois comment la diffusion en direct de Thursday Night Football est construit autour d’une architecture de flux de travail distribué. La seconde est une article récent qui plonge dans l’architecture de leur outil de surveillance de flux, et comment leur expérience et leur analyse les ont poussés à la mettre en œuvre en tant qu’architecture monolithique. Il n’existe pas de solution universelle. Nous encourageons toujours nos ingénieurs à trouver la meilleure solution, et aucun style architectural particulier n’est imposé. Si vous embauchez les meilleurs ingénieurs, vous devez leur faire confiance pour prendre les meilleures décisions.
J’exhorte toujours les constructeurs à considérer l’évolution de leurs systèmes au fil du temps et à s’assurer que les fondations sont telles que vous puissiez les modifier et les étendre avec un minimum de dépendances. Les architectures événementielles (EDA) et les microservices conviennent parfaitement à cela. Cependant, s’il existe un ensemble de services qui contribuent toujours à la réponse, ont exactement les mêmes exigences d’évolutivité et de performances, les mêmes vecteurs de sécurité et, surtout, sont gérés par une seule équipe, il vaut la peine de voir s’il est possible de les combiner. simplifie votre architecture.
Les architectures évolutives sont quelque chose qui nous tient à cœur chez Amazon depuis le début. Réévaluer et réarchitecturer nos systèmes pour répondre aux demandes toujours croissantes de nos clients. Vous pouvez remonter jusqu’en 1998, lorsqu’un groupe d’ingénieurs supérieurs a rédigé le Manifeste sur l’informatique distribuée, qui a mis les roues en mouvement pour faire passer Amazon d’une architecture monolithique à une architecture orientée services. Au cours des décennies qui ont suivi, les choses ont continué à évoluer, à mesure que nous sommes passés aux microservices, puis aux microservices sur infrastructure partagée, et à mesure que J’en ai parlé à re:InventEDA.
Le passage à des systèmes autonomes découplés était une évolution naturelle. Les microservices sont plus petits et plus faciles à gérer, ils peuvent utiliser des piles technologiques qui répondent aux exigences de leur entreprise, les temps de déploiement sont plus courts, les développeurs peuvent monter en puissance plus rapidement, de nouveaux composants peuvent être déployés sans affecter l’ensemble du système et, plus important encore, si un déploiement prend fin. un microservice, le reste du système continue de fonctionner. Lorsque le service revient en ligne, il rejoue les événements manqués et les exécute. C’est ce que nous appelons une architecture évolutive. Il peut facilement être modifié au fil du temps. Vous commencez avec quelque chose de petit et lui permettez de devenir plus complexe pour correspondre à votre vision.
Amazon S3 est un merveilleux exemple de service qui est passé de quelques microservices depuis son lancement en 2006 à plus de 300 microservices, avec des méthodologies de stockage, des mécanismes de politique et des classes de stockage supplémentaires. Cela n’a été possible que grâce à l’évolutivité de l’architecture, qui constitue un facteur essentiel lors de la conception de systèmes.
Cependant, je tiens à réitérer que il n’y a pas un modèle architectural pour les gouverner tous. La façon dont vous choisissez de développer, de déployer et de gérer les services dépendra toujours du produit que vous concevez, des compétences de l’équipe qui le construit et de l’expérience que vous souhaitez offrir aux clients (et bien sûr d’éléments tels que le coût, la rapidité, et résilience). Par exemple, une startup composée de cinq ingénieurs peut choisir une architecture monolithique car elle est plus facile à déployer et ne nécessite pas que sa petite équipe apprenne plusieurs langages de programmation. Leurs besoins sont fondamentalement différents de ceux d’une entreprise comptant des dizaines d’équipes d’ingénierie, chacune gérant un sous-service individuel. Et ça va. Il s’agit de choisir les bons outils pour le travail.
Il existe peu de portes à sens unique. Évaluer régulièrement vos systèmes est aussi important, sinon plus, que de les construire en premier lieu. Parce que vos systèmes fonctionneront bien plus longtemps que le temps nécessaire à leur conception. Ainsi, les monolithes ne sont pas morts (bien au contraire), mais les architectures évolutives jouent un rôle de plus en plus important dans un paysage technologique en évolution, et cela est possible grâce aux technologies cloud.
Maintenant, allez construire !
