Des offres PaaS de 1ères générations à faible maturité…

Les premières offres PaaS, lancées en 2010, constituaient une proposition souvent :

• Limitée, avec un nombre restreint de langages de programmation et d’environnements d’exécution supportés.

En exemple, les premières versions du PaaS Heroku (de SalesForce) supportaient uniquement le langage Ruby; le PaaS Cloudfoundry.com (de Pivotal) supportait uniquement les langages Java et  Ruby.

• Intrusive, avec une adaptation / réécriture de l’application presque systématique.

Nous pouvons prendre l’exemple d’Amazon qui propose le service SGBD (système de gestion de base de données) spécifique  SimpleDB ou Google qui propose le service propriétaire Google’s Big Table sans oublier leur moteur d’exécution propriétaire : « Google App Engine ».

• Verrouillée (lock-in éditeur), avec un manifeste désintérêt pour l’interopérabilité et la portabilité entre les différentes offres et une volonté des éditeurs d’imposer leurs propres standards.

… et ne couvrant que partiellement les besoins réels des entreprises

Les PaaS de 1ères générations offraient des services peu adaptés aux besoins complexes des entreprises. Au-delà des limitations techniques (citées précédemment), on a pu regretter que ces premiers PaaS :

• Proposent une offre de services incapables de répondre aux exigences et contraintes demandées respectivement par les études et la production et ce notamment en termes de SLAs (confidentialité des données, traçabilité, etc.)

• Impliquent une réversibilité complexe en cas de changement d’offres ou d’internalisation des applications (souvent d’ailleurs pas proposée par les fournisseurs de ces offres).

• Répartissent de manière floue les rôles et responsabilités entre le fournisseur de services et le client.

• Aient une présence limitée de support en France, pourtant nécessaire à l’accompagnement des projets.

Un repositionnement efficace des fournisseurs PaaS

Face au manque d’adhésion des PaaS de 1ères générations, de nouvelles offres ont émergé et un repositionnement a été opéré par les fournisseurs. La nouvelle génération s’aligne enfin avec les vraies attentes des entreprises. Les initiatives en cours s’orientent vers des offres :

• Polyglottes (multi langages) et multi-plate-formes

Salesforce a par exemple enrichi son offre Heroku par le support de nombreux langages (Ruby, PHP, JavaScript, Java), ou encore Cloudfoundry.org supporte maintenant plusieurs langages et frameworks de développements comme  Java, .Net, Ruby, PHP, Python, Scala.

• Spécialisées par cas d’utilisation

En exemple, Cloudbees propose deux offres complémentaires :

– Une offre destinée au développement, où l’unité de facturation est le nombre de build opéré.
– Une offre destinée à l’exécution, où l’unité de facturation est une configuration de la mémoire disponible pour l’application

• Sensibles aux normes et standards (en cours de spécification)

Plusieurs initiatives de standardisation sont en cours sur le périmètre PAAS. Nous pouvons noter en exemple : CAMP, TOSCA ou encore Cloud Foundry Core.

Un virage à prendre ?

Contrairement à une adoption généralisée des services SaaS (déjà utilisés en entreprise depuis une dizaine d’années) et facilitée pour les services IaaS (entreprises ayant généralement atteint un niveau de virtualisation assez poussé pour faciliter le passage vers le modèle IaaS), les entreprises optent pour une attitude prudente vis-à-vis des services PaaS, privilégiant une stratégie d’adoption à deux vitesses :

• Une adoption immédiate des offres PaaS pour des :

– Applications non cœur de métier ;
– Applications non pérennes (jetables) ;
– Prototypes ;
– Bacs à sable innovants.

L’idée est de favoriser des solutions non limitatives en termes de technologies.

• Une adoption après études d’opportunités, choix de solutions et prototypage pour les applications cœur de métier.

Références

Études : Net MediaEurope (Juin 2012),

Normes et standards

• CAMP – https://www.oasis-open.org/news/pr/camp-tc
• TOSCA – https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca
• CF Core – http://core.cloudfoundry.org/definition

Offres

• Heroku – https://www.heroku.com/
• Cloud Foundry – http://www.cloudfoundry.com/
• SimpleDB – http://aws.amazon.com/fr/simpledb/
• Google App Engine – https://appengine.google.com/
• Cloudbees –  http://www.cloudbees.com

Cet article Le PaaS, une solution d’avenir. Comment franchir le pas ? est apparu en premier sur RiskInsight.

D’après Fabrizzio Biscotti, Directeur de recherche chez Gartner « Le PaaS est l’endroit où la bataille entre les fournisseurs et les produits s’intensifie le plus ». Le marché du PaaS privé n’est pas exclu de cette bataille. Il fait face à une concurrence de plus en plus rude et une  évolution de plus en plus vite.

Pour mieux comprendre cette évolution, voyons quelle est la proposition des offreurs dans ce marché.

Un positionnement en surcouche des modèles traditionnels

Traditionnellement, un modèle PaaS offre un environnement complet de développement et d’exécution. Du côté du PaaS privé, les acteurs se positionnent sur le marché des « Fabric PaaS ». Il s’agit d’un outil de provisionnement d’environnements, constitués de composants logiciels et applicatifs packagés au préalable. Cet outil s’appuie ensuite sur les infrastructures existantes de l’entreprise, qu’elles soient physiques, virtuelles ou déjà dans le cloud. Les acteurs de ce marché sont très dynamiques, avec une offre qui évolue rapidement. On y retrouve aujourd’hui les acteurs de l’édition logicielle traditionnelle avec Tibco Silver et VMware vFabric, des acteurs de niche comme ActiveState Stackato et une offre open source avec Cloud Foundry, souche de plusieurs solutions commerciales.

Agilité, Scalabilité et Consolidation comme crédos

Les fonctionnalités de packaging intégrées à ces solutions permettent de définir des environnements « clés en main ». Ces environnements contiennent  un ensemble de composants applicatifs, conçus à partir d’une palette d’exécutables tels que Jboss, Websphere, Tomcat, Tibco… ainsi que d’autres logiciels non standards. Les déploiements sont ainsi standardisés, dans une optique d’optimisation des temps de création des environnements.

Ces outils gèrent également les performances des applications déployées. Ils adaptent ainsi la capacité mise à disposition aux pics et baisses de charge en rajoutant ou supprimant des ressources sur la base d’un jeu de règles prédéfini. Ils offrent également la possibilité de s’étendre vers un cloud public.

Le troisième apport est l’optimisation de l’usage des ressources. Les mêmes ressources pouvant être affectées à des applications de natures différentes, évitant ainsi les modes de fonctionnement en silo.

Une mise à disposition en 3 étapes

La mise à disposition des environnements passe généralement par trois étapes clés :

• Le packaging qui permet de concevoir la stack* applicative de l’environnement en définissant les différents composants logiciels nécessaires à l’exécution ;

• Le provisioning pour déployer une stack applicative sur une infrastructure à l’aide d’une interface graphique ;

• Le management pouradministrer les stacks déployées, récupérer des statistiques et  définir des règles de scalabilité automatique.

La Fabric PaaS : un outil adapté à vos besoins ?

Avant toute chose, il est nécessaire de mesurer l’adéquation de l’outil avec le besoin attendu. Comment ? Voici quelques critères qui sauront vous aider à prendre la bonne décision :

• L’évolutivité des environnements

Si vous êtes dans un contexte soumis à de fortes évolutions d’environnement, une Fabric PaaS permet de réduire le temps de déploiement et de limiter les interventions humaines.

• Le niveau de demande de création de nouveaux environnements

Une trop faible demande ne permettra pas d’amortir le coût de mise en œuvre par les gains dégagés

• Le niveau de standardisation des demandes

Plus les demandes sont normalisées / standardisées, plus il sera possible d’aller loin dans le packaging et donc réduire au maximum les interventions humaines

• La variation dans le temps du niveau d’exigence en performance et haute disponibilité 

Une Fabric Paas permettra de gérer les capacités de performance au fil de l’eau : assurer le service lorsque le niveau d’exigence est au plus haut tout comme libérer les ressources lorsque le niveau est bas. Plus ce genre de variation sera fréquent, plus l’outil fera preuve d’utilité.

Les promesses des fabric PaaS sont alléchantes. Pour autant il s’agit de produits très récents et demandant des investissements compliqués en période de pressions budgétaires ainsi que des évolutions organisationnelles. Leur avènement nous semble toutefois inéluctable mais à un rythme d’adoption bien plus lent que celui espéré par les fournisseurs.

*Stack : Ensemble de composants logiciels permettant de mettre en œuvre un environnement (exemple : un serveur web + un schéma de base de données)

[Article écrit en collaboration avec Alaa Jamal-Bennis]

Cet article La Fabric PaaS : cœur de la proposition de valeur du PaaS Privé est apparu en premier sur RiskInsight.