Le mouvement « micro » commence à s’imposer dans le centre de données, de l’intérieur vers l’extérieur. Alors que les développeurs commencent à adopter les microservices pour les applications, les architectes réseau se tournent vers la microsegmentation du réseau.
Un mouvement est en marche dans le domaine du développement, plus particulièrement sur le plan architectural. Il tend à privilégier les microservices au détriment des applications monolithiques d’autrefois.
S’appuyant sur des technologies émergentes telles que la conteneurisation et le cloud, les microservices visent à améliorer la stabilité, l’agilité et l’évolutivité en décomposant les applications en services plus petits et spécialisés.
Parallèlement, les architectes réseau suivent la même voie en décomposant les architectures réseau monolithiques en domaines microsegmentés offrant une meilleure prise en compte des applications. Leur objectif ? Garantir la stabilité, l’agilité et l’évolutivité des services réseau, indispensables à la réussite dans une économie fondée sur les applications.
Ensemble, ces micro-évolutions transforment le visage du centre de données, qui se scinde en une architecture à deux niveaux conçue pour offrir agilité, rapidité et fiabilité.
MICROSERVICES
Ce qui était autrefois une application web monolithique comprenant des milliers de lignes de code devient un ensemble de microservices découplés, chacun ne comportant que quelques centaines de lignes de code et étant entièrement dédié à une fonctionnalité particulière.
À première vue, les microservices peuvent sembler n’être qu’une nouvelle variante de la SOA (architecture orientée services), qui prétendait elle aussi décomposer les applications monolithiques en services plus spécialisés. Si ce principe fondamental reste valable, les microservices évitent la superstructure complexe associée à la SOA, permettant ainsi une évolution rapide et agile des services, sans se soucier de leur pérennité ni de leurs dépendances.
L’impact sur la qualité du développement et le pipeline est notable, car un nombre réduit de lignes de code facilite le dépannage, la maintenance et les modifications rapides.
Cela a également une incidence sur l’architecture réseau et les services nécessaires au déploiement des microservices. Une architecture réseau monolithique à un seul niveau ne permettra probablement pas d’offrir l’agilité opérationnelle et l’évolutivité requises pour prendre en charge le déploiement de centaines, voire de milliers, de microservices.
MICROSEGMENTATION
De l’autre côté de la barrière informatique, les architectes réseau remettent parallèlement en question les principes sur lesquels ils ont conçu le réseau. Le cloud et la mobilité ont poussé l’évolutivité des réseaux à ses limites, et les microservices risquent bien d’être la goutte d’eau qui fera déborder le vase. Une nouvelle approche est nécessaire, souvent appelée microsegmentation.
À l’instar des microservices, la microsegmentation est une approche architecturale fondée sur la décomposition, qui divise les services réseau en composants locaux plus faciles à gérer. Initialement proposée comme un modèle de sécurité plus performant, la microsegmentation convient parfaitement à d’autres services étroitement liés aux applications, tels que l’équilibrage de charge, la mise en cache, l’accélération et la sécurité des applications.
En rapprochant ces services, tant physiquement que logiquement, des applications (ou services) dont ils assurent la mise à disposition, l’architecture réseau gagne en agilité et en résilience face aux changements, car ceux-ci restent circonscrits localement à l’application ou au service concerné.
ARCHITECTURE DE CENTRE DE DONNÉES À DEUX NIVEAUX
La combinaison de microservices et de microsegmentation qui en résulte entraîne de fait une scission de l’architecture du centre de données. Les services centraux partagés restent à la périphérie traditionnelle du réseau, tandis que les services propres à chaque application migrent vers l’intérieur, attirés vers le centre de gravité applicatif. Les services centraux partagés, tels que l’accès de l’entreprise via un VPN SSL, la protection du réseau et des applications de l’entreprise contre les attaques DDoS, ainsi que d’autres services similaires, constitueront l’épine dorsale de cette nouvelle architecture à deux niveaux. Les services propres à chaque application, tels que la mise en cache, l’équilibrage de charge et la sécurité applicative, occuperont le deuxième niveau de l’architecture du centre de données.
Une infrastructure dédiée à chaque application (ou à chaque service) permet un couplage logique plus étroit entre les services et les applications auxquelles ils sont destinés. Lorsqu’elle est déployée sous forme logicielle ou virtuelle, elle offre également davantage d’agilité et de contrôle sur l’ensemble du cycle de vie de l’application ou du service. Cela revêt une importance croissante dans un environnement où les microservices peuvent n’avoir qu’une durée de vie de quelques mois, car les services propres à chaque application doivent pouvoir être mis en place et supprimés avec la même rapidité.
Ces services propres à chaque application seront déployés selon une approche de microsegmentation, avec des politiques granulaires régissant des domaines de sécurité et de mise à l’échelle plus restreints et ciblés, définis en fonction de la responsabilité d’un microservice donné ou d’un ensemble de microservices connexes.
Le mouvement des microservices n’en est qu’à ses débuts, mais il prend rapidement de l’ampleur, à mesure que les entreprises nées dans le cloud et celles dotées d’architectures réseau vastes, complexes et souvent difficiles à gérer cherchent de nouvelles façons de simplifier et de faire évoluer les services indispensables à leur réussite.
Les microservices et la microsegmentation permettent d’aligner l’architecture applicative et l’architecture réseau afin de les faire évoluer conjointement tout en accélérant la mise à disposition des applications essentielles à la réussite dans un monde centré sur les applications.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.