Cloud computing

CLOUD COMPUTING
« Stratégie et révolution de l'infrastructure informatique, de la manière de concevoir les
applications et leur consommation dans le nuage sous forme de services »

Réflexions & analyses

François Tonic
rédacteur en chef Programmez! et de www.cloudmagazine.fr

Septembre 2009 – Version 1.0

Conditions d'utilisation de ce document

L'auteur ne peut être tenu responsable pour les propos contenus dans ce document ni sur l'exactitude
de ceux-ci, ni sur l'interprétation faite.

L'auteur autorise la reprise partielle du document en mentionnant impérativement et explicitement
son origine (titre, nom de l'auteur, ©). Pour une redistribution complète, veuillez contacter l'auteur :
ftonic2@orange.fr

Ce document n'est lié à aucun éditeur ou SSII.

Toutes marques citées sont ©. Si des sources ont été oubliées dans le texte, l'auteur s'en excuse par
avance et fera les rajouts nécessaires.

© François Tonic, septembre 2009

Livre blanc « Cloud Computing » par François Tonic 2

Préambule : d'opendoc à aujourd'hui

Difficile de dire quand apparaît réellement la notion de cloud computing. Peu ou prou avec la
généralisation de la virtualisation, même si le terme cloud computing n'était pas encore sur toutes
les lèvres. Ce mouvement initié depuis plus de 18 mois est en réalité plus profond. Car finalement,
la première charge vint des services en ligne, des services « hostés », de ce que l'on appelle le SaaS
aujourd'hui dont la forme plus ou moins « primitive » était les applications ASP, que l'on connaît
depuis des années. Et IBM avait par ailleurs initié, il y a une dizaine d'années, l'informatique à la
demande, le « on demand ».

Sans vouloir provoquer, nous dirions que le mouvement s'initia sur la façon de passer aux
applications plus dynamiques, plus simples, en opposition aux applications monolithiques par
définition lourdes, chères à maintenir et d'une qualité variable. Or, c'est notre modèle depuis le
début de la micro-informatique. Il y a une quinzaine d'années, nous avions déjà plusieurs modèles
applicatifs balbutiants : les applications ASP et le modèle Opendoc. ASP ne représentait pas
d'évolutions majeures au niveau applicatif mais dans la manière d'appréhender sa consommation,
son déploiement. Par contre, Opendoc au risque de passer pour archaïsant était un concept, une
architecture logicielle totalement nouvelle. Initiée en particulier par Apple et IBM, opendoc ne
connut pas le succès mérité car trop complexe dans son modèle C++ et la nécessité de prévoir « en
dur » l'interaction avec les autres morceaux applicatifs.

Pour résumer, une application opendoc se composait de deux éléments : un conteneur et des
morceaux d'applications (= une fonction). En fait, une application opendoc est au départ une
coquille vide, un simple conteneur dans lequel l'utilisateur compose son application en ajoutant des
composants fonctionnels. Ainsi on pouvait avoir dans un conteneur des fonctions de navigateur
web, de traitement de web, des fonctions audio et vidéo, de messagerie, d'imagerie, etc. Le tout
étant capable d'interagir ensemble pour peu que le développeur ait bien respecté le modèle de
développement imposé par les spécifications. Cette rigidité de modèle fut en partie la cause de son
échec avec le manque de soutien des éditeurs et son manque de visibilité auprès des utilisateurs.
Cependant, opendoc a montré une autre voie dans la manière de penser, de découper, de consommer
une application.

L'idée « actuelle » des applications composites et des mashups n'est guère différente dans son esprit
à opendoc. Ce qui a changé ? L'acceptation du marché et surtout des technologies capables de
simplifier l'interface pour l'utilisateur et surtout de simplifier le travail du développeur même si
certaines couches techniques ne sont guères triviales.

Nous sommes donc en plein mouvement saas (Software As A Service = le logiciel comme un
service), les services en ligne, et désormais le cloud computing. Car finalement, toutes ces notions
sont liées. Le saas représente une sous-partie du cloud. Pour certains, que nous ne suivons pas, c'est
l'inverse.

Car comme avec le web 2, nous assistons à une désinformation ou plus exactement de déformation
des idées, des concepts, avec le matraquage marketing. C'est l'inconvénient d’une idée conceptuelle
floue et non structurée car on peut y mettre tout et n'importe quoi. Il y a un an, la mode était à tout
« saasiser » ; aujourd'hui il faut tout « cloudiser » même si cela n'a aucun sens et que l'on trahit
l'esprit même de la technologie.

Pourquoi ce « livre blanc » ? Sa prétention n’est pas de donner une parole d’évangile. Il s’agit de
vous proposer notre perception, notre analyse du marché, des technologies, des plate-formes. L’un
des objectifs est de fournir les fondamentaux pour comprendre le cloud dans son ensemble et
prendre conscience des nombreux enjeux qu’il recouvre.


Car on oublie souvent qu’en informatique, si une technologie ou une plate-forme est prise
uniquement dans son focus, la plupart du temps le projet échouera ou accusera retard et problèmes
divers et variés. Le cloud impacte l’ensemble de son IT, des applications et même la manière de
penser une infrastructure réseau et applicative. Cette approche globale comprend la stratégie,
l’infrastructure, le IT, l’utilisateur et la technique.

Le sujet est tellement vaste, et passionnant, que nous avons sûrement omis des éléments. Nous
espérons pouvoir, grâce à vos commentaires, vos retours, améliorer ce document.

Bonne lecture.

François Tonic, 16 juillet 2009


Partie 1 : Architectures du cloud computing

« Tout Saas est un service cloud mais tout cloud n'est pas un service Saas. »

Le terme Cloud Computing se traduit littéralement par « informatique dans les nuages », ces nuages
faisant référence à Internet et au web. Pour bien comprendre cette terminologie, il faut rappeler
qu’Internet est un réseau très complexe et difficile à appréhender car constitué de millions de
connexions utilisant des technologies très disparates (fibre optique, câble, ADSL, etc.). Ainsi, le
monde de l’Internet est complètement abstrait pour la plupart des utilisateurs : il n’a pas de réalité
géographique tangible.

L’application de Cloud Computing que nous utilisons peut se trouver à San Francisco, dans un
satellite ou même sur la Lune : cela fait finalement peu de différence pour nous. Les nuages du
Cloud Computing font référence à cette abstraction. Ils font aussi référence au fait que l’on
représente souvent Internet sous la forme d’un nuage dans les schémas informatiques.
Le Cloud Computing signifie donc que les applications en ligne sont utilisées comme si elles étaient
situées dans l’éther, dans un espace sans réalité physique.

Le concept de Cloud Computing englobe les concepts de Software as a Service (SaaS) et de
Platform as a Service (PaaS).

1
Que
signifie
SaaS
?

SaaS signifie Software as a Service, c’est-à-dire un logiciel fourni sous la forme de service et non
sous la forme de programme informatique (code binaire à installer sur une machine). Les
utilisateurs des applications SaaS accèdent à ce service via Internet.
La différence entre SaaS et logiciel est essentielle. En effet, les SaaS proposent des logiciels
opérationnels, prêts à l’emploi, sans passer par une étape d’installation, et sans aucune tâche de
maintenance.
Les SaaS sont exécutés sur des plates-formes mises à disposition par des acteurs (comme Google ou
Salesforce) que nous appellerons opérateurs SaaS, car leur métier est plus proche de ceux des
opérateurs télécoms que de celui d’éditeurs de logiciel. Les SaaS sont les successeurs des ASP
(Application Service Providers). Ils se distinguent de ces derniers par :

• L’usage d’interfaces RIA ;
• Des architectures dédiées et optimisées : les applications SaaS bénéficient d’un
environnement d’exécution conçu pour un usage en ligne avec une forte charge utilisateur ;
elles sont liées à cet environnement et ne peuvent pas être « déménagées » simplement sur
un serveur en entreprise.
• La mise en avant de fonctions collaboratives : les SaaS mettent l’accent sur les pratiques
collaboratives héritées du web 2.0 ;
• La fourniture d’API ouvertes : les SaaS fournissent des API permettant de faire appel à leurs
fonctionnalités.

2
Que
signifie
PaaS
?

PaaS signifie Platform as a Service. Ce terme désigne une plate-forme d’exécution hébergée par un
opérateur et accédée depuis Internet. Cette plate-forme peut être utilisée pour exécuter des SaaS, et
peut aussi être mise à la disposition des entreprises qui souhaitent faire héberger leurs applications
issues de développements spécifiques.
Amazon a été précurseur dans ce domaine avec Amazon Web Services (AWS).
Les PaaS se distinguent des hébergeurs classiques par :
• Une grande abstraction de la plate-forme. L’entreprise utilisatrice ne connaît pas les
configurations des machines qui exécutent son application.
• Une architecture à très haute disponibilité basée sur des datacenters répartis dans le monde
entier, et garantissant une grande résistance aux sinistres (inondations, incendies, etc.)
Les plateformes PaaS reposent généralement sur les composants suivants :
• Un ensemble de datacenters : leur nombre est toujours supérieur à trois. Dans les cas de
Microsoft ou de Google, les centres se comptent en dizaines.
• Une couche d’exécution sur une machine virtuelle via un hyperviseur, ou sur un runtime de
type Java, .NET...
• Une couche de persistance accédée via HTTP sous forme de base de données ou de fichiers.
• Une couche d’authentification en local ou déléguée à l ‘annuaire de sécurité de l’entreprise.
• Une couche d’intégration : une API ou un bus d’intégration pour échanger des données avec
l’entreprise.
• Une console d’administration qui permet de gérer le déploiement et le versioning des
applications, ainsi que le monitoring de la plate-forme.

Cette partie a été écrite par Guillaume Plouin (directeur programme innovation SQLi, auteur de
Cloud Computing & SaaS, aux éditions Dunod, mars 2009). Avec son aimable autorisation.

3 Le IaaS
Le Iaas signifie Infrastructure as a Service. Il s’agit de la partie infrastructure du cloud, c’est-à-dire
les outils serveurs, administrateurs servant à fournir l’infrastructure comme les outils de
virtualisation, la console d’administration, le système, les librairies. Un exemple d’Iaas : l’offre
Ubuntu, Amazon EC2. Dans le IaaS, on retrouvera donc les composants clés : le réseau (montée en
charge, load balancing, firewall), la partie matérielle, la plate-forme de virtualisation, les outils de
facturation et de contrôle de consommation, les niveaux de services.

Le Iaas peut prendre plusieurs formes : fournisseur d’outils IaaS (Vmware, Eucalyptus, Ubuntu) et
les fournisseurs d’infrastructure complète (Amacon EC2, gogrid, etc.).

4 Un cloud mutualisé ou dédié ?
Dans une architecture classique Cloud, nous sommes dans un contexte mutualisé, car en datacenters
globaux gérés ou loués par des fournisseurs. Aujourd'hui, les grands éditeurs (IBM, Microsoft,
Google, Apple, Salesforce, etc.) possèdent leurs centres de données. Plusieurs même pour assurer la
réplication des données et des environnements que le fournisseur doit assurer contractuellement.


Est-il possible de disposer d'un cloud dédié ? Pas dans les grands datacenters (ou tout le moins, pas
pour le moment). Par contre auprès des fournisseurs classiques d'hébergement, de hosting, il est tout
à fait possible de disposer de son cloud dédié, que l'on peut ici nommé cloud privé (nous
simplifions volontairement le terme). Dans ce scénario, les coûts varient énormément.

5 La question du cloud privé (ou private cloud)
Les hébergements, hosteurs tels que Ikoula et les éditeurs misent sur 5 piliers pour justifier de
l’intérêt du cloud privé (source : Ikoula) :
- Flexibilité : votre infrastructure est évolutive. Redimensionner vos Virtual Machines ou réallouer
vos ressources vous permettent d’adapter rapidement votre infrastructure à vos besoins.
- Réactivité : le clonage, les migrations à chaud, ou encore le déploiement de VM sont des
opérations très rapides à réaliser.
- Economies : avec des serveurs consolidés et une utilisation des ressources optimisée, la facture
énergétique et l’investissement serveurs diminue fortement.
- Respect environnemental : en dehors des économies réalisées, le Private Cloud permet de réduire
fortement le gaspillage énergétique.
- Sécurité : totalement dédié, le Private Cloud vous offre un niveau de sécurité maximal.
L’isolation est garantie et des normes de sécurité sont définies spécifiquement pour l’entreprise.

Dans l’architecture type est la suivante (source : Ikoula) :

Pour une entreprise qui ne veut pas risquer une externalisation radicale de son SI, le cloud privé
(hébergé localement ou sur des serveurs dédiés / réservés), peut être une solution à considérer. C’est
en quelque sorte une forme d’intranet, d’extranet mais au niveau infrastructure et plate-forme. A


notre sens, il ne faut pas opposer cloud privé et cloud public, car rapidement, les deux seront
amenés à travailler ensemble. Nous arriverons donc à des cloud hybrides mêlant les deux
approches. Dans le public, on déportera les éléments non sensibles et dans le privé, on gardera les
données, applications sensibles liées au business de l’entreprise.

Désormais la guerre du cloud privé est lancée. Amazon a annoncé son Virtual Private Cloud.
Amazon VPC est présenté comme un pont entre l'infrastructure IT existante et le cloud d'Amazon.
Il s'agit de déporter, tout en restant connecté à son IT, une partie de son infrastructure dans des
instances Amazon isolé pour avoir des ressources supplémentaires, avec accès en VPN. Il est
intégré à Amazon EC2. Mais ce n'est que la première étape. Et comme d'habitude on paie à la
consommation. les fonctions annoncées sont :
- création de son VPC sur l'infrastructure Amazon, avec des IP privées
- possibilité d'avoir un ou plusieurs subnets- connexion sécurité via un tunnel VPN
- rajout possible d'instance EC2 dans sa VPC
- le trafic peut être surveillé par ces outils de sécurité- possibilité d'étendre ses pratiques de sécurité
et de gestion de son infrastructure existante dans sa VPC

6 Les pures players vs éditeurs traditionnels
Le Saas et le cloud favorisent l’émergence d’éditeurs et de prestataires uniquement dédiés à ces
domaines. On peut citer deux noms : Salesforce, ProcessOne ou encore yousaas. Ces pures players
jouent la carte du service en ligne et du cloud. L’avantage est de partir d’un héritage zéro alors
qu’un éditeur traditionnel doit s’adapter à la nouvelle donne technique sans pour autant cannibaliser
ou fragiliser ces fondamentaux.

Souvent, nous nous interrogeons sur le potentiel des pures players à supplémenter les éditeurs.
Lorsque l’on s’attaque frontalement à un géant comme SAP sur les progiciels, difficile d’imaginer
un combat équitable. Sur de petits projets ou des projets précis dans une grande entreprise, le pure
player a sa place. Mais l’éditeur traditionnel, quand il a vu la menace, a réagi soit en tissant des
alliances avec le pure player, soit en commercialisant sa propre solution en ligne.

Des pures players peuvent effectivement prendre des marchés, dans certains scénarios il y aura
collaboration avec une solution traditionnelle ou bien l’éditeur traditionnel imposera ses services en
ligne. Nous sommes là sur du cas par cas. La difficulté pour les pures players, la plupart du temps
de petite taille, c’est la reconnaissance du marché et une visibilité auprès des utilisateurs. En
entreprise, quelle garantie offre un pure player quasi inconnu pour elle ? Même si la DSI a assoupli
ses positions conservatrices, ce n’est pas pour autant qu’elle se lancera tête baissée avec un pure
player. C’est à ce dernier de démontrer sa compétence, sa valeur ajoutée, sa qualité. La pérennité
demeure un argument.

7 Les rachats secouent le cocotier : l’exemple VMware - SpringSource
Depuis des mois, les rachats se succèdent dans le domaine de la virtualisation, l’administration, les
pures players cloud ou saas. L’été 2009 n’a pas été à l’écart du mouvement. Début août 2009,
VMware annonce le rachat pur et simple de SpringSource, éditeur open source d’outils et des
solutions de développment web, avec le bien connu framework Spring. Quel intérêt pour VMware
de ce genre de rachat ?


Il y a à mon sens plusieurs éléments à considérer : VMware dispose d’un solide Iaas avec vSphere
4, VMware reste absent du Paas et surtout possède une énorme faiblesse dans le modèle de
développement. Or, pour prétendre concurrencer ou tout le moins devenir une alternative crédible à
de l’Ubuntu, du Google, du Microsoft et bien entendu à Force.com, VMware n’avait pas le choix :
il lui fallait un solide modèle de développement et d’administration, si possible Java. C’est
maintenant chose faite. Sur le cloud technique de SpringSource, voici un élément particulièrement
intéressant.

Comment mettre une application en production sur du cloud, par exemple en déploiement EC2 ?
L’auteur pointe vSphere et le vApp. Avec le support de Open Virtualization Format, il est possible
d’encapsuler les composants multi-tiers d’une application. Donc vApp est parfait pour les
déploiements d’application blueprints. Dans « dm server » de Spring, il faut alors configurer les
propriétés vApp, puis le déploiement se fera sans connaissance particulière de l’environnement
vApp et des machines virtuelles liées. En associant les deux mondes, on obtient un modèle PaaS
couplé à un modèle de développement et un modèle Appliance d’application.

Pour Vmware, un des accents est mis sur le choix du Paas. Et très clairement, Vmware veut être une
alternative au PaaS actuel Google AppEngine et Force.com ! Et le schéma ci-dessous résume la
fusion entre vSphere et le modèle applicatif Java à l’intérieur :


Le PaaS sera donc un des enjeux majeurs des prochaines années. Car le but est finalement de
proposer un modèle de développement, de déploiement, d’administration unifiée, si possible le plus
large côté langage. Force.com reste le fer de lance de ce marché mais VMware ouvre une (nouvelle)
brèche.

Sitôt racheté par VMware, SpringSource se lance dans le cloud avec CloudFoundry qui vient d’être
racheté par… Spring Source... Le but est simple : proposer une plate-forme pour le déploiement et
l’exécution pour les applications Java. Le tout respectant le cycle de l’application Java : build,
exécution, administration. Foundry est donc une plate-forme de cycle de vie des applications Java,
Spring et Grail. Le tout fonctionne sur Amazon EC2. Cette offre s’appuie sur Cloud Tools.

Cloud Tools est une suite d'outils open source pour déployer, manager et tester les applications Java
EE dans un contexte Amazon EC 2. Cette suite se compose de trois éléments :
- Amazon Machine Images : configuré pour fonctionner avec Tomcat et EC2Deploy
- EC2 Deploy : core framework. manager les instances EC2, à configurer MySQL, Tomcat,
Terracotta et Apache. Permet de déployer les applications
- Maven et Grails plug-ins utilisés par EC2Deploy quand on déploie l'application sur EC2.

8 Et côté matériel ?
Quand on parle de Cloud Computing ou de Saas, on oublie souvent d’évoquer le matériel. Quels
impacts ? En soi, cela ne change pas grand chose. Du moins dans un premier temps. Son ordinateur
(bureau, portable), équipé d’un navigateur internet, d’une connexion web de bonne qualité, suffit à
accéder à son cloud.

L’impact par contre se fait signification sur la partie serveur. Car en passant à une architecture
déportée telle que le cloud limite de facto la puissance serveur nécessaire. Excepté dans le cadre
d’un cloud privé hébergé sur ses serveurs. Mais, dans ce cas, la virtualisation permet de faire mieux
avec moins de serveur ou tout le moins on optimise au mieux l’utilisation de chaque serveur. Dans
le cas d’un cloud entièrement déporté, la partie serveur (matériel) n’a plus besoin d’être aussi
importante car les fonctions prises en charger sont moindre. Pareillement dans une approche Saas.
Par contre, vous devrez garder les services élémentaires (stockage, serveur de fichier,
d’impression…). La même révision de son parc serveur devra être réalisée avec le saas.
Théoriquement, l’usage du cloud ou de service saas ne nécessite pas de PC surpuissants. Cependant,
mieux vaut disposer des dernières versions de navigateurs, d’une connexion haut débit et stable.


Il est vrai que si nous poussons plus loin la réflexion, le cloud peut être une renaissance des clients
légers et ultra clients. Car si on démarrage sur un cloudos, l’utilisateur doit-il disposer de la même
puissance machine ? Non. Car finalement, le traitement et la charge processeur se feront sur le
serveur hébergeant le cloud. On déporte ainsi les besoins matériels de son poste utilisateur au
nuage.

Verra-t-on apparaître des CloudPC, des CloudBook ? Oui sans aucun doute. Dans un premier
temps, nous pensons que ce ne sera que des versions légèrement modifiées de PC actuelles, avec la
possibilité de démarrer sur un cloudos. Déjà, des « netbooks cloud » sont attendus sur le marché
(gos cloud et gigabyte m912). Reste à ouvrir le cloud aux Smartphones ce qui ne tardera pas.

Malgré tout, la partie purement matérielle du cloud, côté utilisateur, ne devrait pas évoluer à court
terme. Les enjeux pour les constructeurs sont trop importantes et les éditeurs logiciels ne sont pas
passés à ce nouveau modèle « on demand ».


Partie 2 : les promesses du cloud (au sens large)

« Le cloud computing permet de réduire la nécessité d’immobiliser des capacités informatiques
avant que ces capacités ne soient nécessaires. Le cloud permet de concevoir et de construire des
nouveaux systèmes quand le business ralentit et les systèmes sont prêts et capable de monter en
charge rapidement quand les conditions l’exigent. » Peter Coffee (director of Platform research –
Salesforce.com)

Quelles sont les promesses et les objectifs du cloud computing pour le développeur, l'utilisateur
final, l'administrateur et de l'entreprise, voire même pour un éditeur ? Si on suit le manifeste Open
Cloud, nous aurions comme buts : le choix, la flexibilité, la rapidité, l'agilité et la qualification.
Cependant, il ne faut pas généraliser ces objectifs et buts car cela dépend de quelle section du cloud
nous parlons. Car il y a une différence de buts d’objectifs entre le cloud pur et les services Saas...

Il semble difficile de donner des objectifs et des buts au cloud car son étendue est telle que cela
dépend finalement de ce que l'on recherche réellement en le mettant en place. Pour notre part, nous
placerons en premier le choix et la flexibilité. Ensuite, il y a en vrac l'administration, le
déploiement, l'infrastructure totalement ou partiellement déportée dans le nuage. Et surtout, ne
l'oublions pas : on paie ce que l'on consomme réellement. Nous insistons sur ce point car la
consommation à la demande, même si ce n'est pas nouveauté, se généralise (enfin pourrait-on dire).
Nous reviendrons sur tout cela plus loin.

1 Les avantages du Cloud computing selon le manifeste Open Cloud
Le manifeste cite les avantages suivants :
- Montée en charge selon la demande (réelle)
- Adaptabilité du datacenter pour l'accès, l'organisation, la volumétrie des données
- Minimiser les coûts d'accès (au départ)
- Améliorer le process business

A cela, nous rajoutons (liste non exhaustive) :
- administration le plus souvent centralisée et simplifiée
- gestion de l'infrastructure simplifiée
- adaptabilité de l'infrastructure selon ces besoins réels à un instant T
- souplesse du plan de reprise d'activité

Clairement, le Cloud Computing propose de solides arguments. La souplesse, la flexibilité et la
montée en charge de l'infrastructure cloud sont de vraies avancées par rapport à une infrastructure
dite locale, le classique réseau – serveur. Ces avantages, nous les avions déjà avec la virtualisation
(type serveur et VDI). Mais ici nous allons plus loin car nous déportons l'infrastructure en dehors.
D'autre part, c'est au fournisseur de l'infrastructure cloud à faire la mise à jour même si
l'administrateur doit toujours veiller à la bonne tenue de son infrastructure.

Ces premiers arguments sont d'autant plus forts que l'on n'immobilise plus dans l'entreprise des
serveurs sous-utilisés avec des coûts de maintenance et de fonctionnement qu'ils soient ou non à
pleine charge. L'informatique à la demande devient donc ici l'infrastructure à la demande dans
laquelle on instancie de nouveaux serveurs quand cela est nécessaire. On peut alors ajuster au plus
juste la puissance serveur (stockage, CPU, bande passante, serveurs...) tout en veillant à une
meilleure charge d’utilisation (on oublie trop souvent la notion de saturation des machines et des
processeurs). Et on paie, comme énoncé déjà à plusieurs reprises, ce que l'on utilise. Sur ce point
précis, attention tout de même à bien maîtriser la tarification car elle est souvent multiple (temps
d'utilisateur, bande passante, CPU, stockage, nombre de serveurs, etc.). Avant tout choix d'un cloud,
le calcul d'un retour sur investissement s'avèrera indispensable.


Sur l'amélioration sur process business, nous ne serons pas aussi catégoriques car cela se voit
surtout dans la partie Saas. Même si effectivement, la fluidité de l'infrastructure fait partie d'un
process business. Sur le coût d'accès, nous sommes ici aussi prudents mais nous le détaillerons dans
un autre chapitre. Par contre l'administration y gagne. Outre l'aspect purement matériel, les offres
cloud misent sur la centralisation de la console (dans le navigateur, voire éventuellement en client
riche). Si des efforts restent à faire sur le monitoring de disponibilité, depuis les pannes fracassantes
de Salesforces, Google, Azure, Mesh, les fournisseurs font des efforts de transparence. Il est
impératif pour l'IT ou même pour un utilisateur avancé de voir exactement ce qui se passe sur son
infrastructure déportée. Voire de pouvoir établir des politiques de basculement automatique si des
serveurs deviennent inaccessibles ou trop lents : il faut pouvoir basculer automatiquement vers un
autre datacenter ou d'autres serveurs.

2 Les inconvénients du Cloud computing selon le manifeste Open Cloud
Le manifeste évoque les inconvénients et freins suivants :
- la sécurité
- l'interopérabilité des données et des applications et de leur portabilité
- gouvernance et administration
- monitoring et métrique.

Sur le monitoring et l'administration, ils peuvent être vus comme des points faibles mais les progrès
constants permettent aujourd’hui une meilleure gestion au quotidien, que ce soit sur les consoles
graphiques ou les consoles en ligne de commande. Cependant, il est vrai que sur les métriques, les
mécanismes ne sont pas à la hauteur des outils « locaux ». Sur l'interopérabilité, véritable point noir
du cloud, un chapitre abordera spécifiquement ce problème. Sur la sécurité, le problème n’est pas
aussi dramatique que l’on voudrait bien nous le faire croire.

Il est vrai qu'aujourd'hui les clients du cloud regardent plutôt à déployer un cloud interne justement
en raison du flou sécuritaire. Cependant, il ne faut pas être extrême car le cloud bénéficie des
mécanismes éprouvés des réseaux et du web en général. Ensuite, si les mécanismes ne sont pas
activés ou mal déployés, ce n'est pas la faute aux fournisseurs mais aux administrateurs,
développeurs, utilisateurs. Depuis des années, les éditeurs et organismes sensibilisent les
développeurs à concevoir des applications, des sites web sécurisés. Mais cette évangélisation reste,
malheureusement, bien trop souvent lettre morte, au mieux, limitée ou mal comprise et mise en
œuvre. Les risques existent sur le cloud comme ailleurs. La sécurité totale n'existe pas et n'existera
jamais (sauf à considérer le proof computing).

3 La sécurité : l’autre enjeu
Il est nécessaire de se poser des questions sur la surface de risques (réelle et supposée), les
mécanismes à utiliser. Finalement, l'administrateur et le RSSI garderont un rôle important. Ensuite
on peut se demander quelle intégrité de mes données, de mes applications, voire de mon interface
avec l'annuaire d'entreprise, la fédération d'identité, etc. N'ayez aucune illusion. La sécurité sur le
cloud aura un coût humain, financier et technique. Un audit précis sera donc nécessaire avant toute
production de son cloud. Il faut impérativement des sessions sécurisées : VPN, SSL, https, cryptage
des données en transits, authentification forte, vérification de l’intégration des données en E/S,
couplage du cloud avec les profils et politiques d’accès de l’entreprise, application des patchs des
environnements serveurs, sécurisation des postes clients. La mise en place de monitoring et d’outils
spécifiques s’avèrera indispensable, ce que l’offre actuelle ne peut faire réellement.

Le schéma suivant (Understanding Service Architecture, MSDN) illustre l’intervention du protocole
https dans un contexte Azure :


La sécurité dans le cloud a un coût sur le temps de traitement, sur le budget et le temps de
développement. D’autre part, le fait de développer dans le cloud ne dispense pas le développeur
d’appliquer les règles du développement sécurisé. Le code doit être qualifié et sécurisé. Les testeurs
doivent mettre en place des matrices de tests de sécurité et les appliquer scrupuleusement. Le
développeur devra utiliser les mécanismes disponibles aussi dans le langage choisi et les
mécanismes offerts par la plate-forme.


Dans le schéma précédent (source : VMware), nous retrouvons l’architecture de l’offre
infrastructure vSphere v4 de VMware. La sécurité est dévolue en grande partie à deux modules :
vShiled Zones (chaque application est soumise aux règles de sécurité dans un environnement
partagé) et VMsafe (pour utiliser des produits de sécurité fonctionnant de concert avec les couches
de virtualisation afin de « blinder » les machines virtuelles).

Côté Amazon Web Services (dont EC2, source : Amazon Web Services overview of security
process june 2009), les recommandations sont claires : certifications et accréditations, design de
sécurité, sécurité physique, backup, sécurité réseau, sécurité liée aux services Amazon (EC, Storage
Service, SGBD…). Si on prend la sécurité réseau, l’éditeur veut prévenir les attaques DDoS via une
API à implémenter, génération automatique de certificat SSH quand on se logue, protection contre
le spoofing IP et contre le scanneur des ports. Le schéma ci-dessous (source : Amazon AWS)
montre une architecture firewall pour protéger l’infrastructure EC.

Sur la partie virtualisation, Amazon pointe du doigt l’isolation des instances (Amazon est très actif
autour de l’hyperviseur Xen). L’isolation des instances est capitale pour la stabilité de
l’infrastructure virtuelle et éviter ainsi toute fuite mémoire ou échange inter-instance non voulue
provoquant à terme l’écroulement de l’infrastructure (voir schéma ci-dessous).


On rajoutera les notions de qualité de services (SLA). Là encore, la vigilance reste indispensable :
vérification des niveaux de qualité par contrat, quelles interventions possibles, quel niveau de
redondance et de réplication des données (entre deux datacenters par exemple), etc. La partie légale
demeure encore assez floue car les implications pour toutes les parties s'avèrent importantes.

4 Les avantages et inconvénients des services en ligne de type Saas
L’une des plus remarquables success story du Saas est sans conteste Salesforce. Il s’agit pour ces
éditeurs de bannir le logiciel du poste de travail. On déporte alors tout ou partie d’une solution,
d’une application sous forme de services, de plate-formes de services en ligne. C’est le cas avec les
Google Apps, Acrobat.com, Microsoft Online, les services Lotus, etc. Aujourd’hui, on trouve des
services en ligne de type Saas pour tout et n’importe quoi : sécurité, mail, ERP, CRM, processus
métier, serveur de messagerie, environnement portail.

Les avantages sont (liste non exhaustive) :
- souplesse et facilité de mise en œuvre
- fin du déploiement de solution monolithique et lourde
- mise à jour du côté éditeur
- tarification plus réelle à la consommation
- migration des données vers les services en ligne

Mais les inconvénients ou points sensibles sont aussi nombreux :
- quelle réversibilité d’un saas ?
- interopérabilité entre les services
- qualité et garantie contractuelle
- définition des responsables légales en cas de panne, de perte de données
- bien maîtriser les aspects coûts
- agrégation des services entre eux

5 Quels utilisateurs ?
Cette question peut paraître bête mais lorsque nous avons testé les solutions Google, Force.com,
Microsoft Online / Azure / Mesh, etc. et durant les discutions avec les éditeurs, l’interrogation


apparaissait plus que pertinente. Le marché premier reste clairement l’entreprise. Les grandes
structures commencent à considérer le cloud après le saas, qui commence « à prendre » ici et là. La
PME utilise déjà, même si le pourcentage reste faible, des services saas. Mais le cloud au sens strict
du terme ? Pour le moment, c’est la prudence et si cloud il y a, nous serons dans une approche cloud
privé pour des raisons de sécurité.

Les offres d’un Amazon EC, Azure, Force.com, etc. ciblent uniquement l’entreprise. Rien pour le
grand public à ce niveau. Même constat pour les offres webos vivant grâce à l’entreprise et non sur
l’utilisateur lambda. Par contre, des services de type Live Mesh peuvent intéresser un public mixte,
« amateur » et professionnel. Mais quel utilisateur lambda à la maison s’amusera à configurer un
App Engine ou un Force.com ? Il faut être réaliste. Ces plate-formes et infrastructures sont
inadaptées dans leur approche et leur ergonomie. Il faut d’autre part absolument des éditions
personnelles / développeur gratuite ou à très faible coût, à côté des offres « normales ».

La démocratisation du Saas et sans doute encore plus de l’approche hybride S+S (dans un premier
temps) viendra par un couplage avec des logiciels du quotidien. Depuis un traitement de texte
pouvoir accéder à un espace de stockage en ligne facilite un tel usage (voir Office 2007). Live Mesh
est un exemple à considérer et à suivre. Par son ergonomie, ses fonctions, il peut séduire un très
large public. Cependant, la réussite dépendra d’un élément incontournable, en plus de l’ergonomie
et de la praticité : l’évangélisation.

Les éditeurs doivent impérativement communiquer, expliquer, présenter, promouvoir. Non pas en
centrant uniquement sur leurs propres solutions mais dans une approche macro : expliquer les
rudiments du cloud, du saas (c’est quoi, pourquoi faire, où, quand, comment). Ensuite, l’explication
micro (plus en profondeur) sera possible. Mais une fois de plus, on confond les deux approches. Et
malheureusement, la presse ne constitue pas toujours un medium fiable. Ni les éditeurs.

Quand nous entendons la question suivante durant une conférence de presse, « Windows 7 sera-t-il
distribué en SaaS ? », on mesure l’océan d’incompréhension.

6 Le succès passera-t-il par des « AppStore » ?
Jusqu’à récemment, nous n’avions pas réellement examiné la problématique des applications et
solutions prêtes à l’emploi, disponibles directement sur une plate-forme cloud. Dans le Saas,
l’agrégation (que se soit par mashup ou applications composites) se répand « facilement » car il
s’agit en quelque sorte d’un morceau ADN de ces services même si l’interopérabilité entre services
est loin d’être garantie. Mais sur le cloud ?

Après un test rapide de la plate-forme Force.com en édition personnelle / développeur (version
gratuite), il est facile de comprendre l’intérêt d’une boutique d’applications où l’on puise la solution
que l’on souhaite et qui répondrait le mieux à un besoin donné. C’est une autre manière, si nous
voulions faire un raccourci, de consommer des services en ligne. Mais là, les solutions disponibles
le sont pour une plate-forme donnée. Les logiciels disponibles sont gratuits ou payants. L’usage
professionnel est une fois de plus mis en avant. Nous avons ainsi une sorte de AppStore, très
primitif sur Azure, Mesh Developer ou encore App Engine, bien plus développé sur Force.com.

Nous pensons que ces boutiques constituent un des avenirs de la consommation de logiciels sur le
cloud. Mais des progrès sur l’ergonomie et les procédures de déploiement restent à réaliser. Notre
expérience sur Force.com démontre à la fois le potentiel d’une telle approche mais les procédures
demeurent trop lourdes et l’ergonomie laisse à désirer.


7 Le Cloud IT est-il le futur du DSI
Le cloud impacte l’infrastructure, le système d’information, comme peut le faire un service Saas,
mais à un périmètre moindre. Comme la virtualisation de serveur permet de consolider et de
rationaliser les serveurs physiques, le cloud externalise une partie de son infrastructure ou le rend
plus réactive, mieux chargée si on garde le cloud chez soi.

Le métier du DSI change aussi car il doit posséder une vision du cloud et savoir comment l’intégrer
lorsque cela lui semble bénéfique. Il ne faut pas s’y lancer tête baissée. Il faut surtout auditer,
définir le périmètre d’action du cloud, les conditions d’externalisation, de migration, de plan PRA et
de retenir en interne si besoin. Le cloud nécessite donc une sérieuse redéfinition de l’architecture
globale de son infrastructure SI, aussi bien matérielle que logicielle. Même remarque pour
remplacer une application par un service en ligne.

Le DSI doit jouer son rôle :
- vision à long terme du SI
- maîtrise des coûts, investissements et évolutions
- aligner le SI sur le métier de l’entreprise.

En théorie, le cloud offre au SI une flexibilité dans la montée en charge, le load balancing, le
déploiement des applications. Si la DSI ne possède pas de compétence. Il faut procéder à une mise à
niveau des compétences et s’adjoindre les compétences d’une SSII, d’un intégrateur spécialisé dans
le domaine. Cependant, toute externalisation doit se faire dans les meilleures conditions et la
maîtrise technique doit être claire pour la DSI, les prestataires, les fournisseurs. Le directeur
informatique doit disposer du niveau de ROI, des alternatives en cas de besoin, des clauses
contractuelles, etc.

Aujourd’hui, pour une DSI, le cloud rejoint les problématiques d’externalisation, d’infogérance. Il
faut franchir le pas mais aussi savoir ce que l’on veut faire à terme avec cette approche. La
difficulté sera, comme vu plus haut, de définir strictement le périmètre que l’on souhaite
externaliser. Ensuite, la conduite du projet est classique.

Le Cloud IT sera la plupart du temps mixte. Il faut rester prudent tant que l’interopérabilité, la
qualité de service, entre autre, ne seront pas clarifiées. Et comme toujours : quelle valeur apporte le
cloud, le saas… au-delà de la simple commodité.


Partie 3 : Saas et S + S, les questions à se poser

Sous ce terme, les éditeurs y mettent tout est n'importe quoi. Nous prenons ici le parti unique du
SaaS, soit le logiciel comme un service et un autre approche le Logiciel + Service ou Software +
Services. Cette dernière est promue par Microsoft. L'éditeur possède d'ailleurs une partie en ligne
avec les services Live et les services Online. Le succès de Salesforce.com est là pour démontrer la
viabilité d’un acteur « pure player ».

1 le marché ne sera jamais tout Saas
Simple constat pragmatique, le marché ne sera jamais 100 % Saas, Cloud. Aucun éditeur ou
analyste ne le pronostique. Cela pourrait devenir réalité mais dans un cycle long. Les estimations
des principaux analystes (Gartner, IDC, etc.) oscillent sur une percée du logiciel de type Saas à
hauteur de 12 à 15 % d'ici 2012 – 2013. Aujourd'hui, les taux de croissance paraissent incroyables
car nous partons de zéro, cependant, même à 5 ou 7 % de volume (pas en valeur), les éditeurs ne
peuvent pas omettre ce marché.

Passer au tout Saas posera des problèmes énormes de disponibilité des services et aussi de pouvoir
assurer une connexion web optimale tout le temps et n'importe où. Irréaliste aujourd'hui. Par contre,
le Saas devient une réalité pour les services de paie, dans l'ERP, le CRM, la messagerie, le stockage
de données, la communication unifiée, la bureautique. Dans le nomadisme, le Saas (en lui assurant
une synchronisation avec le poste de travail pour les données en mode connecté / déconnecté par
exemple), offre un intérêt. Dans les applications nécessitant une forte puissance de calcul, le Saas ne
peut assurer la même qualité qu'une application locale. Nous pensons à la CAO, les jeux, la
compression – décompression audio/vidéo... Rappelons que dans les infrastructures VDI
(virtualisation du poste de travail), les protocoles d’interface déportée ne peuvent supporter les
exigences d’applications intensives.

Le Saas devrait cependant s'imposer sur des fonctions basiques que l'on peut qualifier de
commodité. Nous les avons cités plus haut : messagerie, ERP, la bureautique, etc. Mais clairement,
le Saas de commodité n'est pas un modèle économique viable, ou trop limité. Il faut donc proposer
des services à valeur ajoutée comme le CRM, le process métier, le serveur de messagerie. Mais ce
saas « valorisé » ne sera pas pertinent partout.

D'autre part, pour un éditeur, le modèle Saas impose de nouvelles contraintes et un changement
radical de modèle économique. Et le risque est de proposer du saas bradé ou de mauvaise qualité.
Attention, même dans les pures players Saas, il y a le bon grain et le mauvais. Pour un éditeur
vendant des licences, le saas oblige à repenser ces solutions. Jusqu'où faut-il aller ?

2 – La réalité à ne pas oublier
Il ne faut surtout pas se lancer tête baissée. Il faut définir un plan d’action pragmatique et raisonné.
Tout d’abord, définir le ou les applications que vous souhaitez déporter, et jusqu’à quelle
granularité puis établir une liste de services susceptibles d’être compatibles avec vos attentes. De
cette liste, vous devez définir le niveau fonctionnel offert et celui que vous attendez, la qualité, le
niveau de contrat, les mécanismes de sécurité et notamment sur la réplication des données en cas de
crash.

La reprise de l’existant est un élément crucial pour beaucoup d’utilisateurs. Si vous migrez un ERP,
un CRM, une messagerie, comment se passe la migration des données et quel niveau de migration
est offert. Cette question est loin d’être anodine dans un SGBD, une messagerie, un ERP, une paie.
Mais il faut aussi se poser la question inverse. Si je reviens à un mode local, comment je migre les
données. Et enfin, comment je migre d’un service à un autre.


3 – Prévenir une indisponibilité par un PRA
On parle beaucoup de plan de reprise d’activité dans la virtualisation, le cloud mais plus rarement
dans le Saas. Or, comment une entreprise peut prévenir une coupure de service sans faire tomber
son business, une partie de son IT. Les pannes de Google, de Microsoft et de Salesforce montrent
une forme de fragilité même si les pannes demeurent généralement limitées dans le temps et
finalement assez rare.

Basiquement, pour un service A, il faudrait avoir 1 ou 2 services comparables sur lesquels
l’entreprise sera capable de basculer en cas de panne du service A. Mais là se pose la question de
l’interopérabilité des services et comme dans les Iaas et Paas, le Saas manque cruellement
d’interopérabilité inter-services. Bref soyez très vigilant sur la qualité de service annoncée par
l’éditeur.

Pis, dans une agrégation de services, en cas de panne d’un service B, quelles conséquences sur les
services A et C ? Et quelle responsabilité légale pour les éditeurs des services actifs et pour le
service tombé ? Dans le multi-prestataire, le flou actuel devra être scrupuleusement résolu, et
rapidement.

4 S+S : une approche hybride
Si le logiciel desktop demeurera majoritaire, cela ne signifie pas que le monde online et offline ne
sauront pas communiquer. L'approche logiciel + services constitue une approche hybride alliant du
logiciel desktop et du logiciel en service (donc en saas). Par exemple, une suite bureautique desktop
ayant accès un espace de stockage en ligne. En allant plus loin, le service en ligne correspond peu
ou prou au logiciel desktop mais l'utilisateur peut basculer de l'un à l'autre en cas de besoin par
exemple en cas de coupure réseau par exemple lors d'un déplacement. Microsoft prône ce modèle
notamment avec certains services live, le futur Office 2010. Dans un certain sens, des éditeurs ayant
une offre saas peuvent faire un modèle hybride, dans le sens où le service en ligne vient en
complément et/ou s'insère dans le logiciel desktop.

Un impératif toutefois, l'utilisateur doit comprendre les fonctions et l'utilité du service. A l'éditeur
de bien communiquer et d'éviter des formulations ou une complexité dans l'offre.


Partie 4 : l'éditeur traditionnel à l'épreuve du Saas

Texte paru dans Solutions Logiciels n°7 dans une forme modifiée

Aujourd’hui, le saas, les services en ligne, les services hébergés sont sur toutes les lèvres. Des
conférences s’organisent, les éditeurs commencent sérieusement à y venir. Mais quand on ne
s’appelle pas Microsoft, IBM, Oracle, SAP, comment un éditeur, un ISV peut-il passer en saas sans
menacer son existence et son chiffre d’affaire ?

« Comme toute nouvelle mode, la tendance est exagérée. Même si les fondements sont solides, il ne
faut perdre la raison. Les avantages du saas freinent les éditeurs car il les alourdit. », commente
Avigdor Luttinger (Magic Software). Entre la demande des clients et les capacités de l’éditeur à y
aller, il faut trouver un compromis.

En France, nous avons plus de 2 500 éditeurs ; le plus souvent ce sont des solutions verticales, très
spécialisées sur un secteur économique, un métier. Comme nous allons le voir, le vrai problème du
saas n’est pas réellement la technologie et la migration de l’application mais définir son modèle
économique. Pour un ISV il s’agit d’une étape cruciale. « Nous avons identifié 3 problèmes :
technique, commercial et financière. », avertit d’emblée Jean-Michel Bérard (président du directoire
Esker).

1- L’écueil du modèle économique
« Il faut comprendre le Saas. Le passage en saas n’est pas qu’un problème technique mais business.
Comment aller sur ce marché ? Il faut travailler sur comment on peut avoir des utilisateurs sans
cannibaliser les ventes. Le Saas est un nouveau marché », analyse Colleen A. Smith (directrice
Saas, Progress Software).

Nous touchons le cœur du problème pour un ISV voulant se lancer dans le saas. L’équation peut se
résumer ainsi (en simplifié) :
− une licence est vendue 100 (hors mise à jour et services)
− un abonnement est vendu annuel / par utilisateur est vendu 10

Bref comment générer le même niveau de revenus en vendant des abonnements Saas ? Souvent, on
évoque un délai de 2 à 3 ans avant de retrouver un niveau « normal » de revenus. Or, quand un ISV
(et tous éditeurs) met en place du saas, cela implique plusieurs coûts cachés ou non :
− migrer tout ou partie du code de son application pour le « saasiser » et coût technique /
technologique
− louer ou bâtir un Datacenter pour l’hébergement
− garantir la disponibilité, administrer le service, assurer la montée en charge, les mises à jour
− définir la stratégie tarifaire : abonnement mensuel ou annuel, politique de résiliation, etc.
− migrer des données des utilisateurs du desktop au service en ligne
− motiver et réorganiser une partie de son personnel (commercial, technique, support).

La définition du modèle d’abonnement est là aussi cruciale. Faut-il un abonnement mensuel ou
annuel ? Comment assurer la fin d’une souscription ? Le prix est un prix psychologique très fort. Il
ne faut pas brader le saas ni le rendre trop cher. Et bien souvent, il faudra attendre plusieurs
semaines, voire des mois avant que l’abonnement débute réellement, le temps que le service soit
réellement implémenté dans l’entreprise cliente. A cela se rajoute le surcout engendré par le Saas :
la disponibilité du service (côté serveur), une assistance / contrôle qualité du service en 24/7.

2 - Quand les éditeurs aident les ISV
Des éditeurs proposant une plate-forme complète de développement tels que Magic Software ou


Progress Software peuvent aider les ISV clients et basés sur ces solutions à passer en mode Saas.
Techniquement, il aide à simplifier la migration. Chez Progress, on dénombre plus de 2 000 ISV
clients, environ 250 sont passés au Saas. Quand un client Progress veut passer en Saas, l’éditeur
fournit une plate-forme applicative facilitant le portage. Et l’éditeur supporte uniquement sa plate-
forme.

Magic Software propose ainsi la plate-forme UniPass (ex-eDeveloper). Ainsi une application
développée avec anciennement eDeveloper peut passer en douceur au mode Saas. Il permet de
découpler fortement l’interface et la logique métier dans une approche RIA (Rich Internet
Application pour l’interface sur le poste client, dans le navigateur) et le Saas (partie serveur avec la
logique métier). UniPass permet d’avoir plusieurs modes de déploiement : pure Web, déploiement
local à la demande ou en pur Saas.

3 - Les exigences techniques : ne pas les sous-estimer
Nous avons dit plus haut que, techniquement, il n’y a pas de réel problème pour passer d’une
application desktop à un modèle saas. Nous devons tout de même modérer cette affirmation. Et ce,
pour plusieurs raisons.

Aujourd’hui, quand on utilise une application desktop, déployer localement sur les postes de travail
ou en mode client / serveur classique, la plupart du temps, le logiciel est dit « fortement couplé ».
C’est-à-dire qu’il y a une dépendance extrêmement forte entre les composants utilisés par le logiciel
et le système client. Or, le modèle saas exige une architecture logicielle web. Dans ce cas, nous
avons alors un découplage, ou « couplage lâche », entre les éléments logiciels, la plate-forme
d’exécution et le système client. Le delta entre les deux approches ressemble à un fossé car il faut
repenser entièrement le logiciel et réécrire la solution, ce qui a un coût non négligeable, tout en
considérant le fonctionnement en connecté / déconnecté. Le mode déconnecté permet de gérer une
application web (donc un service saas) dont la connexion réseau se rompt. Il faut alors gérer la
persistance des données sur le poste de travail, les mécanismes de synchronisation quand la
connexion réseau revient. Ce mode de gestion est important pour les utilisateurs mobiles.

L’une des questions est de savoir si vous décidez de monter vous-même un mini Datacenter pour
héberger vos services saas ou si vous passez par un fournisseur cloud computing comme Google,
Amazon. Chez Esker, un investissement de 300 000 euros a été réalisé pour acheter et mettre en
place des serveurs dédiés au Saas. Mais pour un ISV vertical, la solution du fournisseur est la plus
rapide et la moins onéreuse.

4 - Au-delà du business model, repenser l’organisation interne !
Le Saas pour un éditeur, tout particulièrement de petite taille, est de convaincre les équipes
commerciales de vendre ces services. Car nous l’avons vu plus haut, il n’y a pas de vente de
licences et ni de chèques rapides. « Les commerciaux sont habitués à vendre de la licence avec du
service. Là, ce sont des souscriptions à quelques milliers d’euros, pas aussi valorisant. Il peut y
avoir de la réticence sur le « on-demand », avoue Jean-Michel Bérard.
Nous touchons à un problème souvent occulté : motiver ses commerciaux, lisser leur commission
« on demand » sur le temps pour éviter une perte de salaire trop importante. Et vendre un service
saas modifie aussi l’approche commerciale, le discours marketing. Mais « Le Saas a un avantage.
On peut cibler de nouveaux clients, des entreprises plus petites, type TPE. Elles n’achetaient nos
solutions car trop chères. Le saas ne nécessite pas d’équipes dédiées dans l’entreprise. D’autre part,
on change aussi d’interlocuteur dans l’entreprise. On passait par le service informatique. Avec le
Saas, on peut dialoguer avec les personnes directement concernées par le service, tel qu’un directeur
financier. », précise d’emblée Jean-Michel Bérard. Mais l’éditeur Esker précise aussi un point
important que l’on évitait plus haut : il ne faut que le saas cannibalise son offre vendue en licence.
L’éditeur propose ainsi du saas qui doit complémenter ses solutions « classiques ».


D’autre part, la notion de qualité de service constitue un autre défi non négligeable car pour un
client, le saas doit être tout le temps disponible. « Au départ, nous surveillions le service qu’aux
horaires de bureau. Mais des clients utilisent le service Saas la nuit, le week-end… Rapidement,
nous avons mis en place des astreintes. Le week-end il y a toujours quelqu’un qui peut répondre aux
problèmes de la plate-forme. Nous avons aussi mise en place des machines vérifiant les services et
générer des alertes si besoin. Sur le support / assistance, cela change peu de chose. », précise Jean-
Michel Bérard. Et cela passe aussi par le déploiement d’un système de monitoring constant des
serveurs, des services. Mais cela a un coût.

5 - des métiers étendus ou redéfinis ?
Il est trop tôt pour le dire. Ce qui est une évidence, c’est une évolution des rôles actuels par rapport
au cloud et au saas. Cela nécessite une formation, une mise à jour des administrateurs, des
intégrateurs, des développeurs.

Pour l’utilisateur cela doit être le plus transparent possible. Cependant, une conduite du changement
sera indispensable pour éviter tout conflit, toute réticence.


Partie 5 : une tarification complexe

Avec l'arrivée de l'open source professionnel, de la virtualisation, du multi-coeur sur les
processeurs, la tarification a beaucoup évolué et pas toujours dans le bon sens notamment à cause
des clauses spécifiques (ex. : sur la virtualisation ou encore sur le processeur physique ou par
coeur). Le même problème survient avec le Saas et le cloud computing. Dans le cloud, les offres
d’infrastructure se multiplient mais seuls quelques noms se détachent réellement : Windows Azure,
Amazon, Google App Engine, IBM. Ensuite des hébergeurs et hosteurs peuvent proposer des
infrastructures de cloud public ou privé. Notons aussi que les offres de cloud privé commencent
elles aussi à se multiplier, à l’instar d’un Ubuntu.

1 Comprendre une tarification complexe
Toute la difficulté aujourd’hui est de savoir comparer ce qui est comparable dans une grille de
tarification cloud computing de type infrastructure et/ou plate-forme. Ainsi si nous voulons
comparer un Amazon EC2 et un Windows Azure, nous pouvons le faire uniquement sur les aspects
infrastructures pures mais nous rencontrons d’emblée quelques soucis : quelle type d’instance
Amazon EC2 considérée car nous avons 5 niveaux de puissances d’instances (processeur, mémoire,
unité EC). Bref, si le chiffrage officiel est un premier élément de comparaison, allez au-delà du
simple chiffre pour voir la configuration des instances, les possibilités de personnalisation, le niveau
de qualité offert, etc.

Basiquement, la tarification cloud comprend :
- le temps par heure du « compute » : c’est à dire le temps d’utilisation de l’information
- le stockage : en génération par Go et par mois, avec parfois des tarifs dégressifs
- les transactions (par rapport au stockage : en général par tranche de milliers, dizaine de
milliers de requêtes, avec séparation des transactions entrantes et sortantes (In et Out)
- la bande passante : avec bande entrante et sortante (In et Out).

2 Tarification cloud computing : les exemples Azure, Google et Amazon
Prenons comme base les offres EC2, Azure et Google App Engine. En dollars US.
EC2 (Windows) Azure App Engine
Temps de compute 0,125 0,12 0,1
(heure)
Stockage (go/mois) 0,10 0,15 0,15
Transactions 0,01 0,01 (pour 10k) -
Bande passante 0,10 (in) 0,10 (in) 0,10 (in)
0,17 (out/mois) 0,15 (out / gb) 0,12 (out)
Disponibilité 99,95 % (globale) 99,9 % (transaction) -
99,95 % (instance)

Les chiffres bruts permettent d’établir une estimation des coûts du cloud. On constate une
différence de tarif non négligeable sur la partie stockage (avec partie dégressive chez EC2). Ce qui
en cas de volume important peut apporter une sérieuse économie. On constate aussi une différence
dans l’approche de facturation dans la bande passante entre Amazon et Microsoft, là où Google
apparaît plus compétitif. Par contre, si EC2 et Azure s’orientent entreprises et production, App
Engine ne vise pas encore la production.

Si on va plus loin dans la granularité tarifaire, on constate rapidement que Amazon EC2 est plus
complet qu’Azure sur le choix de la puissance et la taille des instances (3 formats disponibles), ou
encore sur la zone (tarifs US et Europe) ou encore sur les instances Windows ou Linux (tarif
différent). D’autre part, en EC2, il est possible de différencier les instances standards et dite « High
cpu ». Il est même possible de réserver des instances sur 1, 3 ans ou par heure.


EC2 permet donc une très grande modularité et souplesse mais complexifie d’autant la grille tarif
alors qu’un Azure sera plus simple à comprendre mais avec une rigidité de l’offre, pareil chez
Google (dont plusieurs éléments restent flous). Enfin, un détail important, comme Azure est aussi
une plate-forme, il ne faut pas oublier dans son calcul de ROI, le coût des .Net Services et de SQL
Azure.

3 La tarification de Force.com
Salesforce propose aussi sa propre offre de cloud. Le but est d’y faire fonctionner ses applications
sur le cloud, dixit l’éditeur. Côté prix, là aussi c’est clair.

Free Edition Enterprise Edition Unlimited Edition
Nombre applications 1 10 Illimité par utilisateur
autorisées
Nombre utilisateurs 100 Au-delà de 100 -
supportés
Objets SGBD 10 200 2000
Stockage 1 Go Au-delà de 1 Go Au-delà de 1 Go
prix Gratuit 50 $ user / mois 75 $ user / mois

Force.com se veut le plus agnostique possible côté application supportant les principaux langages
de développement actuels. Il facilite aussi la connexion aux autres cloud (Amazon, AppEngine).

4 Exemples de tarifications d’infrastructures cloud tiers
Autre catégorie de prix, les offres de cloud privé ou sur d’autres technologies dans le cloud comme
Ruby. Dans le cas d’ubuntu, il s’agit de monter du cloud privé en proposant des services de support
et d’assistance annuels autour d’Ubuntu Enterprise Cloud. Basiquement, il s’agit de créer un cloud
privé sur 5 machines.

Type infrastructure Support standard 9x5 Support avancé 24x7
5 serveurs physiques avec 25 4 750 $ 17 1500 $
serveurs virtuels
Serveur physique 1 250 $ 3 000 $
supplémentaire + 10 serveurs
virtuels
Illimité sur une zone 90 000 $ 150 000 $
géographique

Autre solution cloud mais pour plate-forme Ruby : heroku. Là, le modèle est déjà plus complexe
même si l’architecture de l’offre est un peu particulière.

Il s'agit d'un projet pour déployer rapidement des applications Ruby on Rails (mais aussi de les
coder en ligne). Pour ce faire, le projet s'appuie sur l'infrastructure Amazon Web Services pour la
montée en charge et les ressources matérielles. Heroku est une plate-forme dite « multi-tenant »
couplée à un environnement de hosting. L'aspect intéressant est sa partie Dyn Grid.

C'est là que le code de son application Ruby s'exécute. Et il occupe autant de slots que nécessaire (le
dyno Grid se compose de slots qui s'activent selon les besoins de l'application). Cette approche
permet d'oublier les serveurs. C'est la plate-forme qui gère. Tout cela se couple à un système de
routage puissant dans le dyno grid pour assurer le meilleur load balancing et garder la montée en
charge. En fait, dyno se compose de plusieurs couches : un environnement Posix (base Debian), une
machine virtuelle Ruby (basé sur MRI), un serveur d'applications (Thin), un Rack (interface web


server), un middleware (Rack Middleware, optionnel), un framework (Rails mais pas seulement) et
enfin son application. Heroku expose aussi son API pour gérer au mieux son environnement
Heroku. Il s'agit d'un service REST. Les prix sont modulables selon les ressources (mutualisées ou
dédiées) et le nombre de dynos que l'on souhaite. Notons que le dyno se loue à l'heure. La facture
peut donc rapidement gonfler…

On choisit tout d’abord la base de données qui varie selon la capacité de stockage, en fonction du
mode mutualisé ou dédié. Cela va de gratuit à 50 $ puis de 200 à 1600 $. Puis on ajuste le nombre
de Dyno. Le dyno se paie à l’heure. Le calcul se fait automatiquement.

Autre exemple, GoGrid, un service de cloud hosting. (chiffres GoGrid)
GoGrid EC2
Serveur Windows 0,08 $ heure 0,125 heure
Server 2003 1 Go ram,
Xeon Core, 60 Go
stockage
Transfert de données Gratuit (in, par Go) 0,10 $ (in, par go)
0,17 $ (out, par go) 0,17 $ (out, par go)
Stockage 0,15 $ (go / mois) avec 0,15 $ (go / mois)
10 Go gratuit)
Load Balancing Gratuit 72 $ / mois

Si GoGrib a quelques avantages sur des fonctions précises par rapport à un EC2, ce hosteur mise
surtout sur les outils et les services annexes pour se différencier d’Amazon. Ce n’est pas un hasard
s’il met en avant des solutions déployées comme ceux de la société f5 sur le load balancing.

Et la concurrence fait rage sur le quadrant magique Gartner des hosteurs cloud : Savvis, IBM,
Amazon, GoGrid, OpSource, SunGard, Media Temple, etc. Pour en savoir plus :
http://mediaproducts.gartner.com/reprints/gogrid/article2/article2.html

En France, nous ne voyons pas encore cette vive concurrence mais elle viendra rapidement. Reste à
espérer une qualité de service optimale. Car le prix est dans le hosting cloud un faux argument.

5 Des services d’aide à la mise en cloud
Côté open source professionnel, de plus en plus de projets autour du Cloud (comme Cloudora ou
Eucalyptus) proposent des solutions purement communautaires, donc gratuites, mais dès que l’on
cherche à faire de la production, à avoir un support dédié, une aide active pour le déploiement, ces
éditeurs proposent des supports spécifiques et payants. Ces services s’ajoutent au coût de son
infrastructure cloud. La facture peut donc rapidement grimper.

6 Les services en ligne
Sur les applications en Saas et consorts, là aussi vous trouverez un peu de tout. L’abonnement
mensuel est utilisé. Mais attention, certains éditeurs cherchent à abonner l’utiliser sur un an, voire
en contrat pluri-annuel. Or, souvent, le saas commence à devenir plus cher que le logiciel desktop
après 3 à 4 ans. Donc, il faut se méfier des contrats long terme.

Parmi les points important à regarder :
- les conditions de sortie
- si le support est inclus ou non
- le taux de disponibilité garanti
- le coût pour augmenter ou diminuer les utilisateurs
- les limitations de trafic, de stockage


- la migration des données vers le service est-elle incluse ou non (et prévue)

Si nous prenons exemple de l’offre online de Lotuslive.com (IBM), on dispose tout d’abord de 5
services (un 6e pas encore disponible). Chaque service dispose d’une matrice de fonctionnalités.
Certaines offres peuvent s’acheter par mois ou par an mais à chaque utilisateur. Et des options
existaient. Ainsi dans le service Meeting, l’offre se chiffre à 39 $ par utilisateur pour 15 participants
mais monte à 79 $ pour 1000.

Si nous regardons l’offre bureautique – stockage Acrobat.com (Adobe), le niveau basic revient à
14,99 $ par mois, 39 pour la version Plus. Les limitations existent. Le niveau basic comprend 10
documents PDF créés par mois, 5 personnes en meeting.

Côté Google, l’offre se veut simple : 40 € pour utilisateur et par mois en édition Premier,
comprenant l’ensemble des applications, le web mobile, 25 Go de stockage messagerie, un taux de
disponibilité de 99,9 %. La version standard reste gratuite.

Depuis son lancement, le slogan de Salesforce est : interdit aux logiciels. Pour ce faire, l’éditeur
propose 4 éditions, plus des éditions personnelle et développeur. Mais surtout, Salesforce propose
un abonnement annuel (de 75 à 3 240 €), par utilisateur. C’est clair et toutes les options sont
indiquées et précisées. Cette présentation a contribué à son succès.

Mais attention, une véritable offre low cost existe sur le Saas. Faire du 1er prix n’est pas une
solution ni pour l’utilisateur, ni pour l’éditeur. Car le risque de dévaloriser le Saas existe réellement
car pourquoi à la maison, on paierait 10 et en entreprise 100. L’éditeur doit trouver le bon et juste
prix avec une qualité de service, de la valeur ajoutée réelle. Ensuite, l’éditeur peut décliner son
offre : personnelle, entreprise, illimité, etc.


Partie 6 : l'open source aura-t-il son mot à dire ?

Basé sur un post sur cloudmagazine.fr du 3 juin 2009

La question revient souvent. Pourquoi avoir un cloud ouvert, s'appuyant sur des standards reconnus
et rendre disponible les spécifications, les API ?

La question de l'interopérabilité se pose dès maintenant au cloud (et bien entendu au saas). Nous
avions eu le même problème avec les web services et ce problème fut long à être résolu. Si le cloud
ne veut pas voir des guerres de chapelles, il faut absolument de la souplesse. Mais ce n'est pas
l'image que les gros éditeurs du cloud donnent. Pourquoi le faire ?

En quoi un amazon, google, microsoft, vmware aurait intérêt à être interopérable avec tout le
monde, donnant la possibilité de migrer son application d'une plate-forme à une autre. Cela est
encore un rêve impossible ou presque. Car si le cloud ouvert n'existe pas, les éditeurs croisent les
alliances : salesforces, google, amazon, etc. signent de nombreux accords pour héberger ou être
compatible avec untel. C'est un premier pas, certes propriétaire et unilatéral mais intéressant.

L'open cloud au sens strict du terme peut-il réellement exister ? Oui, mais pas dans l'immédiat. Trop
tôt. Il faut déjà que les fournisseurs de plate-formes terminent la première génération. L'open source
n'est pas encore à niveau pour offrir une réelle alternative à un amazon, microsoft, ibm, salesforce
malgré les efforts du manifest open cloud, de sun, d'ubuntu. Comme dans le logiciel, on aura le
cloud open source et du cloud d'éditeurs. Mais à la différence de l'open source logiciel, le cloud
nécessite d'énormes moyens rien que pour les datacenters. Et derrière se profile la question du
modèle économique notamment pour les fournisseurs de cloud public.

1 Un cloud trop fermé pour Stallman
Le besoin d'API, de spécifications, de formats communs s'avère nécessaire pour avoir une des
promesses du cloud : flexibilité, montée en charge de l'infrastructure et des applications. Et d'autre
part, comment faire une infrastructure cloud redondante avec deux fournisseurs cloud si on n'arrive
pas à être réellement 100 % interopérable ? Richard Stallman a déjà pointé du doigt les risques
propriétaires du cloud computing. Pour contourner cela, les éditeurs tissent des accords bilatéraux
ou ouvrent leur environnement cloud à des langages, outils. Une manière de faire un cloud ouvert
mais profitant avant tout aux éditeurs concernés.

Dans l’open source, les offres cloud se multiplient aussi bien pour créer des plate-formes que pour
les outils d’administration, de déploiement : Ubuntu, Novell, Sun, Eucalyptus, AppScale, etc. Mais
ces offres devront proposer un double modèle pour vivre surtout dans les parties outils en proposant
des licences ou le plus souvent des services. Un cloud public / privé open source aura besoin
d’argent pour acheter du temps Datacenter ou le construire. L’opposition open source – propriétaire
se fera donc sur les fonctions, l’ouverture des API, etc. Par contre, plus des hosters proposeront du
cloud open source, plus ces solutions se diffuseront, à condition d’offrir des niveaux identiques aux
solutions propriétaires.

Si l’open source bouge, le rythme n’est pas assez rapide. A quelques exceptions, l’open source n’est
pas aujourd’hui une alternative à un google appengine, amazon ec, Azure, etc.


2 L’open source peut réussir sur les domaines actuels
Dans la BI, l'open source s'est taillé une belle place notamment grâce à Talend et JasperSoft.
Aujourd'hui, cette BI ouverte investit le cloud. Talend avait déjà une solution en ligne. C'est
désormais Talend, JasperSoft, Vertica et RightScale qui font cause commune. Le but est d’offrir
une offre d’intégration de BI sur le cloud. Les éditeurs travaillent ensemble pour pouvoir s'intégrer
sur la Manager Plat cloud de RightScale. Les outils Vertica, Talend et Jasper sont automatiquement
configurés et les services sont accessibles en ligne avec paiement à l'usage. Une version
d'évaluation est disponible pour 30 jours.


Partie 7 : la révolution Mesh et le problème du WebOS dans un contexte cloud

Avouons que nous nous sommes intéressés réellement à Mesh, par son usage quotidien, après avoir
discuté du sujet avec Gregory Renard (Wygwam), expert reconnu des technologies Microsoft, et
responsable technologique du projet chez l'éditeur. Mais une fois plongé dans l'univers Mesh, on
comprend les implications possibles d'une telle plate-forme. Car Mesh est une plate-forme au coeur
des services Live. Il comprend un espace de stockage en ligne accessible sur Desktop et smartphone
et depuis un bureau en ligne (Live Desktop). Voilà pour la partie la plus visible. Mais il y a aussi la
partie Mesh Developer.

1 Mesh : le double visage et son Live Desktop
La partie développeur permet tout simplement de créer des applications capables de s'exécuter sur
le Live Desktop. Cela offre des possibilités immenses surtout si on voit Mesh comme on devrait le
voir : un webos. Accessible de partout, imaginer pouvoir à la fois accéder à vos données de
n'importe où et aux applications. D'autre part, Mesh possède aussi un puissant mécanisme de
synchronisation. En installant le client Mesh sur nos PC Windows et MacOS X, on accède aux
mêmes documents localement. Surtout, quand on rajoute des documents, ils sont alors répercutés
sur le Live Mesh puis sur les autres Mesh Desktop quand ils sont connectés. Ainsi en voyage, en
déplacement, je ne me soucie plus à mon retour de récupérer les nouveaux documents ou ceux
modifiés. Mesh peut tout synchroniser. Même si aujourd'hui ce mécanisme est encore limité et pas
toujours rapide, Mesh préfigure ce que l'on appelle aujourd'hui l'informatique ubiquitaire. On ne se
soucie plus du terminal utilisé pour accéder aux applications et aux données. Dans une certaine
mesure, le Cloud Computing promet cela. Même si bien entendu nous n’en sommes qu'au début.

Bien entendu, il existe des concurrents à Mesh mais nous pensons qu'aucun n’a réellement compris
Mesh et son ampleur. Il se limite la plupart des temps à proposer des services de stockage et de
synchronisation. Certes c'est un premier pas, mais Mesh est déjà à l'étape suivante avec son Live
Desktop et surtout sa plate-forme applicative. Mesh Developer préfigure ce qu’est réellement le
bureau live de Mesh : un webos !

Sur cette partie, nous vous conseillons vivement, si vous voulez en savoir plus, de vous rapporter à
nos tutoriaux Mesh et surtout aux articles et analyses de Gregory Renard.

2 Et si le Cloud OS était le véritable webos ?
Basé sur un post sur cloudmagazine.fr du 17 janvier 2009

La question est loin d'être anodine. Aujourd'hui, nous avons une approche plate-forme ou une approche
système dans le cloud. Ainsi si nous prenons vCloud de VMware, de quoi parle-t-on ? D'une initiative pour
définir des standards, des techniques pour gérer, déployer une virtualisation (VMware bien entendu) dans
le nuage. Et là, VMWare s'appuie sur des partenaires dans le datacenter, réseau, outils complémentaires à
VMware. Bref, comment construire une infrastructure cloud autour d'outils et de technologies VMware.
L'avantage est de laisser aux clients un large choix de partenaires et espérer négocier un bon prix. Et
l'ensemble des technologies et outils de VMware sont mis en oeuvre : VMotion, VMware Storage, vCenter
Server, etc. Enfin, côté application, on pourrait déployer sur vCloud une simple appliance pour pouvoir
l'utiliser dans le nuage et y accéder. Un jeu d'API est disponible pour les développeurs.

Donc on ne casse pas, en théorie, son usage de VMware, ces appliances VMware. L'éditeur a beau jeu de
critiquer Microsoft avec Windows Azure. Windows Azure ouvre des perspectives aux partenaires,
développeurs, éditeurs car Azure est attaquable par plusieurs langages de développement et si Microsoft
veut réussir, il est condamné à l'ouvrir et à ne pas le fermer sur le seul .Net. Azure est une plate-forme
complète, clés en mains, sans besoin d'utiliser tel ou tel composant tiers. Nous sommes là sur du vrai
système cloud. Nous pensons que nous aurons cette double approche sur le marché. Il y a aura toujours des


entreprises, utilisateurs, développeurs qui voudraient un assemblage de briques et d'autres du clés en mains
de bout en bout comme Windows et sa plate-forme.

Pourquoi finalement opposer les deux modèles ? VMware est dans un rôle de défense de ses positions sur la
virtualisation car la bataille est rude. Et il sait qu'il doit trouver d'autres marchés pour continuer à croître car
sur l'hyperviseur, la bataille est perdue étant donné sa quasi-gratuité.

3 Le CloudOS n’est pas un webos
Mais finalement qu’est-ce que CloudOS au sens système d’exploitation que n’est pas vSphere ? Il s’agit
d’un « OS » bootable au démarrage de son ordinateur. Ainsi au lieu d’accéder à son système desktop
classique, la machine se connecte au système cloud directement sur le web. Contrairement à un webos, on
peut donc se passer de l’OS local. Le projet gOS Cloud tente de matérialiser ce concept de CloudOS. Le
navigateur reste cependant l’outil central par où tout passe… Ce projet mise pour le moment surtout le
marché du netbook. Autre projet : Jolicloud.

En tant que tel, le webos restera un marché limité et malgré quelques belles réussites comme exoplatform,
nous ne voyons pas de percée significative de ces « systèmes ». Mais ce n’est pas pour autant que le
CloudOS constitue l’avenir. Encore trop vague et par le manque de concret, ce marché existe à peine, pour
ne pas dire n’existe pas. Nous demandons à voir…


Partie 8 : la géo-localisation, problème ou faux problème ?

Depuis plus d'un an, quand nous discutions avec des développeurs, entreprises et éditeurs, un des
éléments récurrents qui revient toujours et encore est la géolocalisation des données et des
applications. Le plus souvent, ce sont les utilisateurs qui se posent des questions sur la localisation
des données et des applications. C’est l’une des faiblesses actuelles du cloud.

Par géo-localisation des données, on entend le fait de savoir où sont stockées nos données. C’est à
dire dans quel centre de données et sa localisation géographique (au moins le pays). Cette demande
n’est pas aussi anodine qu’il n’y paraît. Un centre de données (Datacenter) situé par exemple en
Angleterre aura, en principe, des performances d’accès aux données, d’affichages, de traitements,
plus lents qu’un centre localisé en France. Cette proximité joue un rôle non négligeable dans les
performances des logiciels et des fichiers stockés dans le cloud. Mais dans un scénario plus
complexe, imaginé pour une société internationale, de stocker des données selon le fuseau horaire et
l'activité par zone géographique.

Pas aussi simple que cela
En réalité, la géo-localisation pose plusieurs problèmes aux fournisseurs de Datacenter, aux éditeurs
de plate-forme et aux développeurs et administrateurs. Les premiers doivent disposer de plusieurs
datacenters dans le monde pour proposer cette fonction de localisation mais il faut aussi disposer de
consoles d'administration pour automatiser la localisation et les politiques de localisation des
données, sans oublier la disponibilité de librairies de développement pour intégrer ces fonctions
dans les applications.

On s’aperçoit que la géo-localisation demeure peu répandue. Le sujet restant sensible. Google ne
propose rien. Microsoft, avec Azure, possède des librairies de développement, pour la géo-
localisation. Dans le cas d’Azure pour exemple, à la création d’un nouveau projet hosté, on peut
choisir le Datacenter (2 au choix actuellement). Chez Sun, rien de disponible mais le sujet reste
d'actualité chez eux. Ensuite, pour les éditeurs Saas, la situation est à étudier au cas par cas.
Amazon propose, pour EC2, une gestion par régions. Ainsi, il est possible de spécifier une région
comportant un Datacenter selon les besoins. L’un des intérêts est basculer d'un cloud américain à
un cloud européen, etc. selon les besoins immédiats.

L’autre possibilité sera de pouvoir basculer d’un cloud à cloud quel que soit le fournisseur. Or, cette
possibilité est aujourd’hui impossible par l’absence d’intéropérabilité entre les plate-formes. C’est
pour cela que des initiatives telles que Open Cloud, peuvent aider à bâtir un cloud transparent.

Au-delà, la question de la donnée
Mais avant de parler géo-localisation, l'usager doit aussi déterminer quelles données il souhaite
mettre dans le cloud. Car selon la nature des données, la géo-localisation n'aura pas ou peu d'intérêt.
Voici quelques cas de figures possibles :
− localiser la donnée au plus proche de l'utilisateur, du client pour des questions de
performances
− pour des questions légales : n'oublions pas que les entreprises ont des obligations légales par
rapport à certaines informations comptables et l'accès des données par un juge, une
administration. Ainsi si légalement, des données doivent être disponibles et stockées dans la
zone Europe, légalement, l'utilisateur n'a donc pas le droit d'utiliser un cloud américain.
− Pour des questions de sécurité et localisation précise de la donnée.


Partie 9 : la question de l'interopérabilité

Comme sur le poste de travail, le serveur, les applications, les documents, la question de
l'interopérabilité devient une composante de plus en plus stratégique même si aujourd'hui pour les
éditeurs et les utilisateurs, la question se pose peu car le cloud computing reste en pleine
maturation. Mais l'interopérabilité dans le cloud se pose déjà. Contrairement aux web services qui
avaient mis des années avant d'offrir un niveau satisfaisant, le cloud se prépare à cette question mais
avec des solutions pas toujours intéressantes pour l'utilisateur.

1 Open Cloud : et après ?
Il y a quelques mois une initiative prônait un cloud computing ouvert et totalement interopérable.
L'initiative avait connu des débuts assez laborieux mais aujourd'hui elle mérite d'exister et de poser
les bonnes questions même si aujourd'hui l'idée repose sur des principes à respecter et des
spécifications précises.

Comment en effet assurer une interopérabilité sur le cloud ? Les principes énoncés par Open Cloud
posent des idées simples :
- laisser le choix
- flexibilité
- rapidité et agilité

Mais pour cela, le manifeste s’appuie sur :
- les providers cloud doivent travailler ensemble pour adopter et créer des standards
- ces providers ne doivent pas utiliser leur position sur le marché pour verrouiller ledit marché
ou bloquer les utilisateurs
- ces providers doivent utiliser et adopter les standards existants et approprier
- quand de nouveaux standards seront nécessaires, il faudra éviter les doublons et agir de
manière pragmatique
- les organisations, consortiums, communautés doivent travailler ensemble.

2 l'interopérabilité passe par quoi ?
Il y a plusieurs paramètres à prendre en compte. Dans le cloud, il s'agit de pouvoir déplacer son
cloud d'une infrastructure à une autre en toute transparence. De pouvoir déplacer, migrer ces
applications cloud d'une plateforme cloud à une autre en toute transparence. Cela passe donc par
des spécifications paas et iaas communes ou tout le moins compatibles, des SDK et API
compatibles sur plusieurs iaas et paas. Pour faire simple, nous pourrions passer d'une cloud A à un
cloud B pour une application Google App Engine ou Windows Azure.

La notion d'interopérabilité doit concerner l'ensemble des éléments de son cloud, de son application
cloud. Ou encore assurer qu'une partie seulement de son cloud doit migrer d'une infrastructure /
plateforme à une autre. Ainsi, nous pourrions passer d'un stockage A à un stockage B, etc.

Aujourd'hui il existe de nombreux freins à cette interopérabilité. Les grands éditeurs jouent une
partie de leur avenir sur le cloud et les services cloud. Mais, dans le même temps, ils ne doivent pas
non plus trop fermer leurs solutions au risque de perdre des marchés.

Actuellement, une application cloud basée sur des librairies, composants Azure impose un cloud
Azure, pour le moment Microsoft mais des tiers pourront déployer l'environnement Azure. Côté
Google App Engine, il existe le projet AppScale qui offre un support partiel de AppEngine (Python,
Java prévu). Demain, nous aurons des applications cloud Linux, pures Java, Mono et pourquoi pas
une déclinaison Flash – Flex, etc.


Dans la question de l'interopérabilité, nous différencions bien les aspects plate-formes et
infrastructure car les enjeux ne sont pas forcément les mêmes ou tout le moins ne concernent pas les
mêmes personnes. Pour un développeur, la plateforme fournit les SDK, librairies, services. Il ne
doit pas se soucier de la partie infrastructure qui est plutôt liée à l'administrateur. Par contre, au
développeur de tester et de valider, de concert ou non avec l'administrateur, le bon fonctionnement
applicatif sur un ou plusieurs iaas. Ne disons pas encore sur différents paas, ce serait un peu trop
ambitieux dans l'état actuel des solutions du marché.

Cependant, il ne faut pas non plus espérer disposer avec Azure d'une plateforme d'exécution
universelle même si les ouvertures sont là. Mais pour des applications « simples » non .Net, Azure
peut être une bonne solution. A l'opposé, il n'est pas possible d'y faire fonctionner du App Engine et
sur App Engine, pas possible d'y faire exécuter des applications .Net. Par contre dans Sales.com,
App Engine est présent grâce à des accords.

Bref vous l'aurez compris, l'interopérabilité ne va pas de soi et il faudra bien choisir son paas et iaas
tant que l'on ne disposera pas de SDK, API, de spécifications ouvertes, reconnues. Les accords
bilatéraux sont donc à l'heure actuelle une bonne solution, en attendant mieux.

Nous retombons dans les travers des plate-formes RIA. C’est à dire que l’on est obligé de choisir
une plate-forme avec une ou plusieurs solutions complémentaires. L’interopérabilité est clairement
un enjeu que les éditeurs doivent absolument clarifier. Et au moins être parfaitement précis par
rapport à la portabilité des applications d’un cloud à un autre. Gros point noir dans notre cloud.


Web 4.0 en guise de conclusion provisoire

Conclure sur le cloud computing est illusoire car depuis les premières lignes de ce document,
l'univers du nuage a évolué avec de nouvelles offres, de nouvelles tendances mais il faut aussi
savoir se poser et réfléchir à un moment donné. Car depuis des mois, la succession des annonces et
autres initiatives fait perdre la tête. Pas un jour ou presque sans qu'un éditeur nous sorte une
nouvelle déclinaison d'un service en ligne. On atteint parfois la déraison total en tentant de nous
faire passer une offre basique pour du cloud nouvelle génération alors qu'il s'agit simplement de
faire de la virtualisation sur des serveurs distants... Il faut arrêter avec tout cela. Car il est toujours
dangereux de trop noyer la technique dans une marée marketing. Personne ne s'y retrouve.

Comme avec toute technologie, il faut savoir garder la tête froide et analyser, comprendre. Car
comme vous l'aurez compris si on applique une stratégie cloud de bout en bout ou même partielle
cela change pas mal de choses notamment dans la manière de conduire son SI ou tout simplement
de consommer ces applications. Les conséquences sont multiples et pas toujours comprises par
l'éditeur venant dans ce type de technologies et par l'utilisateur.

Au printemps dernier, nous avons entendu dire que le cloud computing sera le web 4.0. Pourquoi
pas ? Cependant, il faudrait déjà que l'on digère la vague 2.0 avant d'avoir l'obscur web 3 dont les
contours changent toutes les semaines. Il faut arrêter avec cette volonté de donner des numéros au
web. Car en réalité nous ne sommes déjà plus réellement dans le web 2 notamment à cause des
technologies riches de type RIA. Et le cloud est-il encore du web au sens actuel du terme ? Nous ne
le pensons pas.

Que le cloud soit ou non le web 4, cela importe peu finalement. Car il préfigure d'une manière ou
d'une autre, une des pistes du futur de l'informatique, des applications. Les prochains mois seront
passionnants. Et si finalement, nous avions dans quelques années un simple PC allégé, un système
client minimum appelant des services en ligne ou alors bootant directement sur un Cloud OS...


Annexes

Pour aller un peu plus loin, voici une petite sélection d'articles et de tutoriaux afin d'ouvrir
l'approche...


Live Mesh : ma première application

Mesh de Microsoft, un service dans le Cloud Computing, propose un puissant service de stockage
avec synchronisation entre les différents terminaux (PC, Mac et bientôt mobiles). Mais combiner à
Windows Azure, il permet de déployer en quelques clics des applications visibles et utilisables
partout sur son compte en ligne !

Les pré-requis
Avant toute chose, vous devez disposer de :
Windows XP ou Vista. Nous avons rencontrer quelques petits soucis avec Windows 7 Bêta.
1 Visual Studio 2008 SP1 ou Visual Web Developer Express 2008 SP1.
2 SQL Server Express 2008
3 Et bien entendu du Framework .Net.

Attention : il est très important d’installer le SP1 car les SDK Azure et Mesh ne fonctionneront pas
sinon !

Ensuite, installez dans l’ordre :
1 Silverlight Tools for Visual Studio
2 SDK Live Framework (attention : pour ce dernier il doit être placé dans le dossier Microsoft
SDKs
3 Installer Live Tools for Visual Studio

Créer un projet Mesh
La création d’un projet Mesh est aussi simple qu’un projet WPF ou WinForm. Dans la fenêtre
projet, on sélectionne Mesh enabled Web Application. Dans notre exemple nous avons utilisé
Visual Web Developer Express 2008. Deux templates Mesh sont disponibles : Mesh enabled web
application et Silverlight Mesh enabled Web Application.

Dans le gestionnaire de projet, on dispose des fichiers nécessaires : index.html, fichiers javascript.


Il suffit ensuite de coder en javascript ce que l’on souhaite avoir dans son application.

Une fois le codage terminé, on build le projet (menu Build - Build). Notre projet est prêt à être
déployé.

Déploiement de son projet Mesh dans Azure
Après avoir réalisé le build du projet, encore faut-il le déployer sur son espace Mesh. Tout d’abord,
vous devez créer un compte utilisateur sur le service Azure Services Developer Portal. C’est lui qui
va en effet permettre le déployer de la solution. Nous préférons le déploiement en ligne que de
passer par l’IDE car nous avons rencontré des soucis de connexion.

Connectez-vous à votre compte. On crée un nouveau projet.


On sélectionne Create a Mesh enabled Web application.

Votre projet s’affichage dans la colonne de gauche et automatiquement l’onglet summary apparaît.

Pour déployer son application, les étapes sont lui suivantes :


1 cliquez sur le bouton upload package
2 ensuite on indique l’emplacement du package zip de notre projet (via le bouton Browse).
3 Bouton Deploy pour charger le projet.

Azure s’occupe de charger les fichiers. Nous n’avons rien à faire ! Quand l’opération est terminée,
il suffit de cliquer sur le bouton Publish. Quand le projet est publié, le label du bouton indiquera
Unpublish.

Déploiement dans Mesh !
La publication dans Azure de son application n’est que la première étape. Il faut maintenant la
déployer dans Mesh pour l’utiliser.


Pour cela il faut aller sur developper.mesh-ctp.com et non sur son compte Mesh qui ne supporte pas
le déploiement d’application. Mais son compe Mesh fonctionne sur la partie Mesh Developer. On
connecte sur le Live Desktop.

Nous cliquez sur l’onglet Apps (en haut) pour accéder à la partie application. Pour installer son
projet, on clique alors sur Browser more applications. Notre application est dans la liste. On la
sélectionne puis on valide par le bouton Add to Mesh.

Par sécurité, Mesh demande l’autorisation d’accès (Allow Access). On clique. On peut alors revenir
sur la partie Desktop et une icône apparaît sur le bureau : MeshApp1. Un double clic et l’application
s’exécute.


C’est tout. Et comme Mesh fonctionne aussi sur MacOS X, on peut utiliser une application Mesh
avec son Mac.

D’autre part, dans un projet Silverlight Mesh, il est possible de créer et de modifier l’interface via
l’outil Expression Blend. Les fichiers d’interface étant des fichiers purs XAML.


Ma première application Google App Engine Java dans le cloud computing !

Après notre tutoriel sur Mesh, nous vous proposons aujourd’hui de voir comment en quelques clics
on génère une application dans le nuage avec Google App Engine Java, Eclipse et le cloud
computing de Google.

Pré-requis
Vous devez disposer des éléments suivants pour ce tutoriel :
− Eclipse 3.3 ou 3.4 (aucune garantie de fonctionnement avec la 3.5 ou e4)
− Compte App Engine actif avec une instance d’application disponible
− Connexion internet

Pour notre part, la configuration utilisée pour notre exemple se compose de :
− Eclipse 3.4.1
− MacOS X 10.5.6
− Connexion internet haut débit

Installation des plug-ins et SDK Google
Pour pouvoir démarrer notre exemple, nous devons préalablement installer les composants Google
dans Eclipse. Pour ce faire, nous utiliserons le module Software Updates (menu Help).

L’opération est très simple : clique sur le bouton Add Site. La fenêtre Add Site apparaît. Il suffit
alors de rajouter le site suivant :
http://dl.google.com/eclipse/plugin/3.4

Automatiquement, Eclipse rajoute le site et liste les éléments Google disponibles. Nous cochons
alors sur Plugin et SDKs pour tout rajouter (Google Plugin for eclipse 3.4, App Engine SDK et
GWT SDK). Lancez l’installation (bouton Install). Puis cliquez sur Finish pour valider
l’installation.


L’installation s’occupe de tout, à la fin, Eclipse demandera la validation des modifications (bouton
Yes pour accepter).

Après le redémarrage, il est très facile de voir si Google est présent. La toolbar Eclipse doit afficher
trois nouveaux icones : Google web application, GWT et App Engine.

Rajouter de son application dans App Engine
Avant d’aller plus loin dans Eclipse, créons dès maintenant une instance applicative dans notre
compte App Engine.


La première étape est de se connecter à son compte App Engine. Nous créons une nouvelle
application (bouton Create an application).

Deux éléments à renseigner :
− l’identification de l’application (ID) : c’est le nom de domaine de son application dans le
cloud Google. Attention : vérifiez toujours la disponibilité de l’ID !
− Puis on renseigne le titre de l’application. Nous allons l’appeler : programmez2009.

Voilà, programmez2009 est disponible sur App Engine. Pour vérifier il suffit d’aller sur son tableau
de bord (Dashboard). Notre application est dite « no version deployed » car aucune application n’a
été déployé pour le moment.

Projet Eclipse
Créons maintenant notre projet dans Eclipse. Faisons un nouveau projet, dans l’assistant, on
choisira : Google - Web Application Projet. Bouton Next.


Cloud computing

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Cloud computing

Ähnlich wie Cloud computing (20)

Cloud computing