Docker, tour d'horizon rapide

Une précédente série d'articles a introduit la virtualisation, ses usages, et son rôle dans le développement de l'offre Cloud, en particulier IAAS et PAAS.

Vous êtes maintenant armés pour aborder le nouveau sujet qui fait le buzz depuis 2 ans et qui ne cesse de monter : Docker !

Si la virtualisation, les termes IAAS PAAS SAAS, la gestion de configuration, sont des termes abstraits, je vous recommande de commencer par lire ces articles précédents qui introduisent toutes ces notions :

La Haute Disponibilité en bref
Virtualisation, principes et usages
Formes et intérêts du Cloud computing

Déjà une précision : Docker est une technologie de conteneurisation, et au delà de Docker nous allons nous intéresser à cette notion de container. Docker est le produit phare dans ce domaine mais il n'est pas le seul et l'offre est probablement amenée à se diversifier fortement. 

On peut aborder Docker et la notion de container sous différents angles. Un angle très technique consisterait à expliquer comment ça fonctionne, ce qui nous amènerait inévitablement à devoir aborder des notions systèmes avancées, avec un pré-requis important sur le fonctionnement interne d'un système d'exploitation Linux. Nous n'allons pas prendre ce chemin, j'aborderais quelques points mais tant mes compétences en la matière que le vocation de ce blog me font privilégier une approche plus axée sur les usages.

L'idée de base du container

Comme le nom l'indique, un container est une espèce de boite logique, virtuelle, dans laquelle on enferme certains éléments pour les isoler du reste du monde.

Pensez à une boite fermée dans laquelle vous stockez des aliments dans votre cuisine. Remplacez la boite physique par une boite virtuelle, les aliments par des fichiers stockant des données binaires représentant des programmes et des données, et la cuisine par un serveur et vous devez comprendre à peu près l'idée. 

On parle bien sur de serveur physique ici, un ordinateur sur lequel on fait tourner un système d'exploitation, Linux dans le cas de Docker.

Vous pouvez donc avoir plusieurs containers sur votre serveur, de la même façon que vous pouvez avoir plusieurs boites dans votre cuisine. L'avantage est que les aliments d'une boite n'iront pas, par exemple, imprégner de leur odeur les éléments d'une autre boite. Et dans le serveur l'objectif est le même, les données et programmes d'un container n'iront pas interagir avec ceux d'un autre container.

L'intérêt est que comme vos boites se partagent la cuisine, ses étagères et son frigo, les containers se partagent un certain nombre de ressources à commencer par le système d'exploitation. Imaginez un peu si deviez avoir un placard ou un frigo distincts pour chaque aliment, ça vous coûterait cher et ça vous prendrait plein de place. Mais grâce aux boites hermétiques, vous pouvez tout ranger côte à côte.

J'arrête là les métaphores culinaires, je pense que l'idée de base est posée.

En terme informatique, on obtient la possibilité pour un serveur physique de fournir davantage de services grâce à la mutualisation de ses ressources entre divers containers fournissant chacun un service. Sans cette technologie, si on a 10 containers et donc 10 services, il nous faudrait 10 serveurs avec chacun un système d'exploitation supportant un service. Ou encore, un serveur physique avec un hyperviseur et 10 machines virtuelles chacune hébergeant un système d'exploitation supportant un service.

Et bien sur comme vous l'aurez deviné, 10 serveurs et 10 licences d'OS ou encore 1 gros serveur de VM, 1 licence pour un hyperviseur, et 10 licences d'OS ça coûte plus cher que la solution où on a un seul serveur, qui a bien moins besoin de puissance que le serveur de VM, avec 1 seul OS et 10 containers.

Pourquoi le serveur qui héberge 10 containers a il moins besoin de puissance qu'un serveur qui héberge 10 VM ?

Point besoin d'être un grand crack en informatique pour comprendre. L'hyperviseur consomme des ressources, et 10 VM ça veut dire 10 OS qui chacun consomment des ressources (et en outre elles émulent le matériel ce qui a aussi un coût), alors que dans le cas du container on n'a ni hyperviseur, ni émulation, et un seul OS qui tourne (qui embarque un démon Docker, c'est à dire un service en tâche de fond qui tourne en permanence).

Alors bien sur, toutes choses étant égales par ailleurs, cet avantage se paye ailleurs par des inconvénients, mais nous y viendrons plus loin.

J'en termine sur cette introduction sur la notion de container pour parler des usages qui sont faits de cette technologie :

• exploiter des plateformes multi-utilisateur : un seul système d'exploitation qui est partagé par un grand nombre d'utilisateurs (bien sur connectés à distance, avec par exemple le bureau à distance Windows, ou avec une solution de DAAS comme le propose Citrix par exemple). On a un container par utilisateur qui isole ses données et programmes de ceux des autres utilisateurs simultanés.

• exploiter de nombreux programmes sur un seul ordinateur de façon à limiter les coûts matériel

C'est ce second usage qui va nous intéresser, et en particulier sa mise en perspective avec les solutions de virtualisation qui permettent également de répondre à ce même besoin.

Container vs Machine virtuelle

La technique de conteneurisation a certaines similitudes avec la virtualisation au niveau des usages ; elle permet d'atteindre de façon différente, avec des avantages et des inconvénients, certains des avantages clés procurés par la virtualisation.

Du fait des ces similitudes, on qualifie souvent Docker, la solution phare, de solution de virtualisation légère pour l'opposer aux hyperviseurs qualifiés de virtualisation lourde. C'est à mon sens un abus de langage, Docker n'étant pas une solution de virtualisation. Simplement, il entre en concurrence avec la virtualisation sur certains cas d'usages.

L'isolation des environnements est un point important. Il ne serait pas acceptable de faire tourner de multiples services sur une même machine physique si ils pouvaient se perturber mutuellement. Cette isolation est assurée par l'hyperviseur dans le cas de la virtualisation et par le logiciel de conteneurisation, disons Docker, dans le cas des containers. Et ici la virtualisation gagne la manche sans aucune discussion possible, l'isolation est bien plus sure et le risque d'avoir un service qui fait dysfonctionner les autres bien moins grand.

La consolidation de multiples serveurs sur un seul serveur physique. C'est l'avantage économique majeur qui a permis à la virtualisation de s'installer depuis 10 ans comme une technologie incontournable. Ici le match est plus serré et dépend fortement des besoins à satisfaire. Comme nous l'avons déjà vu, la conteneurisation est plus optimale en terme de ressources requises et permet donc de consolider davantage de serveurs et donc de réaliser des économies plus importantes. Mais il y a une contrainte forte ; alors qu'avec un hyperviseur vous pouvez faire tourner à peu près n'importe quel système d'exploitation courant, tous les containers se partagent le même OS et donc doivent impérativement tourner sous le même OS, Linux en l’occurrence pour Docker.

Automatisation

La conteneurisation n'est en rien une idée nouvelle et diverses technologies, essentiellement propriétaires, existent depuis bien longtemps, notamment au niveau des systèmes Unix.

En fait, on peut même faire le rapprochement avec un style d'architecture logicielle qu'on appelle le multi-tenant (multi-tenancy) et qui vise à permettre la mutualisation d'un élément utilisé pour rendre un même service dans différents contextes d'utilisation. Simplement ici, l'élément factorisé au lieu d'être un logiciel serveur quelconque ou une application métier commercialisée en PAAS (contexte le plus fréquent de mise en oeuvre du principe) est l'OS lui même.

Linux a des capacités en la matière depuis longtemps, inspirées des Unix propriétaires, mais elles ont été étendues de façon astucieuse par les auteurs de Docker. En particulier, ils ont ajouté la capacité de gérer des modèles de container qu'on peut stocker, référencer, mettre à disposition ... et les outils permettant de les déployer avec une grande facilité et une très grande vitesse. Et ainsi procuré à l'outil un avantage important par rapport aux solutions de virtualisation.

Ainsi, en couplant un repository (un endroit où on stocke des définitions de container) avec un outil simple d'utilisation disponible sur un système Linux équipé du logiciel Docker, on obtient la possibilité d'automatiser le déploiement des environnements avec une grande facilité (chaque environnement étant un container).

De la même façon qu'un développement logiciel bien organisé s'appuie sur un repository de composants (librairies de code, frameworks) et des outils de build automatisant leur téléchargement et leur déploiement (ici le déploiement c'est l'intégration du composant dans le produit final issu du build), on a des repository Docker et les outils Docker associés. Pour faire le parallèle avec le monde du développement Web Java, Docker fournit à la fois le repository Maven et l'outil Maven avec le plugin qui va bien (ou encore un équivalent npm ou bower côté développement front). 

On utilise parfois le terme terme Infrastructure As A Code pour désigner cette capacité. Cette capacité est très importante en ingénierie logicielle car elle améliore la gestion de configuration en permettant de gérer les versions de l'environnement d'exécution d'un programme (la définition d'un container, ce qui est quelque chose de léger) avec ou en parallèle du code du programme proprement dît. Toujours pour faire un parallèle avec le développement Java/Web c'est l'équivalent du stockage du pom.xml Maven avec le code source (pour ceux à qui ça parle).

Un des articles sur la virtualisation cité en préambule détaille l'intérêt de la capacité à reproduire de façon automatisée un environnement et cite un certain nombre d'outils existants et utilisés conjointement avec les solutions de virtualisation (Vagrant and co). Docker apporte les mêmes capacités mais de façon plus simple et mieux intégrée. Et surtout... déployer et démarrer un container Docker est une affaire de secondes, là où la même opération pour une machine virtuelle est infiniment plus lourde.

DevOps

La démarche DevOps est à la croisée de nombreuses tendances (en matière d'organisation des DSI, d'architecture logicielle, d'outils, de démarche agile ...) et on ne saurait la résumer en quelques mots tant elle impacte de nombreux aspects du métier. 

Un de ses aspects clés est de casser la barrière existant entre les équipes de développement d'une part (Devs), et les équipes d'exploitation d'autre part (Ops). Les premières travaillent à fabriquer les logiciels utilisés dans l'entreprise, les secondes à les mettre à disposition des utilisateurs et à s'assurer qu'elles fonctionnent correctement et avec des coûts de fonctionnement maîtrisés. 

Je détaillerais ceci dans un article futur sur le sujet mais pour le moment ce qui nous intéresse est de savoir que ces équipes travaillent chacune sur des environnements différents qui sont, dans une DSI correctement organisée selon les cadres méthodologiques de référence, totalement étanches. Or, il est essentiel que ces environnements soient identiques afin d'éviter des différences de comportement des logiciels entre par exemple le serveur de test utilisé par les développeurs pour le test et la mise au point des programmes, et le serveur de qualification utilisée par la maîtrise d'ouvrage pour qualifier le bon fonctionnement, ou encore le serveur de production utilisé par les vrais utilisateurs.

Et ici Docker apporte une vraie plus value en permettant le partage des environnements (de la définition des containers stockée dans un repository commun par exemple) entre les deux équipes. C'est une autre des raisons de son succès.

Docker peut donc être cité comme un des outils favorisant l'adoption d'une démarche DevOps dans une DSI.

Cloud

Les capacités natives d'automatisation du déploiement des environnements, la forte capacité de consolidation de nombreux environnement sur un serveur physique, et le fort intérêt de la profession envers Docker ont amené tous les grands acteurs du Cloud à mettre en place des offres basées sur Docker, en particulier pour les offres de PAAS.

Et les choses choses vont au delà. Pour offrir de la haute disponibilité, il s'avère nécessaire de gérer des clusters de containers, c'est à dire des ensembles de containers coordonnés sur des machines physiques différentes. Ceci est indispensable pour le support de la tolérance de panne par exemple, mais également utile pour permettre l'ajustement dynamique des capacités de traitements aux besoins ce qui est une caractéristique essentielle du Cloud.

La gestion de repository de container est également un autre aspect, tant pour permettre aux organisation de gérer leurs containers, que fournir des containers "clés en mains" (ce qu'on appelle des appliances) pour répondre aux besoins courants.

Signe de l'intérêt pour Docker et de son adoption, divers outils sont apparus :

• Google a mis à disposition Kubernetes qui a reçu un accueil très favorable
• Docker fournit Swarm
• La fondation Apache (acteur incontournable de l'open source) a étendu son offre Mesos pour prendre en compte Docker

Le temps et la place me manquent pour entrer plus dans le détail de ces sujets passionnants. Si vous devez retenir une chose, c'est que ces outils permettent à Docker de passer à une dimension supérieure et le signe indubitable du grand intérêt de la profession pour cette solution. Pour le reste, Google is your friend ;-)

Adoption de la technologie

Il semble indéniable que la technologie Docker est plus qu'un effet de mode. Elle est soutenue par tous les acteurs majeurs de l'industrie qui investissent.

Quelques éléments à l'appui de cette affirmation.

Un consortium a été créé ce qui est un signe favorable car la mise en place d'une gouvernance autour du sujet est essentielle pour éviter l'apparition de multiples chapelles et d'incompatibilité qui peuvent conduire une belle idée à l'échec.

Microsoft met les bouchées doubles pour le support de Docker, dans son offre Cloud Azure bien sur, mais également dans son offre de systèmes d'exploitation ce qui est déjà plus surprenant. Il y a également des rumeurs de rachat de la société Docker par Microsoft.

Le support de Google s'exprime de diverses façons, nous avons déjà cité Kubernetes, IBM en fait la pierre angulaire de son offre BlueMix, nous avons déjà parlé du support de Microsoft, nous pourrions continuer longtemps ainsi.

La fin de la virtualisation ?

Je tue d'entrée le suspense.

L'intérêt grandissant pour Docker ne va pas mettre un terme à la prééminence actuelle des solutions de virtualisation, et pour de nombreuses raisons.

Détaillons.


Déjà, les entreprises ont lourdement investi sur la virtualisation ; il a fallut recruter, former, monter en compétences... Tout ceci prend du temps et coûte cher et ces investissements ne vont pas être jeté aux orties tout de suite. L'accélération du rythme des innovations technologiques et des ruptures majeures est en décalage avec les capacités des organisations à les intégrer (et la question se pose de leur intérêt d'un point de vue purement économique).

Docker est encore trop jeune, insuffisamment éprouvé, et présente des défauts. Les choses progressent vite, il y a des exemples de sites importants en production mais on n'en est pas encore au stade de l'adoption générale. Même si on a largement dépassé le stade du buzz, il ne faut pas confondre vitesse et précipitation.

La société Docker, qui a développé le produit éponyme, doit faire face à l'émergence de nouveaux acteurs sur ce marché, facilitée par le modèle open source des produits, ce qui peut créer de l'incertitude (mais aussi stimuler l'innovation). Je pense en premier lieu à CoreOS (la société). 

La virtualisation et Docker ont des cas d'usages distincts. Du fait de leurs avantages et inconvénients respectifs, ces technologies sont adaptées à des besoins différents. Docker est par exemple adapté en cas de très nombreuses instances d'un même service unique, tandis que la virtualisation est indispensable pour supporter une multitude d'OS hétérogènes, et recommandée dans le cas où un noeud (une VM ou un container) doit exécuter plusieurs services (encore qu'à titre personnel je sois moins affirmatif sur ce point). 

La combinaison des deux technologies est possible et présente des intérêts certains. On a aujourd'hui trois possibilités :

• un serveur physiques avec un hyperviseur et des VM (virtualisation classique)

• un serveur physique avec Linux et Docker (ou un concurrent équivalent), approche qualifiée de "bare-metal"

• et une architecture mixte : un serveur physique avec un hyperviseur hébergeant des VM Linux/Docker.

Chaque architecture a ses avantages et inconvénients mais on peut simplement noter que l'architecture mixte présente ses intérêts propres et permet de s'appuyer sur l'existant tout en bénéficiant des dernières innovations.

VMWare, le plus gros acteur de la virtualisation, a senti le vent et promeut l'architecture mixte, notamment au travers du projet Photon. Il a tout simplement fait une version de Linux/Docker optimisée pour fonctionner avec son hyperviseur ESX. A noter, d'autres acteurs développent (ou participent dans le cadre d'un projet open source) sur des noyaux Linux spécialisés pour une large utilisation de Docker comme par exemple CoreOS (sur lequel s'appuie Kubernetes de Google).

Conclusion

J'espère que cet article vous permettra d'avoir les idées claires sur ce qu'est Docker et pourquoi tous les geeks ont le zizi tout dur dès qu'on aborde le sujet ;-)

Ce qui me semble le plus important à comprendre est d'une part l'écosystème autour de la solution de conteneurisation proprement dite (dépôts de containers, format standard de container  non lié à un éditeur, outils de gestion de clusters évolués Kubernetes and Co), et le fait que la technologie ne remplacera pas la virtualisation mais sera une possibilité supplémentaire et éventuellement complémentaire. Du pain sur la planche pour les architectes système, et des décisions compliquées pour les directeurs informatique en vue ...

Pour un développeur, au sens large, c'est la vision "infrastructure as a code" et l'appui de la démarche DevOps qui me semble la plus importante.

Formes et intérêts du Cloud computing

Le Cloud Computing ou "informatique dans les nuages" prend diverses formes ayant toutes des aspects communs mais également chacune leur spécificité et intérêt. Nous allons expliquer tout ça de la façon la plus simple possible.

Nous avons abordé un certain nombre de sujets préliminaires dans les deux articles listés ci-après ; il peut être utile d'en prendre connaissance en préalable :

La Haute Disponibilité en bref

Virtualisation, principes et usages

Les formes de Cloud Computing

Les 3 formes les plus connues sont, par ordre d'apparition, SAAS, PAAS, IAAS. Une forme plus récente est DAAS.

Dans les 4 formes courantes, AAS signifie "As A Service". Il s'agit donc d'offrir (enfin de vendre, faut pas déconner non plus) un service dont la nature, on l'aura deviné, est précisé par la première lettre. 

S pour Software, logiciel en Français : ici on offre un logiciel répondant à un certain besoin. Nous sommes déchargés du besoin d'acheter, installer, et administrer un ordinateur (plusieurs si on veut de la Haute Disponibilité), un OS, un logiciel. On a juste à utiliser le logiciel accessible via une url dans son navigateur.

P pour Platform : ici on offre une plateforme d'exécution, c'est à dire un logiciel serveur ou un ensemble de logiciels serveurs, sur lequel on peut déployer ses propres applications grâce à une console d'administration accessible via une url dans son navigateur. On est déchargé du besoin d'acheter, installer, et administrer un ordinateur (plusieurs si on veut de la Haute Disponibilité), un OS, un ou des logiciels serveurs (un serveur web, un serveur d'application, un serveur de base de données ...) et selon les offres d'intégrer des composants à ces serveurs (plugins, frameworks de développement intégrés, fonctions optionnelles ...).

I pour Infrastructure : ici on offre une plateforme de virtualisation sur laquelle on pourra créer autant de machines virtuelles que nécessaire (dimensionnées selon ses choix, avec l'OS de son choix), selon ses besoins du moment, voire selon les offres bénéficier de fonctionnalités de provisionning automatique (installation automatique de logiciels serveurs). On est déchargé de l'achat, installation, administration etc. de la plateforme de virtualisation.

Illustration des différents modèles de Cloud

Ce diagramme montre les différentes couches d'un SI virtualisé, avec en gris les parties dont il est possible de se décharger selon le mode de Cloud pratiqué. La première pile "on premise" correspond au cas où il n'y a pas de recours au cloud, donc tout est en bleu pour montrer qu'on gère chacune des briques. La dernière pile "SAAS" correspond au cas où on loue le logiciel et donc tout est en gris puisqu'on ne gère plus aucune brique.

D pour Desktop (bureau en Français): ici on offre un environnement de bureau (tel que vous l'obtenez en installant par exemple Windows sur un PC chez vous) accessible via Internet. On peut ainsi trouver son environnement de bureau où qu'on soit, pour peu qu'on ait un accès Internet, et sur n'importe quel système d'exploitation, pour peu qu'il soit supporté (c'est le cas de tous les systèmes courants) et qu'on ai installé un petit logiciel localement. Cette forme est plus récente et fait appel à des technologies un peu différentes des 3 précédentes, nous la détaillerons plus loin. Une bonne présentation en Français est disponible sur le site de la société virtuelbureau.com

Le PAAS connait de multiples déclinaisons selon la nature de la plateforme proposée en location, ce qui amène certains à créer diverses déclinaisons où le P est remplacé par l'initiale du type de serveur proposé.

Les aspects communs, avantages

Le premier aspect est l'utilisation d'Internet comme infrastructure réseau. D'où le terme de "Cloud Computing". Les informaticiens ont en effet l'habitude de représenter Internet sous la forme d'un nuage dans les diagrammes d'architecture réseau ; le nom vient de là.

Le second aspect est qu'il s'agit d'un modèle économique basé sur la location au lieu de l'achat, et dont les coûts sont corrélés à l'usage qu'on fait du service : plus on les utilise, plus on paye, moins on les utilise, moins on paye (mais il y a toujours un montant fixe minimum).

Ce second aspect est essentiel : 

• il permet d'ajuster les coûts au niveau de l'activité

• il permet de démarrer une activité (nécessitant un logiciel, ou une plateforme d'exécution, ou encore de la puissance de traitement) sans investissement initial important

• il permet de tester des idées : en effet puisque l'investissement initial n'est plus obligatoire, on peut lancer quelque chose, et si ça ne fonctionne pas, tout simplement arrêter sans grande conséquence (pas de matériel coûteux à revendre à perte, pas de personnel à recaser ou licencier ...).

Autre point essentiel de nos jours et toujours lié au modèle de location : on remplace des investissements par des charges d'exploitation, ce qui a pour effet de changer la structure du bilan (moins de capital immobilisé), et d'offrir une rentabilité financière à court terme plus attrayante pour des investisseurs (on parle bien ici de la nature financière du capitalisme "moderne", opposée à l'approche patrimoniale classique). C'est la même logique qui pousse les grandes entreprises à vendre leur bâtiments et à louer des locaux. 

Un autre aspect essentiel est que ces mécanismes offrent la possibilité aux PME d'accéder à des technologies auxquelles elles ne pourraient prétendre pour la plupart. Les technologies modernes impliquent en effet des coûts élevés notamment du fait de la multitude de spécialistes coûteux requis pour faire tourner une infrastructure informatique de pointe, et ces coûts cumulés constituent une barrière d'entrée infranchissable sans un solide portefeuille.

Enfin dernier aspect très important de nos jours : la réduction du "time to market". Le temps nécessaire entre une idée et sa concrétisation est très fortement diminué ce qui permet de réagir plus vite aux tendances, avant ses concurrents, et de prendre des parts de marché. Au lieu d'acheter et/ou recruter matériel, logiciel et personnel, on va sur une console d'administration, on fait 3 clics de souris et c'est bon (en réalité c'est un poil plus compliqué mais c'est l'idée générale).

Les aspects communs, inconvénients

Parlons maintenant des inconvénients, car bien sur toute médaille à son revers.

Le premier est lié à la prédictibilité des dépenses : il est en effet très difficile parfois d'estimer à l'avance combien va coûter le service. Si dans le cadre du SAAS c'est assez simple (par exemple, vous allez payer un forfait annuel par utilisateur, et vous connaissez votre nombre d'utilisateur), c'est moins vrai dans le cas du PAAS et surtout du IAAS. Les modèles de facturation proposés par les opérateurs sont très complexes et les opérandes délicates à évaluer. Le recours à des prestataires spécialisés est ici plus que recommandé. Dans tous les cas, la facilité de mise en oeuvre des services implique une grande rigueur dans le suivi qui en est fait, pour éviter d'exploser les compteurs.

Un second est lié à la complexité de la contractualisation avec les opérateurs. En effet, il va falloir définir des niveaux de services garantis (SLA : Service Level Agreement) et des mécanismes de pénalités associés en cas de non respect. En effet, si vous faîtes reposer votre business sur une plateforme exploitée par des tiers, vous voulez être rassuré sur le fait que vous n'allez pas rester sans site de vente en ligne pendant 48H car la femme de ménage a débranché la prise électrique de votre serveur le samedi matin (bien sur aucun risque mais l'image est belle). Et non seulement ce n'est pas simple, tant du point de vue technique que juridique, mais le rapport est déséquilibré car vous avez en face de vous des opérateurs de très grande taille opérant à l'échelle mondiale (Google, IBM, Amazon, Microsoft etc.).

Un autre inconvénient encore est lié au fait que vos données vont être hors de vos murs, et stockées quelque part hors de votre contrôle... 

Outre le côté psychologique de la chose, certaines données sensibles font l'objet de réglementations qui interdisent par exemple qu'elles sortent du pays ou de l'union européenne. Par ailleurs, certaines entreprises sont bizarrement très attachées à la confidentialité de leur fichier client (dingue non !). Si il existe aujourd'hui des acteurs nationaux, force est de reconnaître que tous les plus grands acteurs sont américains... (ils déploient aujourd'hui des datacenter en Europe, encore un point à vérifier avant de contractualiser). Ce dernier point, en ces périodes marquées par les espionnages de la NSA, n'est pas à négliger.

Dernier inconvénient : l'utilisation d'Internet comme infrastructure réseau amène des limitations techniques qui interdisent certains usages, en particulier dans le cas où on a des échanges de données entre le SI interne et une partie externalisée dans le cloud (problème de latence ou de bande passante insuffisante ou non garantie).

Focus SAAS

Le modèle n'est pas nouveau. Il était auparavant appelé ASP (Application Service Provider) mais il a été rebaptisé suivant les tendances marketing du moment.

Les premiers domaines concernés ont été les services tels que la messagerie et les agendas partagés. 

En effet, il n'y a aucune plus-value pour une petite entreprise à financer la gestion de ce type de plateforme en interne ; les moyens étant généralement limités,  il est préférable de les concentrer sur des outils plus orientés cœur de métier. En outre, le petit nombre de boites mails à gérer rapporté au coût de gestion de l'infrastructure ne permet pas nécessairement d'atteindre le point mort en terme de rentabilité (bref, ça coûte moins cher de payer pour un service dans le cloud).

Aujourd'hui on trouve une offre importante en matière de CRM (Customer Relationship Management, GRC Gestion de la Relation Client en Français), de gestion RH, de logiciels comptables, d'ERP (Enterprise Resource Planning, PGI Programme de Gestion Intégrée en bon Français), de suite bureautique plus récemment (Office 365 chez Microsoft par exemple qui propose la suite Office en mode SAAS).

La plupart des éditeurs proposent aujourd'hui leur offre dans le mode SAAS (à la location donc) en alternative à la vente de licence traditionnelle (souvent rebaptisé "on premise").

De nombreux particuliers utilisent des services SAAS sans le savoir pour le stockage de leur photos de vacances ou de leurs fichiers sur Internet : DropBox, GoogleDrive, OneDrive pour ne citer que les plus connus sont des services SAAS.

Focus PAAS

C'est probablement l'offre la moins hétérogène ce qui est assez logique vu la multitude d'environnement serveurs et de stacks applicatives (empilement de frameworks, librairies, technologies) qui existent de nos jours.

Les offres PAAS sont à examiner de près car elles imposent toujours des contraintes importantes en matière d'architecture logicielle et de pratique de développement ; ici encore c'est assez logique, afin de garantir un certain niveau de service les opérateurs doivent s'assurer que les logiciels développés par vos soins et hors de leur contrôle respectent certains principes (afin de pouvoir être load-balancés par exemple, ou encore ne pas effondrer les moteurs de base de données, ou tout simplement s'intégrer harmonieusement dans leur infrastructure).

Focus IAAS

Certaines solutions techniques utilisées par les grands opérateurs de domaine pour leur offre sont accessibles en Open Source.

Elle sont notamment utilisées par des sociétés nationales qui peuvent ainsi élargir leur offre d'hébergement traditionnel (location de matériel dédié ou de m2 dans leurs datacenter) ; ce marché est en plein développement (OVH, Ikoula, Gandi etc.).

Il existe également de nombreux acteurs de plus petite taille à considérer : spécialisés sur certaines domaines d'activité (le réseau des ARSOE dans le cas de l'informatique agricole par exemple), ou hébergeurs visant les PME, ils présentent l'avantage d'être plus souples, adaptables, réactifs, et de proposer des prestations complémentaires liées à l'exploitation des plateformes (les grands acteurs du Cloud ont des offres totalement industrialisées et ne font pas d'exploitation au delà bien sur du minimum de supervision système requis).

Elles sont également utilisées par des grands groupes, qui ont des moyens financiers importants et des DSI très développées, pour exploiter des clouds privés. Rappelons qu'un cloud privé est la même chose que ce qui est proposé par les fournisseurs de solutions IAAS pour leur offre de cloud public, mais installé par l'entreprise dans son datacenter privé et administré par ses soins. Le modèle économique change mais les avantages techniques subsistent (flexibilité, time to market, élasticité, support de la haute disponibilité etc). 

Un Cloud privé hébergé et exploité en externe par un sous traitant est une autre option possible. La différence avec un Cloud public est alors que les serveurs de VM utilisés pour héberger l'infrastructure de virtualisation sont totalement dédiés, ce qui peut rassurer certaines entreprises.

Les deux solutions phares sont CloudStack et OpenStack. 

Nos inénarrables technocrates Français (rappelez vous Coluche : "donnez leur le Sahara à gérer, dans 5 ans ils achètent du sable") ont voulu créer une offre de Cloud Public National (avec plein de majuscules partout, ça fait plus Français, Meussieur !). L'idée n'était pas mauvaise, il s'agissait de ne pas dépendre d'acteur Américains et de favoriser l'économie Française. Mais bien évidemment ils ont géré l'affaire comme des branques et après avoir  claqué quelques dizaines ou centaines de millions dans le vide, ont fini par abandonner le projet... de toute façon à chaque fois que l'état veut se mêler d'informatique ... Pour plus de détail, voir ce lien sur le projet Andromède.

Focus DAAS

Revenons à la préhistoire de l'informatique : toute la puissance de calcul était centralisée sur un ordinateur unique (mainframe) et les utilisateurs disposaient d'un simple terminal passif (un écran et un clavier).

Dans ce type d'architecture, chaque action de l'utilisateur au niveau de son terminal (appui sur le clavier, action avec la souris) est transmise côté serveur et c'est le serveur qui traite le signal. Si l'action utilisateur implique une modification du contenu affiché à l'écran, alors le serveur envoie un message à l'écran côté client (en fait à un petit programme qui s'exécute côté client et qui gère l'écran) qui se rafraîchit en conséquence.  Le message décrit simplement les zones de l'écran à mettre à jour.

Ce type d'infrastructure est toujours présent dans l'informatique distribuée moderne (serveur X11 sous Linux/Unix, bureau distant Windows etc.). La société Citrix qui commercialise des solutions spécialisées dans ce domaine reste un acteur très important car ce type de solutions, bien que très minoritaire aujourd'hui, présente des avantages indéniables et est irremplaçable dans certains contextes.

Le DAAS est en fait une utilisation de ces solutions d'infrastructure au travers d'Internet. Au lieu d'installer un serveur capable de gérer ce type d'interactions, l'entreprise (ou le particulier) utilise simplement un service localisé quelque part sur Internet (dans le cloud) et bâti sur la virtualisation des postes clients. Côté client, l'installation d'un petit logiciel peu gourmand en ressources est nécessaire. Ce logiciel étant disponible pour de nombreux OS et matériels, on peut retrouver son bureau Windows et exploiter des logiciels lourds sur des machines très peu puissantes et fonctionnant sous d'autres OS (rappelez vous, les traitements sont exécutés côté serveur, ce sont donc les ressources du serveur qui sont sollicitées, pas celle du client qui ne fait qu'envoyer les frappes clavier, et analyser les messages de mise à jour d'écran reçus en retour pour rafraîchir l'affichage).

Comme toujours ce type de solution a des avantages et inconvénients mais sa combinaison avec les technologies de virtualisation en étend encore l'intérêt, en particulier pour les TPE et PME.

Pour finir, le DAAS c'est comme le SAAS sauf que le service consommé, au lieu d'être une simple application en interface web, est un bureau graphique classique avec toutes ses fonctionnalités (installation de logiciels, paramétrage personnalisé etc.). 

Ce type de solution est encore peu connu mais le marché semble amené à se développer. En plus des acteurs traditionnels sur ce marché, Amazon a lancé une offre, et Microsoft a un projet dans les cartons.

Conclusion

Voilà, j'espère que les choses sont claires. 

L'économie du Cloud est encore quelque chose de relativement récent, le taux d'adoption est sans doute moins rapide que le souhaiteraient les grands acteurs du marché mais vu les milliards qu'ils investissent dans ce domaine, et les avantages de la technologie, on peut difficilement douter que ce soit une tendance lourde.

L'usage interne de la virtualisation et la consommation d'applications en mode SAAS ont mis pas mal d'années à entrer dans les mœurs ; mais aujourd'hui c'est devenu très courant. Nul doute pour moi que PAAS et IAAS suivront le même chemin.

Virtualisation, principes et usages

Dans l'optique d'expliquer ce qu'est le cloud computing ou "informatique dans les nuages", il nous faut comprendre les problèmes auquel répond cette forme d'informatique, et nous avons commencé à aborder ceci dans cet article sur la haute disponibilité ; nous allons en dire un peu plus encore.

Mais il est temps d'en dire un peu plus sur les technologies de virtualisation qui sont à la base d'une partie importante de cette nouvelle forme d'informatique.

Qu'est ce que la virtualisation

L'informatique est, à la base, une forme de virtualisation de la réalité : les logiciels divers et variés ne font que rendre immatériels sous une forme numérique (c'est à dire constituée  de 0 et de 1) les artefacts du monde réel : fichiers de traitement de texte vs manuscrits, images numériques vs photographie argentique, email vs courrier etc.

Le plus souvent l'informatique ne créé rien dans un premier temps mais reproduit avec ses moyens les activités humaines ; puis s'appuie dans un second temps sur ses capacités de traitement dé-multipliables à l'infini pour dégager de nouvelles façons de faire, de nouveaux "usages" comme on aime dire.

Ce recours à l'informatique est sans cesse croissant depuis 2 ou 3 décennies et ne fait que s'accélérer. On assiste à une transformation en profondeur des usages de l'informatique qui pénètre tous les domaines. On entend souvent le terme de '"digitalisation" (ou encore plus pédant : transformation digitale) qui est une très mauvaise traduction de l'anglais et n'a en fait pas grand sens au niveau étymologique. Mais c'est le terme consacré ; c'est ainsi, le marketing a encore frappé.

Et en poussant cette logique à l'extrême, on en vient à virtualiser les ordinateurs eux même.

Les systèmes de virtualisation ce sont donc simplement des logiciels qui permettent de simuler le fonctionnement d'un ordinateur avec l'ensemble de ses composants matériels, son système d'exploitation, les logiciels qui y sont installés, et les données qu'il stocke sur ses périphériques de stockage (disque dur).

La forme virtuelle d'un ordinateur prend donc la forme d'un fichier (ou d'une série de fichiers) qui nécessite pour être exploité un logiciel spécifique. Comme un document Word nécessite le traitement de texte du même nom, un fichier Excel le tableur du même nom, une vidéo un player vidéo sachant en exploiter le format etc.

Les logiciels qui permettent de créer des ordinateurs virtuels proposent une interface qui permet de décrire l'ordinateur qu'on veut virtualiser : architecture processeur, nombre de coeurs du processeur, quantité de mémoire, type de firmware (bios ou uefi), taille du disque etc.

Les logiciels qui permettent d'exploiter ces ordinateurs virtuels permettent de les démarrer, comme on le ferait en appuyant sur l'interrupteur d'un vrai PC, de les éteindre, de les rebooter (bouton reset) etc...

Une fois un ordinateur virtuel démarré, la première chose à faire est d'y installer un système d'exploitation, comme on le ferait pour un vrai ordinateur, puis ensuite on l'utilise comme un vrai : installation de logiciels, utilisation des logiciels etc.

Et cette capacité de virtualisation a permis l'essor de nouveaux usages au fur et à mesure qu'on s'est familiarisé avec l'idée et qu'on a pris conscience des possibilités nouvelles qu'elle offrait.

A partir d'ici nous utiliserons l'acronyme VM (Virtual Machine) pour désigner une machine virtuelle.

Deux types de logiciel de virtualisation

On appelle hyperviseur un système de virtualisation.

Le premier type de système de virtualisation est constitué d'applications qui s'installent et s'exécutent sur un système d'exploitation, de la même façon qu'un navigateur, un traitement de texte ou tout autre logiciel auquel vous êtes accoutumés.

Les produits les plus connus sont probablement Workstation Player (de la société VMWare), VirtualBox (de la société Oracle, anciennement Sun) mais il en existe d'autres. Ces produits sont gratuits, ils se téléchargent et s'installent simplement en quelques minutes.

Le second type de système de virtualisation est constitué d'un système d'exploitation dédié qui s'installe donc sur un ordinateur physique, ou d'un service optionnel fourni par un système d'exploitation traditionnel.

Activation de Hyper-V sous Windows

Les produits les plus connus sont probablement ESX de la société VMWare (qui est leader dans le secteur et a largement contribué par ses produits à la large adoption de la virtualisation), KVM (solution open source basée sur le noyau Linux et soutenue par Red Hat) et Hyper-V (Microsoft, anciennement Virtual PC), mais il en existe d'autres.

Ces produits sont disponibles gratuitement en open source ou soumis à licence.

Les logiciels de virtualisation s'appuient pour plus de performance sur des jeux d'instructions supplémentaires fournis par la majorité des processeurs ; cependant, des versions bas de gamme de processeurs peuvent en être dépourvues (point d'attention à avoir pour choisir un processeur si on prévoit de faire de la virtualisation).

Comment ça fonctionne ?

Loin de nous l'idée d'expliquer en détail le fonctionnement d'un hyperviseur, nous nous contenterons de brosser un tableau général.

Tout d'abord, il faut avoir en tête qu'en informatique, tout est architecturé en couches successives : chaque couche s'appuie sur la couche immédiatement inférieure qui lui expose les services dont elle a besoin, et n'a connaissance que de cette couche. 

Chaque couche constitue une couche d'abstraction pour la couche supérieure : elle est là pour lui masquer la complexité des problèmes qu'elle gère.  

La couche supérieure exploite donc les services et s'en sert elle même pour faire son propre job et fournir à son tour des services à sa couche supérieure (a qui elle épargne les détails de mise en oeuvre) etc.

Prenons un exemple approximatif mais réaliste. Le micro-contrôleur (couche 1) d'un disque dur masque l'utilisation des moteurs et autres éléments mécaniques au driver (couche 2). Le driver (ou pilote) masque les spécificités de chaque modèle de disque dur en fournissant une interface commune à tous les modèles au système d'exploitation (couche 3). Le système d'exploitation fournit une API bas niveau aux applications qui ont ainsi la possibilité de lire et écrire des fichiers Certaines applications, comme l'interpréteur d'un langage interprété constituent une 4éme couche et fournissent des instructions pour les programmeurs qui vont pouvoir écrire des programmes destinés cette fois ci à des êtres humains, qui constituent la dernière couche. Et encore on pourrait imaginer une couche de techniciens spécialisés manipulant les programmes pour fournir un service à des donneurs d'ordre, eux mêmes prestataires consommant les résultats ainsi obtenus pour les agréger avec d'autres sources d'informations et constituant ainsi une nouvelle couche vis à vis d'un consommateur final : et ici encore on se rend compte que cette organisation en couche n'est une fois de plus qu'une reproduction des activités humaines.

Un système d'exploitation hébergé par un ordinateur virtuel croit parler à la couche matérielle (par l'intermédiaire d'un pilote en général) mais en fait une couche est intercalée : l'hyperviseur.

Il se charge de faire le lien avec la couche inférieure (le vrai matériel) mais il en profite pour jouer son rôle, par exemple en arbitrant l'utilisation des ressources réelles de la machine entre plusieurs VM.

Donc au final, on a un hyperviseur qui se fait passer pour le matériel. Le système d'exploitation virtualisé fonctionne de la façon habituelle mais au lieu de parler avec le matériel d'un ordinateur sur lequel il serait installé, il parle avec l'hyperviseur.

Ce qu'il est primordial de comprendre, c'est que pour la VM c'est totalement transparent : le système d'exploitation n'a aucunement conscience d'être virtualisé.

A quoi ça sert ?

Il y a de nombreux usages, et probablement d'autres à inventer, nous en citons quelques un, à commencer par les plus basiques et les plus évidents.

Pouvoir disposer simplement et à moindre coût d'environnements multiples

La virtualisation permet de disposer d'une multitude de configurations de façon simple. Si on a besoin d'avoir des ordinateurs sous différentes versions de Windows, Linux, Mac OS, ou avec différentes architectures processeurs, on n'a plus besoin d'avoir 1000 m2 d'entrepôt pour stocker tous ces matériels. Il faut juste un bon disque dur pour stocker les machines virtuelles : ben oui, ce n'est plus du matériel mais une virtualisation de matériel.

Au delà du côté pratique, il y a un côté financier : le matériel n'est pas gratuit. Les solutions de virtualisation non plus mais c'est quand même beaucoup moins cher.

Et pourquoi aurait on besoin de tout ce matériel toutes ces configurations ? Hé bien par exemple car on développe un logiciel utilisé par des gens qui ont toutes sortes de matériels et d'OS différents. Et il nous faut tester notre logiciel sur chaque plateforme. Egalement, la compilation du produit final ne peut parfois se faire que sur la plateforme cible.

Bien sur, on peut virtualiser autre chose que des ordinateurs ; au hasard et par exemple, les smartphones. Il existe des dizaines de modèles, il n'est guère réaliste de devoir tous les posséder pour faire des tests d'un logiciel pour mobile. Idem pour les tablettes.

Pouvoir disposer rapidement d'un environnement 

Cas de figure : vous signez un contrat avec un client pour développer une application. Il s'agit d'une application qui s'exécutera à terme sur un serveur dans l'environnement du client.

Pour vos tests, vous devez disposer d'une plateforme serveur identique, ou la plus proche possible, de la cible (de celle de votre client). Vous n'en disposez pas nécessairement. Et en admettant que vous en disposiez, elle n'est sans doute pas disponible.

Sans virtualisation, il faudrait commander un serveur chez un fournisseur, il y aurait un coût qui viendrait manger votre marge, et il y aurait surtout un délai de livraison. Or, les délais sont toujours insuffisants et on n'a pas de temps à perdre. Grâce à la virtualisation, la machine virtuelle est créé en quelques minutes (le plus long sera l'installation et le paramétrage de l'OS et des éventuels pré-requis).

Quelles opportunités encore ?

La consolidation des serveurs

Ce point est particulièrement mis en avant par le sociétés qui vendent des solutions de virtualisation.

Il faut savoir que de façon générale, les entreprises dimensionnent le matériel qui héberge une application serveur en fonction de l'activité maximale dudit logiciel. Et c'est bien logique, il s'agit que le système ne s'effondre pas en période de pic d'activité.

Mais du coup, si les pics n'ont lieu que 10% du temps, pendant 90 % du temps le matériel n'est exploité que pour une faible part de ses capacités. Il y a donc du gâchis, d'autant que comme il est très délicat de dimensionner une infrastructure et qu'on ne veut pas prendre de risque, on a tendance à tailler large.

La consolidation consiste à virtualiser les environnements serveurs et à les regrouper sur une machine physique chargé de les faire tourner (un serveur de VM). 

Il s'agit d'une machine puissante et coûteuse, mais beaucoup moins que la somme des serveurs utilisés dans la situation initiale. Comme les VM n'ont pas toutes un pic d'activité en même temps, tout fonctionne (en théorie).

La consolidation de n VM sur un seul serveur a bien sur des limites, on ne peut pas ajouter éternellement des VM sur un seul serveur, il y aura toujours un moment où la somme des besoins de l'ensemble des VM, hors période de pic, dépassera les capacités du serveur. Et il y aura toujours le risque que plusieurs VM aient des pics d'activité simultanés, le risque augmentant de façon statistique avec l'augmentation du nombre de VM sur un même serveur de VM.

Mais les éditeurs ont des solutions à ça : on peut multiplier les serveurs physiques, et mieux encore équilibrer automatiquement la charge des différents serveurs en déplaçant les VM d'un serveur à l'autre, de façon transparente pour les utilisateurs. Et qui plus est de façon dynamique (c'est à dire au moment même ou "on" va se rendre compte qu'un serveur atteint ses limites, le "on" étant ici encore une sonde logicielle ou matérielle).

Parenthèse : la stratégie des éditeurs de solutions de virtualisation

Il existe des solutions de virtualisation qui sont disponibles gratuitement dans des versions "basiques" (en fait toutes je suppose) : elles offrent le service de virtualisation (voire un peu plus) et c'est tout. Il faut se débrouiller ensuite avec le problème de répartition des VM entre serveurs de VM, et plus généralement avec toutes les problématiques liées à l'exploitation de ces infrastructures (supervision, sauvegardes etc.).

Comme bien souvent avec les solutions gratuites, il faut passer par une version payante dite "enterprise" ou "advanced", ou encore par un contrat de support payant, pour pouvoir tirer la quintessence de ces solutions : il faut bien que les éditeurs gagnent de l'argent quelque part pour financer les coûts de développement (et bien sur dégager des marges pour leur pauvres actionnaires).

Les entreprises avec des petits moyens et/ou des petits besoins peuvent tout à fait se contenter des solutions gratuites.

Par contre, si la technologie est adoptée (et c'est généralement le cas car elle a de nombreux avantages), il arrive un moment où inévitablement le recours aux solutions payantes est obligatoire. Et là, le piège se referme... coûts de licences, options innombrables et incompréhensibles, bref les éditeurs dont c'est le métier savent bien tirer le maximum de profit de la bête.

L'alternative est le recours aux solutions open-source. Plus de licence, mais les coûts se situent ailleurs, car il faut recourir à des ressources humaines (des ingénieurs spécialisés en gros) qui d'un part ne courent pas les rues, et d'autres part sont onéreuses. Cette option reste cependant très intéressante pour peu qu'on sache se faire conseiller et qu'on dispose du réseau adéquat.

La Haute Disponibilité

Si vous n'avez pas les idées claires sur le sujet, ce premier article vous donnera le contexte.

La redondance d'une VM est aisée à obtenir puisqu'il suffit de dupliquer une VM pour multiplier le nombre d'instances. 

Même sanction pour la scalabilité horizontale : si on veut paralléliser sur une machine supplémentaire, il suffit de dupliquer une VM et de la mettre en place derrière le répartiteur de charge, tout ceci n'est que de la manipulation de fichier et peut donc s'automatiser.

Et avec la flexibilité qu'apporte la virtualisation, on peut envisager un mécanisme autonome et automatique qui ajuste le nombre de VM en fonction de la charge : la fameuse élasticité. Tout ce qu'il nous faut est un programme qui sache créer automatiquement des VM, et le coupler avec les sondes qui surveillent la charge de nos serveurs de VM (plus facile à dire qu'à faire, mais l'idée de base est simple).

Tout ça est bien beau mais c'est désormais le serveur de VM qui constitue un SPOF. Ici, il faudra passer par l'achat de plusieurs serveurs, et des solutions logicielles ou matérielles commercialisées par les éditeurs.

Et si on veut bien faire, une fois le serveur de VM redondé, il faudra redonder l'espace disque partagé (SAN, NAS, baie de disque dédiée ...), puis les équipements réseau, puis les réseaux d'alimentation électrique, puis les onduleurs, puis les groupes électrogènes, puis les datacenter proprement dits etc... C'est pourquoi on fait généralement appel à des sociétés d'hébergement spécialisées qui mutualisent le coût énorme de tous ces investissement entre une multitude de clients.

La gestion de configuration automatisée

Etant donné que les ordinateurs sont virtualisés, ils peuvent être crées et manipulés de façon automatique par des programmes (ben oui, un ordinateur virtuel c'est juste un fichier). Et l'air de rien ça ouvre des multitudes de possibilités.

En informatique, la gestion de configuration est une discipline très importante : elle consiste à être capable de garder la trace d'un environnement informatique et de le reproduire à l'identique en cas de besoin, même plusieurs mois après.

Il faut être conscient qu'installer un environnement informatique peut être une opération lourde et complexe demandant parfois plusieurs jours entre l'installation du système, sa configuration selon des règles précises, le passage de patchs correctifs à un certain niveau, l'installation de différents applicatifs serveurs, leur configuration, le passage de patchs (encore), l'installation d'applications, leur configuration etc.  Qu'une seule opération diffère et l'environnement final diffère, avec potentiellement des impacts.

Un syndrome courant en informatique est "ça marche sur ma machine" : un programme fonctionne sur la machine du développeur, ou le serveur de test, et dysfonctionne sur son environnement de production. La raison en est souvent une différence entre les environnements. En s'assurant que tout le monde travaille sur le même environnement, on élimine ces problèmes.

Inutile de dire qu'un processus manuel est source d'erreur, et en outre inintéressant dans un environnement virtualisé : ça ne sert à rien d'automatiser la création d'ordinateurs virtuels si on n'est pas capable d'automatiser toute la chaîne.

La virtualisation permet déjà par simple manipulation de fichier de reproduire des machines à l'identique, mais cette façon de faire que nous avons évoquée jusque présent a des limites.

Mais, il existe tout un ensemble de logiciels spécialisés qui savent créer automatiquement des VM et y installer des logiciels selon un plan précis (on parle de provisioning).

Ce sujet est actuellement en plein développement avec des solutions comme Vagrant, Chef, Puppet, Ansible, Docker ... On rejoint ici une des thématique du mouvement DevOps dont nous parlerons dans un autre article.

Cloud privé, Cloud public

Cloud privé

On appelle "Cloud privé" une infrastructure de virtualisation avancée, avec toutes les fonctionnalités évoquées plus haut pour le support de la haute disponibilité (redondance des serveurs de VM, équilibrage de la charge des serveurs de VM par répartition dynamique des VM entre serveurs, et plus si affinité) déployée dans un le centre informatique privé d'une entreprise.

Mais je comprends plus rien : on me dis qu'on parle de Cloud car c'est une forme d'informatique basée sur Internet, et là on parle de cloud privé et il n'y a aucun lien avec Internet... C'est le problème avec le jargon marketing, il n'a pas de sémantique précise, chacun met ce qu'il veut derrière, et ça change selon le sens du vent. Décryptons.

On utilise le terme Cloud privé par opposition au Cloud public qui lui est bien basé sur l'utilisation d'Internet.

En fait, les infrastructures et les logiciels qui permettent de mettre en place, et d'exploiter facilement, une infrastructure de virtualisation ont d'abord été développées pour un usage interne par des sociétés novatrices, qui les ont ensuite commercialisées :  ce fut l'émergence d'une forme particulière de cloud public (au sens d'un modèle économique basé sur la mise à disposition de ressources en location sur Internet) appelé IAAS (expliqué plus bas).

Puis ces solutions se sont répandues et des entreprises ont fait le choix de les déployer au sein de leurs propres centres informatiques (aka datacenter). Dès lors, il n'y a plus de lien avec Internet mais comme c'est la même technologie que celle utilisée par le acteurs du Cloud Public pour leurs offres IAAS, on a appelé ça Cloud Privé.

Cloud public

L'économie du Cloud prend plusieurs formes dont une au moins est directement liée à l'essor des techniques de virtualisation : IAAS (Infrastructure As A Service).

Le principe est de commercialiser la mise à disposition de machines virtuelles qui s'exécutent sur des serveurs de VM qui sont externes à l'entreprise et hébergés "quelque part" sur Internet (donc dans le Cloud), selon un modèle de facturation à l'usage.

Le client loue de la puissance de traitement rendue disponible grâce à Internet, et ne se soucie plus de toute l'infrastructure requise pour disposer des avantages les plus avancés procurés par la virtualisation (haute disponibilité, ajustement automatique des capacités, et donc des coûts, en fonction des besoins, automatisation des opérations poussée au maximum).

Contrairement au "Cloud privé" l'entreprise est déchargée de la gestion de l'infrastructure de virtualisation et de l'exploitation de la plateforme (par contre, ses données sont hors de ses murs ce qui peut être un vrai souci).

Nous détaillerons les différents formes que prend le cloud computing dans un prochain article 

Conclusion

Le premier article sur la haute disponibilité visait à préparer vos esprits aux avantages apportés par la virtualisation en la matière.

Ce second article sur la virtualisation vous fait toucher du doigt l'intérêt qu'il peut y avoir a s'appuyer sur un modèle de consommation de ressources virtualisées via Internet (IAAS).

Le prochain article en dira un peu plus sur ce point, et détaillera les autres formes que prend le cloud computing (SAAS, PAAS, DAAS).

La Haute Disponibilité en bref

Le cloud computing, ou plus poétiquement l'informatique dans les nuages, est un sujet d'étude incontournable pour qui souhaite comprendre l'informatique d'aujourd'hui. 

Je prépare quelques articles sur le sujet, toujours avec l'idée d'essayer d'en expliquer les ressorts de la façon simple et compréhensible par le commun des mortels.

 Et j'ai le sentiment que pour arriver à mes fins, il va me falloir déjà parler

• de la fin : pourquoi le cloud computing, quels sont les apports attendus ?

• des moyens : quelles sont les avancées techniques, et les modèles économiques, qui en ont favorisé l'essor

Cet article constitue un élément explicatif d'une problématique usuelle en informatique et à laquelle le cloud computing apporte une réponse formidable : il expose les notions de Haute Disponibilité que nous abrégerons en HA par la suite (High Availibility, le terme consacré). 

Il y a des pré-requis. En cas de besoin, commencez par lire la série de 3 articles sur le fonctionnement d'Internet (et des technologies réseau), et l'article d'introduction sur le hardware.

Quels sont les objectifs de la HA ?

Un ordinateur est un dispositif matériel composé pour l'essentiel de circuits électroniques mais également d'éléments mécaniques (les disques durs classiques sont composés d'un moteur, de roulements à bille, de disques, de têtes de lecture ...). Tous ces éléments sont susceptibles de tomber un panne : un composant peut surchauffer et cramer, le moteur d'un disque dur peut casser. 

La fiabilité d'une pièce peut s'exprimer par le MTBF (Mean Time Before Failure, temps moyen avant panne).

Un ordinateur héberge un système d'exploitation. Ce système d'exploitation fait fonctionner des serveurs. Ces serveurs peuvent eux même servir de support à des applications comme un sites web par exemple, 

Tous ces éléments logiciels sont susceptible de rencontrer des bogues et de dysfonctionner. Une simple erreur de programmation dans la gestion de la mémoire peut provoquer une "fuite mémoire" (de la mémoire est allouée, réservée, par le programme qui oublie ensuite de la libérer quand il n'en a plus l'usage) : inévitablement, selon la fréquence à laquelle le programme qui comporte l'erreur est appelé, la quantité de mémoire non libérée, et la quantité de mémoire sur le serveur, il arrivera un moment où il n'y en aura plus de disponible et où le système ne pourra plus répondre à de nouvelles demandes.

Enfin, rappelez vous le fonctionnement du modèle client/serveur : sans que rien ne tombe en panne, un serveur peut recevoir un volume de requêtes qui excède ses capacités de traitement, qui sont finies, et se bloquer ou devenir tellement lent que ça revient au même.

N'importe lequel de ces 3 types d'événement a pour effet de rendre le service rendu indisponible : et selon la criticité dudit service, ce peut être juste ennuyeux, comme très grave ou même dramatique quand des vies humaines sont en jeu.

Le niveau de disponibilité attendu d'un système s'exprime par le pourcentage. Un exemple issu de wikipedia sera plus simple qu'une explication laborieuse :

• Soit une machine que l'on souhaite utiliser 12 heures par jour, mais qui tombe en panne en moyenne pendant 1 heure chaque jour et a besoin d'une demi-heure de réglages divers pour sa remise en fonctionnement. Sa disponibilité est :

Pour des systèmes devant tourner en permanence, on utilise parfois le terme 24/7 (24H sur 24, 7 jours sur 7).

L'objectif de la HA est de permettre d'atteindre ces niveaux de disponibilité en dépit de l'inéluctabilité de la survenance de pannes matérielles ou logicielles.

Deux angles d'attaque

La HA peut s'aborder selon deux angles :

• La capacité de tolérance de panne ou failover est l'ensemble des mécanismes qui permettent de pallier à une panne proprement dite.

• La capacité à monter en charge ou scalability (parfois traduit en Français par scalabilité) est l'ensemble des mécanismes qui permettent d'adapter la capacité de traitements au volume de requêtes

Failover

Le failover s'obtient principalement par la redondance des éléments matériels et logiciels : par exemple au lieu d'avoir un ordinateur, on en installe deux. Un est présent pour fournir le service (il est up), le second ne fait rien dans un premier temps. Si "on" détecte une panne du premier ordinateur, les requêtes sont redirigées vers le second serveur qui prends le relais du premier ; on dispose ainsi du temps nécessaire pour réparer le premier ordinateur et revenir à une configuration sécurisée. Si le second ordinateur tombe à nouveau en panne avant qu'on ait eu le temps de réparer le premier, on est planté. On peut alors prévoir 3 machines, ou 4, ou 5 ou ...  

Le scénario évoqué est appelé "actif/passif" (un élément actif, un ou plusieurs autres passifs). Il existe aussi des scénarios actif/actif.

On le voit la redondance a un coût qui augmente de façon exponentielle en fonction du niveau de sécurité qu'on veut obtenir (la probabilité d'avoir deux ou trois ou quatre machines en panne en léger différé ne fait que décroître tandis que le coût des matériels augmente de façon linéaire et constante).

La détection fiable de la panne du premier ordinateur (le fameux "on") est une des problématiques à résoudre. 

On aborde ici un (vaste) sujet de l'informatique : la supervision qui est l'ensemble des moyens matériels / logiciels / humains qui permettent de surveiller le bon fonctionnement des matériels et logiciels en temps réel ou quasi-réel. 

Cette supervision se fait généralement via des sondes matérielles ou logicielles  qui mesurent la "santé" d'un ordinateur. Une bonne image est celle d'un malade en salle de réanimation dans un hôpital branché sur des appareils qui surveillent sa pression artérielle, le fonctionnement de ses poumons etc. et émettent des alertes en cas de problème.

La redirection du trafic entrant (les requêtes émises par les clients) vers la machine numéro 2 (qui passe d'un rôle passif à actif)  au lieu de la machine 1 (qui passe d'un rôle passif à un rôle actif) est fréquemment effectuée grâce à des mécanismes réseau de bas niveau qui permettent d'associer le FQDN du service appelé à une adresse IP virtuelle. 

Cette IP est dite virtuelle car elle n'a aucune correspondance physique avec une carte réseau : au lieu de cela, elle est affectée dynamiquement à la machine active (qui a une carte réseau et une vraie adresse IP)

Quand la machine 1 est en panne, on redirige les requêtes sur la machine 2, et on "répare" la machine 1. Si c'est une panne logicielle, il suffit généralement de rebooter la machine. Si c'est une panne matérielle c'est beaucoup plus ennuyeux, il est parfois possible de changer rapidement une pièce défectueuse si on a du stock mais on trouve vite les limites pratiques. Du coup, la solution consiste généralement à avoir la machine complète en spare (en pièce de rechange) : ça a un coût, il faut stocker le matériel, qui peut très bien être en panne aussi ... vous commencez peut être à percevoir l'intérêt de la virtualisation ? Nous reviendrons sur ceci.

Scalability

La scalabilité se décline sous deux formes :

• scalabilité horizontale : elle s’obtient en multipliant le nombre d’instance du service à mettre en HA et en plaçant en amont un mécanisme de répartition de charge (load-balancer)

• scalabilité verticale : elle s’obtient par l’ajout de ressources physiques au niveau de l’infrastructure (disques durs, mémoire, processeurs etc.).

Dans le cas de la scalabilité horizontale, le FQDN du service en HA est associé à l'IP du load-balancer. 

Ce dernier se charge d'envoyer la requête à une des machines qui s'exécutent en parallèle selon un algorithme. 

Cet algorithme peut être très simple et adresser alternativement et successivement chacune des machines (on parle de round-robin) ou être plus sophistiqué et tenir compte de l'état de santé des différentes machines pour cibler celle qui est la plus en forme, et éviter d'envoyer du trafic à une machine en panne. On retrouve la nécessité de sondes pour ce cas.

C'est ce type de scalabilité qui est le plus employé. La scalabilité verticale consiste simplement à upgrader un matériel pour lui ajouter des capacités (de la mémoire, du disque, un processeur supplémentaire sur une machine multi-processeur etc.).

La scalabilité horizontale peut être gérée dynamiquement simplement en démarrant une nouvelle machine et en informant le répartiteur de charge. On peut même si on pousse l'idée plus loin, ajouter et enlever des machines automatiquement selon les besoins : c'est ce qu'on appelle l'élasticité (une notion clé des solutions cloud comme nous le verrons). Ici aussi, vous devez percevoir l'intérêt de la virtualisation : en effet, à moins d'avoir des robots ou des armées d'ouvriers, comment pourrait on installer et dé-installer dynamiquement des ordinateurs physiques ?

La scalabilité verticale conserve son intérêt. Quand on choisit un serveur chez un fournisseur, on a tout intérêt à se préoccuper de la capacité d'évolutivité de la machine en question. En effet, il ne faut pas perdre de vue que si on virtualise les moyens informatique, il faut quand même des serveurs physiques pour faire tourner les systèmes virtuels, et que ce sont eux qui vont devoir encaisser un accroissement d'activité généré par la multiplication d'ordinateurs virtuels dans le cas d'une scalabilité horizontale. Et ils deviendront à leur tour un facteur limitant si vous devez les changer ou les immobiliser pour ajouter des processeurs, des disques, des interfaces réseau etc. Les serveurs spécialisés professionnels prennent tout leur intérêt avec de fortes capacité d'extension à chaud sans interruption de service.

SPOF

Encore un acronyme comme on les aime en informatique : Single Point Of Failure. Ce terme désigne le maillon faible d'une architecture, celui qui en cas de défaillance met en panne l'ensemble du système.

Dans notre exemple précédent, on parlait de mettre un répartiteur de charge devant n serveurs pour assurer la scalabilité horizontale. 

C'est super mais que se passe il si notre répartiteur de charge tombe en panne ? On aura beau avoir 100 serveurs mega-puissants derrière, on l'aura dans le coin coin. Le répartiteur constitue ici un SPOF.

Comment améliorer les choses ?

On a deux types de répartiteurs de charges : logiciels et matériels. Préférer un répartiteur matériel améliorera les choses : ils sont extrêmement robustes et très peu susceptibles de tomber en panne : mais ça arrive quand même (et en outre ça coûte très cher). Les marques les plus connues sont F5 et Alteon

Pour supprimer le SPOF, il faudra simplement un mécanisme de failover sur le load-balancer : si on met deux répartiteurs physiques en actif/passif par exemple, les probabilités de panne seront très très très faibles (mais pas nulles, le mécanisme qui fournit l'IP virtuelle en amont peut défaillir).

Quoi d'autre ?

Dans tous les exemples ci-dessus, nous avons parlé de HA au sujet d'ordinateurs en nous focalisant sur la ressource "capacité de traitement" du système informatique, qui est assurée bien entendu par le CPU des ordinateurs (en collaboration avec la RAM).

Mais d'autres éléments sont mis en oeuvre :

- de l'espace de stockage

- des communications réseau

Dans les infrastructures de production conséquentes, les ordinateurs n'ont souvent pas de disque et la gestion des disques est effectuée sur des périphériques de stockages dédiés et accessibles via le réseau.

Différents systèmes existent : le NAS est en gros un ordinateur qui héberge un service de serveur de fichiers auquel font appel les serveurs "cpu" (dans l'idée c'est comme un partage réseau sur un ordinateur de bureau), le SAN est un mécanisme beaucoup plus sophistiqué, coûteux et performant.

Tous ces "trucs" (ordinateur, load-balancer, NAS, SAN ...) communiquent par le réseau. Or un réseau ça implique aussi du matériel : switch pour cloisonner différents réseaux virtuels (switch administrable niveau 3), routeur pour l'interconnexion à Internet ou à d'autres réseaux étendus, firewall ...

Tous ces éléments sont également amenés à être supervisés et installés dans une configuration HA car leur défaillance ou surcharge est également critique pour l'ensemble du système.

Et, oui ... ces éléments peuvent également être virtualisés (ça devient un peu compliqué).

Au niveau logiciel

J'ai parlé ici de la HA au niveau matériel et système. Mais on retrouve les mêmes concepts au niveau logiciel. Je vais ici mettre le focus sur les architectures web, et les serveurs d'application mis en oeuvre pour assurer le rendu des pages des sites web dynamiques.

De nombreux serveurs d'applications offrent des solutions pour regrouper des serveurs autonomes en ensembles cohérents, pour l'administration et le déploiement des applications, mais également pour la mise en oeuvre de la haute disponibilité : load-balancing, failover.

Les serveurs d'application JEE (plateforme Java) en particulier sont riches en ce domaine que ce soit IBM Websphere, Oracle Weblogic, Redhat Jboss ...

Les architectures web ont cependant longtemps présentées une contrainte particulière : la gestion d'une session utilisateur se faisant dans la mémoire du serveur sur lequel l'utilisateur s'est initialement authentifié, le load-balancing qui a comme conséquence de le diriger vers un serveur de façon aléatoire ne peut pas être mis en oeuvre. Et si le serveur dans lequel sa session est gérée redémarre, les données de sa session sont perdues (en tant qu'utilisateur, vous perdez vos données mémorisées et vous devez vous authentifier à nouveau).

La session, pour les non spécialistes du web, c'est simplement la mémorisation des données spécifiques à un internaute entre deux requêtes, comme par exemple la liste de son panier d'achat (rappelons que le protocole http est sans état).

Pour pallier à ces deux soucis, il existe différentes solutions que j'expose rapidement :

• on configure le load-balancer dans un mode particulier appelé "affinité de session" (sticky mode) qui permet de toujours rediriger un même utilisateur sur le même serveur Cependant, si ça permet de concilier load-balancing et session serveur, ça ne couvre pas le failover.

• on configure le serveur d'application pour qu'il enregistre les données de session en base de données (sessions persistantes). On a ainsi le load-balancing et le failover mais les inconvénients sont très nombreux : le stockage des données de session en base est très lent et implique l'investissement dans du matériel très coûteux pour héberger le SGBDR, il y a des contraintes de programmation, on introduit un SPOF au niveau du SGBDR et si on veut l'éliminer il faut passer par des solutions techniques (réplication) également très coûteuses et qui ne sont pas sans inconvénient, en particulier au niveau de l'exploitation

• on peut mettre en oeuvre des solutions qui permettent de stocker la session en mémoire mais de façon répartie, rapidement, avec de la redondance qui apporte le failover. C'est sans doute la meilleure solution mais ça implique l'achat de licences pour ces solutions (et leur apprentissage). A réserver pour les gros sites, avec des investisseurs au portefeuille garni.

Ceci étant dis, le mieux est probablement de bâtir une architecture dans laquelle on n'a pas de gestion de la session utilisateur côté serveur.

On qualifie ces architectures de stateless (sans état) et elles constituent l'état de l'art actuel, du moins à humble avis.

Ces architectures sont généralement basées sur des communications asynchrones en http effectuées par du code javascript s'exécutant dans le navigateur (technique de base du web 2.0, parfois encore appelé ajax). On parle de style d'architecture REST (bien que souvent, on soit plutôt sur du simple RPC over HTTP avec de la sérialisation au format JSON).

Explications du jargon : RPC ça veut juste dire "appel de procédure distante" (Remote Procedure Call) ce qui est le cas puisqu'on a un code javascript sur le client qui appelle une procédure sur le serveur ; over HTTP qu'on utilise le protocole HTTP pour faire cet appel de procédure (donc tout bêtement qu'on fait une requête http) : JSON, c'est "Javascript Notation", un format de sérialisation de données, ce qui en bon Français veut juste dire une façon de représenter des données de façon textuelle (dans un format qui en outre est directement compréhensible par un interpréteur EcmaScript, donc par javascript). Ces éléments sont présents et essentiels dans la définition d'une architecture REST qui nécessite cependant le respect d'autres points souvent ignorés par des développeurs qui font du coup du "presque-REST" (la confusion est fréquente).

Ce style d'architecture rencontre un grand engouement actuellement, bien au delà des applications web d'ailleurs, et combiné avec les outils et pratiques DevOps et les techniques de virtualisation moderne remet au gout du jour le SOA dans une variante désormais appelée micro-services.

Explications du jargon : SOA (Service Oriented Architecture) est un style d'architecture répartie qui a été très à la mode malgré une lourdeur certaine dans ses premières implémentations (SOAP pour ceux à qui ça parle), et qui revient actuellement sur le devant de la scène grâce à ce "nouveau" (en fait rien de nouveau pour les vieux briscards, mais bon passons) mode de mise en oeuvre basé sur REST, beaucoup plus simple et léger. Cette facilité d'implémentation, plus l'essor du mouvement DevOps qui rapproche les équipes de développements et d'exploitation et met l'accent sur des solutions techniques légères (comparativement aux serveurs d'application JEE cités plus haut qui sont des usines à gaz redoutables) favorise donc une nouvelle "saveur" de SOA rebaptisé "micro-services" pour faire oublier aux DSI les millions engloutis dans des projets SOA ayant explosé en vol (en partie du fait de la lourdeur des choix techniques initiaux, bien que les écueils de ces projets étaient bien souvent liés à des problèmes organisationnels).

Oui, mais si on a absolument besoin d'un session du fait des fonctionnalités et de l'ergonomie (un panier d'achat pour un site ecommerce par exemple) ? Hé bien, la session est gérée côté client. A un moment, il faudra bien renvoyer le paquet de données au serveur mais ça ne devrait pas constituer un facteur limitant dans 99% des cas. Et les frameworks javascript modernes facilitent désormais la programmation de ce genre de cas.

Comme on le voit, les choix d'implémentations ont donc aussi un impact fort sur la facilité plus ou moins grande à mettre en oeuvre une architecte HA.

Pour le fun : virtual hosting

Juste pour le fun. Si vous avez compris tout ceci, vous devez pouvoir comprendre comment fonctionne le virtual hosting dans un serveur http.

Le virtual hosting est la capacité pour un serveur http à héberger non pas un, non pas deux, non pas trois mais un nombre potentiellement très élevé de sites web. C'est la technique utilisée par les hébergeurs web pour leurs offres d'hébergement mutualisé (un serveur web partagé par n sites).

Mais comment est ce possible puisque chaque site web a un FQDN différent ? Et que chaque FQDN est censé pointer sur son serveur web dédié, via son IP spécifique ?

Hé bien, tous les noms de machines pointent sur la même adresse IP, celle du serveur web. C'est donc le serveur Web qui reçoit toutes les requêtes pour tous les sites. Exactement comme notre load-balancer tout à l'heure. D'ailleurs, on peut configurer un serveur web en tant que load-balancer, c'est l'alternative gratuite à l'utilisation des coûteux boitiers F5./Alteon évoqués (qui sont par contre infiniment plus performants vu que l'algorithme est implémenté au niveau matériel). Ici, le serveur web est configuré en reverse-proxy : comme son nom l'indique il fait l'inverse de ce que fait un proxy (qui rappelons le, reçoit les requêtes en sortie et les réémet) : il reçoit les requêtes en entrée et les adresse vers le bon destinataire en se basant sur le nom (FQDN) avec lequel il a été appelé. Sa configuration consiste à activer la fonctionnalité et à décrire les règles de mise en correspondance entre un FQDN et un répertoire racine d'un site web statique ou une adresse et un protocole de communication d'un serveur d'application pour un site web dynamique.

J'avais évoqué dans l'article sur le fonctionnement d'Internet la possibilité d'héberger plusieurs serveurs web à son domicile malgré le fait que notre box Internet ne dispose que d'une seule IP publique. Hé bien, c'est à cette technique que je faisais allusion : une règle de NAT au niveau de la box pour envoyer le trafic entrant sur le port 80 vers votre serveur http hébergé en interne et qui met en oeuvre du virtual hosting pour relayer le trafic vers n serveurs (http ou serveur d'application) de votre réseau interne. Vous voilà hébergeur !

Conclusion

Bon, j'ai écrit tout ça d'une traite après une nuit blanche (je vais me relire un petit coup quand même). Je n'avais rien produit depuis un moment, je suis en train de voir pour démarrer une activité en indépendant et je passe un temps insensé à chercher les infos à jour sur les mécanismes fiscaux et de protection sociale... bien plus compliqué que l'informatique croyez moi ! Et j'ai fait des études de gestion (j'ose pas imaginer la galère pour celui qui n'y connait rien).

La suite c'est de parler rapidement des solutions de virtualisation, puis de décrire les modèles économiques  du cloud computing (SAAS, PAAS, IAAS et même DAAS), et rebondir ensuite sur les solutions techniques de gestion de cloud et le mouvement/outils DevOps. J'ai toute la trame en tête , faudra juste que je prenne le temps.