Monolithes versus microservices
Les microservices (et leurs meilleurs amis, les conteneurs, souvent cités) commencent à conquérir le cœur et l’esprit des développeurs à tous les niveaux. Ce ne sont pas seulement les startups qui adoptent les principes de conception granulaire, faiblement couplés et basés uniquement sur les API des microservices ; les grandes entreprises se lancent également dans le jeu.
Avec l'adoption croissante ( Datadog , un fournisseur de surveillance d'infrastructure cloud, a connu une croissance presque quintuplée au cours des 12 mois depuis septembre 2014), on entend des cris très vocaux déclarant la mort des applications monolithiques et leur architecture totalement inappropriée comme étant non seulement obsolète, mais tout simplement mauvaise.
Mais comme l’a noté un article récent sur Gigaom , il y a des compromis qui doivent être pris en compte avant de sortir le marteau-piqueur et de briser chaque monolithique en une centaine de microservices différents. Ce n’est d’ailleurs pas un concept nouveau. Le père des microservices, Martin Fowler, a écrit sur ces compromis il y a longtemps et a mis en garde contre ce qui ne peut être considéré que comme une « adoption aveugle » des microservices. En fait, l’article de Gigaom présente généralement les mêmes points que Fowler, mais dans un format plus concis.
Si vous cherchez le TL;DR sur les deux, cela se résume essentiellement à ceci : les microservices ajoutent de la complexité opérationnelle et peuvent avoir un impact négatif sur l’expérience de l’application en termes de performances. Ces deux conséquences sont indésirables – et souvent involontaires – et doivent être comprises en amont, avant que ce type là-bas dans votre centre de données ne commence à utiliser le marteau-piqueur allégorique.
Cela dit, pourquoi diable Lori s’en soucie-t-elle ? Après tout, ni elle ni F5 ne sont dans le domaine de la création ou de la conception d’applications. F5 va fournir ces applications, qu’il s’agisse de monolithes, de microservices ou de la prochaine architecture d’application ici>.
Tout est vrai. Mais notre activité consiste à créer et à déployer les services applicatifs qui fournissent ces applications et les mouvements récents comme DevOps et les microservices (et la fièvre des conteneurs) posent les mêmes questions à notre domaine. Autrement dit, devriez-vous décomposer les services d’application généralement déployés sur une plate-forme ADC en services plus granulaires et affines aux applications dans un modèle qui s’aligne plus étroitement sur l’architecture des microservices ?
Toujours une question de compromis
Qu’il s’agisse d’architecture d’application ou d’architecture de service d’application, la réponse reste la suivante : il faut comprendre les compromis impliqués avant de prendre une telle décision.
L'approche de la plateforme (monolithique)
Il s’agit de l’approche traditionnelle pour fournir les services d’application nécessaires pour sécuriser, faire évoluer et optimiser les applications de tous types. Les services sont déployés sur une plateforme unique et partagée. En raison de l’architecture du proxy sous-jacent, cette approche présente l’avantage d’améliorer les performances. C’est parce que toutes les requêtes (et réponses) peuvent traverser les services requis sans quitter le même environnement. Cela signifie qu'aucun saut de réseau supplémentaire (et la latence associée) ou connexion (ressources, latence) n'est nécessaire. Chaque service peut toujours être mis à l’échelle et géré individuellement, mais ils dépendent tous d’un seul matériel partagé (COTS ou personnalisé). Cela signifie que le matériel partagé est un point de défaillance unique qui aura un impact non pas sur un, mais sur plusieurs services.
L'approche proxy par application (microservices)
Ce modèle s’aligne davantage sur DevOps et les pratiques architecturales d’applications émergentes. Chaque service est déployé, géré et mis à l’échelle individuellement. Bien que cela entraîne des coûts administratifs supplémentaires (il y a après tout plus d’instances à gérer), certains de ces coûts sont atténués si chaque service est déployé sur la même plateforme, mais offre la possibilité de « mélanger et d’associer » des services de différents fournisseurs. L’avantage de cette approche est que les services peuvent être plus étroitement associés à l’architecture de l’application – et donc inclus dans celle-ci – y compris l’intégration avec les cadres d’automatisation populaires.
Les mêmes inconvénients – à savoir ceux liés aux performances et à la complexité croissante – sont associés à la décomposition de la distribution d’applications en ses services applicatifs composites. À l’inverse, les mêmes raisons pour lesquelles les développeurs adoptent les microservices et évitent les monolithes – à savoir le désir d’agilité, de diversité et de modularité – sont également valables pour la distribution d’applications.
Je vais simplement citer Martin Fowler : « De nombreuses équipes de développement ont constaté que le style architectural des microservices était une approche supérieure à une architecture monolithique. Mais d’autres équipes ont constaté qu’ils constituaient un fardeau qui sapait leur productivité. Comme tout style architectural, les microservices apportent des coûts et des avantages. Pour faire un choix éclairé, vous devez comprendre ces principes et les appliquer à votre contexte spécifique.
Cette affirmation s’applique également aux services d’application. Les approches traditionnelles (monolithiques) et modernes (microservices) présentent toutes deux des coûts et des avantages qui doivent être pris en compte dans le contexte de l’application qu’elles vont fournir, sécuriser et optimiser.