La place de F5 dans un monde DevOps
On me demande souvent, après avoir pris la parole lors de conférences, quel est le potentiel de F5 dans la course. Dernièrement, ce sujet est généralement DevOps ou lié à DevOps d’une manière ou d’une autre.
La réalité est que les services liés aux applications, comme l’équilibrage de charge, sont attirés vers les applications , dans l’environnement plus agile, piloté par logiciel et automatisé qui constitue le réseau d’applications. C'est là que les systèmes centrés sur le calcul et les applications, comme les caches (pensez à Memcached et Redis), les bases de données et les conteneurs, sont déployés à l'aide de méthodologies CI/CD (intégration continue/livraison continue) qui reposent sur beaucoup d'automatisation et d'orchestration.
F5 – et plus particulièrement BIG-IP – est presque synonyme d’équilibrage de charge. Nous le faisons depuis avant le début du siècle et de nombreux algorithmes et concepts d’équilibrage de charge de base que vous utilisez aujourd’hui avec d’autres équilibreurs de charge ont en fait été inventés ici. Dire que nous savons une chose ou deux sur l’équilibrage de charge des applications est un euphémisme. Et nous le faisons avec des logiciels déployés sur du matériel sur mesure ou même dans le cloud .
Ce logiciel est activé avec une API. Il s'appelle iControl et est disponible dans les versions SOAP et REST, pour votre commodité de programmation. Cette API permet à quiconque (même moi) de provisionner, de configurer et de contrôler les services d'équilibrage de charge (et autres) d'un BIG-IP pour n'importe quelle application.
Or, comme je l’ai dit, les services axés sur les applications évoluent chaque jour vers l’application. L’évolutivité – l’équilibrage de charge – est l’un de ces services. Il s’agit aujourd’hui d’un composant essentiel pour toute application et, de plus en plus, pour les microservices qui composent les applications modernes. Comme l’a souligné Microsoft dans un document de 2015 sur la mise à l’échelle des services :
En présence de machines diverses et abondantes, le développeur est obligé de réfléchir au partitionnement de la charge de travail de l'application, ainsi qu'à la connectivité réseau nécessaire pour prendre en charge chaque schéma de partitionnement. Un aspect très important de la connectivité existe entre les utilisateurs externes et le service lui-même. À l’exception des plus petits services, une certaine forme de mécanisme d’équilibrage de charge est nécessaire pour répartir la charge des connexions entrantes sur les boîtiers FE. De nombreux mégaservices disposent également de sous-services, qui sont eux-mêmes équilibrés en charge. [soulignement ajouté]
L'équilibrage de charge n'est pas une réflexion après coup ; c'est un complément naturel aux applications et aux services d'aujourd'hui pour permettre l'évolutivité (et la fiabilité) nécessaires pour garder les utilisateurs satisfaits et l'entreprise en activité. Il est donc de plus en plus vrai que l’équilibrage de charge fait partie de l’architecture globale de l’application. Et cela devrait en effet être le cas, car l’ajout d’un composant à l’architecture d’une application peut introduire des problèmes ou des difficultés d’intégration qui doivent être surmontés. Problèmes qui doivent être résolus avant que l’application ne passe en production, et non après. Le temps nécessaire pour trouver et résoudre les problèmes en production est plusieurs fois plus long que dans les environnements de développement ou de test. Par conséquent, l'inclusion de l'équilibrage de charge dans l'architecture de l'application signifie une transition plus fluide (et plus rapide) vers la production et entre les mains des utilisateurs.
Mais cela signifie que vous devez être en mesure d’intégrer l’équilibreur de charge dans les processus automatisés par la chaîne d’outils DevOps qui favorisent de plus en plus l’intégration et la livraison dans les environnements de développement et de test. Il s’agit d’offrir un ensemble complet d’outils de programmation tels que des API et des modèles qui permettent de traiter l’infrastructure comme du code et d’automatiser son provisionnement et sa configuration. C'est ce que fait iControl (REST ou SOAP) pour F5.
Un BIG-IP peut être intégré à DevOps dans les phases de déploiement, de test et de publication en tirant parti de ses API natives en utilisant à peu près n'importe quel langage de votre choix (voici Powershell , Python et Perl) ou via des frameworks comme Chef et Puppet et des outils comme Ansible et SaltStack . iApps , nos modèles qui décrivent une configuration de service d'application, peuvent être traités comme du code : stockez-le dans Github, récupérez-le et déployez-le tel quel ou personnalisez-le avec un script.
Fondamentalement, les services d’application BIG-IP tels que l’équilibrage de charge et bon nombre de ses services de sécurité et de performance des applications doivent être intégrés plus tôt, dans le processus CI/CD, pour garantir que ces services critiques fonctionnent de manière transparente avec l’application, comme prévu.
À terme, nous verrons de plus en plus d’appareils « réseau » traditionnels s’intégrer dans un monde DevOps, car la pression pour déplacer les applications plus rapidement, plus fréquemment et avec moins de perturbations continue de pousser les dirigeants d’entreprise et les responsables informatiques à se lancer tête baissée dans l’économie des applications.
Pour une analyse plus approfondie des outils DevOps que vous pouvez utiliser avec BIG-IP, consultez cet article sur DevCentral « F5 Friday : Outils DevOps et F5 "