Cloud hybride réalisé : F5, Azure et Azure Stack

De nos jours, de nombreux services informatiques subissent la pression des groupes de direction pour s’éloigner de la nature statique des centres de données internes traditionnels vers des architectures plus dynamiques, centrées sur le cloud, augmentant ainsi l’agilité, la flexibilité et l’évolutivité tout en réduisant les coûts opérationnels. Et parce que les clouds publics et privés ont chacun leurs avantages et leurs inconvénients, environ 71 %¹ des entreprises mettent en œuvre des modèles hybrides pour bénéficier d’un plus grand nombre d’avantages, tout en annulant de nombreux inconvénients. Cependant, presque toutes ces organisations le font en utilisant une infrastructure cloud et des services application non homogènes, ce qui augmente considérablement la complexité pour les équipes interfonctionnelles chargées de concevoir et de maintenir ces déploiements.

Lier deux (ou plusieurs) environnements cloud distincts pour créer un cloud hybride n’est pas seulement bénéfique du point de vue de l’agilité, de la flexibilité et de l’évolutivité, mais permet également toute une série de cas d’utilisation spécialisés qui seraient beaucoup plus difficiles, voire impossibles, à mettre en œuvre. Les plus courantes d’entre elles sont sans doute :

La mise en place et la maintenance d’une sauvegarde hautement disponible et géographiquement redondante d’un cloud privé pour éviter les temps d’arrêt des applications essentielles sont très coûteuses et doubleraient probablement l’investissement requis pour exécuter un seul cloud privé. Non seulement vous auriez besoin de deux fois plus de matériel physique, mais vous auriez également besoin d’un centre de données distinct, doté de sa propre alimentation, de son propre refroidissement et de son propre personnel dans un emplacement géographique distinct.

Alternativement, les environnements HA et DR peuvent être hébergés dans le cloud public pour une fraction du coût. Les données de application sont stockées à chaque fois qu'elles sont sauvegardées à partir du cloud privé tandis que les ressources réelles de application et du réseau restent inactives jusqu'à ce qu'elles soient nécessaires, c'est-à-dire en cas de catastrophe ou de défaillance du cloud privé. Si nécessaire, ces applications et ressources sont lancées et rendues opérationnelles à l’aide des données stockées, garantissant ainsi la disponibilité des application et la continuité des activités.

Développer une nouvelle application dans un cloud privé peut être considérablement plus coûteux que dans le cloud public. L’exécution de la charge de travail nécessite un investissement initial en capital, sans aucune garantie qu’elle fonctionnera ou sera adoptée sur le marché actuel. Pour ces raisons, les entreprises suivent le mantra « échouer vite, échouer à moindre coût » en utilisant la capacité à la demande du cloud public pour développer, tester et exécuter de nouvelles applications en mode production. Une fois jugées opérationnelles ou largement adoptées par les utilisateurs, les applications peuvent être migrées vers le cloud privé, qui peut être plus sûr et moins coûteux sur le plan opérationnel à long terme. Alternativement, ils pourraient rester dans le cloud public, déployés dans un environnement à plus long terme et plus rentable, en utilisant des instances réservées moins chères, etc.

Souvent considérée comme la capacité de cloud hybride la plus souhaitable, l'éclatement du cloud est probablement la plus difficile à mettre en œuvre, devenant fréquemment la baleine blanche 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 la capacité, les demandes 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’un état temporaire, conçu pour gérer des pics de trafic inattendus qui durent de courtes périodes. Une fois que les périodes de trafic plus élevées deviennent durables, les entreprises peuvent augmenter la capacité de leur cloud privé.

La configuration d’un environnement cloud hybride pour le cloud bursting est intrinsèquement difficile et complexe. Cela nécessite une relation synergique entre les deux environnements, ainsi qu'une orchestration à sécurité intégrée pour garantir que la redirection se déroule de manière autonome et transparente, avec peu ou pas d'impact sur l'expérience des utilisateurs finaux. La difficulté est encore plus amplifiée pour les équipes chargées de la configuration et de la gestion lorsque l’infrastructure, les services et les outils utilisés pour exécuter et prendre en charge les applications sont différents pour chaque environnement.

Cela ne devrait pas vous surprendre d’apprendre que tous les nuages ne se ressemblent pas. Chacun dispose de sa propre infrastructure, de ses services de réseau et application , de ses outils de développement, de son interface utilisateur et de sa différenciation par rapport aux autres concurrents du cloud. 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 de se déplacer vers AWS ou Google Cloud. Ces différences de plateformes et de services entraînent des incompatibilités entre les clouds et rendent la tâche de développement d’environnements de cloud hybride incroyablement difficile.

Toutefois, Microsoft a réalisé des progrès considérables dans la prise en charge de la création de cloud hybride en proposant des ressources et des services synonymes dans les environnements de cloud public et privé via Azure et Azure Stack, respectivement. Azure Stack, qui a été récemment dévoilé, offre aux utilisateurs de nombreuses fonctionnalités et avantages du cloud public avec le contrôle et la sécurité d'un centre de données interne.

Nous comparerons trois modèles de cloud hybride courants de haut niveau pour démontrer comment cette nouvelle approche, combinée aux services application avancés F5, simplifie considérablement le développement et l'exploitation du cloud hybride.

Modèle 1 – Plateformes cloud et services application non homogènes

Notre premier exemple est un environnement de cloud hybride utilisant Azure avec des services application natifs Azure pour l’aspect cloud public, tout en exploitant VMware avec des services application F5 pour le composant cloud privé, comme illustré dans la figure 1.

Le manque flagrant de cohérence entre les environnements fait de ce modèle le plus difficile à mettre en œuvre et à exploiter. Avec le cas d’utilisation HA/DR évoqué précédemment, une application devrait être configurée individuellement pour 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, il est peu probable que ce soit une tâche simple. Ces différences contribuent à réduire la portabilité globale de l’ application en raison de la complexité de la plomberie requise pour rendre l’application opérationnelle dans chaque cloud, ce qui double effectivement le travail requis pour obtenir des résultats similaires. De plus, chaque plateforme possède également sa propre interface de portail unique et ses propres outils de développement/administrateur, ce modèle devient rapidement extrêmement compliqué.

Et cela ne prend en compte que les différences entre les plateformes. Si l’on ajoute à cela l’effet de services application différents, avec des interfaces, des outils d’administration et des exigences de configuration disparates, la complexité augmente de manière exponentielle. Et le dysfonctionnement de la gestion n’est pas le seul problème ; les incohérences des fonctionnalités empêchent les applications d’être configurées avec les mêmes services dans chaque cloud, vous exposant ainsi à des risques supplémentaires. Par exemple, des services de sécurité différents conduisent à des ensembles de règles et de politiques de pare-feu distincts. Ces failles peuvent créer des failles de sécurité entraînant des temps d’arrêt des application ou la perte de données client à la suite de cyberattaques ultérieures.

Modèle 2 – Plateformes cloud non homogènes avec services application homogènes

Cette configuration est similaire à celle du modèle 1, mais avec chaque environnement cloud pris en charge par les services application F5, comme illustré dans la figure 2.

Avec des services application cohérents, tous les services, configurations et politiques F5 peuvent être répliqués dans tous les environnements avec une gestion à partir d'une seule fenêtre, réduisant ainsi la pression sur les administrateurs système. Au lieu d'apprendre et d'équilibrer deux ensembles distincts de fonctionnalités, d'interfaces et de terminologie, un ensemble de services standardisé et riche en fonctionnalités peut être déployé dans l'environnement de cloud hybride. Et ces services sont indépendants du cloud (c'est-à-dire qu'ils fonctionnent de manière identique dans tous les clouds), éliminant ainsi les craintes de dépendance vis-à-vis d'un fournisseur qui peuvent être associées à l'utilisation de services cloud natifs. Cependant, ce modèle ne répond pas aux problèmes liés à l’infrastructure disparate des plateformes, qui devront être pris en compte.

Modèle 3 – Plateformes cloud et services application homogènes

Ce modèle final voit d’autres améliorations progressives ; en reprenant la configuration décrite dans le modèle 2 et en remplaçant le cloud privé VMware par Microsoft Azure Stack, comme illustré dans la figure 3.