Le Multi-Cloud en 3 étapes

L’interaction entre différents Clusters Kubernetes n'est-elle qu'un élément marketing ? Y a-t-il un intérêt technologique et financier ? Comment cela peut-il fonctionner ?

Trois cas d'usages du Multi-Cloud

Débordement

Vous avez des ressources au sein de votre entreprise pour exécuter vos charges de travail, mais vous souhaitez gagner en agilité pour pouvoir répondre plus efficacement aux évolutions des demandes (période de soldes, sollicitations imprévues d'une solution SaaS, ventes exceptionnelles depuis votre solution de commerce en ligne ...) ?

Certaines entreprises souhaitent bénéficier des avantages qu'offrent les deux modèles. Ainsi les sollicitations habituelles sont traitées par l'infrastructure on-premise et les demandes exceptionnelles sur les Cloud Public.

PCA

Que vous consommiez des ressources auprès d'un fournisseur de Cloud Public ou que vous ayez à disposition un Cloud Privé On-Premise, vous vous posez peut-être la question de la pérennité de vos données en cas de défaillance de votre fournisseur. Qu'en est-il également si votre fournisseur vous impose un changement tarifaire ? La dépendance peut alors être assez forte.

En adoptant une politique Multi-Cloud, vous pourrez alors propulser votre système d'information à partir de plusieurs infrastructures gouvernées par différents fournisseurs.

CDN

Vous fournissez des services à travers le monde entier, vous avez des utilisateurs, des patients, des citoyens pouvant utiliser vos solutions depuis des emplacements très variés ?

Pour répondre à ce besoin, il est nécessaire de pouvoir répondre avec performance à vos usagers, le temps de réponse devient alors critique. Que vous choisissiez de vous reposer sur un fournisseur de services Cloud Public ou que vous ayez plusieurs entreprises réparties aux quatre coins du monde, il vous faudra unifier leurs fonctionnements et proposer un service distribué qui sera accédé par vos utilisateurs en fonction de leur localisation géographique.

1 - Je crée mes environnements

Choisir son standard, le conteneur

La première étape technique dans un projet de création d'architecture Multi-Cloud reste le déploiement de vos environnements. Il faut idéalement que ces derniers soient de même technologie afin de réduire la complexité de mise en œuvre. Évitez les cas d'hybridation VM et conteneurs lorsque vous vous lancez, privilégiez les cas simples. Les VMs possèdent différents formats spécifiques, si vous utilisez VMware vSphere, vos VM seront stockés en VMDK, avec Microsoft Hyper-V, elles seront stockées en VHDX et c'est ainsi pour chaque hyperviseur. Dans ce contexte, difficile de trouver un langage commun pour faire du Multi-Cloud. Avec la conteneurisation, c'est différent, les moteurs exécutant les conteneurs comme containerd ou encore CRI-O utilisent une même norme, le même langage, basé par l'Open Container Initiative (OCI).

Kubernetes Managé, une offre présente sur tous les Cloud

Kubernetes s'est imposé comme l'orchestrateur de conteneurs communément utilisé, vous pourrez l'utiliser sur tout type d'environnement, que ce soit au sein de votre Datacenter (on-premise) ou bien chez les fournisseurs de services Cloud. Les principaux hyperscalers ont tous leur offre de Kubernetes managé (Google Cloud/GKE), (AWS/EKS), (Azure/AKS) ... Les Cloud Providers français sont présents également sur ce marché, OVH Manage Kubernetes Service ou encore Scaleway Kubernetes Kapsule.

Profitez de votre puissance locale

Aujourd'hui encore, un grand nombre d'entreprises possède sa propre infrastructure informatique au sein de leurs établissements, sous forme traditionnelle ou en tant que Cloud privé géré par un tiers. Ces ressources ont l'avantage d'avoir un cout modéré, mais ont l'inconvénient d’être difficilement redimensionnables lors de fortes charges.

Profitez de ces ressources pour y provisionner un environnement Kubernetes. Pour cela, plusieurs méthodes s'offrent à vous. Soit, vous avez des compétences fortes au sein de vos équipes et vous pouvez alors vous permettre de déployer un Kubernetes dans sa version Upstream. Soit, vous décidez de vous reposer sur une solution adaptée aux besoins et contraintes d'entreprises en vous reposant sur l'expertise d'éditeurs. Parmi les versions les plus matures, nous retrouvons, Red Hat Openshift, VMware Tanzu et Suse Rancher.

2 - J'unifie mes infrastructures

Le Multi-Cloud nécessite une interaction forte entre vos environnements Cloud, qu'ils soient on-premise ou chez un Hyperscaleur, il vous faudra les mettre en réseau. Pour y arriver, il existe trois méthodes.

La liaison physique

Difficile à mettre en œuvre et très coûteux, peu d'entreprises peuvent se permettre d'établir des liens physiques sécurisés entre leurs différents fournisseurs de services Cloud.

Le VPN

La méthodologie traditionnelle serait d'empaqueter vos communications au travers d'un VPN sécurisé et de mettre ainsi en relation l'ensemble de vos réseaux, qu'importe leurs emplacements. Un composant OpenSource comme Submariner permet d'y arriver en toute simplicité. C'est le choix qu'a fait Red Hat dans sa solution Advanced Cluster Manager.

Les services MESH

Une solution technologique plus moderne pour y arriver est d'utiliser les services Mesh pour réaliser la mise en relation des clusters Kubernetes. Vous connaissez probablement les bornes Wifi Mesh permettant de créer une couverture Wifi unifiée au travers plusieurs bornes que vous installez à votre domicile ou dans votre entreprise, et bien c'est la même chose avec des clusters Kubernetes. Avec des services Mesh comme Istio ou encore Consul, vous pourrez notamment créer un réseau unifié sécurisé entre vos clusters Kubernetes. Un produit SaaS comme VMware Tanzu Service Mesh permet de s’abstraire de la complexité des services Mesh, car, ne nous le cachons pas, Istio et les autres Services MESH ce ne sont pas les sujets les plus abordables lorsque l'on engage le Cloud Native.

Une fois vos réseaux unifiés, vos services et applications pourront communiquer entre vos différents environnements. Vous pourrez choisir de mettre vos Frontaux Web sur vos Cloud Public, et vos données bien au chaud chez vous sur votre Cloud Privé on-premise.

3 - J'expose mes ressources

La dernière étape reste l'exposition de vos services. Maintenant que vos environnements sont provisionnés et mis en réseau, il vous faut créer une porte d'entrée sur chacun de vos environnements. Sur un Cloud Public, c'est simple, utilisez simplement l'équilibreur de charge mis à votre disposition. Sur votre Cloud Privé, vous devrez également utiliser un équilibreur de charge, F5, Netscaler, VMware NSX ALB, Apache, NGINX, ils sont nombreux à pouvoir assurer ce service.

Cela nous permet d'avoir nos différentes portes d'entrée, mais comment pouvons-nous définir quelle porte d'entrée doit être utilisée pour traiter une requête ? Quelle technologie peut se placer au-dessus des équilibreurs de charges lorsque vous consommez plusieurs environnements Cloud ?

Le DNS! Nous ne parlons pas de faire là d'un pauvre Round-Robin DNS sur vos portes d'entrée, mais bien de mettre en place un environnement GSLB qui provisionnera des serveurs de noms au sein de vos infrastructures et qui seront modifiés en fonction de l'état de charge de vos environnements Kubernetes.

Ainsi, vos utilisateurs, lorsqu'ils souhaiteront venir consommer des services sur vos environnements, réaliseront en premier une requête de translation FQDN vers adresse IP, et le réseau GSLB renverra l'utilisateur vers l'infrastructure la plus apte à répondre.

Conclusion

Il y a encore peu de temps, les projets Multi-Cloud pouvaient être complexes, nous ne possédions pas les standards d'aujourd'hui, et il y avait encore peu de solutions permettant de faciliter leurs mises en œuvre.

Le Cloud Public coute cher, les infrastructures on-premise sont peu agiles, et si la meilleure solution était de profiter des avantages des deux mondes ?