Vos applications en trois étapes avec MultiPaaS

Dominic Clairac est leader au sein de la communauté sud-ouest de onepoint et accompagne les entreprises dans leur stratégie DevOps et leur digitalisation. Expert certifié sur la plateforme OpenShift, il est à l’origine de MultiPaaS et nous en dit plus sur ce projet.

Comment vous est venue l’idée de MultiPaaS ?

Nous travaillons aux cotés de RedHat depuis plusieurs années afin de mettre en place chez nos clients communs des plateformes OpenShift. Cela nous a permis de mesurer l’importance de la conduite du changement dans la mise en place de ces plateformes qui créent une rupture importante dans la manière de développer, de déployer, voire d’aborder les projets.

Beaucoup d’entreprises pensent atteindre le DevOps par la mise en place d’outils technologiques et terminent finalement avec une plateforme de déploiement continue peu adaptée à leurs besoins. Nous avons remarqué que les entreprises qui mettaient en place des plateformes d’orchestration de containerisation (OpenShift, Kubernetes…) en dehors d’une démarche de transformation, se retrouvaient avec un outil techniquement complexe à utiliser, et avaient tendance à le sous-utiliser. Forts de ce constat, nous avons voulu trouver une solution pour offrir une manière simple d’utiliser efficacement ces plateformes, en prenant également en considération les problématiques du cloud hybride.

Nous nous sommes lancés dans la réalisation d’un démonstrateur afin de trouver l’architecture la plus appropriée pour répondre à ce besoin et identifier les challenges techniques qu’il nous faudrait relever. Nous avons fait le choix d’intégrer dès le début la contrainte d’une chaîne de développement et de déploiement qui serait étalée sur plusieurs plateformes, peu importe leur localisation (Cloud, on premise…). Les conteneurs sont nativement faciles à déplacer d’une plateforme à l’autre, dès lors qu’ils ne portent pas de données, ce qui offre de nouvelles possibilités pour les entreprises qui choisissent d’évoluer vers ce mode de déploiement.

Lors du développement du démonstrateur, nous avons remarqué que la solution pouvait aussi répondre à d’autres besoins, tels que la capacité à homogénéiser des développements d’une entreprise, ceux sous-traités et à automatiser leur livraison. Le démonstrateur a été présenté lors du RedHat Forum de Paris en 2017 puis au Cloud Expo Europe dans la foulée. Les retours ont été très positifs et plusieurs clients nous ont demandé de les aider à mettre en place un outil similaire dans leur SI. Mais il y a un pas entre un démonstrateur et une application fiable, que nous avons décidé de franchir en 2018. Nous avons pris le temps de bien identifier, comprendre et prioriser les attentes de nos clients avant de mettre en place une équipe projet et de se lancer dans l’aventure.

Pouvez-vous nous expliquer ce projet?

MultiPaaS propose de créer facilement et rapidement des chaînes de développement, comprenant les environnements et les outils nécessaires au développement, aux tests et à la mise en production des applications.

Il faut voir MultiPaaS comme un catalogue de services destiné aux chefs de projets. A l’inverse des catalogues classiques qui proposent de déployer un conteneur, MultiPaaS crée l’ensemble des environnements nécessaires pour passer de l’idée au déploiement de l’application en occultant les tâches techniques et répétitives (création, gestion des droits, paramétrages des triggers …).

La création d’un nouveau projet se fait en 3 étapes :

1. L’utilisateur sélectionne le « quickstart » du projet et renseigne les informations de base (nom du projet, description …). Un quickstart correspond à un code source exemple, type « hello world », basé sur les règles et bonnes pratiques de l’entreprise. Il est enrichi de métadonnées indiquant les modalités de build et de déploiement dans la plateforme cible.
2. L’utilisateur sélectionne un workflow de déploiement. Un workflow est une description des différents environnements à créer (Dev, QA, PProd, Prod), de l’ordre dans lequel les traverser, ainsi que des règles pour passer de l’un à l’autre. Ces workflows sont également adaptables et il est possible de sélectionner un workflow vide afin d’en créer un de toute pièce par la suite.
3. L’utilisateur peut ensuite sélectionner la plateforme PaaS pour chacun des environnements du workflow sélectionné. Une plateforme PaaS est une plateforme OpenShift, peu importe son emplacement d’installation (on premise, Cloud hybride, hébergeur…).

L’application va créer les différents environnements dans les plateformes PaaS sélectionnées et préparer le repository GitHub avec l’exemple de code présent dans le quickstart. L’opération de build (création d’une image à partir du code source) est également mise en place et se retrouve abonnée à un évènement, comme par exemple la modification du code source.

En quelques minutes, les environnements et toute la mécanique de développement sont mis en place et livrés aux développeurs. Une simple modification du code source suffit à lancer un build et à le déployer dans le nouvel environnement. L’application pourra ensuite passer d’un environnement à l’autre jusqu’à la production, sans faire de distinction sur la localisation de l’environnement (Cloud ou hors Cloud).

Le point important à retenir, c’est que la mise en place de l’usine logicielle se compte en minutes, là où il est souvent questions de jours.

Que se passe-t-il en cas de panne de MultiPaaS ?

Il est important de bien comprendre que MultiPaaS n’héberge pas de projet ou d’application. Nous ne faisons qu’utiliser les API mises à disposition par OpenShift et GitHub, pour automatiser toutes les tâches techniques et rébarbatives de la création et du paramétrage d’un projet. Une fois la mécanique en place, le projet est hébergé par les plateformes OpenShift sur lesquelles il est déployé et le code est stocké dans GitHub. Une panne de MultiPaaS serait sans effet sur le bon fonctionnement des développements et de la production.

Le seul impact serait l’incapacité à générer de nouveaux projets via MultiPaaS, bien que dans ce cas précis, il soit toujours possible de réaliser manuellement les différentes étapes de création. Cela prendra juste plus de temps et nécessitera un technicien disposant de bonnes connaissances OpenShift.

Qui sont vos partenaires ?

Nous sommes partenaires de RedHat depuis près de 10 ans et travaillons avec eux à la mise en place de plateformes OpenShift depuis plusieurs années. Nous avons une grande confiance dans le produit et ses capacités, qui vont bien au-delà d’une simple plateforme d’orchestration de conteneurs.

Notre partenariat avec GitHub est plus récent, mais ils n’ont plus grand-chose à prouver sur leur capacité à héberger des repository git. L’installation de la version on premise est très simple et son exploitation encore plus. GitHub offre de plus une série d’outils puissants, que nous n’utilisons pas forcément pour le moment pour MultiPaaS, mais qui peuvent s’avérer très intéressants pour gérer les développements en dehors de notre application.

Nous avons fait le choix de faire confiance à des acteurs reconnus du marché.

Quelles sont les prochaines étapes ?

Après le démonstrateur, nous avons dû attendre un moment afin de prendre un peu de recul sur ce qui avait été fait et surtout pour comprendre ce qui intéressait les clients sur le démonstrateur. Nous avons aussi profité de notre Centre de services pour identifier les attentes des projets en termes de création rapide d’environnements de développement.

Le projet a ensuite été lancé sur notre plateforme d’incubation Pier 39 et les développements ont pu commencer. Nous avons choisi une approche MVP[1] qui nous permet d’avoir rapidement des résultats présentables et nous venons d’atteindre le premier niveau de viabilité de l’application. Nous sommes en train de regarder pour son déploiement au sein du Centre de services de onepoint dans le sud-ouest (Bordeaux/Toulouse), sur des projets pilotes qui seraient éligibles. Nous recherchons également des clients qui souhaiteraient êtres pilotes. L’objectif est de récupérer les premiers retours et de les ajouter aux idées d’améliorations que nous avons déjà, et de travailler ensemble à la priorisation des nouvelles fonctionnalités.

[1] MVP : Minimum Viable Product – Stratégie de développement qui consiste a prioriser les fonctionnalités vitales au fonctionnement du produit afin d’accélérer sa mise sur le marché. Les fonctionnalités d’amélioration sont ensuite ajoutées au fil de l’eau.