L’ADC prêt pour le cloud

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Un contrôleur de mise à disposition d’applications (ADC) adapté au cloud n’est pas un ADC traditionnel. Déployable sur du matériel personnalisé ou standard (COTS), il s’agit d’une solution logicielle évolutive qui répond aux besoins de rapidité, de sécurité et de disponibilité en matière de mise à disposition et de déploiement des applications. Un ADC adapté au cloud permet d’adopter une approche moderne à deux niveaux pour les architectures de centres de données, alliant la stabilité, la sécurité et l’évolutivité traditionnelles à des fonctionnalités programmatiques modernes, flexibles, adaptées au cloud et compatibles avec les pratiques DevOps.

C’est une belle description, mais qu’est-ce que cela veut dire concrètement ?

J’ai déjà expliqué ce qu’il fallait pour être considéré comme un proxy d’applications moderne et cela fait assurément partie des exigences auxquelles doit répondre un ADC prêt pour le cloud. Mais les environnements exigeants d’aujourd’hui ne se contentent pas de capacités techniques : ils nécessitent également une intégration opérationnelle et écosystémique, ainsi que la capacité à prendre en charge les architectures applicatives modernes et émergentes.

Et honnêtement, de nombreux ADC sur le marché pourraient eux aussi affirmer être prêts pour le cloud et prendre en charge aussi bien les architectures applicatives traditionnelles qu’émergentes, entre autres arguments. Aujourd’hui, j’aimerais donc examiner en détail ce qui distingue un ADC prêt pour le cloud d’un ADC traditionnel, avant d’approfondir les raisons pour lesquelles il est si important dans le paysage applicatif actuel.

Cinq degrés de différenciation

Il existe essentiellement cinq façons différentes — six, si l’on veut vraiment être pointilleux — pour un ADC adapté au cloud de se distinguer d’un ADC traditionnel. Et puisque F5 a pour ainsi dire défini ce que devait être un ADC bien avant mon arrivée, nous comprenons les ADC mieux que quiconque : aussi bien ce qu’ils devaient être que ce qu’ils doivent devenir pour continuer à fournir des applications avec la rapidité, la sécurité et la stabilité dont les entreprises ont besoin.

Performances

Cela va de soi, non ? Après tout, si vous devez vous placer devant les applications et leur servir de proxy, vous avez intérêt à être aussi rapide (voire, mieux encore, plus rapide) que les applications que vous fournissez. Les ADC traditionnels sont proposés sous forme d’appliances : châssis, matériel, équipements dédiés. Ils restent toutefois limités par les processeurs du matériel sur mesure qu’ils utilisent. Les ADC étant des plateformes, ils ont tendance à privilégier les performances globales, tout comme les processeurs généralistes privilégient le traitement généraliste. Mais ils intègrent presque toujours diverses options d’accélération matérielle qui doivent être définies avant le déploiement. C’est peut-être une idée folle, mais nous pensons qu’un ADC adapté au cloud devrait pouvoir dépasser cette limite, en tenant compte du fait qu’une application peut avoir davantage besoin d’un service qu’une autre, tandis qu’une autre application peut avoir davantage besoin d’un autre service. À l’image même de la réaffectation à la demande des ressources de calcul, qui sous-tend tout le concept du cloud computing, les entreprises qui investissent dans du matériel, quel qu’il soit, devraient elles aussi pouvoir le réaffecter.

Si cela est important pour les services superposés au réseau, c’est parce que le fait de décharger les tâches courantes sur du matériel dédié (FPGA) libère le processeur, qui peut alors se consacrer à d’autres opérations, telles que l’inspection, la modification et le nettoyage des requêtes et des réponses, etc. Le « passage » par le proxy est ainsi globalement plus rapide, ce qui se traduit par une latence réduite et des utilisateurs plus satisfaits.

C’est pourquoi un ADC prêt pour le cloud peut repousser les limites en tirant parti de performances définies par logiciel et en permettant aux entreprises d’accroître par programmation les performances de l’ADC pour certains types de traitement, notamment en matière de sécurité. Ainsi, si les besoins de l’entreprise évoluent, le profil de performances de ce matériel peut être adapté à la demande. C’est cela, l’agilité matérielle. Je sais, c’est paradoxal, non ? Mais c’est aussi ce qui caractérise un ADC prêt pour le cloud : la possibilité de réaffecter du matériel spécialisé afin de protéger les investissements et d’éviter de coûteuses mises à niveau nécessitant le remplacement complet des équipements.

Programmabilité

Une frustration de longue date, dont les clients m’ont personnellement fait part à maintes reprises, tient au désaccord entre les équipes NetOps et DevOps en matière de capacités de script. Le problème est que l’ADC traditionnel n’offrait que des fonctionnalités de script très rudimentaires, dans des langages plus familiers aux équipes NetOps qu’aux équipes DevOps. Ces dernières étaient pourtant prêtes à se former afin de tirer parti des scripts dans le chemin de données, car ceux-ci permettaient de mettre en œuvre un routage plus agile des requêtes et des réponses, diverses stratégies de mise à l’échelle, voire des services de sécurité. Mais l’ADC traditionnel étant solidement installé en amont, au cœur du réseau, les équipes NetOps n’étaient pas disposées à laisser les équipes DevOps déployer des scripts susceptibles de perturber le flux du trafic.

Grâce à la disponibilité d’éditions virtuelles, les équipes DevOps avaient désormais accès à leur propre ADC privé et personnel sous la forme d’une machine virtuelle, mais elles étaient toujours contraintes d’apprendre un langage de script orienté réseau. Ce n’est pas une bonne chose. Un ADC adapté au cloud doit prendre en charge à la fois les équipes NetOps sur le réseau central et les équipes DevOps sur le réseau applicatif, notamment dans le cloud. Or, les équipes DevOps, et les développeurs en particulier, préfèrent des langages plus adaptés au développement, comme node.js. Pas seulement parce qu’ils les maîtrisent, mais aussi parce qu’il existe déjà un vaste référentiel de bibliothèques (comme NPM) et de services permettant une intégration plus rapide avec des infrastructures adaptées aux développeurs. C’est pourquoi un ADC adapté au cloud doit répondre aux besoins des deux équipes.

Sécurité des applications

Les ADC traditionnels assurent depuis longtemps une sécurité de base des applications. Placés en amont d’une application, en particulier d’une application web, ils étaient — et sont toujours — généralement les premiers éléments du centre de données capables de détecter une attaque et d’y réagir. L’essentiel de cette sécurité portait, à juste titre, sur la sécurité au niveau des protocoles. La protection contre les attaques par inondation SYN, la détection des attaques DDoS et d’autres options de sécurité liées à TCP et aux fonctions HTTP de base font depuis longtemps partie intégrante des ADC traditionnels.

Mais un ADC adapté au cloud doit aller plus loin. Il sera probablement l’un des rares « dispositifs » intégrés à l’architecture même de l’application afin d’assurer l’inévitable mise à l’échelle requise par les applications actuelles. Il est donc tout à fait logique d’accorder la même attention à la sécurité de l’ensemble de la pile. C’est du moins notre avis, d’autant plus que cette approche améliore les performances. Puisqu’il faut interrompre le flux pour effectuer un type de traitement, autant en réaliser le plus possible au même moment. C’est plus efficace et cela élimine la latence liée au passage successif d’un équipement à l’autre. Si vous avez déjà parcouru de longues distances avec des enfants, vous voyez de quoi je parle. Il y a des toilettes à la station-service. Vous n’avez pas envie de vous arrêter de nouveau sur une aire de repos cinq minutes plus tard, n’est-ce pas ? Il en va de même pour la sécurité du réseau. Effectuez autant d’opérations que possible en une seule fois afin de réduire les surcoûts, souvent source de frustration tant pour les clients que pour l’entreprise. Les performances sont essentielles, et un ADC adapté au cloud doit tout mettre en œuvre pour offrir des expériences applicatives plus rapides.

Cela peut impliquer de proposer de nouveaux modèles pour gérer la demande croissante (et, dans certains cas, l’obligation) de prendre en charge des communications sécurisées entre les appareils mobiles et les applications. Cela implique de prendre en charge la confidentialité persistante (FS) et les mécanismes cryptographiques qui la rendent possible. Il faut également proposer de nouveaux modèles permettant de décharger les opérations de chiffrement et de déchiffrement, très gourmandes en ressources de calcul, vers du matériel conçu à cet effet, sans compromettre les architectures nécessaires à la prise en charge des microservices et des applications émergentes. Un ADC prêt pour le cloud doit prendre en charge ces deux aspects afin de permettre des communications à la fois rapides et sécurisées, tout en s’intégrant parfaitement aux architectures et aux environnements cloud actuels.

Écosystème de partenaires et automatisation

L’autre économie des API est essentielle à la réussite du cloud privé et à l’avantage concurrentiel que les entreprises tirent du développement de l’automatisation et de l’orchestration. Mais, aussi souhaitable que cela puisse être, le centre de données comportera toujours une multitude de services provenant de différents fournisseurs, chacun avec ses propres modèles d’intégration et d’objets. Cela se traduit souvent par une automatisation complexe pilotée par API, qui exige une expertise sur chaque composant nécessaire. En réalité, deux niveaux d’intégration sont requis : l’un pour l’orchestration et l’autre pour l’automatisation (non, ce n’est pas la même chose). Il y a, d’une part, les capacités d’automatisation intrinsèques de la plateforme, accessibles via des API et des modèles, et, d’autre part, l’intégration native à l’écosystème de partenaires, où l’orchestration règne en maître. Ces deux aspects sont indispensables à un ADC prêt pour le cloud. Le premier assure l’automatisation au moyen de produits propriétaires ou de scripts personnalisés et de frameworks tels que Puppet et Chef, tandis que le second permet l’orchestration via des contrôleurs de plus en plus importants comme OpenStack, VMware et Cisco.

Un ADC prêt pour le cloud doit s’intégrer nativement aux frameworks et systèmes utilisés, et permettre leur orchestration afin de fournir une solution d’orchestration complète.

Il ne devrait pas être nécessaire de répéter qu’un ADC prêt pour le cloud doit prendre en charge les modèles cloud.

Voilà, je n’en dirai pas plus à ce sujet.

Modèle d’application

Les ADC traditionnels sont nés de la nécessité d’offrir un ensemble robuste de services aux applications traditionnelles. Des monolithes, si vous préférez. Les applications actuelles sont de plus en plus distribuées, diversifiées et différentes de leurs prédécesseurs traditionnels, et s’appuient sur une variété d’architectures, de plateformes et de modèles de déploiement. Qu’il s’agisse de conteneurs ou de machines virtuelles, d’environnements cloud ou similaires au cloud, les applications ont toujours besoin de certains de ces services. Et dès lors que plusieurs services sont nécessaires simultanément (par exemple, l’équilibrage de charge et la sécurité des applications), un ADC devient indispensable. Si un ADC traditionnel n’est pas forcément adapté aux microservices, un ADC conçu pour le cloud le sera. Cela inclut un éventail plus large de services susceptibles de bénéficier de l’équilibrage de charge et de la sécurité, des services qui relèvent clairement du domaine des devops, et non des netops, comme memcached.

Tout en restant une plateforme, un ADC adapté au cloud répond néanmoins aux exigences de programmabilité, d’intégration et de format nécessaires pour fournir aux applications traditionnelles comme émergentes les services dont elles ont besoin, dans l’environnement qui leur convient.

Un ADC traditionnel et un ADC prêt pour le cloud présentent de nombreuses similitudes. Tous deux restent des plateformes capables de fournir plusieurs services selon un modèle opérationnel commun. Tous deux sont programmables, s’intègrent à d’autres systèmes de centre de données et de cloud, et offrent une grande souplesse en matière de performances. Mais un ADC prêt pour le cloud va au-delà des solutions traditionnelles : il les prend en charge tout en préparant l’avenir des entreprises et des applications, ainsi que leur besoin croissant de s’intégrer et d’interagir avec une grande variété d’infrastructures et d’environnements.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

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 Vittie