L'agence nationale de la sécurité des SI sort enfin du bois ! Ses recommandations en matière de GenAI étaient attendues. Pas de surprise, mais un ensemble pertinent, à garder en tête.
Réflexion sur la question de savoir si l'approche architecturale des microservices triomphe toujours des monolithes, en utilisant le cas récent d'Amazon Prime Video comme exemple.
Nous avons tous été captivés par le grand débat du monde de l'architecture, un débat qui nous oblige à nous interroger, à réfléchir et à réévaluer notre compréhension : microservices contre monolithes. Récemment, le vent a semblé tourner avec un billet de blog de l'équipe d'Amazon Prime Video expliquant comment elle a échangé des services AWS sans serveur contre un "monolithe" conteneurisé, ce qui lui a permis de réaliser des réductions de coûts significatives. Méthodiquement, nous allons décortiquer cela, en essayant de comprendre ce que cela signifie réellement pour ceux qui naviguent dans le monde de l'architecture complexe.
Un retour vers les monolithes ?
Le cas d'Amazon Prime Video ne doit pas induire en erreur. Malgré les hypothèses initiales, l'ensemble de Prime Video n'est pas devenu un monolithe. Au contraire, la transition a été réalisée par la seule équipe d'analyse de la qualité vidéo (VQA). S'attaquant à une fonctionnalité particulière, ils semblaient cibler le modèle fondamental d'un microservice - un service indépendant, communiquant via des API bien définies, géré par une équipe autonome.
Explorer l'équilibre : microservices, monolithes et nanoservices
Cependant, un aspect important a été négligé. Le paradoxe représente un obstacle classique sur la voie du développement d'applications nouvelles. En substance, l'équipe a exploré les nanoservices - en décomposant leur fonctionnalité jusqu'au point où une restructuration est devenue essentielle. Cela souligne l'équilibre insaisissable entre le déploiement d'un monolithe, de microservices et de nanoservices, un trio qu'il est assez difficile de prévoir lors du développement de nouvelles applications.
Naviguer dans l'architecture des logiciels et des solutions
Pour contrebalancer cette situation imprévisible, il est essentiel de distinguer l'architecture logicielle de l'architecture de solution. La première s'articule autour de l'organisation du code, tandis que la seconde concerne la manière dont le code est déployé. Souvent, l'architecture de la solution, avec son découpage en microservices, est prédéfinie, ce qui conduit à des équipes isolées et à des processus d'écriture de logiciels distincts. Cette approche, bien qu'adaptée à des éléments intimement séparés, peut être préjudiciable lorsqu'elle est utilisée à outrance en raison d'une optimisation prématurée.
Les étapes vers l'agilité : flexibilité dans le déploiement et le développement
Une approche plus agile émerge alors, une méthode où les préoccupations d'organisation du code et de la communication sont distinctes du déploiement du code et des canaux de communication. Envisagez un processus plus nuancé : écrivez tout sous forme de nanoservices, mais déployez-les d'abord comme un monolithe, à moins qu'une logique claire n'en décide autrement. L'essentiel est d'être capable de s'adapter et de remanier si nécessaire, en s'appuyant sur une série de principes tels que la dissimulation d'informations, la moindre connaissance, la responsabilité unique, la cohésion élevée, le faible couplage, l'inversion des dépendances, la séparation des interfaces, la substitution de Liskov, l'ouverture et la fermeture, et la séparation des préoccupations.
Ces cadres directeurs aident à façonner le logiciel indépendamment de son déploiement, une compétence vitale surtout à une époque où les architectures de solutions cloud, les conteneurs et le serverless dominent l'industrie. Cependant, nous devons nous rappeler qu'il ne faut jamais oublier d'assurer l'architecture du logiciel au sein de ces solutions.
Ne pas tomber dans le piège d'une optimisation prématurée
Le cas d'Amazon Prime Video offre une nouvelle occasion de réfléchir à la manière dont nous équilibrons les microservices, les monolithes et les nanoservices. Il souligne la nécessité d'adopter des stratégies d'architecture adaptables, capables de répondre de manière transparente à nos exigences en matière de logiciels et de structures de solutions, afin de ne pas tomber dans le piège d'une optimisation prématurée. Et bien que l'équilibre puisse sembler insaisissable, avec un mélange de principes bien définis et un état d'esprit agile, on peut être en mesure de naviguer dans ces eaux troubles. Le prochain sujet à l'horizon - Comment ces principes façonnent les logiciels - attend notre attention.
