Coup de projecteur sur l'open source : Infrastructure F5 en tant que code et gestion multi-cloud
Vous avez peut-être remarqué qu’un élément important du mantra du multicloud est la facilité de gestion. C'est parce que la tâche de mise à l'échelle, de sécurisation et de livraison d'applications aux utilisateurs nécessite un certain ensemble de services : équilibreurs de charge, calcul, stockage, sécurité des applications. Et même si le cloud peut (il le fait) rendre le processus de provisionnement de ces services beaucoup plus facile, il le fait au détriment des opérations. Malheureusement, cela déplace la complexité ailleurs.
Si c’est vous qui fournissez ces services, c’est parfait. Mais si c’est vous qui devez configurer, modifier et gérer les services, ce n’est pas si cool.
Parce que la complexité rend la gestion plus difficile. Aucun cloud n’est identique (en termes d’API et de services) et cela signifie souvent deux modèles opérationnels complètement distincts avec lesquels les utilisateurs doivent désormais composer.
La facilité de gestion est donc un élément essentiel de la réussite du multicloud.
L’une des façons dont les organisations peuvent y parvenir est d’adopter des structures qui simplifient les déploiements. Ceux-ci se présentent de plus en plus sous la forme d'une sorte de modèle : OpenStack HEAT, AWS Cloud Formation et Azure ARM me viennent à l’esprit. Ces modèles codifient l’essentiel d’un déploiement BIG-IP en termes de configuration spécifique qui doit être mise en place afin de faire tourner la valeur réelle d’un BIG-IP : ses services.
Les modèles sont l’un des meilleurs exemples d’infrastructure en tant que code (IAC). C’est parce qu’ils peuvent être traités exactement comme des artefacts de code. Ils peuvent être versionnés, ramifiés, fusionnés, récupérés, clonés et finalement déployés.
Ce modèle correspond bien à la vision orientée DevOps du cloud et de la gestion via des API et des langages de script. Après tout, si DevOps peut étendre son influence à NetOps et, en retour, déployer rapidement des services en utilisant une approche IAC, tout le monde est content. C’est exactement ce que le médecin a ordonné, étant donné que le manque de tels services de la part de NetOps influence considérablement les décisions de DevOps de contourner l’informatique lorsqu’il s’agit de cloud.
La prise en charge de la gestion multicloud est exactement ce que nous (l’entreprise actuelle) avions envisagé lorsque nous avons commencé à développer des modèles pour OpenStack, AWS et Azure. Permettre une approche IAC pour offrir une plus grande agilité et rapidité est la raison pour laquelle ces modèles sont disponibles gratuitement via GitHub.
Parce que nos déploiements en laboratoire ne sont pas vos déploiements et ils ne sont pas non plus ceux de cet autre gars (dans la rangée derrière vous, lisant par-dessus votre épaule). Les déploiements partagent un ensemble commun de caractéristiques, mais toutes les applications ont des besoins spécifiques qui ne peuvent pas être satisfaits avec la même configuration de service standardisée. L'équilibrage de charge Round Robin peut être suffisant pour les applications sans état basées sur des microservices, mais il peut être terriblement inefficace (sans parler du coût) pour d'autres architectures application , en particulier dans les environnements cloud. Vous avez besoin de la liberté d’adapter et d’optimiser les performances des applications et de garantir la sécurité des données et la sécurité des interactions des utilisateurs.
Vous devez être en mesure d'extraire, de cloner et de valider ces artefacts dans vos propres référentiels afin de pouvoir bénéficier des avantages d'une approche NetOps qui inclut IAC pour déployer autant de votre base de services que possible, sur autant d'environnements cloud que possible.
Alors extrayez, clonez, validez et déployez selon votre calendrier, que ce soit trois fois par jour ou trois fois par trimestre. C'est open source et l'accès est toujours ouvert.