Tout le monde parle de microservices maintenant. Presque chaque réunion, conférence et réunion n'est pas complète sans une histoire sur ce que sont les microservices et à quel point ils sont bons, comment ils réduisent la complexité du projet, etc.
Le message principal de tous ces rapports - les microservices aident à échapper à la complexité et à la complexité excessives du projet. Mais, pour moi, on ne peut pas se débarrasser du tout de la complexité, on ne peut pas refaire le projet pour que tout devienne simple à la fois. La difficulté se déplacera d'une zone à l'autre.
Par exemple: il y avait un monolithe enchevêtré très compliqué, nous l'avons divisé en plusieurs services, chacun d'eux a fière allure, n'importe qui peut comprendre le code, mais qu'arrive-t-il à l'environnement? La complexité augmente: ce sont des transactions distribuées qui doivent être enregistrées afin de comprendre qu'il s'agit d'une transaction unique; CI / CD et livraison sont ajoutés pour chaque service; le schéma d'interaction devient non trivial.
Les thèses ou déclarations les plus controversées que j'ai entendues dans les rapports et avec lesquelles je suis prêt à discuter:
Entrer dans un projet monolithique est plus cher pour les nouveaux membres de l'équipe . Pour une raison quelconque, il est habituel d'évaluer le coût de l'adhésion à un projet en fonction de la rapidité avec laquelle un nouveau développeur commence à effectuer des tâches. Oui, il le découvrira très rapidement dans un petit service et exécutera la tâche très rapidement (surtout selon le cahier des charges, «ce qu'ils ont écrit, alors j'ai fait»).
Mais qu'en est-il des autres membres de l'équipe?
Le nouveau testeur traitera du modèle d'intégration. Tester un service est bon, mais en plus de tester un contrat de service, vous devez vérifier un processus métier qui affecte plusieurs services.
Au début, le nouvel analyste peut même se casser la tête, jusqu'à ce qu'il comprenne toutes les subtilités des défis internes.
Les microservices vous permettent de publier plus souvent . Les microservices sont plus rapides à affiner, car ils sont divisés en plusieurs tâches parallèles qui sont développées et testées en parallèle, et il ne reste plus qu'à vérifier l'intégration (sans tenir compte du temps d'analyse).
Vous pouvez aussi le faire avec un monolithe, tout dépend de la décomposition de la tâche. Le plus souvent, au tout début, il y aura une tâche - créer des fonctionnalités générales (pour corriger la base de données générale ou modifier l'interface), puis tout le monde verra ses sous-tâches et les donnera pour les tests.
Et le délai de sortie des fonctionnalités que l'entreprise paie sera le même. La fonction ne sera fermée que lorsque tous les composants seront libérés. Les microservices peuvent résoudre 99% des tâches, mais jusqu'à la fermeture de la dernière fonctionnalité, ils ne seront pas publiés au combat.
De quoi d'autre ils ne parlent pas
La difficulté grandit
Lors de l'utilisation de microservices, l'
infrastructure est compliquée . Cela est dû au fait que vous devez prendre en charge le travail non pas d'une seule application, mais de nombreux services. Il est nécessaire de surveiller les performances de tous les services, de bien comprendre les dépendances des services par version, d'avoir des plans CI / CD pour assembler les services et la livraison, des mécanismes pour répondre aux pannes de service, afin que tout le reste ne baisse pas.
Cela semble être des choses simples, et dans un monolithe, nous devons faire de même. Ce n'est que dans le monolithe que nous travaillons sur une seule application, et avec l'augmentation du nombre de services, la complexité augmente, ce qui nécessite de prendre en charge des compétences plus élevées.
Les microservices ajoutent de la complexité - nouvelles bibliothèques, nouvelles fonctionnalités pour prendre en charge les transactions distribuées, pour gérer les erreurs d'autres services, envoyer des demandes répétées, annuler les transactions. Pour la plupart, ces mécanismes seront communs et la plupart des développeurs n'entreront pas dans les tripes, mais les utiliseront uniquement.
Mais il peut y avoir des erreurs qui devront être corrigées. Si nous faisons face à la réparation sans aucun problème, puis pour déployer les modifications des services 200-300, cela prendra du temps et des contrôles développés. Et si vous avez besoin de reconstruire les services avec la bibliothèque mise à jour, ou même de refaire les appels (ils l'ont réparé comme ça, ne l'ont pas prévu), alors tout cela ne sera pas amusant.
Monolith - pas une grosse boule de boue
Comment les histoires sur le magnifique monde des microservices commencent-elles habituellement? «Nous avions un monolithe, c'était un solide tas de boue, dans lequel tout est déroutant et incompréhensible», en plus ils donneront une image terrible. Et le monolithe est déjà devenu quelque chose d'effrayant, "vous travaillerez mal, votre projet se transformera en monolithe".
Mais NON.Un monolithe peut être (et devrait) être clair, structuré, avec un `` bon '' code, avec de la documentation, tout comme un projet de microservice peut se transformer en un tas de saleté encore plus grand si vous ne vous engagez pas dans des processus de développement et ne surveillez pas la qualité du développement.
Alors quoi utiliser?
Bonne question, et vous seul pouvez y répondre. Parce que vous seul savez quels problèmes commerciaux vous décidez, quel sera le projet. Il n'y a pas de solution miracle, aucune architecture idéale ne peut être utilisée et il y aura toujours du «bonheur».
Et dans le monolithe et dans les microservices, suivez la documentation et tenez-la à jour. Avec la documentation, c'est mieux que sans.
Construisez un processus de développement dans lequel la qualité du code ne fera que croître (revues, tests unitaires). Mais sur la qualité, vous pouvez écrire un livre entier, c'est un sujet pour une grande conversation séparée.
Un code simple et compréhensible ne concerne pas les microservices, le code devrait être comme ça a priori.
L'automatisation des tests concerne également la qualité du code.
Automatisez tout ce que vous pouvez automatiser - CI / CD. Il existe probablement une pile technologique très difficile à intégrer dans CI / CD, mais 99% des assemblages / livraisons peuvent être automatisés.