L'état des microservices et du cloud computing

Selon une récente enquête radar O'Reilly sur la croissance du cloud computing, l'une des mesures les plus intéressantes indiquait que 52% des 1283 réponses déclaraient utiliser des concepts, des outils ou des méthodes de microservices pour le développement de logiciels. Parmi ceux-ci, une grande minorité (plus de 28%) utilise des microservices depuis plus de trois ans.

Il s'agissait du deuxième plus grand cluster parmi les utilisateurs de microservices. Le plus grand groupe, à plus de 55%, utilise des microservices depuis un à trois ans. De plus, seulement 17% des utilisateurs sont nouveaux dans les microservices, avec moins d'un an d'adoption et d'utilisation.

O'Reilly souligne également certaines preuves selon lesquelles l'intérêt pour les microservices pourrait atteindre ou presque atteindre un sommet. En outre, la décomposition notée des structures de service - au moins au degré de granularité prescrit dans l'architecture des microservices - s'avère plus difficile que prévu.

L'utilisation de microservices est vraiment une progression naturelle de l'orientation des services et de l'utilisation de systèmes basés sur le cloud. La possibilité de décomposer des services adaptés aux cours en microservices est juste une bonne idée. Vous aurez plus de services qui ont plus d'utilisations, comme un service de mise à jour de l'inventaire basé sur le cours qui peut être séparé pour lire les données d'inventaire existantes, modifier les données d'inventaire existantes en données d'inventaire mises à jour, valider les données d'inventaire mises à jour et écrire les données d'inventaire mises à jour au stockage.

Une fois que ce service de macro est divisé en quatre microservices, vous pouvez les utiliser dans ce service de macro. Ou vous pouvez les réutiliser dans d'autres services de macro et applications composites (pardonnez l'exemple trop simplifié). L'objectif est d'écrire un microservice une fois et de l'utiliser plusieurs fois.

Vous ferez mieux d'écrire des microservices de manière à les rendre plus génériques et plus généraux, applicables dans de nombreux modèles d'utilisation différents (contrairement aux exemples ci-dessus qui ne sont pas génériques, se concentrant uniquement sur les données d'inventaire). Mais c'est là que vient la difficulté.

La capacité à mettre en place des cadres de décomposition de services où le nombre maximal de microservices est réutilisé est au cœur de l'exploitation efficace des microservices. Cette compétence, cependant, a été difficile à développer pour la plupart des architectes d'application.

J'ai passé une bonne partie de mon temps ces dernières années à développer des conceptions d'applications compatibles avec les microservices et à constater que la plupart d'entre elles n'ont pas la planification nécessaire pour tirer pleinement parti des microservices. J'ai vu un méli-mélo de services à grain fin qui sont écrits une fois et mis à profit une fois, manquant l'avantage principal de ce à quoi servent les microservices: la réutilisation de petits services renforcés et testés.

Comme le souligne l'enquête, nous constatons que la décomposition appropriée des services en microservices - et l'orientation des services en général - est un pont trop loin pour la plupart des concepteurs d'applications. La seule résolution est de suivre une formation, sachant que c'est plus un art que de la science. Peut-être pourrons-nous alors dépasser le stand.