L'informatique est friand des trigrammes et des abréviations et le monde du cloud computing ne fait pas exception à la règle : Iaas, PaaS, SaaS. Ces trois termes proposent de segmenter l'offre de cloud computing. Au delà des mots, qu'est-ce que cela signifie vraiment pour votre entreprise. L'objectif de cet article est de proposer deux visions différentes pour segmenter ce marché : l'une par type de contrat offert, l'autre par typologie de service offert. Nous en tirerons en synthèse quelques repères pour analyser une offre sur ce marché.
Le cloud computing désigne une nouvelle façon de commercialiser des ressources informatiques au sens large sous forme de service. En pratique, une application web ou un service web permet de réserver une ressource (application, machine, plateforme), d'interagir avec elle au travers d'internet, et de payer cette ressource au prorata de l'utilisation, sans limite de scalabilité. Le terme de ressource est à prendre ici au sens large : il peut s'agir de logiciels, de machines, d'unités de stockage. Le terme cloud est largement repris depuis quelque temps et il a parfois divergé. Parmi les caractéristiques qui permettent d'identifier ces offres je retiendrai :
L'offre de cloud computing peut être présentée comme une pile de trois services. IaaS pour Infrastructure as a Service, désigne les fondations du cloud computing. Il s'agit d'offres de capacité de calcul, stockage et réseau sous une forme comparable à une machine virtuelle.
Cette segmentation s'appuie globalement sur la notion de ressources partagées ou gérées en propre et de contrat conclu entre l'utilisateur et le fournisseur de cloud computing. Elle peut être représentée de la façon suivante :
Le contrat de plus bas niveau proposé est comparable à une machine virtuelle. On parle alors d'Infrastructure as a Service. C'est le cas par exemple du couple EC2 et EBS chez Amazon. Les autres acteurs de ce domaine (ex. GoGrid) respectent le même contrat. C'est un contrat simple, parfaitement reconnu par les systèmes d'exploitation Linux, Windows, Solaris (à quelques paramétrages près, ce qui incite à utiliser une image du système d'exploitation préinstallé par Amazon ou par l'éditeur du système d'exploitation).
Ce contrat offre peu de dépendance car même dans un DataCenter traditionnel, Linux et Windows sont les deux systèmes d'exploitation les plus répandus. Avoir un contrat de type machine conduit à remplacer un achat de matériel réalisé auprès d'un constructeur de serveurs par une location souscrite auprès d'un fournisseur de cloud computing. Dans ce type de contrat, on partage avec d'autres clients la machine. Au niveau de la sécurité, le mécanisme de virtualisation garantit que le système d'exploitation que vous installez est isolé : il ne peut accéder qu'à son espace mémoire, à son volume de disque. Un système comme Amazon Virtual Private Cloud garantit en plus que vos machines ne sont adressables que sur votre sous-réseau.
Cependant les ressources physiques restent partagées. Se pose alors la question des performances. Si on prend l'exemple d'Amazon, celui-ci s'engage sur des équivalents CPU et une quantité de mémoire vive qui sont, d'après la documentation, dédiées à chaque instance. Les entrées/sorties (I/O) du stockage et du réseau sont partagées avec les autres utilisateurs. Le type d'instance choisi (et donc le prix du service) ne donne qu'un avantage qualitatif : I/O "moderate" ou "high". Si on se penche sur le service Amazon EBS fournissant des disques durs persistants pour EC2, le paragraphe "Volume Performance" indique que les performances seront influencées par les capacités I/O et seront à tester au cas par cas. Aujourd'hui, la blogosphère est assez active sur le sujet, je citerai cet article qui indique des débits disques pour EC2 (hors EBS) tout à fait raisonnables. Une présentation réalisée conjointement par une startup utilisant MySQL sur EC2 et MySQL fait également état de performances qui l'ont satisfaite (diapositives 27 à 29) malgré quelques points négatifs.
Alors que retenir? Le contrat minimal du cloud computing est de partager des ressources. Intrinsèquement cela suppose un risque de sécurité et une question sur les performances. La sécurité doit être garantie de façon contractuelle par le fournisseur de service. Le contrat implicite au niveau de la performance sera de dimensionner les instances selon ses besoins. La comparaison se fera au niveau du prix payé pour les ressources consommées par rapport au coût d'une installation physique. Le gain sera particulièrement important pour une infrastructure peu utilisée, dimensionnée pour les pics de charge. Très difficile à amortir à l'achat, elle sera beaucoup plus rentable sur le cloud où l'on paye à la consommation.
Dans le contrat de type IaaS, seul le matériel est dans le cloud. Le niveau suivant consiste à inclure la plateforme chez le fournisseur. Dans ce cas le contrat repose sur des API ou un environnement d'exécution au sens du développement qu'il faudra respecter. On parle alors de Plateforme As A Service. Ce niveau de contrat est beaucoup plus diversifié. C'est le cas de Google App Engine et Microsoft Azure qui offrent respectivement un environnement Java et .NET permettant l'exécution d'applications dans le cloud. C'est également le cas de bon nombre de services Amazon : S3, Elastic Map Reduce, Paiment font également partie de cette catégorie car ils seront combinés par des développeurs pour fournir de la valeur ajoutée.
Le premier constat est qu'il y a une grande diversité des contrats et des services fournis. Google App Engine et Microsoft Azure permettent de déployer des applications développées en Java et en .NET. Cependant les API ne sont pas tout à fait identiques à leur version classique (toutes les classes du JDK ne sont pas disponibles dans Google App Engine, toutes les classes .NET ne sont pas à priori disponibles dans Azure), le packaging est également différent. Google offre une pile complètement intégrée pour réaliser des applications web. Microsoft propose une pile complète de services de la base de données relationnelle à l'environnement d'exécution d'applications web. Amazon propose des services de plus bas niveau et plus disparates : stockage de BLOB (S3), stockage non relationnel (SDB), calcul réparti (ElasticMapReduce). La dépendance envers l'API du PaaS, est variable en fonction des plateformes, mais elle est beaucoup plus importante qu'avec une offre de type IaaS. En effet, les offres permettant une portabilité entre le cloud et un déploiement interne sont aujourd'hui très peu nombreuses. La portabilité entre plusieurs fournisseurs PaaS est aujourd'hui inexistante. Les données sont également stockées dans le cloud dans un format qui est parfois propre au fournisseur (exemple du DataStore de Google App Engine).
Dans ce type de contrat, au delà de la machine et du réseau, l'environnement d'exécution (système d'exploitation et middleware) est partagé. Au niveau de la sécurité cela signifie qu'elle devra être entièrement gérée au niveau applicatif à travers les fonctionnalités offertes par la plateforme. Au niveau des performances il faut distinguer deux types de facturation possibles :
Dans le second cas, l'offre est beaucoup plus scalable car le fournisseur prend à sa charge l'optimisation pour que la 101ème requête de la seconde ne consomme pas plus de ressources que la première.
Le plus grand bouleversement viendra à mon sens du changement sur l'organisation de l'entreprise. Les tâches d'administration (montée de version, backup, monitoring des machines) sont désormais à la charge du fournisseur de cloud computing. Le contrat d'interface avec le fournisseur repose désormais sur le packaging de la mise en production. La répartition direction des études, direction de la production vole en éclat. Regardons les rôles qui doivent désormais exister dans l'entreprise :
D'autres responsabilités sont encore mal définies et peuvent se trouver selon la plateforme et les contraintes de l'entreprise
Là encore que retenir? Une offre PaaS permet de remplacer par un abonnement, non seulement de l'investissement des machines, mais également les coûts de licence logicielle et d'administration des plateformes. Ce dernier point est à l'origine de grandes modifications dans l'organisation de la DSI car une nouvelle répartition des rôles est à inventer pour tirer partie de ces offres. Enfin les plateformes au niveau développement sont très variées et évoluent pour apporter de nouvelles fonctionnalités. Chaque offre est basée sur un contrat qui lui est propre sans portabilité possible. La dépendance envers le fournisseur est donc plus importante.
Le dernier type d'offre de cloud computing est finalement le plus répandu. Il s'agit des offres Software as a Service. En première approche il s'agit de fournir un logiciel à travers internet. Cette approche a été démocratisée d'abord avec les WebMail puis avec des offres comme Google Documents. C'est également celle qui est entrée le plus rapidement dans le monde de l'entreprise avec des offres comme le logiciel de CRM en ligne SalesForce. Le contrat est dans ce cas un logiciel fonctionnel que l'utilisateur paye non plus sous forme de licence mais à l'utilisation.
Ce type de contrat peut en première approche être vu comme un progiciel hébergé. Comme le progiciel, les fonctionnalités seront à la discrétion de l'éditeur. Des offres comme SalesForce offrent de façon couplée un environnement (qui peut être assimilé à du PaaS) permettant de réaliser des développements personnalisés autour du logiciel. Au niveau de la sécurité, des performances et des données, les contraintes seront globalement les mêmes qu'avec une offre de PaaS. La société devra en plus savoir conserver la maîtrise des compétences métiers portées par le paramétrage de l'outil et les extensions au même titre que pour un progiciel.
Même si cette classification est la plus répandue, il est intéressant de la comparer à une autre vision. Afin de mieux comprendre les différences et les interactions entre ces différents services, je vous propose de lire ce découpage à travers le masque de lecture proposé par Philip Evans lors de sa keynote lors de l'Université du SI 2009 organisée par Octo Technology.
Son intervention, brièvement résumée, nous décrit le découpage en couches dans l'industrie informatique. L'IBM 360 a introduit le premier la notion de système d'exploitation générique qui sait faire fonctionner différentes applications (Emergence of modularity à 3'41''). Ce découpage se retrouve parmi les acteurs internet (Stack Strategies on the Internet à 32'20'' et 48'20'').
Grâce à cet éclairage, on peut identifier dans l'offre de cloud computing un premier niveau d'offres centrées sur l'investissement. Le fournisseur fournit l'investissement nécessaire pour construire un DataCenter, assurer sa connexion, sa fiabilité. Il achète en tirant partie de l'effet d'échelles des machines nécessaires. Sa valeur ajoutée est dans l'optimisation et l'amortissement de ses ressources. Elles constituent l'ossature des offres de cloud et sont nécessairement assurées par de gros acteurs. On retrouve dans cette catégorie Amazon, Google, Microsoft, des hébergeurs. Philip Evans parle d'infrastructure. Leur business model est basé sur l'effet de masse. Pour honorer ces investissements, ces acteurs ont besoin de massivement communiquer pour attirer les clients dans leur DataCenter.
On a ensuite un niveau d'offres que Philip Evans nomme service. Il nous décrit ici une valeur ajoutée basée sur l'intégration à l'infrastructure et surtout la scalabilité. Le cœur du métier est ici basé sur la technologie et l'architecture. Les services Amazon comme S3, SQS où SimpleDB rentrent parfaitement dans cette description. D'autres existent mais ne sont pas commercialisés directement comme la BigTable de Google.
On a ensuite un niveau d'offres appelé plateforme. Philip Evans nous le présente à travers les plateformes de réseaux sociaux comme MySpace ou FaceBook. Leur valeur ajoutée réside dans l'apport de briques qu'une communauté va s'approprier pour créer une application finale. Cela s'applique parfaitement aux plateformes logicielles : doit-on utiliser une plateforme Java/Google sur Google App Engine, Java/Spring sur Cloud Foundry ou Microsoft .NET sur Azure? Plus une communauté est importante plus elle sera rentable. A la différence des communautés de réseau sociaux, les développeurs, surtout institutionnels, sont aujourd'hui très fortement liés à une plateforme de par les normes de développement mis en place pour protéger les investissements dans les entreprises. Sur ce créneau, on notera l'offre d'appel gratuite de Google App Engine. Cette offre a pour objectif d'attirer la communauté Java et la communauté PHP qui était la seule aujourd'hui à bénéficier d'hébergements à bas coût. Microsoft et Spring Source misent plutôt sur la compatibilité avec l'existant dans l'entreprise pour attirer les institutionnels.
Enfin on a un niveau d'offre appelé communauté par Philip Evans. On est ici dans le monde du Web 2.0 et de la collaboration. Même si la création d'un logiciel par agrégat de contributions comme Wikipedia ne rentre pas encore dans les offres d'entreprise, on note un changement dans ce sens dans les applications de type SaaS. Ainsi celles-ci se veulent beaucoup plus clé en main que les logiciels installés, la montée en compétence ayant beaucoup plus vocation à être réalisée par les utilisateurs que par des formations externes. Par ailleurs elles favorisent les agrégations et la personnalisation. Google Apps, Microsoft Online Services, SalesForce proposent ainsi nativement une très grande quantité d'API. Les utilisateurs peuvent selon les cas :
Aujourd'hui cependant, ces initiatives sont récentes et il reste beaucoup à construire. Comment par exemple assurer la pérennité d'un outil de travail et une maintenance maîtrisée des applications? Une extension à FaceBook pourra facilement être remplacée, abandonnée, ce qui assure une sorte de sélection naturelle. Une extension SalesForce utilisée couramment dans l'entreprise devra à contrario assurer la continuité de l'activité.
Savoir positionner une offre de cloud computing aide ainsi à mieux évaluer la relation qu'on aura avec le fournisseur correspondant.
Choisir un contrat de type IaaS implique d'accepter de partager des ressources. Le fournisseur rentabilise le paiement à la demande par l'optimisation tirée de l'effet d'échelle. Le nombre d'acteurs sera limité du fait des investissements à consentir. Certaines offres de niveau supérieur s'appuient ainsi sur des offres IaaS existantes (par exemple Amazon EC2) pour éviter ces investissements.
Choisir un contrat de type PaaS permet de payer à l'utilisation, par exemple à la requête web pour les offres les plus scalables. Mais cela impacte beaucoup plus l'entreprise car le contrat repose alors sur des API, un modèle de programmation. La gouvernance vis à vis de ce nouveau type de fournisseur est à inventer. La dépendance vis à vis du fournisseur est également un facteur très important. Les offres présentent peu ou pas de compatibilité. Les acteurs ont intérêt à rassembler la communauté la plus vaste et n'ont pas intérêt à faciliter l'interopérabilité.
Choisir un contrat de type SaaS se rapprochera pour une entreprise comme un choix de progiciel en mode hébergé. Les offres SaaS exposées au grand public (web mail, réseaux sociaux) présentent en plus une forte empreinte communautaire : fourniture de widgets, de liens pour tirer partie du marketing viral. Si en interne dans l'entreprise un modèle analogue reste à inventer, certains concepts peuvent dès aujourd'hui être repris de façon plus large pour des sites internet : pourquoi ne pas déployer les téléchargements proposés par son site web sur Amazon S3 comme le fait Spring Source et placer de simples liens sur son site web (regardez les liens sur la page de téléchargement)?. Ou pourquoi ne pas déployer ses vidéos promotionnelles sur You tube et les insérer ensuite sur son site web?
Addendum : Ces deux propositions de segmentation ne sont bien entendu pas les seules. Juste après la rédaction de cet article on m'a ainsi fait part de cette classification en trois niveaux des plateformes disponibles sur internet réalisée par Marc Andreessen. Une vision complémentaire qu'il est intéressant de comparer.