L’avancement axé sur les services est plus ancien que la plupart des gens ne le pensent. Oui, le concept de microservices est un modèle relativement nouveau ; néanmoins, les développeurs utilisent des services depuis des années pour développer des applications et des orchestrations à partir de services existants que vous ne développez pas ou de nouveaux services nets que vous développez.
Peu importe si vous appelez un service un microservice, un service à granularité fine, un service utilitaire (tel que des API ou des services de stockage dans le cloud) ou une API d’application commune pour accéder aux habitudes et/ou aux données. L’exploitation des services suggère généralement que vous utilisiez une architecture orientée services qui se concentre sur la création d’applications à partir de composants neufs ou préexistants.
L’innovation utilisée pour limiter le nombre de services que vous pouvez utiliser dans une seule application et ce ces services l’ont fait. À l’époque, l’utilisation d’un grand nombre de services à granularité fine (des services qui effectuaient des tâches discrètes telles que la mise à niveau d’une base de données avec un type de données spécifique) provoquait des problèmes d’efficacité s’ils étaient utilisés trop de fois dans la même application.
De nos jours, nous pouvons dissimuler les problèmes d’efficacité en jetant des systèmes de calcul, de mise en réseau et de stockage à faible coût sur le problème. L’inefficacité est toujours là, mais elle a été supprimée par les toutes nouvelles générations de traitement amélioré des applications qui éliminent les problèmes d’efficacité. L’utilisation des services n’est plus une question de savoir si vous le pouvez. Au contraire, cela finit par être une préoccupation de combien devriez-vous utiliser les services ? Devriez-vous même les utiliser en tout premier lieu ?
La surutilisation des services que je constate actuellement implique généralement des microservices, à un point tel que l’application finit par être trop complexe, tirant parti de tant de services qu’il est impossible de comprendre l’intention initiale du concepteur de base. Ce qui se produit également trop fréquemment, c’est la répartition d’un seul aspect de l’application vers les services, malgré le fait que le service ne sera utilisé qu’une seule fois tout au long du traitement et jamais par d’autres applications.
C’est parmi les circonstances où la dernière application déployée fonctionne, et elle résout même les principales exigences de l’entreprise désignées pour le projet. La surutilisation par l’application de services de tous types la rend plus complexe, ce qui peut entraîner des problèmes d’efficacité, en pensant au nombre de fois qu’elle contacte des services externes qui s’exécutent généralement ailleurs. Une utilisation excessive des services implique également que l’application prend deux fois plus de temps à construire, tester et déployer.
Avant que les ennemis ne m’appellent sur la bonne utilisation des services, je généralise ici. Utiliser ou ne pas utiliser les services ne sera jamais une réponse binaire. Je préconise l’utilisation des services comme la meilleure méthode pour développer des applications plus dynamiques et agiles, généralement avec des cycles d’avancement plus rapides et une bien meilleure qualité. Néanmoins, je vois aussi des concepteurs tomber d’un précipice en abusant des services. Encore une fois, le résultat trop fréquent est trop de complexité, des problèmes d’efficacité et même des applications instables car elles fonctionnent à long terme.
Alors, quelles sont les règles générales pour éviter les inconvénients de services ?
Profitez des services que vous n’appelez qu’une seule fois, des services qui ne seront jamais appelés par d’autres applications. Il est préférable de ne pas les transformer en services, en général.
Deuxièmement, développez avec un état d’esprit d’optimisation. Examinez le nombre de ressources utilisées lorsque l’application s’exécute sur un cloud public. Gardez à l’esprit que chaque utilisation d’une ressource cloud se traduit par des dépenses cloud plus élevées. Sans une métrique d’optimisation à l’esprit, les applications peuvent rapidement surutiliser les services et augmenter les frais de mise en réseau, de calcul et d’autres services. La plate-forme d’avancement, les systèmes en cours d’exécution et l’utilisation de services natifs du cloud doivent tous entrer en jeu lorsque vous pensez à l’optimisation des ressources d’application.
Enfin, utilisez votre tête. Ce sont des règles générales standard; vous serez le guide suprême de la façon dont ils utilisent votre plate-forme spécifique. De nombreux développeurs reconnaissent que lorsqu’ils abusent des services, l’application sera encore pire. Mon message principal est que lorsqu’il s’agit de faire progresser le cloud axé sur les services, il est facile de pousser une bonne idée trop loin.
Toute l’actualité en temps réel, est sur L’Entrepreneur
