Microsoft est-il vraiment capable de mettre en difficulté VMware ? Faut-il migrer vers Hyper-V ? Adopter une stratégie « multi-sourcing » ? Autant de questions que se pose le marché et auxquelles nous avons tenté de répondre.

Microsoft, un sérieux challenger de VMware

Depuis l’avènement de la virtualisation x86, VMware est le leader incontesté du marché. La majorité des grandes entreprises utilisent sa solution vSphere et en sont satisfaites.

Cependant, comme toute situation de quasi-monopole, cette domination du marché entraîne des préoccupations. Les produits VMware sont chers et la politique commerciale peut évoluer rapidement (la mise en place d’une facturation à la mémoire vive utilisée, abandonnée par VMware par la suite, avait suscité un tollé auprès de ses clients).  De plus la réversibilité est complexe et coûteuse.

De son côté, Microsoft a décidé d’accélérer sa pénétration du marché en intégrant le produit Hyper-V dans Windows Server depuis la version 2008. Jusqu’ici en retard techniquement, Hyper-V s’est amélioré à chaque itération jusqu’à devenir, avec Windows Server 2012 R2 et la suite System Center, un sérieux challengeur de VMware.

Aujourd’hui, la course entre VMware et Microsoft ne se concentre plus sur les caractéristiques techniques maximales ou sur les fonctionnalités. En effet, bien que différentes, les deux solutions répondent à la très grande majorité des besoins (qui a besoin d’une machine virtuelle avec plus de 64 vCPU ?).

Alors comment choisir ? En pratique, VMware reste encore en avance au niveau de l’exploitabilité  et dispose d’un plus grand écosystème de composants compatibles, alors qu’Hyper-V est généralement plus compétitif financièrement.

Au-delà de ces points (qui sont à relativiser selon le contexte de chaque client et les accords éditeurs), ce sont la vision et les trajectoires des deux géants qui doivent être pris en considération.

Deux trajectoires différentes, mais une vision Cloud commune

Les deux constructeurs partagent en effet une vision du Cloud similaire, basée sur le pilotage unifié de ressources internes au sein d’un Cloud privé et externes au sein de leur Cloud public ou de celui d’un partenaire. En revanche leurs trajectoires sont différentes et liées à l’historique.

Ainsi VMware, fort sur la virtualisation on-premise, a développé une offre de Cloud privé complète et résiliente avant de développer des services de Cloud public (vCHS) et une interconnexion avec un réseau de partenaires (Amazon, OVH, et plus généralement tout fournisseur proposant un connecteur vCloud).

De son côté Microsoft a eu une approche inverse. Il est parti de son Cloud public Azure, lancé bien plus tôt, et a développé dans un second temps son offre de Cloud privé basée sur Hyper-V (avec la suite System Center et Azure pack) en intégrant progressivement les fonctionnalités développées pour Azure.

Qu’en conclure ? Nos deux géants ont une vision fondamentalement différente dans la conception des architectures du Cloud public ! Quand Microsoft adopte une approche où l’application doit intégrer la haute-disponibilité au sein de son architecture (concept dit du design for failure), VMware part au contraire du principe que c’est à l’infrastructure d’offrir des services résilients.

Qu’aller chercher avec Hyper-V ?

Le principal intérêt reste financier : Hyper-V est compétitif. Pour une entreprise ayant un important parc Windows Server, les licences nécessaires sont souvent déjà acquises par l’entreprise (licences Windows Server Datacenter et System center). Le levier d’économie est alors substantiel.

Un autre intérêt est la mise en place d’une stratégie de Dual Sourcing, en ayant une ligne de service Hyper-V et une ligne de service VMware. Ainsi, l’entreprise peut rester indépendante des fournisseurs tout en ayant de plus gros leviers de négociation.

En revanche, il ne faut pas sous-estimer la complexité et le coût d’un projet de migration d’une partie d’un parc. Une approche « Big Bang » est trop risquée et nous conseillons plutôt d’adopter une approche progressive.

Comment ? En commençant par expérimenter Hyper-V en démarrant un pilote sur un périmètre limité et non critique (par exemple quelques environnements de test / staging). Ce pilote permettra de vérifier l’exploitabilité de la plateforme et d’acquérir les compétences en interne. Une généralisation pourra être envisagée par la suite sur une filière complète (environnements de développements et de tests par exemple), selon  les résultats et les opportunités.

Si vous souhaitez aller plus loin en matière de « dual sourcing » et simplifier l’architecture globale, il est préférable de piloter les infrastructures Hyper-V et VMware avec la même solution. Microsoft (avec SCVMM), VMware (avec vCAC) ou des tiers (comme HP avec HP OO) proposent des outils, permettant alors de tirer bénéfice des deux plateformes, tout en simplifiant l’exploitation.

Et la cerise sur le gâteau ? Opter pour ces outils permettront à l’entreprise de se préparer à une approche Cloud Hybride !

Cet article Virtualisation : une hyper compétition entre VMware et Microsoft est apparu en premier sur RiskInsight.

Prenons un exemple simple : vous souhaitez changer de téléphone. Vous vous attendez  là à pouvoir récupérer à l’identique :

• vos données : vos contacts, vos photos, votre musique, vos messages, etc.
• vos applications : Candy crush ou encore l’application SolucomINSIGHT dont vous ne pouvez plus vous passer
• et même votre configuration : les mots de passe de vos Wifi, la configuration de vos comptes mails, etc.

La réversibilité c’est cela : la capacité à changer de fournisseur en conservant vos biens (données, applications, etc.). Dans le cas du Cloud Computing le principe est le même et selon le modèle de service, on s’attendra à pouvoir facilement transférer ses données (SaaS), ses applications (PaaS), et jusqu’à son OS dans le cas du IaaS.

Récupérer ses données dans le cas du SaaS

Le cas du SaaS est le plus simple et le plus compliqué à la fois. En effet, vous êtes dans le cas où vous ne récupérez que vos données, car elles seules vous appartiennent (l’application et toutes les couches inférieures sont la propriété de votre fournisseur). Certes la tâche est simplifiée, car c’est autant de travail en moins, mais encore faut-il définir le format et la méthode d’export.

Aujourd’hui aucune norme n’existe pour l’export des données.  Cependant, de nombreux fournisseurs de SaaS ont pensé une clause de réversibilité incluant la possibilité de réaliser a minima un export de ses données. Mieux : dans certains cas, l’API du fournisseur permet à des outils tiers de réaliser une migration automatisée vers un autre fournisseur. C’est le cas d’outils permettant de migrer de Salesforce.com vers Microsoft Dynamics et vice-versa.

Récupérer applications et données dans le cas du PaaS

Dans le cas du PaaS, vous récupérez votre application (son code source) et vos données. Vous aurez donc moins de problèmes de compatibilité des formats d’import et d’export des données, en revanche le problème se situe plus bas, au niveau de la compatibilité entre l’application et l’environnement d’exécution.

De plus, côté configuration de l’environnement d’exécution, il est fort probable que vous ne puissiez pas récupérer le détail de la configuration réalisée. C’est un peu le problème que vous auriez en changeant de téléphone pour des téléphones de marques différentes : au-delà des données, difficile d’exporter les applications et configurations.

Le point positif est que, concurrence oblige, certains fournisseurs se sont mis à développer des outils de migration pour vous attirer chez eux. C’est, par exemple, le cas du PaaS Engine Yard qui a développé un outil de migration d’Heroku (le PaaS de Salesforce) vers leur plateforme.

Et dans le cas du IaaS ?

Le cas du IaaS est peut-être le plus simple, car finalement il ne diffère pas beaucoup de ce que l’on faisait déjà dans les cas traditionnels d’infogérance. Les questions à se poser sont de trois ordres :

• quels moyens mettre en œuvre tout au long de la vie du contrat, notamment en matière de documentation ;
• quels moyens mettre en œuvre lors de la phase de réversibilité : notamment moyens humains et moyens techniques permettant d’accompagner la migration ;
• quel délai (période de transition) et quel coût associé (lui-même fonction des deux précédentes questions, mais aussi de l’impact de la propriété des licences OS et middleware par exemple).

Les seuls obstacles qui peuvent se présenter sont ceux du format d’export des machines virtuelles (format pivot type OVA – open virtual appliance – ou format constructeur ?) et des sauvegardes (comment récupère-t-on l’historique des sauvegardes ?).

Aujourd’hui nombre de fournisseurs proposent ainsi des exports des disques de données au format virtual machine disk (VMDK). Ils ne proposent cependant pas toujours l’OS pour des problématiques de licences. Ce qui peut constituer un frein à la réversibilité.

Les principaux obstacles à la réversibilité dans le Cloud vont donc être les formats d’export, les méthodes et moyens associés (techniques mais aussi humains), la sauvegarde et l’impact sur le coût de la migration.

Pour simplifier cette réversibilité, une solution plus globale peut être, dans le cas du IaaS ou du PaaS, l’usage d’un Cloud Hybride  qui permettra la portabilité des services d’un Cloud à l’autre ainsi que leur interopérabilité, et cela de façon transparente.

Une autre solution pourrait aussi être de conserver une partie de ses données en interne soit par des synchronisations de données, comme a pu le faire Arte par exemple, soit simplement par de la sauvegarde on-premises.

Dans tous les cas il est nécessaire de réfléchir à un plan de réversibilité détaillé, d’intégrer ce plan au contrat et, bien entendu, de le tester.

Enfin, si la réversibilité est encore un facteur de complexité aujourd’hui, on peut espérer que le développement des plateformes d’interopérabilité (iPaas et consorts) et la standardisation des Clouds, nous apportera dans le futur des solutions de portabilité entre fournisseurs aussi simples et efficaces que… la portabilité d’un numéro de téléphone.

Cet article Réversibilité dans le Cloud : préparez dès maintenant la prochaine étape du voyage ! est apparu en premier sur RiskInsight.