Du Capex vers l’Opex : l’ère du « as a Service » révolutionne l’informatique d’entreprise

Du Capex vers l’Opex

Dès le milieu des années 1990, quelques aventuriers d’internet proposent des services d’hébergement Web et de bases de données plus ou moins mutualisés[1]. Ces services sont très rudimentaires, la facturation est forfaitaire et les instance

s sont hébergées sur des machines physiques. La montée en charge est complexe, voire non prévue. Les applications hébergées sur ces plateformes n’ont rien de différent avec leurs équivalents locaux en entreprises. Pourtant, sous l’impulsion d’internet, l’architecture des applications va évoluer pour tirer parti des spécificités de ce nouveau support.

En 1999, « Salesforce » est un des pionniers des applications commerciales délivrées via internet à l’aide d’un simple navigateur, on commence à parler de « Software as a Service ».

En 2006, « Amazon Elastic Compute Cloud » (EC2) est le premier service commercial permettant aux petites entreprises de louer des machines virtuelles sur lesquelles elles pourront installer leurs applications (Infrastructures as a Service).

Ces étapes marquent un tournant important de l’informatique d’entreprise. Il est, désormais, possible de louer (Opex) des moyens de production informatique, au lieu d’investir (Capex) dans d’onéreuses infrastructures.

Ce changement de paradigme de l’informatique d’entreprise vient avec son lot de nouvelles problématiques, non seulement techniques (Sécurité, Intégrité et Performances) mais aussi légales (Législations locales, gestion des contrats etc.).

Application Platform as a Service

En 2005, la plateforme Zimki[2], décrite comme le premier « Framework as a Service », préfigure de l’avenir du développement applicatif dans le Cloud et de ce que l’on appelle désormais le « Application Platform as a Service » aussi dénommé PaaS.

Depuis, de très nombreux fournisseurs ont vu le jour (Heroku, Microsoft Azure, Salesforce Platform,  Google App’s Engine, etc.[3]) et se partagent un marché très dynamique en terme de fonctionnalités.

Un des premiers objectifs du PaaS est de fournir aux développeurs un environnement en « Self-Service », leur permettant de créer, de déployer et de distribuer leurs applications, sans avoir à se soucier des problématiques d’infrastructures sous-jacentes (déploiement de serveurs et de système d’exploitation, réplication, outillage,  équilibrage et montée en charge etc.). Certains PaaS sont même spécialisés dans le développement d’applications mobiles (Appcelerator, Kinvy, Parse, StackMob) on parle alors de « mBaaS » pour  « Mobile Backend as a Service ».

Le PaaS est, particulièrement, adapté au développement d’applications Web et mobiles destinées à un usage internet. On ne consomme plus des machines virtuelles (comme dans le IaaS) mais des composants « sur étagères », préconfigurés et utilisables immédiatement (stockage objet, bases de données, serveurs d’applications, API propriétaires etc.),  ce qui libère de la surcharge administrative, du déploiement et de la gestion des systèmes d’exploitation.

D’un point de vue ressources, la consommation de services permet une granularité plus fine. Le coût initial d’une instance est alors plus faible. La montée en charge des différents services s’effectue verticalement ou horizontalement de manière transparente.

En bénéficiant de l’infrastructure d’un fournisseur de service global, le PaaS permet de rendre son application disponible presque instantanément sur l’ensemble de la planète, pour un coût d’exécution et développement beaucoup plus optimisé que sur de l’« Infrastructure as a Service ».

Vers la fin du système d’exploitation ?

Pour les applications qui s’exécutent dans le PaaS, celui-ci en devient l’environnement d’exécution, éloignant le système d’exploitation derrière de nouvelles couches d’abstraction.

Bien que toujours indispensable, le système d’exploitation standardisé, automatisé, créé et détruit à la demande, devient lui-même une commodité.

En devenant le nouvel environnement d’exécution de l’application, le PaaS concentre, désormais, une partie des adhérences.

La portabilité dans le PaaS

Chaque plateforme possède ses propres caractéristiques (langages de programmation, outils, bases de données, mode de facturation, etc.), et propose un environnement plus ou moins agnostique et plus ou moins ouvert.

Contrairement au IaaS, où le système d’exploitation joue un rôle d’environnement d’exécution facilement portable, l’application qui s’exécute dans un PaaS peut faire référence à des services ou des composants absents ou chez d’autres fournisseurs. Cette adhérence peut alors nécessiter une modification plus ou moins importante de l’application en cas de migration.

Une autre solution consiste à installer son propre PaaS directement dans sur du IaaS. De nombreux projets Open Source permettent de créer des PaaS Hhybrides, capables de consommer des ressources de différents fournisseurs IaaS (Cloud Foundry, OpenShift Origin, Cloudify etc.). Bien que l’adhérence entre l’application et le PaaS subsiste, ce mode de déploiement permet de réduire significativement les risques relatifs à la relation client / fournisseur.

Plates-formes « PaaS » déployées « à cheval » sur différents fournisseurs IaaS.

Applications Cloud Natives & The Twelve-Factor App

Les nouveaux modes de développement des applications dans le Cloud ont donné naissance au concept d’applications « Cloud Natives».

Une « Application Cloud Native » est une application tirant partie des spécificités offertes par les architectures Cloud modernes. D’un point de vue général, ce terme désigne une application créée à partir d’un assemblage de composants (Web, Base de données, Cache mémoire, Environnement d’exécution, File de  Messages, etc.) comme ceux fournis dans le PaaS.

Le manifeste « The Twelve-Factor App [4]», rédigé en 2012 par les ingénieurs de la plateforme « Heroku », compile douze bonnes pratiques issues de l’expérience acquise sur le déploiement de centaines d’application. Cette méthodologie est aujourd’hui considérée par la communauté des développeurs comme une base commune permettant de décrire et de créer une application « Cloud Native ». L’exposition des services par le Web, la montée en charge par différenciation des processus (Y-Scaling) ou l’utilisation de processus sans mémoire d’état (Stateless), sont autant de patterns fondateurs que l’on retrouve dans la plupart des applications Cloud Natives et Microservices.

^[1] A history of Web Hosting [Infographic] (2012 – BizTechMagazine.com)

^[2] Brady Forrest « Zimki, hosted Javascript environment » (2006 – Radar.oreilly.com)

^[3] Dan Sullivan « PaaS Provider List : Comparison and guide » (2014 –TomItPro.com)

[4] The Twelve-Factor App (https://12factor.net/)

Les Cloud Pattern

Parce que les applications Cloud Native partagent de nombreuses caractéristiques, elles partagent des problématiques communes (Gestion des Identités et de la sécurité, élasticité, gestion d’erreurs dans un système distribué, équilibrage de charge, etc.). La communauté des développeurs, ainsi que les principaux fournisseurs de PaaS ont compilés et documentés de nombreux « pattern » permettant de répondre rapidement à ces problèmes (AWS Cloud Design Pattern[1], Microsoft Azure Cloud Design Pattern[2]). Ces « Design Pattern » sont parfois spécifiques à une plateforme.

Les containers, un nouveau standard d’exécution

Les containers sont en passe de devenir un mode de déploiement incontournable des applications Cloud Natives. La majorité des plateformes PaaS modernes proposent ou sont basées sur un modèle d’exécution en container.

Quand un développeur conçoit une application, il doit réfléchir à la manière dont il va pouvoir l’installer et l’exécuter sur des systèmes d’exploitation qui n’auront pas forcément les mêmes caractéristiques ou les mêmes prérequis. Le « packaging », c’est-à-dire la manière dont l’application va être distribuée et installée représente dès lors un coût non négligeable dans le processus de développement et de déploiement.

Les containers permettent de déployer des instances d’application indépendantes dans un même système

En standardisant et au automatisant le déploiement des OS, la virtualisation x86 a permis de répondre à ce problème en devenant l’unité de déploiement d’une application. Cette association se révèle, cependant, peu efficiente à grande échelle, le système d’exploitation constituant un surcoût de ressources,  et de licences non négligeable.

Issus des technologies de virtualisation applicatives développées sous Linux (LXC), les containers utilisent une couche d’abstraction entre l’application et le système d’exploitation. Cette abstraction permet de résoudre les problématiques portabilité des applications en s’affranchissant des contraintes relatives au système d’exploitation (Variables d’environnements, librairies, chemins etc.). Le container embarque non seulement le code applicatif, mais aussi tous les éléments nécessaires à l’exécution (librairies, binaires etc.). Une fois l’application packagée dans une « image » de container, il suffit d’en récupérer une copie pour déployer autant d’instances que nécessaire.

Les containers peuvent s’exécuter dans des OS virtualisés. La virtualisation offre un niveau d’isolation nativement plus important

D’un point de vue fonctionnel, un container est très semblable à une machine virtuelle. C’est une instance de système d’exploitation disposant de son propre système de fichier et de sa propre identité réseau (nom, adresse IP). Comme une machine virtuelle, il est possible d’allouer une certaine quantité de ressources mémoire et CPU.

Cependant, contrairement à une VM, le container ne permet pas nativement de stocker des informations résilientes (on dit qu’il est « StateLess »). Le stockage d’informations résilientes doit s’adosser à des partages réseaux ou des technologies annexes (Ex : Flocker, Docker Data Volumes, Distributed File System etc.).

Le container conserve une adhérence avec le noyau de l’hôte. Tous les containers qui s’exécutent sur un OS partagent le même noyau système (il n’est pas possible de faire tourner un container Linux sur une machine Windows et vice et versa). Pour ces raisons les containers sont une technologie qui ne permet pas une isolation aussi forte que la virtualisation x86 offerte par la plupart des IaaS.

Le container est plus léger qu’une machine virtuelle (car débarrassé du surcoût de l’OS) et plus rapide à déployer (la création d’un container étant presque instantanée).

En « cassant » la relation « un pour un » entre l’application et le système d’exploitation, le container deviens une unité de déploiement et de facturation plus efficiente.

Plus agiles et plus efficients, les containers sont en passe, progressivement, de remplacer les machines virtuelles dans le déploiement des applications « Cloud Native ». Cette évolution ne peut cependant avoir lieu sans l’intégration d’une culture « Dev Ops » au sein de l’organisation pour révéler son potentiel.

[1] AWS Cloud Design Patterns (en.clouddesignpattern.org)

[2] Cloud Design Patterns : Prescriptive Architecture Guidance for Cloud Applications (microsoft.com)