L'ADC compatible avec le cloud

Un contrôleur de distribution d'applications (ADC) compatible avec le cloud n'est pas un ADC traditionnel. Disponible pour un déploiement sur du matériel personnalisé ou COTS, il s'agit d'une solution logicielle évolutive qui répond à la fois au besoin de distribution et de déploiement rapides, sécurisés et disponibles des applications. Un ADC prêt pour le cloud permet une approche moderne à deux niveaux des architectures de centres de données combinant la stabilité, la sécurité et l'évolutivité traditionnelles avec des fonctionnalités programmatiques modernes, flexibles, adaptées au cloud et à DevOps.

C'est une belle description, mais qu'est-ce que cela signifie ?

J'ai déjà écrit sur ce qu'il faut pour être considéré comme un proxy d'application moderne et cela fait certainement partie de ce dont un ADC prêt pour le cloud a besoin, mais les environnements exigeants d'aujourd'hui nécessitent plus que de simples capacités techniques, ils nécessitent une intégration opérationnelle et écosystémique et la capacité de prendre en charge les architectures d'application modernes et émergentes.

Et honnêtement, il existe de nombreux ADC qui feraient les mêmes déclarations en matière de préparation au cloud et de prise en charge des architectures d’applications traditionnelles et émergentes, entre autres déclarations. Aujourd’hui, j’aimerais donc examiner en détail ce qui différencie un ADC compatible avec le cloud d’un ADC traditionnel, avant d’approfondir la raison pour laquelle il est si important dans le monde des applications d’aujourd’hui.

Cinq degrés de différenciation

Il existe essentiellement cinq (six si vous voulez être vraiment pédant) façons différentes par lesquelles un ADC compatible avec le cloud se différencie d'un ADC traditionnel. Et comme F5 a défini à peu près ce que devrait être un ADC bien avant que je sois ici, nous comprenons en quelque sorte l'ADC mieux que quiconque. À la fois ce qu'ils devaient être et ce qu'ils doivent faire évoluer pour continuer à fournir des applications avec la rapidité, la sécurité et la stabilité dont l'entreprise a besoin.

Performance

C'est évident, n'est-ce pas ? Si vous devez gérer des applications en les relayant, vous devez être aussi rapide — voire plus rapide — que les applications que vous diffusez. Les ADC traditionnels se présentent sous forme d’équipements. Châssis, matériel, appareils. Pourtant, les ADC traditionnels restent limités par les processeurs des équipements personnalisés qu’ils utilisent. Les ADC sont des plateformes centrées sur la rapidité globale, tout comme les processeurs généraux favorisent un traitement généraliste. Ils intègrent presque toujours plusieurs options d’accélération matérielle qu’il faut choisir avant le déploiement. Nous pensons qu’un ADC conçu pour le cloud doit dépasser ces limites, en s’adaptant aux besoins spécifiques de chaque application, qui peut privilégier un service plutôt qu’un autre. À l’image du concept même de réaffectation des ressources informatiques à la demande qui fonde le cloud computing, vous devriez pouvoir réutiliser tout matériel dans lequel vous investissez.

La raison pour laquelle cela est important dans les services superposés au réseau est que le déchargement des tâches courantes vers un matériel spécifique (FPGA) signifie que le processeur est libéré pour faire d'autres choses, comme l'inspection des requêtes/réponses, la modification, le nettoyage, etc. Cela accélère l'ensemble de l'« arrêt » au proxy, ce qui se traduit par une latence plus faible et des utilisateurs plus satisfaits.

C’est pourquoi un ADC compatible avec le cloud peut briser les barrières, en tirant parti des performances définies par logiciel et en permettant aux organisations d’augmenter par programmation les performances de l’ADC pour certains types de traitement, comme la sécurité. Cela signifie que si les besoins de l'organisation changent, le profil de performance de ce matériel peut être modifié en même temps, à la demande. C’est ça l’agilité matérielle. Je sais, paradoxal, non ? Mais cela fait partie du fait d’être un ADC prêt pour le cloud ; la capacité de réutiliser du matériel spécialisé afin de protéger les investissements et d’éliminer le besoin de mises à niveau coûteuses et fastidieuses.

Programmabilité

Une frustration de longue date que j’ai personnellement entendue à maintes reprises de la part de mes clients est la discorde entre NetOps et DevOps en ce qui concerne les capacités de script. Le problème est que l’ADC traditionnel n’offrait que les scripts les plus basiques, et dans des langages plus familiers à NetOps, pas à DevOps. Désormais, DevOps était prêt à apprendre à tirer parti des scripts dans le chemin de données, car cela permettait une variété de routages de demandes/réponses plus agiles, de stratégies de mise à l’échelle et même de services de sécurité. Mais avec l'ADC traditionnel installé en amont, dans le réseau central, NetOps n'était pas prêt à laisser DevOps déployer des scripts susceptibles de perturber le flux de trafic.

La disponibilité des éditions virtuelles signifiait que DevOps avait désormais accès à son propre ADC personnel et privé sous la forme d'une machine virtuelle, mais ils étaient toujours obligés d'apprendre un langage de script en réseau. Ce n’est pas une bonne chose. Un ADC prêt pour le cloud doit prendre en charge à la fois NetOps dans le réseau principal et DevOps dans le réseau d'applications, comme dans le cloud. Et DevOps et les développeurs en particulier préfèrent les langages plus conviviaux pour les développeurs, comme node.js. Non seulement parce qu'ils connaissent la langue, mais un riche référentiel de bibliothèques (comme NPM ) et de services existe déjà pour permettre une intégration plus rapide avec une infrastructure adaptée aux développeurs. C'est pourquoi un ADC prêt pour le cloud doit prendre en charge les deux.

Sécurité des applications

Les ADC traditionnels assurent depuis longtemps la sécurité des applications de base. Être assis devant une application, en particulier les applications Web, signifie qu'elles étaient (et sont toujours) généralement la première chose dans le centre de données à pouvoir reconnaître une attaque et à y remédier. La majeure partie de cette sécurité tournait, naturellement, autour de la sécurité au niveau du protocole. La protection contre les inondations SYN, la détection DDoS et d’autres options de sécurité de base liées à TCP et HTTP font partie intégrante des ADC traditionnels depuis un certain temps maintenant.

Mais un ADC prêt pour le cloud doit aller plus loin. Il sera probablement l’un des rares « appareils » intégrés dans l’architecture de l’application elle-même, afin d’assurer l’échelle inévitable nécessaire aux applications actuelles. Il est donc logique de concentrer l’attention sur la sécurité complète de la pile. Nous le pensons en tout cas, surtout parce que cela favorise la performance. Si vous devez impérativement interrompre un type de traitement, profitez-en pour en faire autant que possible en une seule fois. C’est plus efficace et cela supprime la latence liée aux allers-retours entre unités. Si vous avez voyagé longtemps avec des enfants, vous voyez très bien ce que je veux dire. Il y a une toilette à la station-service. Vous ne souhaitez pas vous arrêter à nouveau dans cinq minutes à une aire de repos, n’est-ce pas ? C’est la même chose pour la sécurité dans le réseau. Faites le maximum en une fois pour éliminer les surcharges qui frustrent souvent clients et entreprises. La performance est cruciale, et un ADC prêt pour le cloud doit tout faire 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’exigence) de prise en charge des communications sécurisées entre les appareils mobiles et les applications. Cela signifie la prise en charge du Forward Secrecy (FS) et de la cryptographie qui le permet. Cela signifie permettre de nouveaux modèles permettant de décharger le traitement coûteux en calcul du chiffrement et du déchiffrement sur le matériel conçu pour le gérer, sans perturber 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 les deux, permettant des communications rapides et sécurisées tout en s'intégrant de manière transparente dans les architectures et les environnements cloud d'aujourd'hui.

Écosystème de partenaires et automatisation

L’économie des autres API est essentielle au succès du cloud privé et à l’avantage concurrentiel conféré aux entreprises par l’augmentation de l’automatisation et de l’orchestration. Mais aussi agréable soit-il, il y aura toujours une variété de services dans le centre de données provenant de différents fournisseurs, tous avec des modèles d'intégration et d'objet différents. Cela implique souvent une automatisation fastidieuse basée sur des API qui nécessite une expertise dans tous les composants nécessaires. La réalité est qu’il y a deux niveaux d’intégration requis, un pour l’orchestration et un pour l’automatisation (non, ce n’est pas la même chose) . Il y a les capacités d'automatisation inhérentes à la plateforme, via des API et des modèles, puis il y a l'intégration native dans l'écosystème des partenaires, où l'orchestration règne en maître. Les deux sont nécessaires pour un ADC prêt pour le cloud. Le premier assure l'automatisation via des produits propriétaires ou des scripts et frameworks personnalisés comme 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 et proposer une orchestration native via les frameworks et les systèmes utilisés pour fournir une solution d'orchestration complète.

Il n’est pas nécessaire de répéter plus d’une fois qu’un ADC prêt pour le cloud doit prendre en charge les modèles cloud.

Voilà donc tout ce que j’ai à dire à ce sujet.

Modèle d'application

Les ADC traditionnels sont nés du besoin d’offrir un ensemble robuste de services pour les applications traditionnelles. Des monolithes, en quelque sorte. Les applications d’aujourd’hui sont de plus en plus distribuées, diversifiées et différentes de leurs prédécesseurs traditionnels, exploitant une variété d’architectures, de plates-formes et de modèles de déploiement. Qu'il s'agisse de conteneurs ou de machines virtuelles, d'environnements cloud ou de type cloud, les applications ont toujours besoin de certains de ces services. Et lorsqu'il est nécessaire de disposer de plusieurs services à la fois (comme par exemple l'équilibrage de charge et la sécurité des applications), vous aurez alors besoin d'un ADC. Bien qu'un ADC traditionnel ne soit peut-être pas adapté aux microservices, un ADC compatible avec le cloud le sera. Cela inclut un ensemble plus large de services qui peuvent bénéficier de l'équilibrage de charge et de la sécurité, des services qui relèvent directement du domaine de DevOps, et non de NetOps, comme Memcached .

Bien qu'il s'agisse toujours d'une plateforme, un ADC prêt pour le cloud prend néanmoins en charge les exigences de programmabilité, d'intégration et de facteur de forme nécessaires pour fournir les services dont les applications traditionnelles et émergentes ont besoin, dans l'environnement dont elles ont besoin.

Il existe de nombreuses similitudes entre un ADC traditionnel et un ADC compatible avec le cloud. Tous deux restent des plateformes, capables de fournir plusieurs services avec un modèle opérationnel commun. Les deux sont programmables, s’intègrent à d’autres systèmes de centres de données et de cloud et offrent une flexibilité en termes de capacités de performances. Mais un ADC prêt pour le cloud va au-delà du traditionnel, prenant en charge les deux tout en permettant l'avenir des entreprises, des applications et de leurs besoins de plus en plus diversifiés d'intégration et d'interopérabilité avec une grande variété d'infrastructures et d'environnements.