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. Livre blanc « Cloud Computing » par François Tonic 3

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

Livre blanc « Cloud Computing » par François Tonic

4

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 : Livre blanc « Cloud Computing » par François Tonic 5

• 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. Livre blanc « Cloud Computing » par François Tonic 6

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 Livre blanc « Cloud Computing » par François Tonic 7

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 ?

Livre blanc « Cloud Computing » par François Tonic

8

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 :

Livre blanc « Cloud Computing » par François Tonic

9

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. Livre blanc « Cloud Computing » par François Tonic 10

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 ».

Livre blanc « Cloud Computing » par François Tonic

11

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. Livre blanc « Cloud Computing » par François Tonic 12

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 :

Livre blanc « Cloud Computing » par François Tonic

13

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.

Livre blanc « Cloud Computing » par François Tonic

14

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).

Livre blanc « Cloud Computing » par François Tonic

15

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 Livre blanc « Cloud Computing » par François Tonic 16

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.

Livre blanc « Cloud Computing » par François Tonic

17

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é.

Livre blanc « Cloud Computing » par François Tonic

18

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.

Livre blanc « Cloud Computing » par François Tonic

19

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.

Livre blanc « Cloud Computing » par François Tonic

20

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 Livre blanc « Cloud Computing » par François Tonic 21

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 plateforme. 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 ». Livre blanc « Cloud Computing » par François Tonic 22

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 JeanMichel 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.

Livre blanc « Cloud Computing » par François Tonic

23

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. Livre blanc « Cloud Computing » par François Tonic 24

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. Nombre applications autorisées Nombre utilisateurs supportés Objets SGBD Stockage prix Free Edition 1 100 10 1 Go Gratuit Enterprise Edition 10 Au-delà de 100 200 Au-delà de 1 Go 50 $ user / mois Unlimited Edition Illimité par utilisateur 2000 Au-delà de 1 Go 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 5 serveurs physiques avec 25 serveurs virtuels Serveur physique supplémentaire + 10 serveurs virtuels Illimité sur une zone géographique Support standard 9x5 4 750 $ 1 250 $ 90 000 $ Support avancé 24x7 17 1500 $ 3 000 $ 150 000 $

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 Livre blanc « Cloud Computing » par François Tonic 25

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 Livre blanc « Cloud Computing » par François Tonic 26

-

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.

Livre blanc « Cloud Computing » par François Tonic

27

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.

Livre blanc « Cloud Computing » par François Tonic

28

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.

Livre blanc « Cloud Computing » par François Tonic

29

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 Livre blanc « Cloud Computing » par François Tonic 30

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…

Livre blanc « Cloud Computing » par François Tonic

31

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éolocalisation. 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.

Livre blanc « Cloud Computing » par François Tonic

32

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.

Livre blanc « Cloud Computing » par François Tonic

33

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.

Livre blanc « Cloud Computing » par François Tonic

34

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...

Livre blanc « Cloud Computing » par François Tonic

35

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

Livre blanc « Cloud Computing » par François Tonic

36

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.

Livre blanc « Cloud Computing » par François Tonic

37

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.

Livre blanc « Cloud Computing » par François Tonic

38

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 : Livre blanc « Cloud Computing » par François Tonic 39

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.

Livre blanc « Cloud Computing » par François Tonic

40

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.

Livre blanc « Cloud Computing » par François Tonic

41

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.

Livre blanc « Cloud Computing » par François Tonic

42

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.

Livre blanc « Cloud Computing » par François Tonic

43

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.

Livre blanc « Cloud Computing » par François Tonic

44

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.

Livre blanc « Cloud Computing » par François Tonic

45

Livre blanc « Cloud Computing » par François Tonic

46

Nous donnerons comme nom au projet : programmez2009. Nous gardons la configuration par défaut de GWT et de la version de App Engine. Bouton Finish pour créer l’ossature du projet. Build et déployer Comme notre « hello world » sera notre projet créé, cliquons maintenant sur le bouton App Engine.

Livre blanc « Cloud Computing » par François Tonic

47

Dans la fenêtre Deploy Projet to Google App Engine, renseignons tout d’abord : − le nom du projet : programmez2009 − nom utilisateur et mot de passe de son compte App Engine

Puis, on configure le projet App Engine en allant sur App Engine project setting pour y indiquer l’application ID : programmez2009 et la version (ici 1). Bouton OK pour valider. Si la mention « ready to deploy application programmez2009, version 1 apparaît sur la fenêtre Deploy projet to Google App Engine, tout est prêt et nous pouvons cliquer sur le bouton Deploy. Maintenant Eclipse s’occupe de tout. Comme il est ce fait tard, une petite tisane fera passer le temps… Dans le log d’activité d’Eclipse : deployment completed successfully couronnera de succès notre déploiement sur le cloud ! Vérifier cela sur notre compte App Engine. L’application est dans le cloud A défaut d’être dans le pré, programmez2009 est censé être sur le cloud de Google. Nous retournons sur le navigateur web et cliquons sur Dashboard pour mettre à jour notre compte App Engine. Comme prévu, la version 1 de programmez2009 est reconnue par App Engine. Il suffit d’aller sur Show All Applications (au niveau du Dashboard) pour la voir. Livre blanc « Cloud Computing » par François Tonic 48

Pour exécuter programmez2009, cliquons simplement sur la 1 (de current version).

Livre blanc « Cloud Computing » par François Tonic

49

Sauvegarde et stockage en ligne : y aller ou non ? Avertissement : article paru dans Solutions & Logiciels n°5 Le stockage et la sauvegarde en ligne reste un petit marché par rapport aux matériels classiques (NAS, RAID, bande, CD/DVD, etc.), mais la tendance est là. Rien qu’en France, on trouve des dizaines d’offre, à tous les prix, à tous les services de qualité, pour grand public et entreprise. « Il ne faut pas confondre stockage et sauvegarde » prévient Gilles Fauriaux (directeur commercial, Database-Bank). « Une sauvegarde externe peut sécuriser. Autre solution, avoir une sauvegarde locale et externe.» poursuit M. Fauriaux. Dans le cas de Datbase-Bank, une offre couplée permet cela avec un serveur résistant (serveur Wooxo). Aujourd’hui, les solutions en ligne viennent en complément aux unités locales (desktop et réseau), on parlera alors souvent d’architecture ou de sauvegarde sécurité, de secours. Dans certaines conditions, le stockage en ligne peut servir de stockage primaire. La sauvegarde ne doit pas être prise à la légère. « Les entreprises ne sauvegardent pas » affirme Dylan Goubin-Dahan (gérant associé de neobe). « La télésauvegarde reste un petit marché mais la tendance est à la croissance. Le haut débit autorise cela. Les utilisateurs ont moins de manipulations à faire. Les échanges sont sécurisés. On gagne du temps. » poursuit Dylan Goubin-Dahan. D’autre part, il ne faut pas oublier que les entreprises ont l’obligation de posséder une copie de sauvegarde des documents comme la comptabilité. Le pur internet Les solutions purement Internet sont très nombreuses. Dans ce cas de figure, nous passons uniquement par un navigateur pour charger sur votre espace de sauvegarde vos fichiers, pareillement pour accéder aux fichiers et les récupérer ou tout simplement à la console de contrôle. Les fonctionnalités offertes varient avec les prestataires. On trouve aussi régulièrement des espaces de stockages en ligne couplés avec des logiciels ou des services en ligne, surtout des services de partage, de collaboration. « Office Live Workspace peut servir de stockage mais on le voit comme une extension à la suite Office. C’est ni plus ni moins un sharepoint hébergé même si on peut y stocker des fichiers de tout type ! On peut y accéder de n’importe où. On peut y poster, faire un glisser-déposer… On peut définir les droits d’accès. » indique Franck Halmeart (chef de projet Office – Microsoft France). Client + Web Le plus fréquent dans le stockage en ligne est de disposer d’un logiciel client. Ce client permet de crypter et de sécuriser les échanges entre l’espace de stockage et le poste de travail. Il permet aussi de configurer les backup, de les automatiser. Bien entendu, les échanges se font via une session sécurisée, le plus souvent en https avec ou sans cryptage des fichiers. Dylan propose en plus un instant de n’importe où avec une authentification par une clé USB sécurisée. Des constructeurs proposent aussi de genre de services. Ainsi HP a lancé le service upline. Malheureusement pas encore accessible en France, cette offre propose une déclinaison pro entre 3 à 100 utilisateurs avec stockage illimité et des services de backup en ligne, une fonction de publication, recherche, partage e prochainement la possibilité de sauvegarder sa messagerie ! EMC autre acteur informatique majeur propose aussi son service ligne en rachetant en 2007 le service Mozy et depuis l’été dernier, Mozy est utilisé par les portables Thinkpad Lenovo (Lenovo Online Data backup). Aux Etats-Unis, Mozy est un des leaders du marché. En France, Mozy se positionnera en premier vers les TPE / PME. Aujourd’hui, les outils les plus avancées permettent de se synchroniser sur les profils utilisateurs Livre blanc « Cloud Computing » par François Tonic 50

présents dans un annuaire d’entreprise, bien pratique pour simplifier le travail de l’administrateur. Surtout, si à la première sauvegarde, l’ensemble des fichiers est transféré, ensuite, on fonctionne en mode incrémentale. Cela signifie que l’outil vérifie l’ajout de fichiers ou ceux modifiés. Cela permet d’optimiser le temps de sauvegarde. Surveiller les services et leurs qualités Si les offres pullulent, il faut savoir faire le tri. Plusieurs éléments vous aideront à choisir : − quelle disponibilité des données : par contrat, le prestataire propose-t-il du 24/24 ? En cas de panne, un délai de retour en disponibilité est-il précisé ? − les données stockées sur le service sont-elles répliquées sur plusieurs datacenters ? − la restauration intégrale des données stockées est-elle clairement indiquée et spécifiée par contrat ? − le contrat et/ou les conditions générales d’utilisation doit clairement reconnaître que vous êtes le seul et unique propriétaire des fichiers déposés sur l’espace de stockage du fournisseur. Cette liste peut vous paraître exagérée mais de nombreuses déconvenues sont survenues par le passé et vous devez réellement vous montrer très prudent sur la qualité de service proposée. Pour une entreprise, surtout si le stockage en ligne est massivement utilisé, le service doit être accessible sans coupure et sa dégradation des données stockées. D’autre part, avec l’explosion des offres, on trouve de plus en plus un stockage illimité. Si ce n’est pas le cas, vérifiez le coût par Go supplémentaire. La facture peut alors monter très vite ! D’autre part, quelle est la tarification ? Est-ce par mois ou annuelle ? Vous trouverez les deux, HP facture à l’année, par exemple. Enfin, le fournisseur doit préciser le mode de sécurité et de cryptage des données. La sécurité est un élément vital à ne pas négliger. Autre détail, le support et assistance. Si vous prenez un prestataire étranger, le support se fera souvent par mail et en anglais. Un prestataire français ou ayant une filiale en France facilite l’assistance (en général).

Livre blanc « Cloud Computing » par François Tonic

51

A propos de l'auteur

Historien et journaliste, François Tonic fut développeur et testeur de progiciels durant près de dix ans sur plate-forme Windows, Macintosh, Java, SGBD. Il débute dans la presse informatique en 1997. Depuis son côté geek n'a jamais cessé. Journaliste reconnu et fin connaisseur des technologies et des stratégies IT, il a collaboré avec une douzaine de magazines papiers et Internet. Travaillant aussi bien sur Windows, Linux que MacOS X, il aborde toutes les problématiques de l'IT actuelle. Rédacteur en chef du magazine spécialisé Programmez! depuis 2002, dont il fut journaliste dès 1999, il travaille aussi à Solutions & Logiciels, spécialisé sur le IT. Plongé dès les origines du Saas et du cloud, il fonde début 2009, un blog dédié à ces technologies : www.cloudmagazine.fr. En 2001, il fonde aussi un magazine entièrement dédié à l'Egypte des Pharaons dont il est toujours le rédacteur en chef. François est aussi auteur de plusieurs ouvrages archéologiques et historiques et de très nombreux articles sur ces domaines principalement dans les magazines Histoire de la Marine (12 numéros) et Les Grands Secrets de l’Archéologie (actuellement au numéro 13). Pour le contacter : ftonic2@orange.fr Site officiel : www.francoistonic.com

Livre blanc « Cloud Computing » par François Tonic

52

Sign up to vote on this title
UsefulNot useful