Technologies

PaaS : Platform as a Service

Publié le : Auteur: vhanniet Laisser un commentaire
paas

Le cloud est à la mode : utiliser des ressources matérielles/logicielles distantes via internet est devenu facile. Une des principales conséquences est que plutôt que d’acheter des machines, les configurer, installer des frameworks et services techniques, les maintenir, etc. on peut louer la même chose sous forme de services.


Parmi les intérêts des services cloud :

  • on peut adapter le volume et le timing des ressources au juste besoin en suivant son évolution
    • mais en contrepartie on ne maîtrise plus aussi bien l’évolution du coût puisque celui-ci dépend d’une offre commerciale tierce, et se pose aussi la question de la pérennité du fournisseur
  • on s’affranchit des efforts de mise au point et optimisation des configurations
    • mais en contrepartie on est tributaire des configurations standards proposées par le fournisseur, et l’optimisation n’est pas forcément simple si les plateformes sont mutualisées

Pour des projets de développement, la tentation est forte d’envisager d’utiliser le cloud pour s’affranchir de la construction et du maintien en état de marche de la plateforme de développement. Au sein de la famille cloud ce type d’offre s’appelle Platform as a Service : PaaS (en français : plateforme en tant que service). On trouve sur Wikipedia un schéma qui décrit bien les grands catégories d’offre du cloud :

Cloud Computing Layers

PaaS

Parmi les acteurs clés de l’histoire, récente, de l’offre PaaS qui offrent la possibilité de développer des applications sans contraintes particulières fortes je retiens :

  • Heroku : le pionnier en 2007. Racheté en 2010 par Salesforce.com
  • AppFog : plateforme créée en 2010 qui se définit comme agnostique techniquement. Basée sur Cloud Foundry. Rachetée en 2013 par CenturyLink
  • Microsoft Azure (anciennement Windows Azure) : un des pionniers car lancé en 2008. Réservé cependant au afficionados du développement .Net
  • Open shift : l’offre PaaS de Red Hat, orientée sur le développement web. Particularité : peut-être déployée sur un cloud privé d’entreprise
  • Blue Mix : c’est le petit nouveau (2014) en provenance d’IBM. Fondé sur Cloud Foundry (une bonne base) il apportera certainement, un fois au point, la richesse de l’écosystème IBM en matiére de développement Java

Parmi les acteurs clés que je ne retiens cependant pas dans la catégorie PaaS :

  • Cloud Foundry : CF est plutôt à classer dans la catégorie « meta-PaaS » : c’est une infrastructure cloud permettant de construire une PaaS !
  • Google App Engine : bien que pionnier (2008), GAE possède des restrictions qui en font un écosystème à part. A réserver aux utilisateurs « Google App ».
  • Amazon AWS : Amazon est certainement le pionnier de la réussite commerciale du cloud computing (2006). Même avec de multiples offres pouvant contribuer partiellement à du PaaS, Amazon AWS n’est pas à portée du 1er projet de développement venu.

 

PaaS ou pas PaaS ?

Imaginons que je m’apprête à lancer un projet de développement. Avant même de me poser la question du choix d’une PaaS, qu’est-ce qui pourrait me faire aller vers du PaaS plutôt que vers l’approche traditionnelle – ie monter/adapter une plateforme de développement et traiter ses éventuels impacts sur l’environnement de production ? Généralement, mon projet s’inscrit dans un programme ou dans une filière de développement qui sont déjà balisés technologiquement et la question ne se posera même pas. Quels sont les contextes exceptionnels dans lesquels se présente une opportunité pour la PaaS ?

  • Nouvelle activité : nouvelle entreprise, nouvelle entité, nouveau métier, etc.
  • Rupture : transformation digitale, nouvelle approche projet, etc.
  • Expérimentation : recherche d’alternatives, POC, etc.
  • Projet indépendant focalisé sur le résultat plus que sur la manière : application évènementielle, application « bonus », etc.

Ces opportunités présentes des profils et exigences différents : les critères de choix, et surtout la pondération qui leur sera donnée, seront très variables. Par exemple, pour une nouvelle activité il faudra se mettre dans une perspective de capitalisation dans la durée alors que pour un projet indépendant la durabilité importe beaucoup moins. L’intérêt principal du PaaS est certainement de gagner du temps dans le choix, la mise en oeuvre, l’exploitation d’une plateforme technologique. Dans cet esprit, si la technologie importe peu (Java, .NET, autre) les critères favorisés seront certainement la facilité d’usage, le prix, la couverture « tout en un ». Si la technologie compte, cela restreindra l’éventail de choix. Si le choix est engageant dans la durée, l’approche PaaS devra être prototypée et comparée à l’approche traditionnelle (facile à évaluer même sans prototype). Paradoxalement, un intérêt du PaaS est certainement d’avoir l’assurance de ne pas prendre de retard sur l’état de l’art mais ça peut aussi être vu comme un inconvénient par rapport à une situation projet/exploitation obsolète mais qui fonctionne, qu’on maîtrise parfaitement et qu’on ne veut pas prendre le risque de quitter. Un contexte en faveur du PaaS semble être le cas où la priorité sur la valeur business à court terme est forte en face d’un enjeu technique faible. Et notamment dans tous les cas où la filière technique n’existe pas ou n’est pas maîtrisée.

Quelle PaaS choisir ?

Imaginons que je me sois décidé pour du PaaS, quelle solution choisir ? La qualité de la relation avec le fournisseur, ainsi que la capacité à survivre à sa disparition ou à sa réorientation, sont comme pour toute solution des critères importants. Pour le PaaS en particulier, pouvoir internaliser l’infrastructure et/ou la redéployer chez un autre fournisseur sont également des critères importants dans la durée. Tout comme le fait de disposer d’une documentation complète et d’une solution fonctionnant en mode « boîte blanche » où il est possible de faire intervenir des experts externes au fournisseur. Les affinités technologiques comptent aussi. Par exemple si je suis habitué à développer en Java il paraît peu opportun de choisir Microsoft Azure ! Si aucun autre élément ne m’a permis de faire choix, il me reste à comparer entre elles ces solutions sur des critères purement techniques. Une comparaison intéressante se trouve ici : http://fr.slideshare.net/Pivotal/paa-s-comparison2014v08.

En guise de conclusion

Cet article survole le sujet PaaS. Il existe d’ailleurs de nombreuses offres PaaS, généralement spécialisées, non mentionnées ici. Dans le monde du cloud, il me paraît facile et fiable d’envisager d’utiliser de l’IaaS (stockage par exemple) et du SaaS (application clé en main hébergée chez le fournisseur). Ce sont des usages entrés dans la vie courante, en particulier à un niveau individuel (qui n’a jamais utilisé DropBox ou un de ses équivalents ? qui utilise encore un logiciel de messagerie installé sur son PC/Mac ?). Ça me paraît par contre beaucoup plus impliquant en ce qui concerne le PaaS car au delà des données, qu’on arrive toujours à bouger d’un environnement vers un autre, il s’agit avec le PaaS de déléguer l’architecture d’implémentation des applications sans pour autant qu’il existe un modèle de cette architecture qui fasse qu’on puisse facilement la migrer vers un autre fournisseur. C’est certainement jouable et accessible à tout le monde pour des projets « jetables ». Au delà, et si la faisabilité et la valeur ajoutée du PaaS est démontrée face à une approche traditionnelle, cela nécessite certainement un accord stratégique long terme avec le fournisseur, ou de disposer de la capacité à internaliser la plateforme. NB : un très bon avant-goût de ce à quoi ressemble le PaaS une fois qu’on a mis le doigt dedans : http://www.eventuallycoding.com/index.php/paas-or-not-paas-that-is-the-question/