GitOps versus DevOps : quand les containers rebattent les cartes

GitOps et DevOps : qu’est-ce que c’est ?

L’approche DevOps a été conçue comme un mécanisme de pipeline, tandis que la méthode GitOps correspond à une amélioration des processus de développement. L’intégration continue et la livraison continue (CI/CD) ainsi que l’utilisation de microservices ont favorisé le chevauchement de ces deux concepts. Bien que le modèle GitOps ne soit pas un sous-ensemble du DevOps, ces approches vont probablement converger à l’avenir. Aujourd’hui, les différences – et les points communs – entre les deux systèmes influencent la manière dont les organisations les concilient.

Réduit à l’essentiel, le concept DevOps c’est :

• une culture et une méthodologie, autant que des techniques et des outils ;
• maintenir un cloisonnement entre les étapes associées au développement et les étapes liées aux opérations ;
• mettre l’accent sur le déploiement avec des crochets vers le développement, en particulier dans les outils ;
• s’appuyer sur des scripts et des paramètres qui doivent être gérés ;
• mettre en place une chaîne d’outils complète.

En comparaison, le GitOps :

• est essentiellement un paradigme et une technique ;
• assouplit les restrictions entre les étapes liées aux séquences de développement et d’opérations ;
• est centré sur le référentiel, les fichiers de configuration et les paramètres de déploiement des ressources centralisés au même endroit que le code source de l’application ;
• met l’accent sur le développement rapide et les changements complexes, et minimise la dépendance à l’égard de scripts complexes ;
• repose sur l’utilisation d’un seul outil (Git).

Comment le manifeste DevOps a donné naissance au GitOps

Le manifeste DevOps a été la première tentative de l’industrie pour créer un pipeline fluide du développement à la production, tout au long duquel les caractéristiques essentielles des applications et les besoins de configuration sont transmis d’une équipe à l’autre. Presque tous les outils DevOps populaires convertissent les instructions créées par les développeurs en étapes de déploiement ; c’est la condition sine qua non pour une intégration efficace du développement et des opérations.

L’avènement des applications composées de microservices et de la CI/CD a soulevé deux points importants dans cette intégration.

Premièrement, le processus de développement lui-même nécessitait une meilleure structure pour les relations multicomposantes complexes inhérentes aux nouveaux modèles d’application, dans lesquels les services et les microservices deviennent la règle.

Deuxièmement, dans les applications à composants, le pipeline entre le développement et les opérations est beaucoup plus complexe, car une version est un ensemble de changements de composants poussés à leur propre rythme dans le pipeline.

La solution logique à ces deux défis est de centrer à la fois le développement et les opérations sur un référentiel partagé – une source unique de vérité qui guide individuellement toutes les activités de développement et les opérations IT et les relie par un pipeline, tout en apportant une piste d’audit. Le dépôt Git a été le choix dominant pour le contrôle de version de code. De nombreuses organisations ont commencé à construire un ensemble amélioré d’outils et de pratiques de développement autour de Git. Ainsi est née l’approche GitOps.

Différencier les deux approches

L’approche GitOps repose sur la centralisation et la description au sein du fameux dépôt d’un service ou d’un microservice cloud natif. Cette méthodologie est déclarative plutôt que prescriptive : elle demande de définir un objectif et les moyens pour l’atteindre. Le manifeste DevOps conduit les étapes de déploiement et de redéploiement par l’intégration avec ce même dépôt. Ainsi, dans un véritable modèle GitOps, le DevOps est un sous-domaine, et dans un nombre croissant de cas, ce n’est même pas une exigence.

Le modèle DevOps accepte des approches tant déclaratives que prescriptives. Il s’adapte bien aux modèles d’application monolithiques, ainsi qu’aux applications à la modularité limitée. Les entreprises peuvent également appliquer le DevOps tout aussi facilement aux déploiements de VM et bare metal qu’aux containers.

L’approche DevOps porte en son sein une vision centrée sur les opérations : elle se concentre dès le départ sur la manière de déployer le code – même dans la mesure où les premiers outils étaient prescriptifs, ou axés sur les scripts. Cela correspond bien aux besoins des entreprises lorsque les applications évoluent lentement, et que les changements de configuration et les problèmes matériels se produisent quotidiennement. Cela fait du DevOps un instrument idéal pour les organisations qui ont du mal à passer au cloud, par exemple, plutôt qu’à faire face à des problèmes de développement et de CI/CD.

De nombreux outils DevOps étendent la méthodologie à des domaines tels que la supervision, la gestion de la configuration et l’infrastructure as code. Mais il existe peu d’outils conçus pour soutenir le processus de développement, ce qui laisse penser que DevOps reste axé sur les opérations, même si la CI/CD change la donne.

Comment Kubernetes change la donne

Il est difficile de dissocier les containers et Kubernetes, des approches DevOps et GitOps. En pratique, la plupart des DevOps ne déploient pas de containers, tandis que la plupart des organisations GitOps se sont résolues à utiliser des logiciels containerisés. Les entreprises qui n’utilisent pas encore de containers ne devraient généralement pas envisager de recourir au GitOps, mais celles qui commencent à explorer les capacités de Docker et de Kubernetes ne devraient pas l’ignorer.

Parce que la méthodologie GitOps se concentre à la fois sur les développeurs et sur la CI/CD, elle se trouve au centre de l’évolution de la relation entre le développement et les opérations dans le cadre de développement d’applications à base de composants multiples.

Si cela est vrai, alors les containers et Kubernetes représentent des atouts évidents, car ils deviennent des moteurs essentiels pour développer des applications de plus en plus morcelées. L’approche DevOps, elle, est compatible avec un éventail beaucoup plus large de modèles applicatifs, mais si le monde converge vers les containers, alors la polyvalence n’a plus autant d’importance.

Les administrateurs IT peuvent adapter le DevOps à un environnement containerisé, mais les pratiques d’orchestration peuvent entrer en collision avec le formidable écosystème de Kubernetes, qui connaît une expansion explosive. Oui, les deux philosophies s’entrelacent, mais l’une et l’autre correspondent à des infrastructures et des environnements différents.

Si le monde des containers et du cloud est l’avenir, alors le modèle GitOps et l’écosystème Kubernetes sont aussi l’avenir. À moins que le marketing fasse son œuvre et ne retienne que la terminologie DevOps, plus simple à vendre.