I. Les Définitions du Cloud Computing▲
Il existe deux principales définitions du Cloud Computing.
I-A. Le cloud utilisateur▲
La première consiste à externaliser ses données et ses applications vers des serveurs d'applications web, au lieu d'utiliser des logiciels installés sur son ordinateur de bureau, et de charger des fichiers sur le disque local. Typiquement, il s'agit d'utiliser Gmail, Google Agenda ainsi que Google Docs au lieu de la suite MSOffice (Outlook, Word, Excel, etc.).
I-B. Le Cloud cluster▲
L'autre définition est de type architectural : plusieurs serveurs sont mis au service d'une seule application. On parle d'un cluster de serveurs, mais l'innovation récente est l'élasticité. Le locataire du service peut programmer en fonction des événements la montée ou baisse de charge. Le cluster augmente ou se réduit en quelques minutes, et la facturation suit.
I-C. Le « Vendor »▲
Le terme « service » étant ici sujet à de multiples interprétations, j'utiliserai souvent l'anglicisme Vendor pour Fournisseur de Services. Le Vendor sera donc Amazon, Google, SalesForce, et vend de la location de serveurs, des autorisations d'accès à une application web, du support, etc.
I-D. Deux définitions pour finalement un même usage▲
En pratique, des millions d'utilisateurs vont utiliser en mode cloud leurs données à travers une application web, et ces données seront gérées par un cluster élastique de serveurs.
Comme le Vendor d'applications et le Vendor de clusters ne sont en général pas les mêmes, le terme marketing cloud est âprement disputé pour vendre à deux types de clients très différents : utilisateur classique (professeur mettant ses notes sur Google Spreadsheets, grand-parent sur Facebook ) ou utilisateur spécialisé (développeur paramétrant ses clusters, passionné(e) bidouillant des web services sur son Androïd, etc.).
II. IaaS, PaaS, SaaS▲
II-A. IaaS : Infrastructure as a Service▲
Le IaaS permet de gérer son parc informatique à distance. Les serveurs et l'application de gestion (ou les commandes en ligne) sont gérés par le Vendor.
Exemple typique : Amazon EC2
Notons que Amazon EC2 propose la location de ses serveurs, alors que Sun propose la couche logicielle permettant de gérer un parc informatique avec Open Cloud. Ainsi un entrepreneur pourrait utiliser cette couche logicielle, acheter des serveurs, et devenir, très rapidement et sans de lourds investissements en développement, un fournisseur IaaS.
II-B. SaaS : Software as a Service▲
Apparu vers 2006, le terme SaaS remplace progressivement, et peut-être à tort, le terme ASP (Application Service Provider). Historiquement, un Vendor ASP propose un logiciel distribué sous forme de client léger : c'est par exemple le cas pour le paiement des amendes ou des impôts qui sont des services qui n'auraient jamais vu le jour sans Internet, puisque l'on voit mal la FNAC vendre un logiciel de paiement d'amendes.
Un Vendor SaaS propose des services web permettant d'accéder ou de modifier des données. Ainsi la messagerie Gmail, concurrent SaaS de Outlook, est accessible à partir d'une multitude de clients (gmail.com, Netvibes, Facebook pour la recherche dans les contacts, iPhone, etc.).
Application typique en SaaS : AccuWeather, service de météo accessible sur leur site, mais aussi en barre de tâches sous Firefox
Application typique en ASP : le paiement des impôts, accessible uniquement sur le site officiel.
II-C. PaaS : Platform as a Service▲
Dernière en vogue, la PaaS est une plateforme de développement s'appuyant sur le IaaS gérée par le Vendor. Un Vendor va proposer à des développeurs un langage de programmation, des API, et des modules afin de déployer aussi rapidement que possible une application web supportant la montée en charge.
Le gros avantage est qu'il n'y a pas à s'encombrer de la configuration détaillée Linux, Apache et MySQL, l'inconvénient est que l'on est sensiblement lié aux évolutions de cette plateforme. En général, le prix de départ est assez faible, voire gratuit. Et surtout le nombre de compétences techniques requises est lui aussi moindre.
En contrepartie, il sera difficile de passer d'une plateforme à une autre, pour des raisons stratégiques, techniques, financières, ou si la plateforme périclite.
Plateformes typiques : Force.com, Google App Engine.
III. Le Cloud, pour quoi faire ?▲
III-A. Migrer un client lourd vers le SaaS▲
Le choix se pose si vous êtes utilisateur, ou gestionnaire d'un parc informatique : faut-il abandonner Microsoft Office pour Google docs ? SAP pour Salesforce ?
Pour les applications bureautiques comme Google Docs ou Gmail, c'est souvent un choix d'ergonomie. On aime ou on n'aime pas. Préfère-t-on partager un document directement en ligne, ou le renvoyer par email ? En général, les clients web proposent également des fonctionnalités différentes (partage facilité, contrôle de version, mais gèrent plus difficilement les gros fichiers).
Mais on peut aussi choisir Salesforce plutôt que SAP pour des raisons pratiques, si vos commerciaux sont en déplacements et qu'ils changent souvent de PC.
Pour une entreprise de logiciels, le choix de l'application SaaS impose des contraintes technologiques plus compliquées et surtout demande des compétences plus variées. Pour le même coût de développement, votre application proposera donc en général moins de fonctionnalités. Par contre elles sont plus faciles à distribuer et votre client aura un parc applicatif beaucoup plus facile à gérer, ce qui ouvre des marchés non contrôlés par les réseaux de distribution en place.
III-B. IaaS ou PaaS▲
III-B-1. Le choix▲
Le choix se pose si vous êtes développeur, ou responsable technologique d'une activité de production d'application web.
Le choix de l'IaaS nécessite de contacter un Vendor, choisir quelles machines (fréquence, mémoire, etc.), installer ces machines (Quel Linux ? Quel Windows ? Comment configurer FTP, etc.), déployer les machines. Puis il faut développer. Alors que le PaaS ne nécessite que le développement.
Le tarif est également un choix important. Alors qu'on paye chaque cycle CPU réellement consommé par l'application sur Google App Engine, on paye chaque instance déployée sur Amazon EC2. Si votre application sur EC2 consomme 0.1 instance de CPU, vous payez le même prix qu'une instance entière. En cas de pic, vous pourrez par contre déployer une deuxième instance pendant seulement quelques minutes.
III-B-2. Avantage et risque des PaaS par rapport à l'IaaS▲
En principe, il est plus rapide de développer pour une PaaS, car on se décharge de toute la partie Infrastructure. Cependant, il faut programmer dans l'environnement de cette plateforme, et il faut donc apprendre une nouvelle API, avec une documentation souvent insuffisante, et si cette API évolue sans assurer pleinement la compatibilité, votre code devra souvent évoluer. Pire, la plateforme pourrait faire des évolutions guidées par des choix à court terme rendant votre application trop coûteuse à faire évoluer. Encore pire, la plateforme pourrait tout simplement disparaitre. Si, comme Force.com, la plateforme n'est pas open source, votre application sera peut-être bonne à jeter !
III-B-3. Le futur pour le PaaS ?▲
Concernant la technologie Java, dans le futur, on peut espérer que des plateformes très proches des standards JEE permettent un déploiement à partir de la création Entities, et le déploiement d'un .war normalisé (telle l'architecture proposée par Netbeans).
JEE et .NET étant technologiquement très proches, il est probable que la même chose se passe sur .NET. Cela permettrait la migration rapide entre deux Vendor, qu'ils soient IaaS ou PaaS, maximisant la concurrence.
Par-dessus le déploiement standardisé, il est possible d'ajouter une API spécialisée. Il n'y a pas plus simple que Force.com pour générer des rapports personnalisés (voire faussés, c'est le privilège du codeur ;)), consultables de façon sécurisée par vos collaborateurs et clients.
III-C. Cloud Public ou Cloud Privé ?▲
Si Cloud Computing est mal défini, définir « private cloud » contre « public cloud » est encore plus délicat.
En général on parle de private cloud quand l'entreprise garde le contrôle unique des données. Il va de soi que cette sécurisation peut se faire sur n'importe quelle machine, mais on rentre dans un contexte marketing visant à rassurer les acheteurs sur la sécurité des données stockées chez un tiers. Amazon propose par exemple un système où seuls les membres d'une entreprise peuvent accéder aux services EC2. Reste que les données sont toujours stockées chez Amazon.
Si dans une entreprise, on veut faire une recherche de documents accessibles uniquement dans l'intranet, on peut déléguer cette recherche à un logiciel de type Google ou Exalead plutôt qu'à l'outil de recherche inclus dans Windows. Est-ce un private cloud ? Ce n'est ni spécialement élastique ni dans le web, mais utilise les techniques les plus modernes du web.
Dans la même veine, il arrive également de plus en plus fréquemment que des sociétés développent des applications web en interne pour gérer leurs travaux spécifiques. Par exemple, les employés remplissent en ligne la répartition de leurs heures, plutôt que de transmettre une feuille de service. Cela réduit en principe la charge administrative.
IV. Conclusion▲
J'utilise volontiers le Cloud Computing en tant qu'utilisateur. Si Google ferme demain, je perdrai tous mes mails, contacts, documents. Mais je peux très bien tout perdre en étant cambriolé ou en faisant tomber mon PC portable. Ces incidents peuvent très bien arriver en entreprise, et le cloud apporte en ce sens une nouvelle et réelle sécurité. À ceci près que si Google ferme, c'est toutes les données de l'entreprise qui sont perdues, alors qu'il est improbable que tous les disques durs crashent en même temps.
Pour le développement, je conseillerais d'avoir besoin d'au moins quatre ou cinq machines et d'avoir une véritable raison de penser qu'il en faudra bientôt dix avant de m'installer chez un IaaS, sans quoi je resterais chez un concessionnaire classique comme OVH. Les coûts par machines sont en général plus grands et les contraintes de migration importantes et difficiles à prévoir. Cela n'empêche cependant pas de mixer en utilisant par exemple un service Amazon S3 couplé à votre application hébergée de manière classique.
Quant à la PaaS, on peut attendre. On peut l'utiliser pour de petits projets, ou pour une opportunité particulière. Par exemple, et c'est un paradoxe, Google App Engine est un moyen extrêmement simple et gratuit d'héberger un site web 1.0.
Ma conclusion finale est toutefois que le PaaS standardisé est le principal avenir de la programmation. Mais quel standard ?
V. Remerciements▲
Merci à BiM et jacques_jean pour leur précieuse aide.