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 une évidence, n'est-ce pas ? Après tout, si vous devez vous asseoir devant des applications et agir en tant que proxy pour elles, vous feriez mieux d'être rapide (ou mieux encore, plus rapide) que les applications que vous fournissez. Les ADC traditionnels sont fournis sous forme d'appareils. Châssis, matériel, appareils. Mais les ADC traditionnels ont toujours été limités par les processeurs et le matériel personnalisé avec lesquels ils doivent travailler. Les ADC sont des plates-formes, ils ont donc tendance à se concentrer sur la vitesse générale, tout comme les processeurs à usage général se concentrent sur le traitement général. Mais ils incluent presque toujours une variété d’options d’accélération matérielle qui doivent être déterminées avant le déploiement. Nous sommes peut-être fous, mais nous pensons qu’un ADC prêt pour le cloud devrait pouvoir dépasser cette limitation, en comprenant qu’une application peut avoir besoin d’un service plus qu’un autre, tandis qu’une autre application peut avoir besoin d’un autre service plus qu’un autre. Tout comme l’idée même de réutilisation des ressources de calcul à la demande qui sous-tend l’ensemble du concept de cloud computing, les organisations qui investissent dans du matériel de toute sorte devraient également pouvoir le réutiliser.

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 devrait aller plus loin. Il est probable qu'ils soient l'un des rares « appareils » inclus dans l'architecture de l'application elle-même, afin de garantir l'évolutivité inévitable requise par les applications d'aujourd'hui. Il est donc logique de se concentrer sur la sécurité de la pile complète. Du moins, c’est ce que nous pensons, d’autant plus que cela favorise la performance. Si vous devez vous arrêter pour effectuer un certain type de traitement, il est logique d’en faire autant que possible en même temps. C'est plus efficace et élimine la latence nécessaire pour voyager d'une boîte à l'autre. Si vous avez parcouru de longues distances avec des enfants, vous savez de quoi je parle. Il y a des toilettes à la station-service. Vous ne voudriez pas vous arrêter à nouveau sur une aire de repos cinq minutes plus tard, n’est-ce pas ? Même chose avec la sécurité dans le réseau. Faites tout ce que vous pouvez à la fois pour éliminer les frais généraux qui sont souvent une source de frustration pour les clients et l’entreprise. Les performances sont essentielles et un ADC prêt pour le cloud doit faire tout ce qu'il peut pour garantir des expériences d'application 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.