De plus en plus d’entreprises reconnaissent que l’adoption des pratiques DevOps représente un avantage pour l’accélération des cycles de déploiement, tout en améliorant la qualité, la fiabilité et la sécurité de ces opérations. Ainsi, les disparités se sont accrues entre les entreprises ayant entamé leur transformation DevOps et celles qui n’ont pas encore franchi le pas. Les avantages grandissants dont bénéficient les organisations appliquant ces pratiques ont notamment été mis en évidence dans le rapport State of DevOps.[1] En plus de souligner que les pratiques DevOps « améliorent la culture organisationnelle et l’implication des employés », ce rapport évoque plusieurs découvertes clés sur les organisations les plus performantes. Il montre ainsi que, comparativement, ces entreprises présentent une meilleure fidélisation des employés et consacrent moins de temps à des tâches non planifiées ou à refaire. Elles réalisent également des déploiements 200 fois plus souvent, ont des temps de récupération 24 fois plus courts après une panne et des délais d’exécution 2 555 fois plus rapides pour les modifications.

Plusieurs des entreprises performantes interrogées pour le rapport ont commencé leur transformation DevOps en comblant les écarts amont-aval entre le développement et le de déploiement, et ce, à trois niveaux :

  • Collaborateurs et culture
  • Processus et pratiques
  • Outils et technologies

Les trois éléments de ce trio sont interdépendants et l’établissement d’une culture DevOps efficace nécessite donc de tous les aborder.

Figure 1.  Combler les écarts entre les étapes en amont (développement)
et en aval (opérations) pour les trois composantes du trio DevOps.

Concernant le troisième aspect de ce trio (outils et technologies), les entreprises performantes reconnaissent depuis longtemps l’importance des outils d’automatisation du déploiement, par exemple pour l’intégration continue et la livraison continue. Cependant, elles finissent par réaliser que l’automatisation d’architectures anciennes à l’aide de technologies elles-mêmes anciennes ne les mène finalement pas très loin. Elles cherchent ainsi de plus en plus à améliorer leurs logiciels en mettant en place une architecture de microservices et des technologies de conteneur. Ces deux outils sont, à bien des égards, parfaitement adaptés au DevOps, car ils en favorisent les pratiques fondamentales : builds fréquents, déploiements rapides, ainsi qu’équipes plus flexibles et plus petites. L’objectif de cet article est d’étudier les microservices et l’expansion de l’écosystème de conteneur Docker, et d’analyser également comment associer ces éléments à une culture DevOps en vue de fournir davantage de fonctionnalités plus rapidement, sans pour autant sacrifier la qualité, la fiabilité ou la sécurité.

Une architecture non traditionnelle : les microservices ne sont pas qu’un nouvel avatar de la SOA

D’un certain point de vue, les microservices ressemblent à une nouvelle version de l’architecture orientée services (SOA), concept apparu il y a quelques années. La SOA étant à l’origine des microservices, les deux concepts partagent de nombreuses caractéristiques. Cependant, il existe d’importantes différences entre eux. À l’instar de la SOA, les microservices découplent les composants d’un système complexe et définissent les interfaces ou les contrats entre lesdits composants. Avec les microservices, les communications entre les composants ont tendance à être moins lourdes, tandis que les interfaces et les contrats sont moins rigides et sont souvent implémentés via des API RESTful. Beaucoup considèrent également que les microservices se concentrent davantage sur les fonctionnalités destinées aux utilisateurs que sur les services internes, mais il ne s’agit pas d’une règle bien définie.

Les microservices peuvent aussi être déployés sous forme de composants indépendants, ce qui permet à des équipes relativement petites (y compris celles spécialisées dans un seul domaine) d’appliquer facilement des processus itératifs pour développer, tester et proposer un microservice individuel.

L’apparition des microservices est assez récente dans le secteur. Néanmoins, ils sont vite devenus populaires, car ils permettent aux entreprises de fournir des logiciels plus rapidement.

Google Trends révèle un intérêt croissant pour les microservices

Plusieurs facteurs contribuent à cette accélération. De petits composants peuvent être élaborés de manière indépendante par des équipes de 8 à 12 développeurs contrôlant le développement et le déploiement de bout-en-bout. De plus, le découplage des fonctionnalités système en composants plus petits permet de mettre à jour des composants individuels fréquemment et de façon fiable sans que cela n’ait d’impact important sur le système général (de fait, les systèmes résilients conçus à partir de microservices restent opérationnels même si un service donné n’est pas disponible). La décomposition des anciennes applications monolithiques en microservices facilite également les restaurations lorsque des problèmes de production sont détectés, ainsi que les déploiements continus et les déploiements « bleu/vert ». Pour résumer, une équipe Scrum plurifonctionnelle spécialisée dans le développement, l’assurance qualité et l’exploitation peut rapidement élaborer, tester et déployer un composant de microservice complet, puis réagir immédiatement à tout problème inattendu après le déploiement.

Quel est le rôle des conteneurs ?

Tout comme les microservices ont donné un nouveau souffle aux concepts essentiels de la SOA, Docker a redynamisé la technologie de conteneur vieille de plusieurs décennies. Les premiers conteneurs Linux sont apparus il y a 15 ans, et leur technologie de base est plus ancienne encore. Pourtant, l’implémentation de conteneurs par Docker a récemment attiré toutes les attentions. Docker est aujourd’hui, et de loin, la technologie de conteneur la plus populaire et la plus largement adoptée. En définissant un format d’image standard et en établissant un écosystème de fournisseurs et d’outils, cette entreprise a rendu la technologie de conteneur largement accessible et l’a introduite dans le secteur informatique général. Il est d’ailleurs difficile de trouver un fournisseur d’outils de distribution et de développement standard qui ne s’appuie pas d’une façon ou d’une autre sur les services Docker.

Quel est l’intérêt d’utiliser des conteneurs Docker plutôt que des serveurs distincts voire des machines virtuelles, qui peuvent être utilisés de manière similaire ? Grâce aux conteneurs, vous n’avez pas besoin de développer et de configurer entièrement un nouveau serveur physique, ni de mettre sur pied un nouvel environnement virtuel, ce qui requiert une émulation de processeur, un système d’exploitation et des logiciels installés. Le conteneur Docker vous permet de faire tenir un environnement complet dans une seule image légère. Par exemple, les conteneurs Docker proposent un accès rapide à l’infrastructure, une exigence fondamentale du DevOps et des pratiques de déploiement continu.

L’immuabilité est une caractéristique fondamentale des environnements fournis par les conteneurs, comme l’indique John Willis, directeur du développement des écosystèmes chez Docker : « L’immuabilité est un concept qui consiste à ne rien créer de nouveau sur une infrastructure active (généralement, la production). Le système d’exploitation de base, le middleware et l’application sont identiques en tout point[2] ». Car l’application, avec toutes ses dépendances et son environnement tout entier, repose sur une image Docker, l’intégralité du déploiement se fait en même temps et peut traverser le canal de distribution sans être endommagé. L’application dispose d’un environnement cohérent du développement jusqu’à la production, en passant par les phases d’assurance qualité et de mise en place. Cette cohérence évite aux développeurs de devoir poursuivre une cible en mouvement.

La capacité à créer des builds et à les tester pour chaque modification des logiciels reste le Graal du secteur et requiert la mise en place d’environnements disponibles à la demande capables de gérer l’augmentation du nombre et de la fréquence de ces builds. Les conteneurs Docker répondent à cette attente et représentent un gain de temps considérable, puisqu’il n’est plus nécessaire d’attendre le provisionnement des environnements.

Une combinaison gagnante

Plus de la moitié des participants à l’étude Jenkins Community de 2016[3] déclaraient que leur société utilisait déjà la technologie de conteneurs. Plus de 90 % d’entre eux disaient avoir recours à Docker. L’étude montre également une légère hausse de la fréquence des déploiements et de leur automatisation. Parmi les participants réalisant des déploiements continus, plus de 40 % déployaient du code au moins une fois par semaine et 30 % effectuaient des déploiements de production entièrement automatisés.

Ces résultats peuvent être mis en corrélation avec la popularité grandissante des microservices et de Docker auprès des entreprises ayant adopté des pratiques DevOps. La division d’une même application en plusieurs composants fonctionnels permet à de petites équipes interfonctionnelles de développer, de tester et de déployer ces composants sous forme de microservices dans des conteneurs.

Les conteneurs sont parfaitement adaptés aux petites équipes flexibles, car ils offrent un accès rapide à une infrastructure immuable sans interférer avec d’autres flux de développement. Les conteneurs sont aussi un complément idéal aux microservices, puisqu’ils sont bien adaptés à l’hébergement de composants autonomes plus petits. L’association des microservices et des conteneurs a permis à des équipes agiles de travailler de manière plus indépendante, d’obtenir leur propre infrastructure et de fournir des logiciels plus rapidement, notamment lorsque le canal de distribution est géré par des produits Jenkins et d’autres outils d’automatisation prenant en charge Docker.

Quelques avertissements toutefois avant que vous ne vous engagiez sur la voie des microservices et des conteneurs : tout d’abord, la technologie de conteneur évolue rapidement et de nouvelles versions de Docker sont publiées fréquemment. Si vous souhaitez vous lancer très rapidement dans l’adoption des conteneurs, soyez vigilant quant aux modifications susceptibles d’avoir des répercussions sur l’utilisation que vous comptez en faire. De plus, au lieu de consacrer du temps et des ressources à décomposer un système monolithique (mais fonctionnant correctement) en microservices, vous pouvez laisser ce logiciel en place et utiliser une architecture de microservices uniquement pour l’implémentation de nouvelles fonctionnalités, en remplaçant progressivement votre ancienne architecture.

DevOps nécessite une alliance entre culture, processus, outils et technologie.  Une entreprise capable de mettre des outils (dont Docker) et des technologies (dont les conteneurs et les microservices) au service d’une culture collaborative et de pratiques éprouvées a de grandes chances de se démarquer en développant des logiciels plus rapidement (du concept à la commercialisation) et en les distribuant avec plus de fiabilité et de sécurité.

 


__________
[1] https://puppet.com/resources/white-paper/2016-state-of-devops-report

[2] DevOps and Immutable Structure, présentation réalisée lors du Cloud Expo 2015 par John Willis, Docker :

[3] Jenkins Community Survey, septembre 2016 :