Le cloud hybride concrétisé : F5, Azure et Azure Stack
Introduction
De nos jours, de nombreux services informatiques subissent la pression des équipes dirigeantes pour abandonner le caractère statique des centres de données internes traditionnels au profit d’architectures plus dynamiques, axées sur le cloud, afin de gagner en agilité, en flexibilité et en évolutivité tout en réduisant les coûts d’exploitation. Et comme les clouds publics et privés présentent chacun des avantages et des inconvénients, environ 71 %1 (https://www.f5.com/resources/white-papers/hybrid-cloud-realized-f5-azure-and-azure-stack#footnote01) des entreprises mettent en œuvre des modèles hybrides afin de profiter d’un plus grand nombre d’avantages tout en éliminant bon nombre des inconvénients. Cependant, la quasi-totalité de ces organisations s’appuie pour cela sur des infrastructures cloud et des services applicatifs hétérogènes, ce qui accroît considérablement la complexité pour les équipes pluridisciplinaires chargées de concevoir et de gérer ces déploiements.
Principaux cas d’usage du cloud hybride
Relier deux environnements cloud distincts (ou plus) pour créer un cloud hybride présente non seulement des avantages en matière d’agilité, de flexibilité et d’évolutivité, mais permet également de mettre en œuvre toute une série de cas d’usage spécialisés qui seraient autrement bien plus difficiles, voire impossibles, à réaliser. Les plus courants sont sans doute les suivants :
Haute disponibilité (HA) et reprise après sinistre (DR)
La mise en place et la maintenance d’une sauvegarde de cloud privé à haute disponibilité et géographiquement redondante, afin d’éviter toute interruption des applications essentielles, sont très coûteuses et doubleraient probablement l’investissement nécessaire à l’exploitation d’un seul cloud privé. Il faudrait non seulement deux fois plus de matériel physique, mais aussi un centre de données distinct, disposant de sa propre alimentation électrique, de son propre système de refroidissement et de son propre personnel, dans une zone géographique différente.
À l’inverse, les environnements de haute disponibilité (HA) et de reprise après sinistre (DR) peuvent être hébergés dans le cloud public pour une fraction du coût. Les données applicatives sont stockées à chaque sauvegarde depuis le cloud privé, tandis que les ressources applicatives et réseau restent en veille jusqu’à ce qu’elles soient nécessaires, par exemple en cas de sinistre ou de défaillance du cloud privé. Le cas échéant, ces applications et ressources sont déployées et mises en service à partir des données stockées, garantissant ainsi la disponibilité des applications et la continuité des activités.
Développement et test d’applications
Le développement d’une nouvelle application dans un cloud privé peut s’avérer nettement plus coûteux que dans le cloud public. Il nécessite un investissement initial pour exécuter la charge de travail, sans aucune garantie que l’application fonctionnera ou sera adoptée sur le marché actuel. C’est pourquoi les entreprises suivent le principe « échouer vite, échouer à moindre coût » en utilisant les capacités à la demande du cloud public pour développer et tester de nouvelles applications, puis les exécuter en production. Une fois leur fiabilité opérationnelle établie ou leur adoption généralisée par les utilisateurs constatée, les applications peuvent être migrées vers le cloud privé, qui peut offrir une meilleure sécurité et s’avérer moins coûteux à exploiter sur le long terme. Elles peuvent également rester dans le cloud public et être déployées dans un environnement à plus long terme et plus économique, en recourant notamment à des instances réservées moins coûteuses.
Débordement vers le cloud
Souvent considéré comme la fonctionnalité la plus recherchée du cloud hybride, le cloud bursting est probablement la plus difficile à mettre en œuvre et devient fréquemment le défi insaisissable de nombreuses stratégies de cloud hybride. Avec le cloud bursting, une application s’exécute principalement dans le cloud privé. Lorsque la demande dépasse les capacités disponibles, les requêtes supplémentaires sont redirigées vers une réplique exacte exécutée dans le cloud public sur une infrastructure louée. Il s’agit toutefois d’une situation temporaire, destinée à absorber les pics de trafic imprévus de courte durée. Lorsque les périodes de forte affluence se prolongent, les entreprises peuvent augmenter la capacité de leur cloud privé.
La configuration d’un environnement de cloud hybride pour le cloud bursting est par nature difficile et complexe. Elle nécessite une synergie entre les deux environnements, ainsi qu’une orchestration à toute épreuve afin que la redirection s’effectue de manière autonome et fluide, avec peu ou pas d’incidence sur l’expérience des utilisateurs finaux. La tâche des équipes chargées de la configuration et de la gestion se complique davantage lorsque l’infrastructure, les services et les outils utilisés pour exécuter et prendre en charge les applications diffèrent d’un environnement à l’autre.
Homogénéité : la clé du succès du cloud hybride
Vous ne serez sans doute pas surpris d’apprendre que tous les clouds ne se ressemblent pas. Chacun possède sa propre infrastructure, ses propres services réseau et applicatifs, ses outils de développement, son interface utilisateur et ses éléments distinctifs par rapport aux offres cloud concurrentes. Par exemple, il est beaucoup plus facile pour les utilisateurs de SharePoint, Exchange, SQL Server ou d’autres technologies Microsoft de migrer vers Microsoft Azure que vers AWS ou Google Cloud. Ces différences entre les plateformes et les services entraînent des incompatibilités entre les clouds et rendent extrêmement complexe la création d’environnements de cloud hybride.
Cependant, Microsoft a considérablement progressé dans la prise en charge de la création de clouds hybrides en proposant des ressources et des services équivalents dans les environnements de cloud public et privé, par l’intermédiaire d’Azure et d’Azure Stack, respectivement. Azure Stack, qui n’a été dévoilé que récemment, offre aux utilisateurs de nombreuses fonctionnalités et avantages du cloud public, tout en leur assurant le contrôle et la sécurité d’un centre de données interne.
Nous allons comparer trois modèles courants de cloud hybride à haut niveau afin de montrer comment cette nouvelle approche, associée aux services applicatifs avancés de F5, simplifie considérablement le développement et l’exploitation d’un cloud hybride.
Modèle 1 – Plateformes cloud et services applicatifs non homogènes
Notre premier exemple est un environnement de cloud hybride qui utilise Azure et des services applicatifs natifs Azure pour la partie cloud public, tout en s’appuyant sur VMware et les services applicatifs F5 pour la partie cloud privé, comme illustré à la figure 1.
Le manque manifeste de cohérence entre les différents environnements fait de ce modèle le plus difficile à mettre en œuvre et à exploiter. Dans le cas d’usage de haute disponibilité et de reprise après sinistre évoqué précédemment, une application devrait être configurée séparément afin de fonctionner de manière identique dans chaque cloud. Compte tenu des différences entre les machines virtuelles, les API et les ressources réseau sous-jacentes, cette tâche ne serait probablement pas simple. Ces différences réduisent la portabilité globale de l’application en raison de la complexité des mécanismes nécessaires à son exploitation dans chaque cloud, ce qui double de fait le travail requis pour obtenir des résultats similaires. En outre, chaque plateforme dispose de sa propre interface de portail ainsi que de ses propres outils de développement et d’administration, si bien que ce modèle devient rapidement d’une complexité rédhibitoire.
Et cela ne tient compte que des différences entre les plateformes. Si l’on y ajoute les effets de services applicatifs hétérogènes, avec des interfaces, des outils d’administration et des exigences de configuration disparates, la complexité augmente de manière exponentielle. Et les dysfonctionnements de gestion ne sont pas le seul problème : les incohérences fonctionnelles empêchent de configurer les applications avec les mêmes services dans chaque cloud, ce qui vous expose à des risques supplémentaires. Par exemple, des services de sécurité différents entraînent la mise en place de jeux de règles de pare-feu et de politiques distincts. Ceux-ci peuvent créer des failles de sécurité susceptibles d’entraîner une indisponibilité des applications ou une perte de données clients en cas de cyberattaque.
Modèle 2 – Plateformes cloud non homogènes avec des services applicatifs homogènes
Cette configuration est similaire à celle du modèle 1, mais chaque environnement cloud est pris en charge par les services applicatifs F5, comme illustré à la figure 2.
Grâce à des services applicatifs cohérents, l’ensemble des services, configurations et politiques F5 peuvent être répliqués dans différents environnements et gérés depuis une interface unique, ce qui allège la charge des administrateurs système. Au lieu de devoir maîtriser et concilier deux ensembles distincts de fonctionnalités, d’interfaces et de terminologies, il est possible de déployer un ensemble unique, standardisé et riche en fonctionnalités dans tout l’environnement de cloud hybride. De plus, ces services sont indépendants du cloud (c’est-à-dire qu’ils fonctionnent de manière identique dans tous les clouds), ce qui dissipe les craintes de dépendance vis-à-vis d’un fournisseur pouvant être associées à l’utilisation de services natifs du cloud. Toutefois, ce modèle ne résout pas les problèmes liés à l’hétérogénéité des infrastructures de plateforme, qui devront être pris en compte.
Modèle 3 – Plateformes cloud et services applicatifs homogènes
Ce dernier modèle apporte une nouvelle amélioration progressive : il reprend la configuration décrite dans le modèle 2 et remplace le cloud privé VMware par Microsoft Azure Stack, comme illustré à la figure 3.
Pour ceux qui ne connaissent pas Azure Stack, cette plateforme cloud est conçue comme une extension d’Azure (ou simplement une région supplémentaire) dans le cloud privé, avec des services, des outils et une infrastructure virtuelle identiques. Son intérêt réside dans la possibilité de transférer facilement les charges de travail entre des environnements de cloud hybride sans avoir à remanier les applications. Par ailleurs, l’homogénéité des outils Azure et de l’interface du portail simplifie la gestion. En tant que propriétaire d’une application, vous pouvez la développer et la tester dans Azure, puis la transférer rapidement et en toute transparence vers Azure Stack pour son déploiement en production (ou inversement), tout en prenant en charge les deux instances avec les mêmes services applicatifs F5 de niveau entreprise.
Par rapport au modèle 1, ce modèle de cloud hybride combine les avantages de services applicatifs et d’une infrastructure cloud cohérents, tout en réduisant de moitié le nombre de variables système, qui passe de quatre à deux. Il améliore ainsi considérablement la portabilité des applications et allège la charge de gestion informatique. L’unification des plateformes et des services applicatifs permet aux opérateurs réseau et aux responsables informatiques de considérer leur architecture de cloud hybride comme une seule entité homogène, plutôt que comme deux monolithes distincts.
Le véritable cloud hybride : F5 pour Azure et Azure Stack
Fonctionnant de manière identique sur les deux plateformes, l’édition virtuelle (VE) de BIG-IP de F5 renforce la parité des architectures Azure/Azure Stack grâce à la réplication des services applicatifs associés. Les développeurs peuvent non seulement développer une application dans un environnement et la transférer vers un autre, mais aussi répliquer des piles complètes prêtes pour la production, avec les mêmes configurations, politiques et services applicatifs BIG-IP. Cela évite d’innombrables heures de remaniement et de test des applications, et permet aux développeurs de se consacrer à ce qu’ils font le mieux : écrire du code.
La sécurisation des applications et de leurs données est souvent une source de préoccupation pour les développeurs qui migrent des applications vers le cloud public, mais cela ne devrait pas être le cas. Un développeur peut créer une application dans son environnement Azure Stack, tandis qu’un architecte de sécurité configure les paramètres nécessaires sur le pare-feu d’applications web (WAF) de F5. L’ensemble de la pile peut ensuite être répliqué dans Azure, avec l’assurance que l’application sera protégée par le même WAF de pointe. Grâce à des politiques et des ensembles de règles identiques, aucune faille de sécurité ni vulnérabilité susceptible de résulter de l’utilisation de WAF différents ne sera introduite.
Et comme Azure Stack prend en charge Azure Resource Manager (ARM), la vaste sélection de modèles ARM de F5 permet d’automatiser le déploiement et la configuration des instances BIG-IP VE dans les deux environnements, ce qui réduit considérablement les délais de mise en service et améliore l’efficacité du cloud hybride. En définitive, tout le travail accompli par F5 pour parvenir à une intégration aussi étroite avec Azure profite désormais aux clients d’Azure, ainsi qu’à ceux d’ Azure Stack.
Conclusion
De nombreuses raisons peuvent inciter une organisation à investir dans une stratégie de cloud hybride, et il existe tout autant de façons de la mettre en œuvre. En diversifiant leurs solutions et en faisant appel à plusieurs plateformes cloud et fournisseurs de services applicatifs hétérogènes, les entreprises rendent la mise en œuvre et l’exploitation d’une architecture de cloud hybride considérablement plus complexes.
En standardisant les services applicatifs avancés de F5 dans les différents environnements cloud, tout en tirant parti de la nature homogène des plateformes cloud Azure et Azure Stack de Microsoft, les services informatiques peuvent créer une véritable architecture hybride permettant une portabilité totale des applications entre les écosystèmes. La prise en charge des applications avec les mêmes services de gestion du trafic et de sécurité BIG-IP permet aux équipes réseau et sécurité d’optimiser la disponibilité des applications pour les utilisateurs finaux, tout en protégeant les applications et leurs données grâce à des fonctionnalités et des politiques de sécurité cohérentes.
Et à ce stade encore relativement précoce de l’histoire du cloud computing, de nombreuses organisations informatiques sont contraintes de prendre des décisions difficiles concernant leur stratégie cloud à long terme : doivent-elles opter exclusivement pour le cloud public, exclusivement pour le cloud privé ou pour une combinaison des deux ? Les services applicatifs F5 pour Azure et Azure Stack atténuent les conséquences de cette décision en proposant une solution globale qui permet de migrer à tout moment l’ensemble d’un portefeuille d’applications d’un environnement cloud à un autre afin de s’adapter à l’évolution des besoins de l’entreprise.
NOTE DE BAS DE PAGE :
1 Rapport 2018 de RightScale sur l’état du cloud
PUBLIÉ LE 9 MAI 2018