Les Paas changent de braquet avec l’émergence des conteneurs
Les Paas se sont adaptés à la tendance des conteneurs, avec des outils d’orchestration et de gestion. Ce qui évidemment séduit une nouvelle génération d’opérationnels.
Les couches d’abstractions offertes par les conteneurs constituent une nouvelle alternative en matière d’automatisation d’infrastructure aux Iaas relativement peu intelligents et aux offres de Paas très établis. Les entreprises mordent-elles pour autant à l’hameçon ?
Les offres de Paas, comme celles d’Heroku, de Red Hat avec OpenShift et Cloud Foundry, ont depuis longtemps intégrés les conteneurs – ou une segmentation des workloads -, présentant cela comme une unité d’exécution. Les conteneurs permettent en effet un partage minutieux de l’infrastructure tout en conservant une séparation des workloads.
Les conteneurs passant en production, ils sont de plus en plus déployés sur des clusters de serveurs, dont l’infrastructure a été conçue pour leur orchestration, leur automatisation, ainsi que leur suppression et re-création.
C’est encore le cas pour les Paas les plus récents, mais l’engouement récent pour les conteneurs a changé le discours : Il ne s’agit plus uniquement de savoir comment les conteneurs segmentent les workloads, mais comment ils sont gérés à grande échelle. Le besoin de gérer de grandes quantités de petits objets – imposant ainsi l’orchestration de conteneurs - est désormais clé, comme le montrent Tectonic chez CoreOS, Apache Mesos et Kubernetes.
Ces outils de gestion de clusters apportent de nouvelles fonctions d’automatisation et libèrent les DSI des procédures manuelles. Cela conserve un des principes du Paas, tout en permettant un contrôle direct plus abouti sur l’infrastructure que les Paas traditionnels – où l’abstraction y est plus forte.
Nouveaux Paas pour nouveaux profils
Toutefois, les développeurs sont loin d’écarter de leur chemin les Paas traditionnels. Au lieu de cela, cette nouvelle approche a séduit une génération d’opérationnels qui doivent composer avec des infrastructures capables de supporter des architectures modernes. Celles-ci nécessitent un niveau d’automatisation qui ne peut pas être atteint avec des Iaas traditionnels.
« Ceux qui utilisent ces technologies sont, dans une certaine mesure, différents de ceux ciblés avec les Paas classiques et leur niveau d’abstraction », indique Marco Hochstrasser, en charge du développement Cloud, chez Swisscom, un fournisseur de Paas qui a récemment intégré le support de Docker.
« Cela ne fait aucune différence pour moi en ce qui concerne la technologie, soutient-il. Mais Docker connait une forte adoption et disposer d’un standard détend le marché et offre une fondation pour la création de valeur. »
La montée en puissance de Docker profite également aux Paas car cette nouvelle génération d’utilisateurs insuffle un vent nouveau à ce segment, même si elle en modifie la mécanique.
« Ils commencent à se fondre dans un seul concept », affirme de son côté Nirmal Mahta, Lead technologist, chez Booz Allen Hamilton, une société de conseil américaine qui travaille avec le secteur public sur DevOps.
« Le Paas a accéléré l’adoption de la conteneurisation, qui en retour a accéléré l’adoption du Paas », explique-t-il « Nous sommes au début d’une bataille entre toutes ces plateformes, avec pour thème central, l’orchestration de conteneurs. Le Paas est une forme de ciment de tous les composants nécessaire pour orchestrer les conteneurs. »
Les vieux singes apprennent de nouveaux tours
Pour les opérationnels novices en matière de microservices, les offres de Paas les plus récentes, comme Apcera, constituent une alternative pour gérer les infrastructures IT. Celle-ci ne nécessite pas de donner complètement les clés aux fournisseurs de services ou aux développeurs.
La configuration de ressources au rôle d’Apcera était différente que celle proposée par les autres Paas, souligne Juan Garcia, CTO de nextSource. « Sa capacité à bâtir des pipelines sémantiques, et de configurer des accès depuis nos applications vers des microservices sans avoir à comprendre les couches réseau est vraiment unique », ajoute-t-il.
La plupart des développeurs se moquent de savoir si les conteneurs s’exécutent sur l’infrastructure, au-dessus d’une couche Paas – le modèle d’infrastructure n’est pas leur problème. Mais pour les opérationnels IT, les plateformes d’orchestration de conteneurs proposent un moyen de convertir l’infrastructure traditionnelle sur laquelle s’adosse les applications, en un monde de microservices.
OpenShift (Red Hat), par exemple, propose dans son Paas des fonctions de delivery d’applications et d’intégration continue que les orchestrateurs de conteneurs, comme Kubernetes, n’ont pas. Il a plutôt intégré une cartouche dédiée à l’orchestration de conteneur pour offrir un Kubernetes configurable par l’utilisateur.
OpenShift offre le meilleur des deux mondes traditionnels, Iaas et Paas, selon Dietmar Fauser, vice-président de l’architecture, de la qualité et de la gouvernance pour Amadeus IT Group, la division IT du spécialiste du voyage.
« Cela nous a donné le moyen de rester coller aux applications en place sans trop les changer ni les re-écrire en Java. Et ce avec un investissement raisonnable. »
Que reste-t-il aux Paas traditionnels ?
Il existe certes encore des arguments en faveur des Paas traditionnels, l’un d’eux étant que l’orchestration de conteneurs est une chose toute nouvelle et plus compliquée à mettre en place qu’à acheter une offre de Paas dans le Cloud.
« Les grands entreprises aiment les standards à cause de la conformité en termes de sécurité et de régulation », affirme Josh McKenty, CTO pour Cloud Foundry chez Pivotal. « Elles aiment savoir qu’elles n’ont q’uun unique moyen de se logguer et de s’identifier, et qu’elles disposent d’options SQL et NoSQL, mais pas de toutes les options de la terre. »
La direction que prendront les entreprises n’est pas encore claire, soutient à son tour Mitchell Hashimoto, fondateur de HashiCorp, qui développe la plateforme Nomad. « Nous ne constatons pas encore de cas d’usage d’orchestrateur en production, même si l’intérêt est là. La plupart des entreprises ayant poussé cela en production sont des entreprises de pointe, de la Silicon Valley. Les plus traditionnelles en sont encore à tester et vérifier la technologie.
Les entreprises comme Amadeus qui se sont lancées dans Kubernetes dès la version 1.0 ont essuyé les plâtres. « Les modifications de code sont nombreuses, vous devez toujours les accepter ou les rejeter, parfois les APIs changent, ce qui est dérangeant », explique le responsable d’Amadeus. « On ne voit généralement pas ça chez Red Hat qui est très axé sur la stabilité. »
Trouver l’équilibre
Pourtant, Josh McKenty reconnait que Cloud Foundry a modifié son approche pour proposer, dans des dernières versions, plus de flexibilité. Cloud Foundry devrait proposer une API, Route Services API, dans sa prochaine version, pour connecter des gateways tierces.
C’est aussi vrai pour Heroku, un pionnier sur ce segment, affirme Alex Gross, senior vice-président chez Salesforce, qui a racheté Heroku en 2010. L’année dernière par exemple, Heroku a présenté Private Spaces, qui propose un Paas privé sur la technologie Virtual Private Cloud d’AWS.
Heroku supporte désormais Docker. « Si vous souhaitez descendre de niveau et plonger plus bas dans le stack, nous pouvons vous le proposer », explique Alex Gross.
Cela ne veut pas dire qu’Heroku change pour autant ses habitudes. Développer un Paas avec de nouveaux frameworks d’orchestration de conteneurs est plus faisable qu’auparavant, mais cela n’est pas moins complexe, particulièrement en termes de disponibilité, de performances, soutient-il.
Traduit et adapté par la rédaction