BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Table ronde virtuelle : Le futur du PaaS dans le Cloud Computing

Table ronde virtuelle : Le futur du PaaS dans le Cloud Computing

Un débat fait rage au sujet du Platform-as-a-Service. Le PaaS a-t-il toujours une place de choix dans un portefeuille de services Cloud ? InfoQ a contacté quatre leaders du domaine pour connaitre leurs opinions sur le futur du PaaS.

Dans cet entretien, Krishnan Subramanian, partisan du Cloud, le développeur Dan Turkenkopf, JP Morgenthal, homme d'affaires dans le domaine, et l'expert du Cloud James Urquhart discutent de la perception erronée que l'on peut avoir du PaaS et du rôle qu'il pourrait jouer dans le futur du Cloud Computing.

InfoQ : Quelle est la valeur réelle (non théorique) propre au PaaS que le IaaS n'apporte pas ? Pourquoi ne pourrions-nous pas simplement utiliser des machines virtuelles pour héberger nos divers portefeuilles d'applications ?

Krish : Vous pouvez très bien utiliser des machines virtuelles et les outils d'administration associés pour mettre en place un environnement qui offrira une valeur similaire à celle du PaaS. Il n'y a aucun doute là-dessus. Mais ce que fait le PaaS, c'est qu'il déleste les entreprises de la complexité de l'automatisation en la confiant à des revendeurs IT et ce, de façon transparente grâce à des outils de développement. Ce sont les deux choses à retenir à mon sens. Les bénéfices sont, d'une part, une meilleure productivité pour les développeurs et d'autre part, une charge moindre pour les entreprises pour ce qui est des compétences DevOps à acquérir. En effet, les rôles de développeur et de responsable des opérations restent séparés mais le PaaS les rapproche, dans une collaboration allant du développement à la production.

JP : Je pense que la première valeur du PaaS dans ce domaine se trouve dans la simplification de la gestion du cycle de vie de l'application. Cela comprend la possibilité d'adapter l'application aux attentes des utilisateurs, mais aussi aux niveaux de service les plus courants. Prenez une application, construite selon une approche n-tiers, déployée sans recours au PaaS. Il faudra installer et configurer tous les composants : la base de données, le serveur Web, le load balancer, etc. Cela représente des efforts considérables pour les équipes d'exploitation et un coût important de maintenance sur la durée. De plus, la pile de technologies utilisée lors du développement ne correspond généralement pas exactement à celle utilisée par les équipes d'exploitation. Ceci peut créer les conditions d'un incident de production impossible à reproduire sur les environnements de développement. Le PaaS fournit des services aux applications et permet de se focaliser sur la construction de solutions répondant aux problématiques métier plutôt que sur la mise au point de techniques d'exécution et de déploiement. Le PaaS gère le déploiement et s'assure que l'application satisfait les niveaux de service prédéterminés en production.

Dan : Formuler les choses de cette manière est un peu trompeur. Si tout ce qui vous intéresse est d'héberger des composants applicatifs, alors, comme vous l'avez dit, vous avez de nombreuses options. J'en conviens, le PaaS est plus adapté que la plupart des environnements d'entreprise car il crée un modèle d'interaction partagé par les équipes de développement et les équipes de production. Mais je pense que c'est une partie minime de la valeur d'une plate-forme.

Je ne vais pas m'adresser ici aux architectes Cloud (dans l'ancien sens du terme) ni chercher à parler des niveaux d'abstraction à utiliser et de ce genre de choses. Je vous propose plutôt de vous focaliser sur la façon dont le PaaS rend possible et bénéficie de l'existence d'un écosystème de services qu'il est difficile d'obtenir avec des conteneurs automatisés de solutions. Une plate-forme efficace permet de consommer de façon transparente des services d'entreprise tels que l'authentification, l'autorisation, le map/reduce, etc. Les meilleures de ces plate-formes le font en utilisant le principe d'inversion de contrôle, "ne nous appelez pas, nous vous appellerons". On peut trouver cela actuellement avec le service binding de CloudFoundry, les plugin cartridges de OpenShift et les add-ons d'Apprenda et Heroku.

Pour aller encore plus loin, ce que je vois comme étant le vrai futur du PaaS est dans la capacité d'injecter des fonctionnalités directement dans l'application, soit pour mettre à disposition des fonctions additionnelles (comme le fait Apprenda pour la gestion du multi-tenant), soit pour instrumenter les applications et leur ajouter des fonctions d'administration (voir la théorie du PaaS de William Louth). Mais je m'éloigne de la question.

James : La question révèle la fausse idée que se font les développeurs (et d'autres) au sujet de la façon de consommer les services Cloud. La question n'est pas de consommer une certaine catégorie de services de façon exclusive. Il s'agit plutôt de trouver la meilleure façon de combiner les services (et autres logiciels) disponibles via le Cloud. C'est pourquoi je pense que le modèle ultime qui intéressera les développeurs correspond bien à ce qu'exprime le terme "Services as a Platform", utilisé par Lew Tucker de Cisco et d'autres.

Le "Services as a Platform" évacue le SaaS, le PaaS et le IaaS de la perspective des développeurs et se focalise beaucoup plus sur le "quoi consommer", plutôt que sur le "comment consommer". Le Services as a Platform porte l'idée que le PaaS composable l'emporte sur le PaaS contextuel (voir ici) et que "SaaS, PaaS et IaaS" font simplement référence à différentes façons de consommer qui se chevauchent souvent.

Y a-t-il un intérêt à ce que le PaaS soit capable d'automatiser la scalabilité et la disponibilité d'un maximum d'applications en ligne de différents types ? Oui, bien sûr ! Seulement, AWS et les autres ajoutent tous les jours de nouvelles fonctions qui brouillent les limites entre le Framework qui se veut complet et l'option du IaaS entièrement auto-composé.

Finalement, le PaaS a toujours couvert un spectre allant du pur IaaS (avec de l'outillage pour le développeur) à l'extension ciblée du SaaS et autres modèles spécifiques à certains contextes. Le besoin d'identifier le PaaS comme une "catégorie à part entière" lui donne moins de valeur que celle qu'il apporte en réalité, dans le contexte plus large du Cloud, en tant qu'interface de consommation des services, une parmi d'autres (bien qu'importante).

InfoQ : Est-ce que l'idée (et la réalité) du PaaS a évolué depuis les débuts d'Heroku et de Google App Engine ? Si oui, pourquoi et comment ?

Krish : Oui, elle a évolué depuis les premiers temps. Au début, le PaaS s'attachait à apporter des solutions au problème du scaling, avec les services hébergés. La plupart des plate-formes de l'époque étaient orchestrées en utilisant divers services au-dessus d'une "compute fabric". Pour scaler de façon efficace, les premières offres PaaS imposaient des contraintes à l'architecture des applications. Les développeurs y ont trouvé de l'intérêt mais les entreprises étaient plus réticentes, à cause de ces restrictions imposées par les fournisseurs de PaaS. Avec les offres PaaS mieux taillées pour l'entreprise, nous avons vu une évolution : on s'est éloigné du focus sur le scaling pour se refocaliser sur la productivité de développement, avec moins de restrictions. Nous avons aussi vu quelques plate-formes open source utiliser le modèle conteneur, qui est important pour la portabilité des applications.

JP : Le PaaS a évolué de façon considérable en tant que concept et en tant qu'outil depuis les premiers temps de Heroku et GAE. Je qualifierais ces derniers plus de Frameworks que de PaaS. Aujourd'hui, les plate-formes PaaS offrent beaucoup plus de contrôle sur la scalabilité et offrent la capacité d'incorporer de nouveaux services. Il y a énormément d'instrumentation sur ces plate-formes, pour faciliter l'accès à certains niveaux de service. Cependant, le concept a clairement bifurqué avec l'avènement des PaaS privés et publics. Les PaaS privés mettent l'accent sur l'expérience proposée aux développeurs pour livrer leurs applications entre les mains des opérations IT. Les PaaS publics s'attachent à permettre au développeur d'exploiter et de gérer ses applications en production.

James : Au départ, les offres PaaS ont essayé de se faire partie intégrante de l'expérience de développement, en fournissant des constructions déterminées pour les services clés, sur un mode "à prendre ou à laisser". Il est vite devenu clair, cependant, qu'un tel mode ne pouvait pas fonctionner sur le marché du développement web plus global et les premiers fournisseurs de PaaS ont rapidement changé de fusil d'épaule en acceptant plus de services, de langages de programmation et d'options de développement en général.

Ce qui est essentiel, c'est que le PaaS moderne est plus lié à l'automatisation de l'exploitation qu'aux abstractions de développement. La façon de s'interfacer à des services est standardisée, mais plus de la perspective de la connectivité et de l'exploitation que de celle dictant comment les utiliser. Les écosystèmes de Cloud Foundry et Heroku sont la preuve qu'ouvrir la porte sur un modèle hautement composable mettant en avant l'automatisation de l'exploitation ouvre des champs d'application à un très large éventail de modèles applicatifs.

Finalement, à mon avis, les lignes séparant les types d'automatisation proposés par les outils IaaS les plus avancés (c'est-à-dire AWS, Azure et GCE) et les offres "pures PaaS" vont se brouiller, si bien que les standards des interfaces de services vont commencer à apparaitre. La valeur ajoutée des plate-formes PaaS sera liée à la cohérence des interfaces et des formats, ce qui ouvrira grand les portes à un marketplace couvrant de multiples fournisseurs. Alors, nous arrêterons de parler de PaaS vs. IaaS et commencerons à parler de ce que tout cela nous a permis de faire.

Dan : Au début, le PaaS était essentiellement de l'hébergement au niveau applicatif ciblant les développeurs ou les petits éditeurs. Au lieu d'acheter des serveurs à une société d'hébergement et configurer une pile LAMP vous-mêmes, vous louiez des ressources de "compute" à votre fournisseur PaaS et vous vous conformiez à ses contraintes de conception et ses règles de déploiement. Vraiment, la killer feature de cette époque était le déploiement à base de Git. Et ce n'était pas seulement une feature vraiment cool, elle raccourcissait en plus le temps de développement, elle jouait un rôle dans la proposition de valeur du PaaS : "nous rendons la vie plus facile aux développeurs".

Aujourd'hui, le terme PaaS a été détourné par les marketeux zélés et les gens des opérations IT. Je plaisante bien sûr, mais il y a peut-être un fond de vérité. Une des raisons pour lesquelles nous tenons cette discussion est qu'à peu près tout ce qui concerne l'automatisation des déploiements et la scalabilité est maintenant appelé PaaS. Ainsi, nous avons vu un vaste spectre de capacités condensé en une unique catégorie.

Je pense que nous allons nous accorder plus finement sur la terminologie dans les 18 mois à venir ou quelque chose comme ça, en commençant par admettre que les fournisseurs comme Azure, Google Compute, Verizon et autres ne sont pas des fournisseurs de IaaS ou de PaaS, mais plutôt des fournisseurs de ressources qui offrent de multiples moyens de consommation. À partir de là, nous assisterons à un intérêt renouvelé pour la mise en œuvre d'un modèle de service tel que mentionné dans ma réponse précédente. Ainsi que, probablement, à l'apparition d'un nouveau buzzword.

InfoQ : Ces descriptions du PaaS sont excellentes mais semblent toujours, quelque part, ambitieuses. Est-ce que la majorité des produits PaaS commerciaux (publics) actuels n'offrent pas plus simplement un ensemble de services Web et applicatifs et des outils de déploiement et d'administration au-dessus d'une "fabric", et non pas les "environnements sans contraintes" décrits par Krish ou les modèles "d'automatisation plutôt qu'abstraction de développement" évoqués par James ? Où percevez-vous aujourd'hui ce mouvement vers ce "Service as a Platform" idéal qui transcenderait les contraintes du PaaS classique ?

Dan : Je pense que cette vision existe en partie chez tous les fournisseurs PaaS traditionnels depuis un certain temps maintenant. J'ai mentionné les modèles d'add-on proposés par quelques fournisseurs dans une réponse précédente. Toute la philosophie d'Apprenda est construite autour d'une intégration profonde avec l'application hôte. Azure offre un ensemble de services, comme un ESB, une authentification multi-factor, etc. Buildpacks et cartridges sont surtout utilisés pour empaqueter des environnements d'exécution spécifiques ou des plugins à l'heure actuelle mais ceux-ci ouvrent la porte à une composition d'applications plus robuste. Je pourrais continuer en ce sens.

Donc pourquoi est-ce que le marché semble se concentrer sur l'hébergement d'application et l'administration ? En partie parce qu'il est encore tôt et que l'administration des applications est un premier pas nécessaire vers l'existence d'une plate-forme. En partie parce que ces capacités sont le point commun entre toutes ces options qui se proclament elles-mêmes plate-formes (sans se demander si elles offrent le bon niveau d'abstraction au sens de Simon Wardley). Et en partie parce que les fournisseurs eux-mêmes évoluent aussi. Personne n'a une solution complète aujourd'hui et je ne suggèrerais même pas que nous soyons capables de dire à quoi une solution complète devrait ressembler. Prenez la conversation que nous tenons en ce moment. Nous avons des philosophies similaires, particulièrement par rapport au grand public ; pourtant nous imaginons tous des finalités un peu différentes et, je suppose, des chemins très différents pour y arriver.

Les usages gagnant en maturité, les plate-formes évoluant et de plus en plus de personnes voyant l'IT comme un système, plutôt que comme un paquet d'applications disparates, je pense que les autres aspects du PaaS deviendront plus apparents. Il y a vraiment des entreprises qui exploitent déjà ces aspects (prenez Netflix) mais une grande part de leurs technologies sont faites maison. Ce qui est excellent, mais qui ne se diffuse pas très bien. Les applications, comme les systèmes business et le PaaS devraient aller vers le mainstream d'un même pas.

Krish : Je suis d'accord avec Dan. Nous en sommes encore au début de l'adoption du PaaS et il s'adaptera en même temps que l'utilisation augmentera. La principale raison pour laquelle le PaaS est encore vu comme une extension du hosting vient des premiers succès des services PaaS hébergés, qui étaient plus taillés pour répondre aux besoins des applications web à destination de clients qu'à ceux de plateformes faites pour "repenser l'IT".

Tout cela est en train de changer avec les entreprises de plus en plus nombreuses qui embrassent les offres de "PaaS moderne", elles réalisent que le PaaS leur offre une chance de repenser complètement l'IT et de se transformer pour répondre aux challenges modernes. Dans ce contexte, j'apprécie l'idée de Jonathan Murray d'Entreprise Composable et je pense qu'il a une bonne prescription pour les entreprises modernes quant à la voie à suivre pour construire leur plateforme IT. Nous voyons de plus en plus d'organisations qui adoptent cette approche. Les plate-formes avec une architecture ouverte aideront les entreprises à construire de tels systèmes IT robustes et flexibles.

Le changement en entreprise prend du temps et les fournisseurs de PaaS n'ont pas fait un bon travail pour faire en sorte que leurs offres puissent être utilisées pour construire ces plate-formes IT modernes. Mais le vent tourne rapidement et les entreprises réalisent qu'elles vont passer notamment à côté des bénéfices de big data si elles ne transforment pas leur approche de l'IT.

Les vendeurs PaaS doivent envoyer des signaux clairs aux entreprises. L'IT moderne a besoin d'une automatisation à grande échelle mais cela peut être fait plus efficacement avec des abstractions de plus haut niveau. En plus, les vendeurs de PaaS doivent faire un bon travail pour expliquer aux équipes IT que les abstractions appliquées aux plus hautes couches de la pile technologique réduisent la possibilité d'erreurs.

JP : Votre question soulève une question alternative : avons-nous besoin de prendre en considération le PaaS public et le PaaS privé séparément ? En fin de compte, ils pourraient partager un modèle cohérent mais le PaaS privé met en avant un degré de distinction plus élevé entre équipes d'exploitation et équipes de développement. Le PaaS public est correctement conçu pour les équipes qui conçoivent des applications Cloud et qui seront certainement responsables de l'administration et de l'exploitation de ces applications une fois en production. Ainsi, je ne considèrerais pas les premières de ces descriptions comme ambitieuses. Mais je comprends qu'on puisse ne pas trouver toutes ces fonctionnalités dans une offre de Cloud public.

InfoQ : JP met en avant la distinction entre le PaaS privé et le PaaS public. Pensez-vous que leurs caractéristiques doivent être différentes ou que l'un présente des capacités plus importantes que l'autre ?

JP : D'abord, le PaaS privé doit pouvoir être supporté par les équipes d'exploitation IT. Rien que cela introduit tout un ensemble de besoins pour l'administration, le monitoring et la configuration qui sont pris en charge par les fournisseurs de PaaS, en tant qu'éléments de leurs offres. En plus, comme je le disais dans ma réponse précédente, je pense que l'outillage est différent. Dans un PaaS privé, je m'attends à ce que l'outillage supporte un processus collaboratif DevOps, entre le développement applicatif et les opérations IT. Le PaaS public, lui, peut concentrer son outillage sur le support et la simplification des processus de déploiement et d'administration des applications pour le développeur.

Dan : La distinction importante à faire n'est pas entre le privé et le public. Elle est plutôt entre middleware et service opérationnel. Les capacités de la plate-forme devraient être entièrement séparées des services d'exécution sur lesquelles elles reposent. Ceci permet une expérience applicative cohérente, quelle que soit la forme de mise à disposition du service, que cela soit depuis une installation physique, une installation virtualisée, depuis un Cloud hybride ou complètement public. Le choix d'une plate-forme applicative ne devrait pas dicter le résultat de ce qui devrait être une décision totalement décorrélée.

Évidemment, une société prendra sa décision en fonction de ce qu'elle prévoit quant à l'exploitation de la plate-forme, si elle prévoit de le faire elle-même ou pas. À ce moment-là, les aspects tels que l'administration des machines et autres fonctions de gestion prennent une part importante en tant que critères d'évaluation, critères qui auraient pu être ignorés sans cela. Mais ceci n'élimine pas la nécessité d'administrer la plate-forme. Cela change uniquement qui en est le responsable. Du point de vue du vendeur de la plate-forme, qu'un fournisseur de service interne ou externe remplisse la fonction ne devrait pas avoir d'importance.

Si les premiers vendeurs de PaaS n'avaient pas essayé de proposer à la fois le software et l'environnement d'exploitation sous-jacent, à mon avis, le marché n'aurait pas de lui-même réclamé d'avoir les deux, fortement liés l'un à l'autre. Le fait que nous continuions à confondre les deux domaines de responsabilités est un héritage malencontreux, pas une fonctionnalité.

Kirsh : Je suis du même avis que Dan. Le sujet n'est pas Cloud privé ou Cloud public. Un PaaS moderne bien architecturé peut offrir une même expérience que cela soit sur une offre publique ou sur une offre privée (hébergée à demeure). Aux premiers jours du PaaS, lorsqu'il n'y avait que les offres hébergées de Google App Engine et Heroku, il y avait quelques limitations sur la conception des applications afin d'obtenir une efficacité opérationnelle à grande échelle. Mais cela a changé avec les offres PaaS ciblant les entreprises. Qu'on l'aime ou pas, le Cloud hybride va être une réalité à un moment donné. Les offres PaaS modernes essaient de combler la distinction entre le PaaS public et le PaaS privé afin que les organisations puissent tirer avantage des deux versions, à demeure et hébergées.

Dans ce contexte, je voudrais parler de Docker. Avec la prolifération des conteneurs, que cela soit ceux de Docker ou d'autres, la distinction entre privé et public va disparaitre complètement. Non seulement nous pouvons avoir des environnements comparables dans les deux versions, mais nous pouvons aussi porter les applications de façon transparente entre les PaaS publics et privés. Dans certains cas, on peut même être capables d'effectuer ce portage entre différentes plate-formes, à partir du moment où elles se conforment à certains modèles de conteneurs.

InfoQ : Le PaaS semble être mis en avant dans le cadre d'autres concepts d'actualité comme les conteneurs et le DevOps. Comment voyez-vous l'intersection de ces idées ?

Krish : Pour moi, c'est plutôt simple. Le PaaS est ce qui rend possible DevOps. Les conteneurs sont les composants standardisés sous-jacents (pour certaines offres PaaS).

Dan : Je pense que les concepts que vous mentionnez conduisent vers les mêmes objectifs. Nous essayons d'améliorer la mise à disposition de services métier. DevOps est une approche qui recommande certains types de processus sans nécessairement imposer la façon dont ils sont implémentés. Les conteneurs et le PaaS s'assemblent bien dans le domaine du DevOps, en particulier lorsqu'on essaie d'appliquer les concepts DevOps chez un éditeur qui fonctionne en silo (ce qui est plus facile à dire qu'à faire).

Les conteneurs présentent quelques capacités intéressantes, à savoir la portabilité et l'isolation des applications, qui peuvent répondre aux besoins de beaucoup d'entreprises. C'est juste un sous-ensemble de ce qu'une plate-forme devrait proposer. Et, comme Krish l'a dit, les fournisseurs de PaaS devraient considérer les technologies de conteneurs pour atteindre ces objectifs.

Le PaaS est une solution plus complète, et le PaaS privé en particulier peut encourager les valeurs DevOps là où les entreprises peuvent ne pas être structurées pour l'application d'une démarche DevOps pure. Dans ces cas, la plate-forme peut représenter la lingua franca réunissant les développeurs et les équipes d'exploitation pour chercher la plus optimale des qualités de livraison.

JP : Sur mon blog, dans l'article "Without a Strong PaaS, ITaaS, DevOps & IaaS Fall Short", j'établis une forte association en montrant l'utilisation du PaaS comme un canal de mise à disposition d'une plate-forme partagée entre les opérations et le développement qui forme le pipeline DevOps, conception, build, test et finalisation (dé-commissionnement). Finalement, Le PaaS est simplement un outil et comme tous les outils, le secret réside dans le fait de savoir comment l'utiliser pour obtenir le résultat désiré. Avoir un environnement de production configuré différemment de l'environnement de développement a été pendant longtemps une des causes de mauvaise qualité, de coupures de services et de coûts trop élevés. Le PaaS propose à l'IT un recentrage sur les applications, ce qui permet aux domaines métier non liés à l'IT d'être agiles et efficaces. Il permet aux Ops de se focaliser sur la conception et la mise à disposition de services supportant le PaaS et permet aux équipes de développement applicatif de se focaliser sur les besoins métier. De même pour les conteneurs, ce sont des outils fantastiques pour atteindre ce même but, car ils offrent l'isolation des processus et des données et permettent ainsi une mise à disposition facilitée des scénarios de développement et de test.

Au sujet des interviewés

JP Morgenthal peut être qualifié de "voix de l'IT d'entreprise", il donne sa vision de l'application des technologies et de la complexité du delivery dans les entreprises, de taille importante et moyenne. Senior dans le domaine des technologies de l'information, avec plus de 25 ans d'expérience dans l'analyse du marché et des technologies, JP est une tête pensante et Auteur reconnu du Cloud Computing et de l'intégration.

James Urquhart est Directeur de produit pour Dell Cloud Manager (anciennement Enstratius), environnement précurseur de gestion multi-Cloud. Ingénieur des systèmes distribués de longue date et focalisé sur les architectures virtuelles scalables ainsi que sur le Cloud Computing, James a été nommé expert du Cloud par la MIT Technology Review, NextWeb et The Huffington Post. James écrit fréquemment pour GigaOm au sujet des tendances du Cloud et des systèmes distribués.

Dan Turkenkopf (@dturkenk) est actuellement Analyste Développeur front Office chez Tampa Bay Rays. Avant d'avoir trouvé le boulot de ses rêves avec une équipe de baseball, il a travaillé chez Apprendra, CGI et IBM en tant qu'Architecte Cloud et applicatif. Il habite à Saratoga Springs, NY, avec sa femme et ses jumeaux de 4 ans. Il passe ses rares moments libres à lire au sujet de la complexité des systèmes, la programmation et apprécie la bière artisanale, pas nécessairement dans cet ordre.

Krish Subramanian est actuellement Directeur de l'OpenShift Strategy chez Red Hat. Il y travaille avec l'équipe OpenShift pour atteindre l'objectif de devenir une offre PaaS majeure. Avant cela, Krish était Analyste de l'industrie et Créateur de Rishidot Research. Il s'intéresse particulièrement aux plate-formes de services, à big data et à l'open source.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT