Lors de son événement Commit 2021, GitLab a vanté les mérites de sa Plateforme DevOps, un concept qui risque de se diffuser chez d’autres éditeurs dans les mois à venir.
Selon Sid Sijbrandij, PDG de GitLab, l’avènement de la Plateforme DevOps signerait la quatrième ère DevOps. Elle succéderait à trois phases précédentes imaginées par le dirigeant en s’inspirant des périodes de l’évolution individuelle conceptualisée par Jean Piaget, un psychologue suisse.
Cette théorie concerne quatre stades de la vie d’un enfant, de sa naissance à ses 16 ans, pour estimer son développement.
Sid Sijbrandij s’amuse à étendre cette notion à l’évolution de l’approche DevOps, née entre 2007 et 2008, il y a 14 ans déjà. Nous serions donc à l’adolescence de cette pratique, l’âge de sa formalisation.
Mais avant cela, nous serions passés par une application en silo du DevOps. « Dans cette première phase, chaque service ou équipe a construit ou acheté ses propres outils, de manière isolée, qu’il a optimisés pour ses propres objectifs exigus, sans coordination explicite avec les autres », juge le PDG. « L’environnement chaotique ralentit la collaboration et le partage des connaissances, voire les arrête complètement ».
La deuxième phase correspondrait à une ère fragmentée du DevOps, dans laquelle les équipes employaient les mêmes outils, mais les pipelines CI et CD n’étaient pas étroitement connectés. Dans la troisième phase, le DevOps DIY (Do It Yourself), les entreprises ont enfin une chaîne complète d’outils, mais en contrepartie elles doivent intégrer, déployer ces briques et les maintenir. « Pour de nombreuses organisations, le maintien de chaînes d’outils DevOps DIY nécessite des efforts importants, ce qui entraîne des coûts plus élevés, des cycles de développement plus lents et crée davantage de vulnérabilités », écrit Sid Sijbrandij dans un article de blog.
« Si vous combinez la planification agile, la gestion du code source, le CI/CD, l’approche GitOps, la sécurité et la surveillance, vous obtenez la Plateforme DevOps ».
Porte-parole Gitlab
Cette quatrième ère serait celle « de l’application unique avec une interface unique et un data store unifié ». « Si vous combinez la planification agile, la gestion du code source, le CI/CD, l’approche GitOps, la sécurité et la surveillance, vous obtenez la Plateforme DevOps », justifie un porte-parole de GitLab auprès du MagIT.
GitLab 14 et 14.1, les instruments de cette phase
Bien évidemment, GitLab aurait atteint cette quatrième ère du DevOps, étrangement similaire au concept de Lakehouse, défendu par Databricks dans un tout autre registre.
Selon l’éditeur, l’on trouverait des traces de cette vision au sein des dernières mises à jour, certes incrémentales, de GitLab, c’est-à-dire les moutures 14.0 et 14.1.
Dans GitLab 14, l’entreprise a d’abord misé sur une évolution graphique, notamment en revoyant la navigation dans certains sous-menus. GitLab ajoute les Epic Boards, des tableaux de bord pour gérer des epics – des collections d’issues associées – à la mode Kanban. Cette interface glisser-déposer doit « fluidifier la collaboration entre les développeurs », tout comme le Content Editor, un outil pour créer des interfaces « pour des éléments tels que les diagrammes, les contenus embarqués, la gestion des médias, etc. ». En clair, cette brique doit donner davantage d’options pour concevoir une documentation associée à un projet.
En outre, cette version introduit un registre pour les modules Terraform, des paquets autonomes de configurations qui sont gérés en groupe. Sur le papier, cela doit permettre de parcourir les collections de paquets nécessaires à un déploiement Infrastructure as code et de les mettre à jour plus simplement.
La version 14.1 poursuit cet effort avec l’introduction d’un dépôt pour publier et partager les Helm charts, à la manière des fichiers Terraform et de petits ajouts pour le Content Editor.
Pour les utilisateurs de Kubernetes, l’éditeur a revu dès la version 14.0 la manière de créer un projet de gestion de clusters. Là encore, un template désormais basé sur Helm v3 doit supporter des fonctions préconfigurées pour des applications comme Fluentd, Elastic, Prometheus, Hashicorp Vault, les objets Ingress ou encore AppArmor.
Par ailleurs, la mouture 14.1 annonce les prémisses d’un tunnel CI/CD qui connecte GitLab Runners avec un cluster Kubernetes afin d’éviter d’ouvrir un pare-feu pour faire communiquer GitLab et l’orchestrateur via un agent. Si la fonction « est prête pour la production », elle ne peut être administrée qu’au niveau d’un projet. Surtout, certaines de ses caractéristiques doivent encore évoluer.
La version 14.1 apporte également un moyen pour identifier les erreurs de code, permettre d’effectuer des validations externes de merge requests depuis un outil tiers, ou encore de lier les issues Jira avec des merge requests.
Une Plateforme DevOps faute de mieux, selon les critères de Gartner
« La plateforme DevOps permet de gérer l’ensemble de la chaîne de valeur de votre logiciel, de la planification à l’utilisation du logiciel par les utilisateurs. C’est un processus de bout en bout, du concept à la monétisation », renchérit le porte-parole.
Ce concept de chaîne de valeur émerge tout droit des têtes pensantes de Gartner. Le cabinet d’analystes a sa propre dénomination pour un concept similaire à la Plateforme DevOps : « Value Stream Delivery Platform ». Manjunath Bhat, analyste chez Gartner, expliquait ce concept lors de GitLab Commit. Cette plateforme émergerait de la nécessité de « maximiser les workflows », « réduire les activités sans valeur ajoutée » et « minimiser le time-to-value ». Elle comprendrait des notions « de planification agile, d’orchestration des livraisons, d’automatisation de l’infrastructure, d’administration des artefacts, de la CI et de la sécurité ». L’on note ici quelques variations entre la plateforme de livraison de valeurs en continu de Gartner et la Plateforme DevOps de GitLab.
« Au demeurant, je dois mentionner qu’aucun éditeur ne satisfait pleinement les capacités que je viens de décrire ».
Manjunath BathVP, Analyste, Gartner
« Au demeurant, je dois mentionner qu’aucun éditeur ne satisfait pleinement les capacités que je viens de décrire », signale Manjunath Bath. « Le but est moins de rassembler toutes les fonctionnalités imaginables au sein d’une plateforme, mais de la rendre extensible et facile d’usage “out of the box” », ajoute-t-il.
En ce sens, cette plateforme à l’instar de ce que propose GitLab n’est pas une chaîne d’outils « best of breed », mais un tout, plus ou moins complet « voué à s’améliorer au fur et à mesure des feedbacks clients » et des saillies « de la compétition ». Ces plateformes doivent « améliorer la collaboration des utilisateurs, l’expérience des développeurs et réduire les coûts de déploiement », liste l’analyste.
« Gartner remarque un intérêt croissant pour ces plateformes et nous nous attendons à une adoption rapide au cours des trois prochaines années », ajoute-t-il. Et à GitLab de reprendre la prédiction du cabinet affirmant que d’ici 2023, « 40 % des entreprises auront abandonné leurs multiples solutions ponctuelles au profit d’une plateforme afin de rationaliser la fourniture des applications ».
Une phase pour l’élite DevOps
Or la dixième étude State of DevOps, elle-même bâtie pour mettre en avant ce concept de guichet unique du DevOps, pointe le fait que les entreprises subissent principalement des freins organisationnels. Seules les entreprises les plus avancées sont aptes à adopter cette quatrième phase. Lors de la conférence, les témoignages d’UBS, d’Intel, de T-Mobile America vont en ce sens.
« Le but est moins de rassembler toutes les fonctionnalités imaginables au sein d’une plateforme, mais de la rendre extensible et facile d’usage “out of the box” ».
Manjunath BhatAnalyste, Gartner
Sans parler de l’enfermement propriétaire qui, semble-t-il, effleure uniquement l’esprit des membres de certaines fondations ou organisations open source, ces retours d’expérience mettent en avant l’application et l’imposition de méthodologies, de processus par l’outil. Les mécanismes de standardisation et de conformité ne sont pas transparents : ils demandent une acception des équipes. D’autres témoignages auprès du MagIT le démontrent : « l’outillage ne fait pas tout ». Comment GitLab aide-t-il les clients qui subissent ces défis organisationnels ? Ceux-là mêmes qui viennent à peine de s’ouvrir à la troisième phase décrite par Sid Sijbrandij ?
« Nous sommes d’accord sur le fait que les facteurs humains et la gestion du changement sont essentiels à la transformation DevOps », répond le porte-parole de GitLab. « Bien que la Plateforme DevOps de GitLab aide en garantissant que toutes les équipes regardent et agissent sur les mêmes données, nous laissons à voir également en public comment GitLab utilise GitLab », ajoute-t-il. « En outre, nous disposons d’une organisation de services professionnels talentueuse et de partenaires mondiaux, pour aider les clients à tirer le meilleur parti de la plateforme. Enfin, nous espérons que des événements comme GitLab Commit, où la communauté et les clients se réunissent, peuvent aider les entreprises à apprendre comment faire avancer leur propre transformation DevOps ».
Pourtant, après avoir cité les chiffres d’une étude d’IDG Connect affirmant que 75 % des professionnels de l’IT ont déjà été harcelés au travail et que 21 % l’ont été l’année dernière, selon Mercer Human Resources Consulting, Christopher Wang, Senior Solution Architect chez GitLab, assure que l’une des solutions à ce problème est une plateforme DevOps unique qui « favorise la communication entre équipes ». L’on atteint sûrement ici les limites de l’exercice.
Nouvelle ère, nouveau modèle tarifaire
Cette apparente surenchère peut se comprendre. GitLab demeure un challenger face à la pieuvre GitHub. Et c’est sans doute pour cette raison que l’entreprise mise pleinement sur la conceptualisation de son produit… ainsi que sur un changement de modèle tarifaire.
GitLab affiche la volonté d’apaiser les « frustrations des clients » (sic) en passant d’un mode de souscription annuel à un autre trimensuel, de sorte que l’achat de nouveaux sièges au cours de l’année ne génère pas de « charges rétroactives ». En clair, l’éditeur instaure une réduction du coût à la souscription en contrepartie de l’instauration d’une « licence cloud ».
Dans un même temps, l’abonnement à GitLab SaaS est renouvelé de manière automatique avec la possibilité de désinscrire et d’employer le service jusqu’à la date butoir du contrat. Les adhérents de l’édition Self-managed, activeront les instances via un code disponible depuis le portail client de GitLab. De sorte que les données comme le tier choisi, le nombre d’utilisateurs actifs, d’invités, d’utilisateurs inactifs, puissent être synchronisées quotidiennement afin de « faciliter la réconciliation liée à la facturation trimestrielle ». Les usagers des instances self-managed qui souhaitent accéder à ce mode de facturation devront obligatoirement partager des renseignements sur le nombre de projets, de pipelines, d’issues, et de merge requests. Ces agrégations « ne contiennent pas d’informations personnelles d’un utilisateur individuel ou d’informations spécifiques à un projet », promet GitLab.
Ces mesures sont actives pour les nouveaux clients et ceux qui renouvellent leurs licences à partir du 1er août 2021. S’ils veulent en bénéficier, ils doivent migrer vers la version 14.1. Les clients qui ne souhaitent ou ne peuvent pas (pour des raisons de sécurité, notamment) se voir imposer ce régime n’ont d’autre choix que de conserver le modèle de paiement annualisé. Seuls les partenaires revendeurs continueront à proposer cette approche à de nouveaux clients avant d’adopter ce modèle tarifaire. « Nous étudions les moyens de permettre la soumission manuelle des données de licence requises, sans avoir besoin d’une connexion Internet active. Lorsque nous aurons ces moyens, nous informerons les clients concernés », écrit l’éditeur dans une FAQ.
Ici, point question de persuader les développeurs, ils ont déjà fait leur choix. Désormais, il faut convaincre les directions.
