« Passer à une approche basée sur les microservices présente clairement des avantages d'ingénierie »

Estime O'Reilly en marge de son enquête Microservices Adoption in 2020

Le 17 juillet 2020 à 17:08, par Stéphane le calme

76PARTAGES

Les applications sont généralement créées de manière monolithique. Autrement dit, tous les éléments de l'application qui peuvent être déployés résident dans cette seule application. L'inconvénient, c'est que plus celle-ci est volumineuse, plus il devient difficile de l'enrichir de fonctions et de traiter rapidement les problèmes qui surviennent. Avec une approche basée sur des microservices, il est possible de résoudre ces problèmes, d'améliorer le développement et de gagner en réactivité.

Les microservices désignent à la fois une architecture et une approche de développement logiciel qui consiste à décomposer les applications en éléments les plus simples, indépendants les uns des autres. Contrairement à une approche monolithique classique, selon laquelle tous les composants forment une entité indissociable, les microservices fonctionnent en synergie pour accomplir les mêmes tâches, tout en étant séparés. Chacun de ces composants ou processus est un microservice. Granulaire et léger, ce type de développement logiciel permet d'utiliser un processus similaire dans plusieurs applications. Il s'agit d'un élément essentiel pour optimiser le développement des applications en vue de l'adoption d'un modèle cloud-native.

Les microservices ont le vent en poupe. Pour mieux analyser cette approche et répondre à un certain nombre de questions (depuis combien de temps les gens les utilisent-ils ? À quoi les utilisent-ils ? Ont-ils du succès ? Si oui, quels types d'avantages voient-ils ? Que pouvons-nous apprendre de leurs échecs ?), O'Reilly a lancé une enquête du 31 janvier 2020 au 29 février.

Le panel a essentiellement fait appel à des rôles techniques, mais les rôles de gestion étaient également représentés. Les ingénieurs logiciels ont constitué le groupe le plus important de l'audience de l'enquête, soit plus du quart (27 %) des répondants. Si vous combinez les différents rôles architecturaux (architectes logiciels et systèmes, responsables techniques), les architectes représentent près de 28 % de l'échantillon. En prenant en considération architectes et ingénieurs, environ 55 % des répondants sont directement impliqués dans le développement de logiciels. Les répondants occupant des postes de direction représentent près de 23 % du panel; les postes de direction (vice-présidents, PDG, DSI, etc.) représentent environ 13 %.

Adoption de microservices : explication et analyse

Un peu plus du tiers des personnes interrogées affirment que leur organisation utilise des microservices depuis 1 à 3 ans. Le deuxième groupe en importance, près du quart (plus de 23 %) des organisations interrogées, n'utilise pas du tout de microservices. Les entreprises qui ont adopté les microservices pour la première fois il y a entre 3 et 5 ans, constituent le troisième cluster en importance, avec 18 %. Si vous tenez compte des répondants dont les organisations ont adopté les microservices pour la première fois il y a plus de 5 ans, cela signifie que plus de 28 % des organisations interrogées utilisent les microservices depuis au moins trois ans. Cependant, un peu moins d'un sixième des entreprises (15 %) commencent tout juste à adopter des microservices ; ils utilisent des microservices depuis moins d'un an.

Le rythme d'adoption, dans lequel une nette majorité (61 %) des répondants déclarent que leurs organisations utilisent des microservices depuis 1 à 5 ans, correspond à peu près aux tendances empiriques qu'O'Reilly a observées en interne (par exemple, en ce qui concerne la recherche par mot-clé et l'utilisation du sujet sur la plateforme d'apprentissage en ligne O'Reilly) et dans d'autres contextes. La part des adoptions pour la période de 12 mois entre janvier 2019 et janvier 2020 suggère également que les microservices restent un sujet d'intérêt pour les utilisateurs d'O’Reilly. D'un autre côté, il existe des preuves provenant d'autres milieux que l'intérêt pour les microservices - à la fois comme sujet et comme terme de recherche général - s'est rétracté au cours des 12 mois.

Ainsi, non seulement la plupart des répondants utilisent des microservices, mais les trois cinquièmes (61 %) les utilisent depuis un an ou plus. Mais décrivent-ils leur expérience comme réussie ? Quelle part des systèmes qu'ils déploient ou entretiennent sont intégrés à l'architecture de microservices ? Quelles caractéristiques les adoptants qui réussissent partagent-ils ? Que pouvons-nous apprendre de ceux qui disent qu’ils ont échoué avec les microservices ?

Facteurs critiques de réussite

À la question « de ces systèmes avec une architecture de microservice, comment évaluez-vous le succès en termes de voir les avantages que vous attendiez ? », la majorité des répondants (55 %) affirment que l’utilisation des microservices par leur organisation a été soit un « succès complet » (près de 9 %), soit « la plupart du temps une réussite ».

Plus du tiers (37 %) affirment avoir eu « un certain succès » avec les microservices. Environ 8 % disent ne pas avoir connu de succès du tout. Cependant, les relations dans les données suggèrent plusieurs facteurs critiques de succès. Par exemple, près de la moitié (près de 49 %) des entreprises dans lesquelles les équipes de développement détiennent l'intégralité du cycle de développement (c.-à-d. La construction, les tests, le déploiement et la maintenance) ont également déclaré avoir « surtout réussi » avec les microservices - et plus de 10 % ont déclaré que leurs efforts de développement de microservices ont été un « succès complet ». Le décompte combiné (près de 59 %) est environ 18 % plus élevé que le décompte de référence pour le public de l'enquête dans son ensemble. Rendu à ce niveau, il était question de déterminer quels éléments pouvaient contribuer à ce succès.

Utilisation de conteneurs pour le déploiement de microservices

O'Reilly a demandé aux répondants quelle proportion de leurs microservices ils déployaient à l'aide de conteneurs. Le plus grand cluster unique (38 %) pour cette question est constitué des répondants qui ne déploient pas leurs microservices dans des conteneurs. On pourrait raisonnablement s'attendre à ce que les conteneurs soient le moyen le plus courant d'instancier des microservices. Ce n'est tout simplement pas le cas, cependant. Les résultats du sondage indiquent que, pour l'ensemble de l'auditoire d'O'Reilly, la plupart des répondants (58 %) déploient des microservices en utilisant un support autre que les conteneurs.

Il existe des raisons valables de ne pas utiliser de conteneurs. Pour certains adoptants, la dette technique (sous la forme de systèmes, d'applications ou d'architectures sur mesure, propriétaires et monolithiques) est un facteur contraignant. Il est donc logique d'instancier des microservices au niveau de la machine virtuelle (VM), qui est distincte du conteneur. Ou peut-être est-il plus rapide et moins coûteux, au moins à court terme, de créer et d'instancier des microservices en tant que code non virtualisé fonctionnant dans le contexte d'un système d'exploitation conventionnel, d'une base de données, d'un serveur d'applications, etc.

Cela ne signifie pas que les répondants n'utilisent pas de conteneurs, la plus grande partie du public de l'enquête le fait. C'est juste que les conteneurs ne sont pas encore le moyen le plus populaire d'instancier des microservices, bien que cela puisse changer. Par exemple, le deuxième plus grand cluster (31 %) pour cette question est constitué d'organisations qui déploient entre 75 % et 100 % de leurs microservices à l'aide de conteneurs. Et 11 % utilisent des conteneurs pour déployer entre 50 et 75 % de leurs microservices.

Le résultat est que plus des deux cinquièmes (42 %) des organisations interrogées utilisent des conteneurs pour déployer au moins la moitié de leurs microservices - et que, pour le public de l'enquête dans son ensemble, près des deux tiers (62 %) utilisent des conteneurs pour déployer au moins certains de leurs microservices. Nous avons donc une scission: d'une part, la plupart des microservices sont instanciés en utilisant autre chose que les conteneurs; d'autre part, la plupart des organisations qui utilisent des microservices instancient également au moins certains d'entre eux dans des conteneurs. Par exemple, 10 % des personnes interrogées disent utiliser des conteneurs pour déployer entre 10 et 25 % de leurs microservices; un peu plus de 9 % déploient entre 25 et 50 % des microservices avec conteneurs; et, encore une fois, 11 % se déploient entre 50 et 75 % en utilisant des conteneurs. Il semble que les adoptants optent pour la plupart des conteneurs, les utilisent pour la plupart des microservices ou les utilisent avec parcimonie.

Il y a un « mais » critique et intrigant ici: une proportion plus élevée que la moyenne de répondants qui déclarent avoir réussi avec les microservices choisissent de les instancier à l'aide de conteneurs; à l'inverse, une proportion beaucoup plus élevée de répondants qui décrivent leurs efforts de microservices comme « n'ayant pas réussi du tout » ne les instancient pas dans des conteneurs. Par exemple, près de la moitié (49 %) des répondants qui décrivent leurs déploiements comme « un succès complet » instancient également la plupart de leurs microservices (75-100 %) dans des conteneurs. C'est plus de 5 fois le pourcentage d'instanciation de ceux qui ont déclaré ne pas avoir réussi du tout (9 %). À l'inverse, une écrasante majorité (83 %) des répondants qui décrivent leurs efforts de microservices comme « n'ayant pas réussi du tout » les instancient par d'autres moyens que les conteneurs. (Il s'agit des répondants qui utilisent des conteneurs avec moins de 10% de leurs microservices).

Cette observation a un sens intuitif. Avec les microservices, au lieu de déployer une application monolithique, vous devrez peut-être déployer et gérer des centaines ou des milliers de services. L'utilisation de conteneurs pour standardiser le déploiement et des outils d'orchestration de conteneurs pour automatiser la gestion continue simplifie considérablement la charge de déploiement et de gestion.

Utilisation d'une base de données centrale et gérée

Lorsqu'O'Reilly a demandé aux répondants quelle proportion de leurs microservices partageait une base de données centrale et gérée, il a constaté que le fait de ne pas utiliser une base de données gérée de manière centralisée avec des microservices a tendance à être associé à une défaillance. Cela dit, la question elle-même (c.-à-d. «Quel pourcentage de vos microservices partagent une base de données gérée de manière centralisée?») Ne nous donne pas grand-chose. O'Reilly ne savait pas ce que les répondants considéraient comme une base de données gérée de manière centralisée; quel type de base de données ils utilisaient (relationnel ou non relationnel); ou si l'intégrité transactionnelle était un problème.

Interface utilisateur monolithique

O'Reilly a également demandé aux utilisateurs quel pourcentage des systèmes déployés en tant que microservices avaient une interface utilisateur monolithique. Cette question est également problématique. Tout d'abord, qu'est-ce qu'une interface utilisateur monolithique ? Plus précisément, qu'est-ce que le panel a considéré comme étant une interface utilisateur monolithique, et que fait-il s'il ne construit pas une interface utilisateur monolithique ? Il existe plusieurs possibilités, dont aucune n'est entièrement convaincante. Une tendance récente dans le développement Web est celle des « micro frontends », mais O'Reilly pense que cela ne semble pas suffisamment connu pour avoir un effet significatif sur les données. Les répondants sont susceptibles d'associer une «interface utilisateur monolithique» au développement Web traditionnel (ou peut-être même des applications de bureau ou d'anciens «écrans verts»), par opposition à l'utilisation de composants dans un framework comme React (comme les micro frontends sont construits avec des frameworks comme React, il peut s'agir de deux noms pour presque la même chose). Dans tous les cas, il est probable qu'une interface utilisateur monolithique représente un compromis entre simplicité et flexibilité et complexité. Un front-end construit avec un framework Web réactif moderne est presque certainement plus flexible - et plus complexe - qu'un formulaire Web des années 1990.

Prenez le groupe de répondants qui ne construisent pas une interface utilisateur monolithique (autrement dit, <10 % de leurs microservices utilisent une interface utilisateur monolithique). Pour 31 % de tous les répondants, il s'agit du groupe le plus important. Mais il a également le taux d'échec complet le plus élevé : 17 % décrivent leurs implémentations comme « pas du tout réussies». Les répondants de ce groupe étaient également plus susceptibles de décrire leurs projets comme un « succès complet » (12%); 37 % ont déclaré avoir « réussi pour la plupart ».

À l'autre extrémité de ce spectre, parmi les répondants qui ont utilisé une interface utilisateur monolithique pour 50 à 75 % de leurs systèmes, seulement 2 % ont déclaré qu'ils n'avaient pas réussi du tout. 8 % ont déclaré que leurs projets étaient un « succès complet », tandis que 52 % ont déclaré que leurs projets étaient « pour la plupart réussis ».

Avantages et freins à l'adoption

O'Reilly a demandé aux répondants quels avantages, le cas échéant, ils attribuent à leur utilisation réussie des microservices. Il leur a été demandé de sélectionner tous les avantages applicables.

Le plus grand cluster pour cette réponse (45 %) a nommé « flexibilité des fonctionnalités », suivi (à un peu moins de 45 %) par « répondre rapidement à l'évolution de la technologie et des exigences commerciales ». Un peu moins de 44 % ont cité l'avantage d'une « meilleure évolutivité globale », suivie (43 %) par « des rafraîchissements de code plus fréquents ». L'avantage le moins cité (15 %) était celui de la baisse des coûts de développement; seulement 20 % des personnes interrogées déclarent avoir réalisé l'une des principales promesses des microservices : une disponibilité améliorée grâce à des fonctions multiples et redondantes (c'est-à-dire des services).