Comment le réseau s'adapte aux architectures d'applications en constante évolution

Il y a beaucoup de buzz autour des microservices aujourd’hui. Ils constituent la nouvelle tendance en matière d'architectures d'application et sont souvent mentionnés en conjonction avec leurs meilleurs amis, les conteneurs. Une enquête récente menée par InfoQ a révélé que les deux figuraient en tête de la liste des « utilisateurs ou des utilisateurs prévus », les conteneurs (71,79 % des répondants) surpassant à peine les microservices (70,4 %). Il est intéressant de noter que la même recherche a montré que les microservices étaient aujourd’hui plus utilisés (32,21 %) que les conteneurs (29,44 %).

Quoi qu’il en soit, il semble incontestable que les microservices et les conteneurs sont des technologies qui sont sur le radar de la plupart des organisations.

Cependant, comme pour tout changement significatif dans les architectures d’application, un changement comparable se produit dans le réseau, à mesure que les services d’application et les fonctions réseau s’adaptent pour répondre aux besoins de ces nouvelles architectures d’application. Cela est en partie dû au fait que les changements – en particulier les plus radicaux – dans les architectures d’application modifient les modèles de réseau et s’accompagnent souvent de nouveaux langages, de nouvelles plateformes Web et des défis qui en découlent en matière de sécurité.

Par exemple, le passage d’un système client-serveur à l’application Web traditionnelle à trois niveaux (désormais) a apporté avec lui non seulement un autre niveau dans l’architecture de l’application, mais également un niveau complémentaire d’infrastructure conçu pour fournir l’évolutivité et les performances requises des applications à l’ère de l’Internet en plein essor. Vous vous souvenez peut-être de la croissance soudaine des passerelles XML, des passerelles de sécurité XML, des pare-feu XML et d’autres dispositifs « réseau » associés, axés uniquement sur la résolution des défis découlant de la nouvelle architecture d’application (à l’époque), SOA.

Puis, à mesure que le cloud et le mobile ont commencé à faire connaître leur impact, la sécurité est devenue primordiale et une vague de nouvelles solutions de sécurité réseau est née. Ils étaient axés sur la gestion et la sécurisation des appareils mobiles, y compris les réseaux sur lesquels ces appareils agissaient, ainsi que les courtiers en sécurité d'accès au cloud. Un changement subtil s’est produit ici dans « le réseau » et se fait encore sentir : l’expansion du « réseau » pour inclure, virtuellement, Internet. La dispersion continue des applications dans de multiples environnements sera sans aucun doute compensée par une migration continue des services traditionnellement liés au LAN (notamment la sécurité) vers Internet, « en tant que service ».

Aujourd’hui, nous assistons à l’essor des microservices et des API, principalement RESTful, dans les architectures d’applications. Dans le même temps, l’Internet des objets et la croissance explosive des applications et des utilisateurs humains continuent de stimuler le besoin d’évolutivité, mais aujourd’hui, cette évolutivité est axée sur les opérations.

Le résultat est que le réseau doit (et doit, dans de nombreux cas) réagir en s'efforçant de réaliser une compatibilité architecturale avec les applications (services) qu'il est chargé de mettre à l'échelle, de sécuriser et d'optimiser. Cela signifie adopter des facteurs de forme virtuels et conteneurisés, y compris le cloud, et mettre l’accent sur l’orchestration et l’automatisation. Les modèles, les API et la capacité d'intégration avec les frameworks et les ensembles d'outils qui permettront en fin de compte de mettre les applications en production sont l'objectif d'aujourd'hui.

Le « réseau » réagit. Les API abondent. Les modèles et la prise en charge d'autres systèmes de modèles (OpenStack Heat et AWS Cloud Formation Templates quelqu'un ?) deviennent monnaie courante, tout comme la prise en charge du traitement de l'infrastructure de distribution d'applications « en tant que code ».

Cette adaptation n’est pas comme les adaptations traditionnelles du réseau, où les vitesses et les flux de paquets sont essentiels. Cette dernière adaptation concerne la vitesse de provisionnement et les capacités des API en tant que flux dans le réseau. Il s’agit de se concentrer sur la réalisation de la compatibilité architecturale avec l’architecture de l’application, qu’elle soit déployée dans un cloud public ou privé (sur site), sous la forme d’une application unique et monolithique ou d’un ensemble découplé d’une centaine de microservices.

Ne vous y trompez pas : la mise en réseau est impactée – et même pilotée – par les changements dans les architectures d’application. Il existe une relation symbiotique entre les deux qui ne peut être ignorée, en particulier à l’heure où nous entrons dans une ère axée sur les opérations, dans laquelle la coordination et la coopération sont essentielles pour que les entreprises puissent fournir les applications sur lesquelles elles comptent aujourd’hui pour réussir et se développer.