Mis à jours 22 mai 2018 Suivez ces étapes pour assurer une transition réussie de l’application monolithique aux microservices distribués.
Adopter des microservices pour des applications modernes n’est plus un facteur de différenciation, mais un impératif pour les organisations qui veulent rester pertinentes sur le marché actuel. Le rythme de l’innovation technologique fait en sorte que les entreprises évoluent plus rapidement, plus intelligemment et plus efficacement, ce qui signifie que la modernisation de l’informatique est nécessaire afin de rester en avance sur ses concurrents et de développer ses activités.
Il y a de nombreuses leçons clés de mise en œuvre progressive d’un système de traitement de données à très grande échelle pour les journaux et les métriques. Pour vous épargner de certaines difficultés, voici sept conseils sur la façon d’exploiter les microservices pour faire évoluer votre entreprise.
1. Mettez en place des unités de développement de production
D’abord, vous devez configurer vos équipes. Vous pouvez appliquer un modèle appelé unités de développement de produit (PDU). Les PDU sont des unités complètes qui possèdent un ensemble de microservices. Cela permet de garder les petites équipes concentrées sur des projets spécifiques et évite les complications liées au fait d’avoir trop de mains sur un ensemble de microservices. C’est essentiellement l’idée de la règle « deux pizzas » rendue célèbre par Jeff Bezos chez Amazon, ce qui signifie que si vous ne pouvez pas nourrir une équipe avec deux pizzas, alors l’équipe est trop grande.
Bien que les PDU soient assez solides en raison de leurs connaissances opérationnelles et de leur expertise autour de certaines parties du produit, il existe des inconvénients lorsque vous devez déployer des modifications transversales. (Un exemple de projet impliquant tous les microservices était la transition de Java 7 à Java 8.) Obtenir toutes les PDU pour exécuter le changement transversal n’est pas facile, mais si votre équipe communique efficacement, cela peut être fait. Habituellement, vous devez désigner une personne pour assurer toute la communication et le gardiennage autour d’un tel changement, et cette personne envoie autour d’une liste de microservices à code couleur une liste de distribution relativement grande. Les gens ne veulent pas voir leurs services apparaître en ROUGE.
2. Changez la structure de votre organisation pour encourager la propriété
La façon dont vous allez diviser vos équipes change avec le temps. Par exemple, au début, c’était quatre ou cinq développeurs et une poignée de microservices. Maintenant, l’équipe est beaucoup plus grande et vous aurez 40 ou 50 microservices. À l’origine, le fait que chaque service appartenait à une personne ou à une équipe n’avait aucun sens, car l’architecture évoluait toujours rapidement. Mais au fur et à mesure que l’équipe grandissait et que les pierres angulaires de l’architecture se mettaient en place, vous pouvez répartir les services entre plusieurs équipes.
Il est extrêmement important que les personnes qui construisent le logiciel en prennent pleinement possession. En d’autres termes, non seulement ils construisent des logiciels, mais ils les testent, les déploient et les exécutent également. Ils sont responsables de tout le cycle de vie. Vous aimeriez la responsabilité que cela crée. D’un autre côté, les gens ont également besoin de suffisamment de libertés pour être entièrement propriétaires de leur travail et se sentir habilités à prendre des décisions concernant le logiciel. Si ce sont eux qui sont réveillés par leur code au milieu de la nuit, il faut aussi leur faire confiance pour prendre des décisions en temps de jeu.
En fin de compte, cela ressemble beaucoup à un système fédéral et à une culture dans la société, où il existe un système fondé sur plusieurs unités indépendantes qui s’unissent pour atteindre un objectif plus important. Cela limite dans une certaine mesure l’indépendance des unités, mais au sein des plus petits groupes, elles sont habilitées à prendre elles-mêmes autant de décisions dans le cadre de lignes directrices établies à un niveau supérieur.
3. Déterminez les limites du service
Lors de l’établissement des limites de service, une partie revient à l’intuition pure. Cependant, comme tout le monde, vous devez saisir un tableau blanc et commencer à identifier les principaux composants du système, puis vous devez dessiner des boîtes autour d’eux.
Au début, vous allez établir une limite stricte pour les microservices – une stratégie sur laquelle vous seriez très catégoriques. Au départ, vous avez des dépôts séparés pour tout. Vous seriez gravés dans des travaux précédents avec des systèmes monolithiques parce que les gens ne pouvaient même pas suivre les conventions de base de l’organisation de code, comme ce qui devrait aller dans quel paquet Java, et quel paquet ne devrait jamais appeler d’autres paquets. Donc, afin de garder le couplage faible, il faut être radical sur ce point. Vous vous retrouviez avec un dépôt monolithique et des limites plus souples finalement, mais cela fonctionne aujourd’hui parce que vous aviez enseigné à toutes les équipes à respecter les limites.
Du point de vue de l’affacturage initial du système, l’expérience du domaine aide également – l’équipe initiale doit avoir une certaine expérience dans la construction de systèmes de gestion de journaux. Mais bien sûr, il y a eu des choses que vous devez brutalement vous tromper. Par exemple, à un moment donné, vous sépareriez l’indexation et la recherche de données, alors qu’elles auraient dû être le même module ou le même service. C’est un processus très lourd d’échanger ce qui est essentiellement les mêmes données entre ces clusters, et en plus d’ajouter de la latence, il a de mauvaises implications pour votre architecture. En fait, il vous faut deux à trois ans pour comprendre à quel point cette décision initiale affectait une partie essentielle de l’architecture, mais une fois que vous l’aviez fait, cela a grandement facilité la vie de vos développeurs.
4. Approche de la synchronisation des services mis à niveau avec prudence
Vous ne devriez pas exagérer le point suivant : la mise à niveau de tous les services à la fois est une mauvaise idée. C’est une idée absurde, et il devait y avoir un moyen plus efficace de s’y prendre. Bien sûr, c’est une connaissance courante aujourd’hui, et peut-être que c’était en 2010, mais parfois les gens doivent découvrir eux-mêmes ces vérités fondamentales.
À l’époque par exemple, Sumo Logic aviez déjà environ 25 services et une équipe d’environ 15 ou 20 personnes. L’alternative était de déployer le service de mises à niveau par service, ce qui semblait également absurde. Comment allez-vous mettre à niveau un service, le redémarrer et vous assurer qu’il fonctionne correctement 25 fois dans une fenêtre de maintenance de deux heures ? La réponse courte est que vous ne pouvez pas.
Alors, ils avaient inventé un concept appelé « groupes d’assemblage », qui sont des regroupements plus petits des 25 services. N’importe où entre deux et six de ces services seraient mis à niveau ensemble, ce qui s’est avéré être une entreprise beaucoup plus réaliste pour l’équipe.
5. Adoptez plusieurs façons de tester
Les tests sont difficiles avec les microservices, en particulier lorsque vous vous dirigez vers un modèle de déploiement continu. Pour lutter contre cela, vous devez investir – et continuez à investir assez fortement – dans l’intégration et les tests unitaires, et vous devez utiliser différentes méthodes de test en fonction de chaque circonstance.
Une approche est ce que nous appelons un « déploiement local », où vous exécutez la plupart des services sur un ordinateur portable pour obtenir un système entièrement opérationnel. Cependant, actuellement un ordinateur portable avec 16 Go de RAM a été mis à niveau aux limites d’exécution, de sorte que cela n’est pas facile.
La seconde variante est ce que nous appelons un « déploiement personnel ». Tout le monde possède son propre compte AWS et vos outils de déploiement seront tellement automatisés que vous pouvez afficher une instance complète dans AWS en 10 minutes environ. C’est l’avantage d’être né à 100% et élevé dans le cloud, spécifiquement AWS.
La troisième voie est ce que nous appelons « Stubborn », qui est le nom d’un module de talonnage. Stubborn vous permet d’écrire des bouts de microservices qui se comportent comme s’ils étaient le vrai service, et qui s’annoncent dans votre découverte de service comme s’il s’agissait de vrais services. Cependant, ils sont une implémentation factice qui fait quelque chose dont vous avez le contrôle. C’est beaucoup plus léger que l’exécution de tous ces services.
Par exemple, si vous travaillez sur des composants de recherche, vous avez toujours besoin du service qui connaît les clients existants. Vous avez également besoin du service qui connaît les utilisateurs et les partitions, mais vous n’avez pas vraiment besoin de la version réelle avec toute sa complexité et ses fonctionnalités. Vous avez juste besoin de quelque chose qui fait comme s’il y avait un utilisateur. Vous devez utiliser Stubborn dans des cas comme ça.
6. Apportez la sécurité avant et pendant la mise à niveau
Les clients accordent de plus en plus d’importance au respect des certifications telles que GDPR, HIPAA, PCI, etc.
Compte tenu de cela, la sécurité doit être construite à partir de zéro. Votre outil de déploiement est basé sur un modèle, et le modèle comprend non seulement des éléments tels que les clusters et les microservices, mais aussi comment ils se parlent. Vous pouvez générer un ensemble assez serré de contrôles de sécurité à partir de ce modèle.
Par exemple, au niveau du réseau, vous pouvez générer les règles du pare-feu strictement à partir de la compréhension de qui parle à qui. C’est l’un des endroits où AWS fait le gros du travail pour nous.
Construire sur le cloud peut être avantageux du point de vue de la sécurité. Vous ne pouvez rien faire à la main, tout doit donc être automatisé. Et une fois que vous commencez à scripter et automatiser tout, il devient soudainement beaucoup plus facile de tout lier par défaut.
Mais, la sécurité n’est pas seulement une question d’architecture et de code. En réalité, il y a une tonne de processus autour de cela. Plus précisément, les clients doivent consulter les rapports d’audit. Vous pouvez transformer cela en un avantage en examinant ce que les audits nécessitent en termes de contrôles, puis les tester. Ensuite, lorsque les auditeurs le testent à nouveau, il établit de bonnes habitudes.
7. Des wikis aux besoins spécifiques de votre organisation
La mise à l’échelle signifie accumuler beaucoup d’informations, et souvent rapidement. De nombreuses équipes de développement utilisent des pages wiki internes auxquelles ils peuvent se tourner pour documenter les informations et les meilleures pratiques. Cependant, s’ils sont laissés ouverts à l’édition par n’importe qui dans l’organisation, ceux-ci peuvent devenir un désordre d’information désorganisée. Un tel contenu est difficile à gérer et à maintenir, il est donc préférable de désigner un modérateur ou un conservateur responsable de la maintenance du wiki de votre organisation.
Si la désignation d’un modérateur peut sembler trop centralisée ou trop lourde pour une personne, il peut être difficile d’inciter un groupe de développeurs à garder les wikis à jour avec le temps. De plus, alors que les employés techniques (en particulier dans les entreprises en démarrage) sont souvent polyvalents, le leadership devrait accorder la priorité à l’entretien de cette documentation et des meilleures pratiques.
Les modérateurs Wiki devraient être stratégiques quant au contenu qu’ils organisent. Au lieu d’inclure tout, gardez-le limité aux concepts clés que les développeurs doivent comprendre. Trop de contenu peut être accablant et conduire à une sous-utilisation.
Diviser et conquérir avec les microservices
À la base, l’architecture des microservices consiste à diviser et à conquérir. Le système distribué qui doit être construit va être complexe. Une façon de gérer cela est d’essayer de limiter la complexité d’une partie donnée, et en suivant ces sept conseils, les organisations peuvent plus facilement s’attaquer à la transformation.
L’adoption d’une architecture de microservices est l’un des meilleurs moyens de mettre à l’échelle le système et les systèmes humains qui l’entourent, en particulier compte tenu de la complexité croissante des exigences fonctionnelles – et en particulier non fonctionnelles. Bien que la transition du monolithe aux microservices peut sembler une tâche ardue, si vous pouvez mobiliser les développeurs autour de l’idée et faire participer tous les membres, non seulement la transition sera gérable, mais cela simplifiera le processus de mise à l’échelle de l’organisation. Ce qui allège le travail des développeurs, et finalement, construit un système plus efficace qui répond mieux aux besoins des clients.
