Blog de l'IDBSdéployer et gérer des microservices dans des environnements gxp

IDBS Blog | 20 juillet 2022

Déployer et gérer des microservices en nuage dans des environnements GxP - Partie 2

déployer et gérer des microservices dans des environnements gxp

La dernière fois, nous avons planter le décor pour les microservices. Maintenant que nous savons ce qu'ils sont et pourquoi ils sont importants, nous allons explorer le déploiement et la gestion des microservices dans le nuage en GxP environnements. Entrons dans le vif du sujet.

Approches pour le déploiement de microservices en nuage dans les environnements GxP

Lorsque vous travaillez dans des environnements réglementés, une approche courante consiste à déployer une copie du microservice pour chaque client. Il s'agit d'une approche très consciente des risques qui correspond vraiment aux approches réglementées classiques des années précédentes, mais elle a un coût. Si vous avez 400 clients, vous devez gérer 400 services.  

Et cela dans l'hypothèse d'un seul service par client (pour mettre les choses en perspective), La banque Monzo propose 2000 services).  

Comment gérer ce nombre croissant de services ? Vous pouvez automatiser, vous pouvez vous étendre en embauchant plus de personnel DevOps, mais au fil du temps, cela peut entraver votre capacité à innover. Si vous prenez le Log4Shell En 2021, par exemple, plus vous avez de services, plus vous pouvez être vulnérable et plus vous devez vous protéger contre des exploits de ce type.  

C'est là que l'utilisation des services partagés entre en jeu. Mais avant de parler des services partagés, faisons un petit détour pour parler de la location, car lorsque vous commencez à parler de services partagés, les gens supposent généralement que vous parlez d'un système à plusieurs locataires, ce qui peut soulever des inquiétudes pour les entreprises réglementées.  

Multi-tenance  

L'une des préoccupations souvent soulevées au sujet de la multi-location est le risque potentiel de fuite de données, en raison du stockage des données de chacun dans la même base de données (une préoccupation valable, mais qui peut être résolue en suivant certains modèles de conception standard et les meilleures pratiques). Mais la multi-location ne se limite pas aux bases de données - elle se résume à "une instance logicielle unique au service de plusieurs locataires".  

Si les inquiétudes portent sur le risque de fuite de données, vous pouvez facilement atténuer ce risque en supprimant les données du tableau. Il s'agit de services qui ne stockent aucune donnée - ils reçoivent une entrée, la traitent et renvoient une réponse (comme le service de logiciels malveillants). Ces types de services sont des candidats de choix pour devenir des services partagés dans un environnement réglementé.   

En fait, si l'on y réfléchit bien, chaque service est intrinsèquement multi-tenant au niveau de l'utilisateur. Si Karen et Virendra soumettent tous deux un travail à un service, Karen devrait obtenir son résultat et non celui de Virendra, et vice-versa.  

Qu'est-ce qui change si ce service n'est plus appelé par 100 personnes de l'entreprise A, mais par 100 personnes de l'entreprise A et 100 personnes de l'entreprise B ? Rien - un utilisateur soumettra un travail et obtiendra une réponse (vous devrez peut-être faire évoluer le service, mais cela devrait être automatique !)  

Ce qu'il faut en retenir, c'est que la multi-location peut se produire à de nombreux niveaux et que sa présence ne doit pas être considérée comme une sonnette d'alarme. Le défi auquel sont confrontées les entreprises telles que l'IDBS est de s'assurer qu'elle est adaptée à l'objectif visé, en particulier pour nos clients réglementés. 

Services partagés  

Revenons donc à notre approche des services partagés, où nous avons un service unique qui prend en charge plusieurs clients :  

En partageant les services de cette manière, nous réduisons encore les coûts opérationnels de fonctionnement, de maintenance et de sécurisation du service. Si un défaut est détecté ou si une nouvelle capacité est ajoutée, le service peut facilement être mis à niveau et tous les clients en bénéficieront.   

Examinons quelques scénarios de mise à niveau :  

Correctif de sécurité pour le moteur d'exécution du service 

L'application de correctifs de sécurité est un élément clé du service SaaS (Software as a Service) contracté et ces correctifs de sécurité devraient être distribués à tous les clients afin de garantir la sécurité de leurs systèmes. Ces types de modifications présentent peu de risques car le code du système ne change pas et ne nécessite donc pas d'activités de requalification de l'application.  

Nouvelle fonctionnalité ajoutée au service 

L'ajout de nouvelles fonctionnalités à la base de code nécessite une analyse d'impact et éventuellement une revalidation (bien qu'elle soit généralement limitée puisque le changement ne concerne que le service et non l'ensemble de l'application), et tous les clients réglementés ne souhaitent pas faire cela. Ce problème peut être résolu en introduisant un système de versions pour les services. Lorsqu'une mise à niveau est disponible, une version actualisée du service est déployée, parallèlement à la version existante. Un client réglementé peut, lorsqu'il est prêt, choisir de passer à ce nouveau service, en effectuant les validations nécessaires.   

Enfin, lorsque tout le monde a migré, l'ancienne version du service peut être retirée. L'essentiel est que le client soit impliqué dans ce processus de mise à niveau - il n'est pas contraint de le faire. Il voit les avantages d'un système cohérent et vous voyez les avantages de l'exploitation de services partagés.  

Comment gérer les microservices en nuage dans les environnements GxP

À ce stade, j'espère que vous êtes enthousiasmé par les microservices, que vous comprenez la valeur qu'ils peuvent apporter et que vous savez comment les exploiter efficacement, même dans des environnements réglementés. Le défi consiste maintenant à déterminer comment les utiliser. Et la réponse à cette question est à prendre au cas par cas. Il peut être trop facile de tomber dans l'excès et de tout mettre en microservice, ce qui peut mener à l'échec. Nous vous conseillons d'examiner chaque capacité que vous ajoutez au cas par cas :  

  • Quel est le schéma d'utilisation - y a-t-il des pics et des creux qui pourraient bénéficier d'une mise à l'échelle automatique ?  
  • À quoi ressemble l'utilisation des ressources ? Elle pourrait être suffisamment importante pour être séparée de votre application existante afin d'éviter les problèmes de stabilité.  
  • Peut-il être partagé entre plusieurs applications et/ou plusieurs clients ?  
  • Coûts d'exécution - prendre en compte les ressources informatiques, la maintenance et toutes les autres ressources dont le service peut avoir besoin et utiliser objectivement ces informations pour prendre une décision éclairée.  
  • Le service peut-il bénéficier d'une pile technologique plus optimisée en se découpant pour répondre aux exigences ? La beauté des microservices réside dans le fait que l'outillage peut être complètement différent de celui des autres services fonctionnant dans le cadre de votre plateforme. En d'autres termes, choisissez le bon outil pour le bon travail !  
  • À quelle vitesse souhaitez-vous mettre en production de nouvelles fonctionnalités ? Une architecture de microservices peut se prêter à la livraison rapide de nouvelles capacités.  
  • Quel est le contexte délimité du microservice ? Considérez ses responsabilités et assurez-vous que les limites sont appropriées afin que vous ne soyez pas trop petit et que vous ne distribuiez pas le domaine à travers plusieurs microservices.  
  • Dans le prolongement du contexte délimité, si la fonctionnalité est limitée à un cas d'utilisation particulier et qu'aucune des options ci-dessus n'a été retenue, il convient d'envisager la possibilité de distribuer la logique du domaine plutôt que de la conserver là où elle se trouve actuellement si elle est préexistante - ce qui peut entraîner des défis et des coûts différents.  

Conformité aux bonnes pratiques de fabrication  

Comme indiqué ci-dessus, l'utilisation de microservices peut offrir de nombreux avantages, notamment une amélioration des performances, une simplification de la maintenance et une flexibilité des déploiements et des mises à niveau. Pour les systèmes utilisés dans des environnements réglementés par le GxP, il y a aussi l'avantage supplémentaire d'introduire de nouvelles fonctionnalités plus rapidement et avec moins de temps et d'efforts de revalidation par rapport à une mise à niveau complète du système en raison de l'impact limité des microservices sur l'ensemble de l'application.    

Comme pour tous les systèmes fonctionnant dans un environnement réglementé par les BPx, il est important de maintenir le système dans un état validé et d'introduire tout changement dans l'application de manière contrôlée. Cela s'applique aux microservices comme à tout autre composant de l'application. Pour maintenir l'état validé de toute solution SaaS, il est important de s'associer à un fournisseur qui comprend les besoins des clients réglementés.   

Chez IDBS, nous comprenons les besoins de nos clients réglementés et nous l'avons démontré en fournissant et en maintenant avec succès des applications basées sur SaaS à nos clients réglementés. Tous les associés d'IDBS sont tenus de suivre une formation annuelle sur le GxP et des évaluations des risques GxP sont effectuées dans le cadre du cycle de développement logiciel (SDLC) de notre ingénierie.   

 

Ce blog accompagne notre panel de discussion sur Déployer et gérer des microservices en nuage dans un environnement GxP  

Pour en savoir plus sur l'IDBS GxP Cloud, cliquez ici !

Plus de nouvelles