Le 17 février 2012 (08:30) - par Christophe Bardy
A l'heure où l'adoption du cloud par les entreprises s'accélère,
l'interopérabilité des clouds restent un voeux pieux, avec le risque à
terme d'un enfermement dans des approches propriétaires qui pourrait
être nuisibles aux objectifs recherchés par les entreprises dans leur
migration vers le cloud. LeMagIT fait un état des problèmes et des
travaux en cours en matière d'interopérabilité.
Depuis l’émergence du cloud, les entreprises utilisatrices se posent
la question de l’interopérabilité entre les différents services cloud.
Cette préoccupation n’est pas anodine. Pour nombre d’entreprises, il
s’agit d’éviter les phénomènes de verrouillage (vendor « lock-in ») que
l’on a connu par le passé dans les environnements physiques et de rendre
fluide la migration de ressources d’un cloud vers un autre. Pour
d’autres, il s’agit de simplifier la constitution d’architectures
hybrides visant à mixer ressources internes et ressources cloud. Pour
certains, il s’agit d’assurer la portabilité des données d’un cloud à un
autre ou du datacenter de l’entreprise vers le cloud et vice-versa.
Enfin d'autres encore rêvent de la possibilité de coordonner de façon
transparente l’orchestration de ressources distribuées sur de multiples
cloud, et donc sur des infrastructures utilisant souvent des APIs très
différentes pour permettre leur pilotage.
Un univers en quête de standards
Dès 2009, la DMTF( Distributed Management Task Force) a mis en place un incubateur afin d’effectuer des travaux sur le sujet et de tenter d’élaborer des normes d'interopérabilité pour l’administration de cloud. Le groupe avait il est vrai déjà contribué à améliorer l’interopérabilité des environnements virtualisés en poussant à l’adoption du format OVF (Open Virtualization Format) qui permet de définir et modéliser des chaînes applicatives complexes incluant plusieurs machines virtuelles. OVF est aujourd’hui le format de fait d’échange de machines virtuelles entre plates-formes virtualisées. Pour avoir une idée du défi que représente l’interopérabilité dans le cloud, il suffit de constater qu’après 5 ans d’adoption rapide de la virtualisation, les éditeurs sont toujours incapables de s’accorder sur un format de disque virtuel (un problème tellement sensible que la DMTF ne l’a pas traité dans OVF). Ainsi VMware continue d’utiliser son VMDK tandis que Microsoft et Citrix lui préfèrent le VHD – et bientôt le VHDX dans Windows 8 Server - et que KVM privilégie le format QEMU (qcow2-). Et c’est sans compter avec les problèmes spécifiques qu’introduisent certains cloud comme l’utilisation de formats « propriétaires » comme le format d’image AMI d’Amazon…
Et encore ne parle-t-on ici que des problèmes liés au cloud d’infrastructure. Car si l’on aborde la question du PaaS, le problème devient inextricable. Certes le code applicatif développé pour le cloud X peut en général être porté sans trop d’efforts sur le cloud Y (disons de Heroku à Azure ou de Joyent à Heroku), mais les couches d’administration réseau, de bases de données, de load balancing et d’orchestration sont toutes différentes ce qui rend plus que délicat la migration d’une application déployée sur un PaaS X vers un PaaS Y.
Après 10 ans d’efforts pour standardiser l’exploitation de ressources informatiques dans les datacenters, un effort largement rendu possible par la standardisation d’une large part de la production informatique sur des serveurs x86 et sur un nombre réduit d’OS (comme Windows, Linux et Solaris x86), les entreprises se retrouvent donc une nouvelle fois face à la perspective de devoir gérer de multiples formats, outils et API d’administration et ce, alors qu’elles sont sous pression de la part de leur management pour adopter le cloud.
harmoniser la manipulation des objets d'un cloud à un autre
Au cœur de l’interopérabilité du cloud se trouve tout d’abord la possibilité de manipuler de façon standard les différents objets du cloud. Cela commence comme on l’a vu par un minimum de standardisation des images serveurs, mais aussi par une standardisation de la configuration des objets réseau (firewall, configuration réseau…). Il s’agit de répondre à des questions basiques comme comment migrer une application de mon datacenter vers le cloud ou comment migrer une application d’un cloud à un autre.
Aujourd’hui la question reste toujours problématique. Certes il est relativement simple de porter une application physique vers un conteneur virtuel et de migrer ce dernier sur un cloud d’infrastructure. Mais cela se fait toujours au prix de multiples manipulations de conversion ou d’adaptation. Par exemple, une image système destinée à fonctionner sur Hyper-V devra comporter des pilotes différents de ceux d’une image destinée à s’exécuter sur XenServer ou VMware vSphere si elle veut fonctionner de façon optimale (et parfois tout simplement démarrer). Cela contraint les entreprises à maintenir de multiples versions des mêmes images systèmes et à cultiver de vrais savoir-faire en matière de conversion de VM.
La question du paramétrage réseau est encore plus compliquée. Les cloud ont en effet une gestion du réseau assez particulière du fait de leur contrainte d’offrir une infrastructure « multitenant ». Et il est plus que probable qu’un nuage X aura une gestion du réseau différente du nuage Y (et des méthodologies différentes pour piloter les firewall, routeurs, commutateurs et autres services essentiels au bon fonctionnement d’un environnement de production informatique). Ignorer l’existence de ces différences, c’est risquer de mettre les pieds dans un environnement cloud et ne plus pouvoir en sortir (du moins facilement). C’est d’ailleurs la situation dans laquelle se trouvent, de facto, la plupart des entreprises qui ont adopté très tôt la virtualisation et le cloud, leurs efforts s’étant largement concentrés sur un fournisseur unique.
Bataille autour de l’orchestration de clouds d’infrastructure
Ce vendeur, VMware, a perçu très tôt les problèmes d’interopérabilité que pose la migration d’infrastructures entières vers le cloud et leur orchestration. Et il a mis en place un ensemble de mécanismes propriétaires et ouverts (ou en tout cas documentés) pour permettre l’interconnexion transparente de ressources situées au sein de datacenters d’entreprises, avec des ressources situées dans le cloud (via son outil d’orchestration vCloud). Avec vCloud, il est en théorie possible d’opérer un ensemble de datacenter virtuels comme une entité unique quelle que soit leur localisation ou le fournisseur qui les héberge. Cisco a encore un peu plus facilité la gestion réseau d’un cloud distribué entre de multiples datacenters en apportant des technologies de tunneling comme OTV (Overlay Transport Virtualization) dans ses commutateurs Nexus – OTV fait ce que l’on appelle du MAC in IP, c’est-à-dire qu’il permet d’encapsuler un trafic Ethernet de niveau 2 au niveau 3 et permet donc à des infrastructures cloud dans deux datacenters d’être gérées comme une seule entité - et en intégrant dans son commutateur Nexus 1000v le support de technologies comme VXLAN. Ces technologies n’en sont toutefois qu’à leurs débuts ou restent très largement limitées au monde VMware (même si VMware a soumi svCloud à la DMTF dans l'espoir d'en faire la base d'un standard d'interopérabilité).
Leur interopérabilité avec des environnements tiers, par exemple basés sur KVM, Xen ou Hyper-V est pour l’instant... nulle (VXLAN devrait arriver sur Hyper-V 3.0 fin 2012 avec le portage en cours du Nexus-1000v pour l’hyperviseur de Microsoft). VMware contre cet argument en notant qu’il existe de multiples fournisseurs vCloud et que les entreprises ont donc le choix entre de multiples cloud. C’est vrai… À condition toutefois qu’elles standardisent l’orchestration de leur cloud interne sur vCloud. Bref, pour gagner une forme d’interopérabilité dans le monde cloud tel que vu par VMware, il faut déployer les solutions de l’éditeur de bout en bout aussi bien en interne qu’en externe. C’est un peu comme si l’on revenait 30 ans en arrière, où pour être interopérable avec les mainframes IBM, il fallait faire tourner leur OS et leur moniteur transactionnel et c’est pour le moins une curieuse interprétation de la notion d’interopérabilité…
À la décharge de VMware, sa vision du cloud n’est guère différente de celle imaginée pour l’instant par Microsoft, pour lequel le discours sur l’interopérabilité se résume largement à encourager les entreprises à adopter System Center 2012 pour gérer l’ensemble de ses infrastructures virtualisées(SC 2012 supporte la gestion de ressources virtualisées avec XenServer, vSphere et Hyper-V ainsi que la gestion de ressources sur le nuage maison, Azure). Encore une fois, les deux titans de la virtualisation ont des excuses. Le domaine est récent et évolue à une vitesse accélérée. Mais faute de prévoir très tôt l’interopérabilité, les deux sociétés s’exposent à reproduire des erreurs, qui, par le passé, ont toujours fini par leur revenir dans la figure que ce soit avec l’émergence de Linux contre Windows, ou avec les ennuis juridiques liés aux poursuites initiées par différentes agences en charge de la concurrence dans le monde.
Le monde open source en ébullition
Dans un monde où les technologies évoluent à un rythme rapide, l’Open Source s’organise d’ailleurs rapidement et promet de prendre en compte le besoin d’interopérabilité (tant que l’on reste dans le monde libre). Depuis plusieurs années, Red Hat travaille au développement d’une série d’API censées apporter l’interopérabilité entre architectures virtualisées.Son projet Deltacloud est aujourd’hui un projet de premier rang de la fondation Apache, visant à fournir une API unique pour gérer de multiples clouds hétérogènes (et Red Hat a, comme VMware, soumis deltaCloud à la DMTF). Et le moins que l’on puisse dire est que la route risque encore d’être longue pour que deltaCloud répondent aux besoins des entreprises. La partie « compute « de l’API ne supporte en effet que des fonctions basiques d’inventaire, de création, démarrage et arrêt de machines virtuelles sur une dizaine de « cloud » (dont ceux pilotés par les technologies VMware, OpenStack, Amazon EC2, et RHEV-M).
Un univers en quête de standards
Dès 2009, la DMTF( Distributed Management Task Force) a mis en place un incubateur afin d’effectuer des travaux sur le sujet et de tenter d’élaborer des normes d'interopérabilité pour l’administration de cloud. Le groupe avait il est vrai déjà contribué à améliorer l’interopérabilité des environnements virtualisés en poussant à l’adoption du format OVF (Open Virtualization Format) qui permet de définir et modéliser des chaînes applicatives complexes incluant plusieurs machines virtuelles. OVF est aujourd’hui le format de fait d’échange de machines virtuelles entre plates-formes virtualisées. Pour avoir une idée du défi que représente l’interopérabilité dans le cloud, il suffit de constater qu’après 5 ans d’adoption rapide de la virtualisation, les éditeurs sont toujours incapables de s’accorder sur un format de disque virtuel (un problème tellement sensible que la DMTF ne l’a pas traité dans OVF). Ainsi VMware continue d’utiliser son VMDK tandis que Microsoft et Citrix lui préfèrent le VHD – et bientôt le VHDX dans Windows 8 Server - et que KVM privilégie le format QEMU (qcow2-). Et c’est sans compter avec les problèmes spécifiques qu’introduisent certains cloud comme l’utilisation de formats « propriétaires » comme le format d’image AMI d’Amazon…
Et encore ne parle-t-on ici que des problèmes liés au cloud d’infrastructure. Car si l’on aborde la question du PaaS, le problème devient inextricable. Certes le code applicatif développé pour le cloud X peut en général être porté sans trop d’efforts sur le cloud Y (disons de Heroku à Azure ou de Joyent à Heroku), mais les couches d’administration réseau, de bases de données, de load balancing et d’orchestration sont toutes différentes ce qui rend plus que délicat la migration d’une application déployée sur un PaaS X vers un PaaS Y.
Après 10 ans d’efforts pour standardiser l’exploitation de ressources informatiques dans les datacenters, un effort largement rendu possible par la standardisation d’une large part de la production informatique sur des serveurs x86 et sur un nombre réduit d’OS (comme Windows, Linux et Solaris x86), les entreprises se retrouvent donc une nouvelle fois face à la perspective de devoir gérer de multiples formats, outils et API d’administration et ce, alors qu’elles sont sous pression de la part de leur management pour adopter le cloud.
| L’Open Data Center Alliance pousse les fournisseurs à plus d’interopérabilité |
| Cliquez pour dérouler |
Au cœur de l’interopérabilité du cloud se trouve tout d’abord la possibilité de manipuler de façon standard les différents objets du cloud. Cela commence comme on l’a vu par un minimum de standardisation des images serveurs, mais aussi par une standardisation de la configuration des objets réseau (firewall, configuration réseau…). Il s’agit de répondre à des questions basiques comme comment migrer une application de mon datacenter vers le cloud ou comment migrer une application d’un cloud à un autre.
Aujourd’hui la question reste toujours problématique. Certes il est relativement simple de porter une application physique vers un conteneur virtuel et de migrer ce dernier sur un cloud d’infrastructure. Mais cela se fait toujours au prix de multiples manipulations de conversion ou d’adaptation. Par exemple, une image système destinée à fonctionner sur Hyper-V devra comporter des pilotes différents de ceux d’une image destinée à s’exécuter sur XenServer ou VMware vSphere si elle veut fonctionner de façon optimale (et parfois tout simplement démarrer). Cela contraint les entreprises à maintenir de multiples versions des mêmes images systèmes et à cultiver de vrais savoir-faire en matière de conversion de VM.
La question du paramétrage réseau est encore plus compliquée. Les cloud ont en effet une gestion du réseau assez particulière du fait de leur contrainte d’offrir une infrastructure « multitenant ». Et il est plus que probable qu’un nuage X aura une gestion du réseau différente du nuage Y (et des méthodologies différentes pour piloter les firewall, routeurs, commutateurs et autres services essentiels au bon fonctionnement d’un environnement de production informatique). Ignorer l’existence de ces différences, c’est risquer de mettre les pieds dans un environnement cloud et ne plus pouvoir en sortir (du moins facilement). C’est d’ailleurs la situation dans laquelle se trouvent, de facto, la plupart des entreprises qui ont adopté très tôt la virtualisation et le cloud, leurs efforts s’étant largement concentrés sur un fournisseur unique.
Bataille autour de l’orchestration de clouds d’infrastructure
Ce vendeur, VMware, a perçu très tôt les problèmes d’interopérabilité que pose la migration d’infrastructures entières vers le cloud et leur orchestration. Et il a mis en place un ensemble de mécanismes propriétaires et ouverts (ou en tout cas documentés) pour permettre l’interconnexion transparente de ressources situées au sein de datacenters d’entreprises, avec des ressources situées dans le cloud (via son outil d’orchestration vCloud). Avec vCloud, il est en théorie possible d’opérer un ensemble de datacenter virtuels comme une entité unique quelle que soit leur localisation ou le fournisseur qui les héberge. Cisco a encore un peu plus facilité la gestion réseau d’un cloud distribué entre de multiples datacenters en apportant des technologies de tunneling comme OTV (Overlay Transport Virtualization) dans ses commutateurs Nexus – OTV fait ce que l’on appelle du MAC in IP, c’est-à-dire qu’il permet d’encapsuler un trafic Ethernet de niveau 2 au niveau 3 et permet donc à des infrastructures cloud dans deux datacenters d’être gérées comme une seule entité - et en intégrant dans son commutateur Nexus 1000v le support de technologies comme VXLAN. Ces technologies n’en sont toutefois qu’à leurs débuts ou restent très largement limitées au monde VMware (même si VMware a soumi svCloud à la DMTF dans l'espoir d'en faire la base d'un standard d'interopérabilité).
Leur interopérabilité avec des environnements tiers, par exemple basés sur KVM, Xen ou Hyper-V est pour l’instant... nulle (VXLAN devrait arriver sur Hyper-V 3.0 fin 2012 avec le portage en cours du Nexus-1000v pour l’hyperviseur de Microsoft). VMware contre cet argument en notant qu’il existe de multiples fournisseurs vCloud et que les entreprises ont donc le choix entre de multiples cloud. C’est vrai… À condition toutefois qu’elles standardisent l’orchestration de leur cloud interne sur vCloud. Bref, pour gagner une forme d’interopérabilité dans le monde cloud tel que vu par VMware, il faut déployer les solutions de l’éditeur de bout en bout aussi bien en interne qu’en externe. C’est un peu comme si l’on revenait 30 ans en arrière, où pour être interopérable avec les mainframes IBM, il fallait faire tourner leur OS et leur moniteur transactionnel et c’est pour le moins une curieuse interprétation de la notion d’interopérabilité…
À la décharge de VMware, sa vision du cloud n’est guère différente de celle imaginée pour l’instant par Microsoft, pour lequel le discours sur l’interopérabilité se résume largement à encourager les entreprises à adopter System Center 2012 pour gérer l’ensemble de ses infrastructures virtualisées(SC 2012 supporte la gestion de ressources virtualisées avec XenServer, vSphere et Hyper-V ainsi que la gestion de ressources sur le nuage maison, Azure). Encore une fois, les deux titans de la virtualisation ont des excuses. Le domaine est récent et évolue à une vitesse accélérée. Mais faute de prévoir très tôt l’interopérabilité, les deux sociétés s’exposent à reproduire des erreurs, qui, par le passé, ont toujours fini par leur revenir dans la figure que ce soit avec l’émergence de Linux contre Windows, ou avec les ennuis juridiques liés aux poursuites initiées par différentes agences en charge de la concurrence dans le monde.
Le monde open source en ébullition
Dans un monde où les technologies évoluent à un rythme rapide, l’Open Source s’organise d’ailleurs rapidement et promet de prendre en compte le besoin d’interopérabilité (tant que l’on reste dans le monde libre). Depuis plusieurs années, Red Hat travaille au développement d’une série d’API censées apporter l’interopérabilité entre architectures virtualisées.Son projet Deltacloud est aujourd’hui un projet de premier rang de la fondation Apache, visant à fournir une API unique pour gérer de multiples clouds hétérogènes (et Red Hat a, comme VMware, soumis deltaCloud à la DMTF). Et le moins que l’on puisse dire est que la route risque encore d’être longue pour que deltaCloud répondent aux besoins des entreprises. La partie « compute « de l’API ne supporte en effet que des fonctions basiques d’inventaire, de création, démarrage et arrêt de machines virtuelles sur une dizaine de « cloud » (dont ceux pilotés par les technologies VMware, OpenStack, Amazon EC2, et RHEV-M).
A l'heure où l'adoption du cloud par les entreprises s'accélère,
l'interopérabilité des clouds restent un voeux pieux, avec le risque à
terme d'un enfermement dans des approches propriétaires qui pourrait
être nuisibles aux objectifs recherchés par les entreprises dans leur
migration vers le cloud. LeMagIT fait un état des problèmes et des
travaux en cours en matière d'interopérabilité.
Amazon, dont le cloud s'appuie sur des briques de virtualisation
libres (Xen), a largement publié ses API, qui sont devenues une forme de
référence pour certains éditeurs, à tels points que de nombreux projets
libres font du support des API Amazon un passage obligé (c'est par
exemple le cas d'OpenStack, qui supporte très bien les API Amazon, même
si à terme, le projet espère que ses propres API prendront le pas en
terme de popularité sur celles d'Amazon).
OpenStack est conçu, en principe pour supporter de multiples technologies de virtualisation sous-jacentes. Mais la priorité des développeurs est pour l’instant au support des grands hyperviseurs open source (Xen et KVM) ainsi qu’à celui de l’API d’Amazon et de vSphere. Le support d’Hyper-V par OpenStack est au point mort. D’une certaine façon, OpenStack émerge aujourd’hui comme la principale alternative à vCloud de VMware pour la constitution de clouds d'infrastructure, ce qui ne veut pas dire qu’il règle par miracle tous les problèmes d’interopérabilité. Avec OpenStack, on peut par exemple envisager de déplacer à froid une machine virtuelle d’un hyperviseur à un autre (pour peu que l’on ait pris quelques précautions). En revanche, la gestion de la couche réseau dans OpenStack est encore l’objet d’importants développements. et il en va de même des couches hautes en matière de gestion de SLA ou de gouvernance.
Avec son rachat de Cloud.com, Citrix dispose aussi d’une couche d’orchestration de cloud - baptisée CloudStack - qui supporte un grand nombre d’hyperviseurs comme celui de VMware, mais aussi KVM et Xen. La couche d’orchestration open source de l’éditeur est sans doute l’une des plus avancée du moment, si l’on exclut celle d’OpenStack qui progresse à grand pas. Elle est d'ailleurs déployée à l'échelle industrielle par plusieurs grands clouds comme ceux opérés par Korea Telecom, Tata ou Zynga
Interopérabilité aussi pour la gouvernance et la facturation des clouds
Il est à noter qu’au-delà des considérations purement techniques, de nombreuses entreprises poussent aussi à l’uniformisation des informations permettant la gouvernance des clouds. Elles demandent notamment des mécanismes de reporting standardisés en matière de sécurité, de conformité, mais aussi une forme d’unification des mécanismes de facturation (au travers de la définition d’unités d’œuvres comparables de cloud à cloud). Des exigences similaires apparaissent pour le reporting de SLA, prouvant encore une fois que les exigences d’interopérabilité vont bien au-delà de simples paramètres techniques.
Le casse-tête du PaaS
L’un des modèles de Cloud les plus prometteurs, le PaaS, est aussi celui qui pose aujourd’hui le plus grand nombre de problèmes d’interopérabilité. Si la portabilité du code entre PaaS est possible, notamment du fait que la plupart des Cloud PaaS supportent de multiples langages , c’est surtout au niveau des couches d’administration, de services et d’orchestration que se posent aujourd’hui les problèmes.
Par exemple, tous les cloud PaaS utilisent un système de versionning différent, un bus applicatif et un système de workflow différents. Tous utilisent une couche de base de données différente et c’est sans parler de la gestion du load balancing, de la configuration des services réseau, des services de sécurité…
Encore une fois, cela semble peu préoccuper les géants du secteur. Microsoft est 100 % concentré sur Azure et sur l’enrichissement de ses fonctions et les préoccupations d’interopérabilité figurent bien loin dans les priorités de l’éditeur. VMware de même est tout au développement de sa plate-forme de PaaS Cloud Foundry, avec un objectif similaire à celui de vCloud. Convaincre les entreprises d’adopter Cloud Foundry en interne puis offrir via de multiples partenaires – opérateurs, SSII, hébergeurs – des services de cloud Foundry interopérables avec ceux déjà opérés en interne par l’entreprise.
Reste à savoir si au lieu d’interopérabilité, les utilisateurs se satisferont d’uniformité. Une recette qui par le passé a eu ses avantages et ses (gros) inconvénients et est loin d’avoir fait ses preuves…
OpenStack est conçu, en principe pour supporter de multiples technologies de virtualisation sous-jacentes. Mais la priorité des développeurs est pour l’instant au support des grands hyperviseurs open source (Xen et KVM) ainsi qu’à celui de l’API d’Amazon et de vSphere. Le support d’Hyper-V par OpenStack est au point mort. D’une certaine façon, OpenStack émerge aujourd’hui comme la principale alternative à vCloud de VMware pour la constitution de clouds d'infrastructure, ce qui ne veut pas dire qu’il règle par miracle tous les problèmes d’interopérabilité. Avec OpenStack, on peut par exemple envisager de déplacer à froid une machine virtuelle d’un hyperviseur à un autre (pour peu que l’on ait pris quelques précautions). En revanche, la gestion de la couche réseau dans OpenStack est encore l’objet d’importants développements. et il en va de même des couches hautes en matière de gestion de SLA ou de gouvernance.
Avec son rachat de Cloud.com, Citrix dispose aussi d’une couche d’orchestration de cloud - baptisée CloudStack - qui supporte un grand nombre d’hyperviseurs comme celui de VMware, mais aussi KVM et Xen. La couche d’orchestration open source de l’éditeur est sans doute l’une des plus avancée du moment, si l’on exclut celle d’OpenStack qui progresse à grand pas. Elle est d'ailleurs déployée à l'échelle industrielle par plusieurs grands clouds comme ceux opérés par Korea Telecom, Tata ou Zynga
| Compatible One : quand les Français se préoccupent d'interopérabilité |
| Cliquez pour dérouler |
Il est à noter qu’au-delà des considérations purement techniques, de nombreuses entreprises poussent aussi à l’uniformisation des informations permettant la gouvernance des clouds. Elles demandent notamment des mécanismes de reporting standardisés en matière de sécurité, de conformité, mais aussi une forme d’unification des mécanismes de facturation (au travers de la définition d’unités d’œuvres comparables de cloud à cloud). Des exigences similaires apparaissent pour le reporting de SLA, prouvant encore une fois que les exigences d’interopérabilité vont bien au-delà de simples paramètres techniques.
Le casse-tête du PaaS
L’un des modèles de Cloud les plus prometteurs, le PaaS, est aussi celui qui pose aujourd’hui le plus grand nombre de problèmes d’interopérabilité. Si la portabilité du code entre PaaS est possible, notamment du fait que la plupart des Cloud PaaS supportent de multiples langages , c’est surtout au niveau des couches d’administration, de services et d’orchestration que se posent aujourd’hui les problèmes.
Par exemple, tous les cloud PaaS utilisent un système de versionning différent, un bus applicatif et un système de workflow différents. Tous utilisent une couche de base de données différente et c’est sans parler de la gestion du load balancing, de la configuration des services réseau, des services de sécurité…
L'architecture de communication entre utilisateurs et fournisseurs
de cloud, telle que vue par Compatible One
En l’état, le choix d’une plate-forme SaaS est encore plus
« verrouillant » que le choix d’une plate-forme IaaS, même si certains
acteurs ont appris à gérer des workload réparties entre plusieurs
fournisseurs PaaS. Et plus les services des plates-formes PaaS
s’enrichissent, plus la perspective d’une interopérabilité entre ces
plates-formes s’éloigne.de cloud, telle que vue par Compatible One
Encore une fois, cela semble peu préoccuper les géants du secteur. Microsoft est 100 % concentré sur Azure et sur l’enrichissement de ses fonctions et les préoccupations d’interopérabilité figurent bien loin dans les priorités de l’éditeur. VMware de même est tout au développement de sa plate-forme de PaaS Cloud Foundry, avec un objectif similaire à celui de vCloud. Convaincre les entreprises d’adopter Cloud Foundry en interne puis offrir via de multiples partenaires – opérateurs, SSII, hébergeurs – des services de cloud Foundry interopérables avec ceux déjà opérés en interne par l’entreprise.
Reste à savoir si au lieu d’interopérabilité, les utilisateurs se satisferont d’uniformité. Une recette qui par le passé a eu ses avantages et ses (gros) inconvénients et est loin d’avoir fait ses preuves…
http://www.lemagit.fr/article/microsoft-citrix-vmware-interoperabilite-amazon-kvm-xen-cloud-red-hat-openstack/10491/1/le-cloud-mal-interoperabilite/?utm_source=essentielIT&utm_medium=email&utm_content=new&utm_campaign=20120220&xtor=ES-6
Aucun commentaire:
Enregistrer un commentaire