Aujourd'hui encore, la plupart des applications de votre entreprise tournent sur une couche de virtualisation VMware ? Vous pouvez alors étendre de manière transparente votre cloud privé existant soit vers Azure, soit vers AWS. Ces solutions autorisent une migration sans temps d'arrêt entre le cloud privé, Azure et AWS afin d'amener les applications existantes ou de nouvelles applications dans le cloud public. Voici quelques avantages de cette première stratégie :

· Un déploiement on ne peut plus simple. Il suffit de relier le réseau et d'acheter des hôtes hyperviseurs VMware sur le cloud public de votre choix. Et voilà, vous venez déjà d'étendre votre infrastructure existante en lui ajoutant un composant de cloud public.

· Vous constatez que votre infrastructure de reprise après sinistre reste inactive la plupart du temps ? Envisagez donc la possibilité de la reprise après sinistre basée sur le cloud (" as a service "). Aujourd'hui, un scénario de reprise après sinistre ne doit plus nécessairement consister en deux datacenters dédiés (dont l'un est généralement utilisé pour l'environnement hors production) avec des systèmes de réplication de stockage coûteux. Si vous optez pour une solution de reprise après sinistre basée sur le cloud, vous avez seulement besoin d'une très petite capacité dans le cloud, celle-ci pouvant être augmentée automatiquement en cas de catastrophe. Par ailleurs, vous pouvez aussi supprimer une bonne partie de cette capacité lorsque vous n'en avez pas besoin.

· La flexibilité des ressources. La mise à disposition de nouvelles ressources est rapide et facile. Quelques minutes après l'ajout d'un nouvel hôte, ce dernier est entièrement configuré et prêt à être utilisé dans le cluster. L'ajout et la suppression d'hôtes sont possibles soit manuellement, soit automatiquement grâce à Elastic DRS (dynamic resource scheduling) en fonction de l'utilisation. C'est ce qui permet à votre VMC (VMware Cloud) d'évoluer à la demande pour répondre à vos besoins en ressources. Fini donc les attentes de plusieurs semaines avant de voir le matériel arriver sur place et être installé.

Les machines virtuelles ne doivent pas, elles non plus, se conformer au dimensionnement rigide affiché par les fournisseurs de cloud public. Tout est donc adaptable en fonction des besoins de l'application.

· Les outils de gestion existants restent fonctionnels. Vos gestionnaires peuvent tout simplement continuer à utiliser leurs outils de gestion Vmware habituels, à commencer par la célèbre suite vCenter. Il vous suffit d'étendre l'environnement existant en y ajoutant les plateformes de cloud public de votre choix.

Cette solution améliore donc la rentabilité grâce aux avantages que nous venons de citer. Elle vous permet de différer les nouveaux investissements dans le matériel de votre cloud privé ou de votre datacenter, et d'absorber les pics de demande et la croissance naturelle en misant sur l'élasticité du cloud public. En outre, cette stratégie vous donne l'occasion de commencer à réduire la capacité dont vous aviez besoin dans votre second datacenter pour la reprise après sinistre, et peut-être même de restreindre la capacité de vos datacenters au sens large.

L'autre stratégie pour utiliser les clouds publics tout en évitant l'enfermement propriétaire, réside dans la conteneurisation. Les clouds publics disposent chacun d'une PaaS (Platform as a Service) destinée à la conteneurisation (Azure Kubernetes Service, Elastic Cloud Kubernetes pour AWS, Tanzu pour VMware). Grâce à ces plateformes, vous commencez aisément la conteneurisation de vos applications et systèmes. Une fois l'application conteneurisée, vous l'utilisez en toute simplicité sur les diverses plateformes.

Transférer des applications vers des conteneurs est un exercice un peu plus complexe, mais qui vaut la peine puisqu'il débouche sur les avantages suivants :

· En utilisant les solutions de conteneurs gérés existantes, vous n'avez plus besoin de maintenir un système d'exploitation. Cette stratégie permet aussi de libérer des ressources informatiques, qui étaient auparavant nécessaires pour faire tourner le système d'exploitation.

· Autre avantage : l'évolutivité. Une fois qu'une application s'exécute dans un conteneur, il devient aisé de lancer une instance supplémentaire de ce conteneur. En cas de charge de travail plus élevée, des conteneurs supplémentaires sont automatiquement créés, pour être à nouveau supprimés lorsque la charge de travail retombe. C'est la solution idéale pour garantir l'expérience utilisateur des applications.

· Lorsque les applications sont correctement transférées vers les conteneurs, le paysage existant se transforme, la grande application monolithique se muant en micro services. Cette transformation favorise également la flexibilité entre les diverses plateformes.

· Les conteneurs sont parfaitement utilisables dans un contexte d'automatisation, notamment avec DevOps, ce qui se traduit par une amélioration des délais de mise sur le marché et une meilleure prise en compte de la tendance du travail agile mais aussi, de l'intégration et du déploiement en continu, qui impliquent de pouvoir amener rapidement une nouvelle fonctionnalité en production.

· Vous bénéficiez d'une plus grande sécurité avec les applications conteneurisées par rapport aux applications exécutées dans des systèmes d'exploitation. La conteneurisation peut même apporter une solution pour vos applications patrimoniales qui tournent aujourd'hui encore sur des systèmes en fin de vie.

· Il y a 13 ans, nous faisions une grande avancée avec la virtualisation. Aujourd'hui, la conteneurisation est une nouvelle étape majeure en termes d'optimisation.

Conclusion : les deux stratégies présentent chacune des avantages distincts. Dès lors, l'approche idéale serait peut-être, dans un premier temps, d'étendre le datacenter existant vers un cloud public, puis de commencer à migrer les applications existantes selon la méthode " lift and shift ". Viendra ensuite l'étape de la conteneurisation des applications.

Aujourd'hui encore, la plupart des applications de votre entreprise tournent sur une couche de virtualisation VMware ? Vous pouvez alors étendre de manière transparente votre cloud privé existant soit vers Azure, soit vers AWS. Ces solutions autorisent une migration sans temps d'arrêt entre le cloud privé, Azure et AWS afin d'amener les applications existantes ou de nouvelles applications dans le cloud public. Voici quelques avantages de cette première stratégie :· Un déploiement on ne peut plus simple. Il suffit de relier le réseau et d'acheter des hôtes hyperviseurs VMware sur le cloud public de votre choix. Et voilà, vous venez déjà d'étendre votre infrastructure existante en lui ajoutant un composant de cloud public.· Vous constatez que votre infrastructure de reprise après sinistre reste inactive la plupart du temps ? Envisagez donc la possibilité de la reprise après sinistre basée sur le cloud (" as a service "). Aujourd'hui, un scénario de reprise après sinistre ne doit plus nécessairement consister en deux datacenters dédiés (dont l'un est généralement utilisé pour l'environnement hors production) avec des systèmes de réplication de stockage coûteux. Si vous optez pour une solution de reprise après sinistre basée sur le cloud, vous avez seulement besoin d'une très petite capacité dans le cloud, celle-ci pouvant être augmentée automatiquement en cas de catastrophe. Par ailleurs, vous pouvez aussi supprimer une bonne partie de cette capacité lorsque vous n'en avez pas besoin.· La flexibilité des ressources. La mise à disposition de nouvelles ressources est rapide et facile. Quelques minutes après l'ajout d'un nouvel hôte, ce dernier est entièrement configuré et prêt à être utilisé dans le cluster. L'ajout et la suppression d'hôtes sont possibles soit manuellement, soit automatiquement grâce à Elastic DRS (dynamic resource scheduling) en fonction de l'utilisation. C'est ce qui permet à votre VMC (VMware Cloud) d'évoluer à la demande pour répondre à vos besoins en ressources. Fini donc les attentes de plusieurs semaines avant de voir le matériel arriver sur place et être installé.Les machines virtuelles ne doivent pas, elles non plus, se conformer au dimensionnement rigide affiché par les fournisseurs de cloud public. Tout est donc adaptable en fonction des besoins de l'application.· Les outils de gestion existants restent fonctionnels. Vos gestionnaires peuvent tout simplement continuer à utiliser leurs outils de gestion Vmware habituels, à commencer par la célèbre suite vCenter. Il vous suffit d'étendre l'environnement existant en y ajoutant les plateformes de cloud public de votre choix.Cette solution améliore donc la rentabilité grâce aux avantages que nous venons de citer. Elle vous permet de différer les nouveaux investissements dans le matériel de votre cloud privé ou de votre datacenter, et d'absorber les pics de demande et la croissance naturelle en misant sur l'élasticité du cloud public. En outre, cette stratégie vous donne l'occasion de commencer à réduire la capacité dont vous aviez besoin dans votre second datacenter pour la reprise après sinistre, et peut-être même de restreindre la capacité de vos datacenters au sens large.L'autre stratégie pour utiliser les clouds publics tout en évitant l'enfermement propriétaire, réside dans la conteneurisation. Les clouds publics disposent chacun d'une PaaS (Platform as a Service) destinée à la conteneurisation (Azure Kubernetes Service, Elastic Cloud Kubernetes pour AWS, Tanzu pour VMware). Grâce à ces plateformes, vous commencez aisément la conteneurisation de vos applications et systèmes. Une fois l'application conteneurisée, vous l'utilisez en toute simplicité sur les diverses plateformes.Transférer des applications vers des conteneurs est un exercice un peu plus complexe, mais qui vaut la peine puisqu'il débouche sur les avantages suivants :· En utilisant les solutions de conteneurs gérés existantes, vous n'avez plus besoin de maintenir un système d'exploitation. Cette stratégie permet aussi de libérer des ressources informatiques, qui étaient auparavant nécessaires pour faire tourner le système d'exploitation.· Autre avantage : l'évolutivité. Une fois qu'une application s'exécute dans un conteneur, il devient aisé de lancer une instance supplémentaire de ce conteneur. En cas de charge de travail plus élevée, des conteneurs supplémentaires sont automatiquement créés, pour être à nouveau supprimés lorsque la charge de travail retombe. C'est la solution idéale pour garantir l'expérience utilisateur des applications.· Lorsque les applications sont correctement transférées vers les conteneurs, le paysage existant se transforme, la grande application monolithique se muant en micro services. Cette transformation favorise également la flexibilité entre les diverses plateformes.· Les conteneurs sont parfaitement utilisables dans un contexte d'automatisation, notamment avec DevOps, ce qui se traduit par une amélioration des délais de mise sur le marché et une meilleure prise en compte de la tendance du travail agile mais aussi, de l'intégration et du déploiement en continu, qui impliquent de pouvoir amener rapidement une nouvelle fonctionnalité en production.· Vous bénéficiez d'une plus grande sécurité avec les applications conteneurisées par rapport aux applications exécutées dans des systèmes d'exploitation. La conteneurisation peut même apporter une solution pour vos applications patrimoniales qui tournent aujourd'hui encore sur des systèmes en fin de vie.· Il y a 13 ans, nous faisions une grande avancée avec la virtualisation. Aujourd'hui, la conteneurisation est une nouvelle étape majeure en termes d'optimisation.Conclusion : les deux stratégies présentent chacune des avantages distincts. Dès lors, l'approche idéale serait peut-être, dans un premier temps, d'étendre le datacenter existant vers un cloud public, puis de commencer à migrer les applications existantes selon la méthode " lift and shift ". Viendra ensuite l'étape de la conteneurisation des applications.