Le cloud sans tour de PaaS-PaaS
Publié par La rédaction le | Mis à jour le
Si le SaaS semble aller de soi (encore que.), il en va autrement de l'IaaS et du PaaS dont l'eldorado annoncé à engendré une Cour des Miracles virtuelle. Jean-Marc Defaut, Monsieur Cloud chez HP France, apporte son éclairage dans ce Big Bazar.
Silicon.fr - Le cloud est omniprésent. Est-ce la voie incontournable pour l'entreprise ? Comment percevez-vous l'état actuel des offres cloud ?
Jean-Marc Defaut - Tout d'abord, toutes les applications n'ont pas vocation à être virtualisées ou à passer en mode cloud.
Les fournisseurs de services cloud proposent de l'énergie numérique à travers des machines virtuelles qui s'adaptent dynamiquement et qui comprennent plus ou moins de composants logiciels. L'utilisateur peut ainsi utiliser des services ou applications sans se poser des questions sur l'hyperviseur, ou encore opter pour une ou plusieurs machines virtuelles chaînées ou non.
La plupart des offres cloud dignes de ce nom proposent de monter simplement des serveurs ou des machines virtuelles en quelques clics. Toutefois, on trouve encore de nombreuses offres qui ne proposent pas (ou très peu) d'outils d'administration de cette "Infrastructure as a Services".
On commence à voir apparaître des services annoncés comme PaaS, mais très différents. Comment s'y retrouver ?
Pour ce qui est du PaaS (Platform as a Service), il ne suffit pas d'ajouter du middleware à une infrastructure dynamique pour la transformer en PaaS, encore faut-il proposer aussi des outils de développement et de gestion des composants logiciels.
En outre, l'Application continuous Delevry (capacité à fournir l'application cloud de manière continue et à la mettre à jour sans interruption) est la clé de ce type de plate-forme.
Le développeur doit pouvoir assurer la promotion de son code, c'est-à-dire pouvoir le mettre automatiquement en test en quelques clics selon les étapes de validation, et de même pour le mettre en production. Bien entendu, tout cela repose sur un référentiel de code, avec instanciation de machines virtuelles selon les besoins.
Alors, de nombreux faussaires se servent de pseudo-PaaS comme clé d'entrée sur du soi-disant cloud ?
En effet, il existe de nombreux services qualifiés de PaaS par leurs hébergeurs, mais qui n'en possèdent que très peu de caractéristiques. Parmi les plates-formes sérieuses, on trouve CloudBees, ou Google Apps. Dans ces cas, tous les éléments sont présents et l'utilisateur n'a plus à se soucier de la mise en production. Instancier des objets est aussi simple à réaliser pour le logiciel que pour le matériel.
De nombreux acteurs du marché contribuent à cette confusion. Et cela convient parfaitement à des prestataires qui peuvent ainsi vendre diverses solutions en les qualifiant de cloud.
Qu'en est-il de l'IaaS (Infrastructure as a Service) ?
Certains acteurs se positionnent à la fois comme fournisseurs d'Iaas et de PaaS. Parmi eux, on retrouve Microsoft Azure ou HP Cloud Services, avec des modèles directs ou indirects (via des partenaires).
Plus généralement, sur ces deux types de solutions, quels critères permettent de faire le tri ?
Ce n'est pas parce qu'on a quatre roues qu'on dispose d'une voiture.
Les trois questions à se poser pour savoir si l'on a affaire à du cloud IaaS ou PaaS sont : Existe-t-il un portail de services ? Repose-t-il sur un catalogue de services ? La mise à disposition de tout cela est-elle immédiate ? Si ce n'est pas le cas, au mieux, on a juste les quatre roues !
Mais alors, s'il faut calibrer des VM et en définir des éléments, il reste encore à se préoccuper d'architecture. Aujourd'hui, tout cela n'est-il pas encore automatisé ?
L'idéal serait effectivement que tout ça soit automatisé. Actuellement, il faut encore instancier des machines virtuelles flexibles et y déposer le code pour la mise en production.
Cependant il est possible d'attribuer des propriétés dynamiques à une VM (machine virtuelle) ou à un groupe de VM.
Il suffit d'invoquer l'API de la plate-forme pour automatiser une tâche (allocation dynamique, migration automatique, etc.). En effet, une application peut déterminer si son environnement physique devient critique, et alors automatiquement générer l'évolution de l'infrastructure matérielle via cette API. Il faut toutefois que le développeur y pense en amont de son développement.
Quelques plates-formes de développement intègrent déjà dans leur framework les appels vers ce type d'API pour discuter avec les solutions de supervision de l'infrastructure. D'où l'importance d'utiliser des standards sur ce type d'éléments, à l'image de ce qui se fait avec Openstack.
Côté cloud privé (qui semble se développer très rapidement aussi), existe-t-il des indifférences majeures ?
Généralement les offres de cloud privé répliquent les modes de fonctionnement du cloud public à l'intérieur du firewall : catalogue de services, portails, mécanismes de mesure et de facturation, Openstack intégré (ou autre), possibilité de mettre en place des infrastructures hybrides.
Selon vous, quels critères doit vérifier un utilisateur avant d'adopter une solution de cloud privé ?
Je mettrais en avant quatre points essentiels.
Tout d'abord, une couche d'accès aux ressources est indispensable pour éviter d'être pieds et poings liés avec un fournisseur : serveur, stockage, réseau, hyperviseur, liens avec les clouds externes, etc.
On retrouve ici l'importance d'Openstack, qui permet d'obtenir un contrôleur cloud unique (compatible avec tous les clouds). Ainsi, un programmeur peut utiliser la même fonction depuis l'application pour interagir avec un cloud externe, sans avoir à connaître ses spécificités a priori.
Puisqu'une plate-forme cloud permet d'instancier n'importe quel objet, la couche d'instanciation doit offrir un service prêt à l'emploi, sans que l'utilisateur ait à se préoccuper des « boulons ». Pour gérer et harmoniser l'explosion de tous ces objets, une couche d'orchestration doit non seulement assurer cette coordination, mais aussi permettre d'automatiser et de livrer à la volée tout service ou objet.
Dans un tel environnement, la cohérence n'est possible qu'avec un point unique de design : le référentiel qui permet de concevoir les services en gérant les éléments de l'infrastructure physique, des logiciels, du code binaire, du monitoring.
Enfin, le portail doit jouer un rôle de pilotage des services qui s'appuient sur le référentiel, et faciliter la gestion grâce à des mesures et une fonction de tarification évoluée. Généralement, l'éditeur propose des modèles (blueprints) servant de base à l'utilisateur qui peut décliner et paramétrer les modes de souscription à un service, la modification des souscriptions. ainsi qu'une fonction de reporting favorisant l'audit.
S'il manque l'un de ces éléments, l'entreprise rencontrera certainement des problèmes.
Certains éditeurs proposent encore du cloud privé, sans réel orchestrateur ni portail. Ils obligent alors l'utilisateur à créer des scripts d'automatisation, ce qui reste assez éloigné d'une orchestration en mode cloud. De plus, l'orchestrateur doit bien prendre en charge l'infrastructure physique (serveur, stockage et réseau) et le cycle de vie des services.
Voir aussi
Quiz Silicon.fr - Le vocabulaire du cloud