Le Cloud Hybrid comble les inconvénients du Cloud Public

C’est un constat personnel que j’ai fait, dans certains secteurs d’activité notamment là où c’est économiquement très tendu comme dans la distribution ou l’industrie, il y a une plus grande appétence au cloud public. Ils ont mis en place une stratégie Cloud Public First ou Cloud Public Only. Quand je pose la question à mes interlocuteurs habituels quelle est la raison de cette stratégie, la réponse est souvent la même, ça vient d’en haut, de la direction informatique et/ou des finances. En effet un gros contrat signé avec l’un des trois acteurs du Cloud Public à savoir Amazon pour AWS, Microsoft pour Azure ou Google pour GCP, promettant de faire de grosses économies financières. Les opérationnels eux, ne sont pas consultés dans cette décision mais ont tout de même la charge de devoir mettre en place une campagne de migration massive pour suivre cette stratégie.  Pour la majorité de ces entreprises cette stratégie est récente, d’autres ont été précurseurs et cela permet d’avoir un peu de recul sur les bénéfices et les déficits qu’elle apporte :

  • L’aspect économique doit être scruté à la loupe car il y aura des mauvaises surprises, c’est sûr. Les éléments à prendre en compte :
    • Le gabarit des machines virtuelles. Un certain gabarit de machine virtuelle en ressource processeur et mémoire sera plus favorable au Cloud Public. Ce gabarit permet à l’hébergeur de faire fonctionner un nombre optimal de machine virtuelle sur un hôte physique et donc mieux amortir le coût de la machine physique. Alors que d’autres gabarits seront plus favorables au cloud privé. Il faut bien vérifier le coût du gabarit à migrer avant de faire le transfert.
    • La saisonnalité. Si votre application a des saisonnalités comme par exemple en période de solde, elles vont nécessiter des ressources physiques à la hausse durant cette période puis à la baisse une fois cette période terminée. L’élasticité native présente dans le Cloud Public évite des investissements en matériel et en logiciel d’infrastructure pour une utilisation périodique faible.
    • La périodicité. Si des environnements peuvent fonctionner sur une plage horaire partielle comme par exemple, la journée ou la nuit, ils permettent de payer l’infrastructure uniquement durant ces périodes d’utilisation et non pas tout le temps comme ça serait le cas sur un environnement On-Premise.
    • Les flux réseau. Les flux entrants vers le cloud public sont gratuits par contre les flux sortants sont dans la plupart des cas facturés, c’est un élément à prendre en compte si vous avez des échanges inter application ou si vous devez faire des exports de model de données volumineux.
    • Les services additionnels. Certains services comme une adresse IP publique ou encore des load balancer peuvent être commander (donc payés) à la demande puis associés à des VMs. Lorsque que la VM est détruite, les services associés ne sont pas “décommissionés” pour autant et continueront à être facturés.
    • Pour éviter les surprises il faut se doter d’un outil (eg : CloudHealth) qui vous donnera une visibilité pertinente de la consommation à l’instar d’un tableau de bord d’un d’avion. Il proposera ainsi des économies en identifiant les ressources mal, peu ou pas utilisées.
  • L’aspect services à valeur ajoutée comme l’intelligence artificielle ou le machine learning apportent un bénéfice indéniable car ce genre de service est difficile à obtenir On-Premise.
  • L’aspect agilité est là aussi un point fort au cloud public, avoir des ressources à la demande et les libérer quand on en a plus besoin.
  • L’aspect couverture géographique international est intéressant mais ne pourra pas se faire avec un hébergeur unique car pour des raisons réglementaires et/ou politiques, les trois acteurs principaux ne sont pas présents dans certains pays comme en Russie.

Il y a plusieurs possibilités pour aller dans le cloud public, il faut soit développer ses applications directement dessus, soit avoir une application basée sur des containers pour les transférer sans les retoucher, mais pour les autres qui sont la grande majorité des cas, il faudra les transformer. En effet il y a une forte chance que le format des VMs qui hébergent les applications dans vos Data Center On-Premise soit différent de celui des VMs du cloud public, il faudra donc les transformer. Il existe des outils pour les transformer mais ils fonctionnent correctement que si ce sont des applications simples.

Une fois que vous êtes dans le cloud public, êtes-vous sûr d’y rester ? Que faire si les coûts d’hébergement augmentent ou si les éditeurs des applications changent leur mode de tarification lorsqu’elles sont hébergées sur le Cloud Public ? Que faire si l’hébergeur devient un concurrent dans votre secteur d’activité, si les performances, le niveau de service ou les services ne sont pas au rendez-vous ? Comment faire des retours arrière, car cela nécessiterait une deuxième transformation pour revenir sur l’On-Premise et voire une troisième si c’est pour aller ensuite vers un autre hébergeur ?

La transformation n’est pas si simple, elle comporte des indisponibilités de service, des risques techniques et financiers et est très chronophage. Le coût de cette transformation et l’évaluation des risques associés ne sont pas pris en compte dans le coût de cette stratégie.

Alors comment éviter une telle transformation et pouvoir être libre de changer d’hébergeur tout en respectant la stratégie de son entreprise exigeant d’aller vers le Cloud Public ?

Il existe une solution moins radicale et plus agile, si vos applications sont hébergées sur l’hyperviseur vSphere ce qui doit représenter environs plus de 80% des cas, vous pouvez commander directement un SDDC VMware (Software Defined Data Center : Data Center virtualisé) chez l’hébergeur de votre choix, Atos, AWS, Azure, GCP, Oracle, OVH et bien d’autres avec pas loin de 4500 partenaires (VMware Cloud Verified Partner). Cela se fait en général directement à partir de la Market Place de l’hébergeur (Exemple : Azure VMware Solutions), ou directement chez VMware dans le cas d’AWS seulement (VMware Cloud On AWS) Ce processus prend environs 2 heures et vous avez ensuite un environnement complet serveur, stockage, réseau et sécurité qui vous ait dédié. Cet environnement est aussi basé sur l’hyperviseur vSphere, ce qui permet d’exécuter vos applications sans avoir à les transformer. La virtualisation du réseau permet de reproduire la topologie de votre réseau actuel sans avoir à modifier les adresses IP des serveurs et des applications. Vos applications s’exécutent ainsi comme chez vous mais dans le Data Center d’un Cloud Public à proximité des services natifs de l’hébergeur, comme montré dans le schéma qui suit, exemple sur AWS :

Vous avez ainsi le meilleur des deux mondes. Vos applications consomment des services natifs via les APIs et si vous souhaitez changer d’hébergeur, vous déplacez votre application vers le nouvel hébergeur et modifiez uniquement les appels API à ces services natifs. Et même cette partie peut être éviter en utilisant un “Wrapper” qui sera adresser les spécificités des APIs de chaque fournisseur. Il n’est donc pas nécessaire de transformer l’application complète. 

Maintenant que vous avez un SDDC chez un cloud public, comment déplacer simplement ses applications ?

Il est possible d’utiliser la méthode classique, c’est à dire faire un vMotion entre les deux environnements comme il est possible de le faire On-Premise depuis plusieurs années, ce qui fut une des forces de l’hyperviseur vSphere, ou utiliser l’outil de migration HCX qui permet de faire des migrations à chaud ou à froid, en masse, planifiable tout en bénéficiant d’une optimisation réseau pour que les migrations durent moins longtemps.

Le Cloud Public offre beaucoup de services innovants qu’il ne faut pas hésiter à utiliser. Par contre, il ne faut pas vous “verrouiller” avec un acteur, il faut que vos applications soient mobiles. La meilleure approche pour cela est de minimiser au maximum les dépendances. Cela passe par la modification partielle du code de l’application, en modifiant uniquement l’appel aux services natifs (ou passer par un “wrapper” d’API) et de garder son hébergement sur un format de VM qui garantira sa mobilité. Il n’y aura pas de “verrouillage” commercial avec VMware car les SDDC se contractualisent directement avec les fournisseurs des Cloud Public, sauf pour AWS où vous avez le choix de contractualiser avec VMware ou AWS.

Pourquoi VMware Cloud On AWS (AKA VMC)

VMC on AWS c’est le SDDC (Software Defined Data Center / Data Center logiciel) de VMware hébergée sur les infrastructures physiques d’AWS. Elle permet d’avoir un Data Center agile et programmable sans avoir à le gérer. Lorsqu’il est couplé à un Data Center privé on obtient un réel Cloud Hybrid, c’est à dire une administration centralisée commune des deux, la possibilité de migrer à chaud et à froid les workloads de l’un vers l’autre, de synchroniser les templates de VMs et d’étendre les réseaux (niveau 2 et 3) afin d’avoir le même plan d’adressage. La condition minimale pour avoir un cloud hybrid est d’avoir au moins l’hyperviseur vSphere sur son Data Center privé, sinon on n’a juste un cloud public SDDC VMware hébergé chez AWS (et c’est déjà très bien).

 

Je ne vais pas aborder les avantages du Cloud Public et du SDDC, je pars du principe qu’ils sont connus. Cependant, je vais aborder les points de vigilance auxquels ont fait face certains de mes clients :

 

  • Pour être efficient, il faut connaître l’architecture de l’infrastructure sous-jacente (réseau, stockage, serveur, sécurité, …).
  • Il faut que l’application soit développée en intégrant dans son design la prise en compte de panne des différents éléments constituant l’infrastructure.
  • Pour les applications existantes, il faut transformer les VMs car elles n’auront surement pas le même format.
  • Intégrer un nouveau model opératoire pour lequel il faut prévoir, de nouveaux outils d’administration à acquérir et à connaître, de nouveaux scripts d’administration à écrire ou à adapter, de nouvelles compétences à recruter et former celles existantes.
  • Appréhender une nouvelle gouvernance et de nouvelles règles de sécurité.
  • Il faut prévoir un retour arrière, les intérêts que vous avez trouvé à un hébergeur (notamment tarifaires) peuvent ne plus correspondre dans le futur.

 

Quels sont les principaux avantages techniques que trouvent les clients à utiliser VMC, notamment ceux qui ont déjà une infrastructure à base de vSphere ?

 

  • Une infrastructure qui leur est dédiée, donc une plus grande sécurité car elle n’est pas partagée par d’autres clients et des performances prédictibles car ce sont uniquement ses propres applications qui y fonctionnent.
  • Pas de besoin de transformer les VMs et les applications, le format et le même que sur les hyperviseurs vSphere de leur Data Center privé.
  • Une réversibilité, du fait d’avoir le même format, s’ils changent d’avis ils peuvent (re)transférer leurs VMs sur leur Data Center privé.
  • Un mode opératoire et des compétences identiques à ce qu’ils ont pour leur environnement vSphere sur leur Data Center privé, les investissements antérieurs sont ainsi pérennisés.
  • Être au plus proche des services AWS. Si vos applications hébergées sur votre Data Center privé ont besoin d’accéder aux services AWS, elles doivent passer par Internet ou par un lien direct connecte et les trafics réseaux sortants d’AWS vous seront facturées. Lorsqu’elles sont hébergées sur VMC, elles sont au plus proche des services AWS, vous allez gagner en performance et leurs échanges ne seront plus facturés.

 

Comment bénéficier de VMC et qui contacter en cas de problème ?

 

  • Au moment de la rédaction de cet article, le seul moyen d’y bénéficier et de passer par vos contacts VMware habituels. 
  • En cas d’incident, quel qu’y soit, VMware est votre interlocuteur unique.

 

La création du SDDC hébergé chez AWS, se fait directement via le site de VMware en l’associant à un compte et à un VPC AWS.

 

Contrairement à un Cloud Public, vous n’achetez pas de VMs ou des services applicatifs mais bien des ressources physiques bénéficiant du SDDC de VMware, le minimum pour démarrer c’est un cluster de quatre hyperviseurs puis si besoin des incréments d’au moins un hyperviseur. Un hyperviseur vient avec ses processeurs, sa mémoire et sa capacité de stockage. La tarification est basée sur le même principe.

Les cas d’usages constatés sont ceux d’un Data Center classique plus ceux qui figurent dans le schéma ci-dessous :

 

Les avantages non techniques constatés sont :

  • Ne plus avoir à gérer les acquisitions d’infrastructure bas niveau, le cycle de vie, la gestion des changements, les opérations de maintenance, la formation du personnel.
  • Libérer du temps et du budget aux services plus proche des métiers de l’entreprise.
  • Un accroissement de l’agilité, désormais un projet peut démarrer de zéro en quelque heures et adapter ses besoins en ressources en quelques minutes si nécessaire.
  • Être libre de choisir son hébergeur et d’y changer si besoin.
  • Récupérer les budgets qui auraient dû être alloué à la transformation applicative, à la formation et à l’adaptation d’outils.
  • Diminuer les risques, en utilisant une plate-forme au comportement connu et maitrisé.
  • Garder la gouvernance habituelle.

Pour plus d’information, je vous invite à visiter le site de VMware sur ce sujet : https://cloud.vmware.com/fr/vmc-aws