Architecture de cloud hybride traditionnelle
À l'origine, l'architecture de cloud hybride se concentrait principalement sur les mécanismes impliqués dans la transformation de certaines parties du centre de données sur site de l'entreprise en infrastructure de cloud privé, puis sur la connexion de cette infrastructure aux environnements de cloud public hébergés hors site par un fournisseur de cloud public (par exemple, AWS, Google Cloud Services, IBM Cloud, Microsoft Azure). Ce processus s'appuyait sur une solution de cloud hybride prête à l'emploi comme Red Hat OpenStack (le lien externe à ibm.com) ou sur des middlewares d'entreprise sophistiqués pour intégrer les ressources cloud dans les environnements, et sur des outils de gestion unifiés pour le contrôle, l'attribution et la gestion de ces ressources dans une console centralisée pour une « visibilité unifiée ».
Architecture de cloud hybride moderne
Aujourd'hui, l'architecture hybride se concentre moins sur la connectivité physique que sur la prise en charge de la portabilité des charges de travail dans tous les environnements de cloud et sur l'automatisation du déploiement de ces charges de travail dans l'environnement de cloud le mieux adapté à une utilisation commerciale donnée. Plusieurs tendances sont à l’origine de ce changement.
Dans le cadre de la prochaine étape critique de leur transformation numérique, les organisations créent de nouvelles applications et modernisent les applications existantes pour tirer parti des technologies cloud natives, des technologies qui permettent un développement, un déploiement, une gestion et des performances cohérents et fiables dans les environnements de cloud et entre les fournisseurs cloud.
Pour être plus précis, elles créent ou transforment les applications pour qu'elles utilisent une architecture de microservices, qui décompose les applications en composants plus petits, à couplage flexible et réutilisables, axés sur des fonctions métier spécifiques. Et elles déploient ces applications dans des conteneurs, des unités exécutables légères qui contiennent uniquement le code d'application et les dépendances du système d'exploitation virtualisé requises pour l'exécuter.
À un niveau plus général, les clouds publics et privés ne sont plus des « emplacements » physiques à connecter. Par exemple, de nombreux fournisseurs cloud proposent désormais des services de cloud public qui s'exécutent dans les centres de données sur site de leurs clients. Les clouds privés, autrefois exécutés exclusivement sur site, sont désormais souvent hébergés dans des centres de données hors site, sur des réseaux privés virtuels (VPN) ou clouds privés virtuels (VPC), ou sur une infrastructure dédiée louée auprès de fournisseurs tiers (parfois des fournisseurs de cloud public).
De plus, la virtualisation de l’infrastructure, également appelée infrastructure en code, permet aux développeurs de créer ces environnements à la demande à l’aide de ressources de calcul ou de ressources cloud situées derrière ou au-delà du pare-feu. Cette tendance devient d'autant plus importante avec l'avènement de l'edge computing, qui permet d'améliorer les performances globales des applications en rapprochant les charges de travail et les données des ressources informatiques réellement utilisées.
Pour s'adapter à ces facteurs et à d'autres encore, l'infrastructure de cloud hybride moderne commence à s'articuler autour d'une plateforme hybride multicloud unifiée qui inclut :
- La prise en charge du développement et du déploiement d'applications cloud natives sur tous les types de clouds (publics et privés) et pour tous les fournisseurs cloud
- Un système d'exploitation unique dans tous les environnements
- Une plateforme d'orchestration de conteneurs, généralement Kubernetes, qui automatise le déploiement des applications dans les environnements de cloud
Le développement cloud natif permet aux développeurs de transformer des applications monolithiques en unités de fonctionnalités métier pouvant être exécutées n'importe où et réutilisées au sein de diverses applications. Un système d'exploitation standard permet aux développeurs de créer n'importe quelle dépendance matérielle dans n'importe quel conteneur. L'orchestration et l'automatisation de Kubernetes permettent aux développeurs de contrôler une fois pour toutes de manière granulaire la configuration et le déploiement des conteneurs, y compris la sécurité, l'équilibrage de la charge, l'évolutivité et bien plus encore, dans plusieurs environnements de cloud.