Les microservices sont un coût que votre startup ne peut probablement pas se permettre

Par Oleg Pustovit

Les microservices sont un coût que votre startup ne peut probablement pas se permettre, par Oleg Pustovit

Pourquoi diviser votre base de code trop tôt peut discrètement détruire la vitesse de votre équipe — et ce qu'il faut faire à la place.


Dans une start-up, votre survie dépend de votre capacité à itérer rapidement, à livrer des fonctionnalités et à offrir de la valeur aux utilisateurs finaux. C'est là que l'architecture fondamentale de votre start-up joue un rôle important ; en outre, des éléments tels que votre pile technologique et le choix du langage de programmation ont une incidence directe sur la vitesse de votre équipe. Une architecture inadaptée, en particulier des microservices prématurés, peut nuire considérablement à la productivité et contribuer à la non-réalisation des objectifs en matière de livraison de logiciels.

J'ai vécu cette expérience en travaillant sur des projets entièrement nouveaux pour des startups en phase de démarrage, où des décisions discutables ont été prises en matière d'architecture logicielle, ce qui a conduit à des services à moitié finis, à des configurations locales fragiles, surdimensionnées et défaillantes, et à des équipes démoralisées qui peinent à maintenir une complexité inutile.

Avant d'aborder les pièges spécifiques, voici ce à quoi vous vous engagez réellement lorsque vous introduisez prématurément des microservices :

Les microservices dès le début : ce que vous payez


Voyons pourquoi les microservices se retournent souvent contre vous au début, où ils sont vraiment utiles et comment structurer les systèmes de votre start-up pour gagner en rapidité et assurer sa survie.

Les monolithes ne sont pas vos ennemis


Si vous développez un produit SaaS, même un simple wrapper de base de données SQL peut finir par apporter beaucoup de complexité interne au fonctionnement de votre logique métier. De plus, vous pouvez avoir recours à diverses intégrations et tâches en arrière-plan qui permettent de transformer un ensemble de données en un autre.

Avec le temps et des fonctionnalités parfois inutiles, il est inévitable que votre application devienne désordonnée. L'avantage des monolithes, c'est qu'ils continuent de fonctionner. Même lorsqu'ils sont désordonnés, les monolithes permettent à votre équipe de rester concentrée sur ce qui compte le plus :

• Rester en vie
• Offrir de la valeur ajoutée aux clients

Le plus grand avantage des monolithes est leur simplicité de déploiement. En général, ces projets s'articulent autour de frameworks existants, tels que Django pour Python, ASP.Net pour C#, Nest.js pour les applications Node.js, etc. En vous en tenant à une architecture monolithique, vous bénéficiez d'un avantage considérable par rapport aux microservices sophistiqués : un large soutien de la communauté open source et des responsables de projets qui ont principalement conçu ces frameworks pour fonctionner comme un processus unique, une application monolithique.

Dans une start-up immobilière où je dirigeais l'équipe front-end et où je conseillais occasionnellement l'équipe back-end sur les choix technologiques, nous avons connu une évolution intéressante d'une application basée sur Laravel. Ce qui avait commencé comme un petit tableau de bord destiné aux agents immobiliers pour gérer leurs transactions s'est progressivement transformé en un système beaucoup plus vaste.

Au fil du temps, il a évolué pour devenir une suite riche en fonctionnalités capable de traiter des centaines de gigaoctets de documents et s'intégrer à des dizaines de services tiers. Pourtant, il restait basé sur une pile PHP assez basique fonctionnant sous Apache.

L'équipe s'est fortement appuyée sur les meilleures pratiques recommandées par la communauté Laravel. Cette discipline a porté ses fruits, car nous avons pu augmenter considérablement les capacités de l'application tout en répondant aux besoins et aux attentes de l'entreprise.

Il est intéressant de noter que nous n'avons jamais eu besoin de découpler le système en microservices ou d'adopter des modèles d'infrastructure plus complexes. Nous avons ainsi évité beaucoup de complexité accidentelle. La simplicité de l'architecture nous a donné un avantage. Cela fait écho à ce que d'autres ont écrit, comme Basecamp dans son article sur le « Majestic Monolith », qui explique pourquoi la simplicité est un atout majeur dès le début.

On souligne souvent qu'il est difficile de rendre les monolithes évolutifs, mais c'est une mauvaise modularisation à l'intérieur du monolithe qui peut poser ce genre de problèmes.

À retenir : un monolithe bien structuré permet à votre équipe de se concentrer sur la livraison, et non sur la résolution de problèmes urgents.

Mais les microservices ne sont-ils pas la « meilleure pratique » ?

De nombreux ingénieurs se tournent rapidement vers les microservices, pensant qu'ils constituent « la bonne solution ». Et bien sûr, à grande échelle, ils peuvent être utiles. Mais dans une start-up, cette même complexité devient un frein.

Les microservices ne sont rentables que lorsque vous rencontrez de réels goulots d'étranglement en matière d'évolutivité, que vous disposez de grandes équipes ou que vous avez des domaines qui évoluent indépendamment. Avant cela ? Vous en payez le prix sans en tirer les avantages : infrastructure dupliquée, configurations locales fragiles et itération lente. Par exemple, Segment a finalement annulé la division en microservices pour cette raison précise : trop de coûts, pas assez de valeur.

À retenir : les microservices sont un outil de mise à l'échelle, pas un modèle de départ.

Quand les microservices échouent (surtout au début)

Dans une équipe en phase de démarrage que j'ai conseillée, la décision de diviser les services a créé plus de frais de coordination entre les chefs de projet et les ingénieurs que de gains techniques. L'architecture a façonné non seulement le code, mais aussi la façon dont nous planifiions, estimions et livrions. Cette charge organisationnelle est facile à négliger, jusqu'à ce qu'il soit trop tard.


Schéma : la charge de coordination augmente de manière linéaire avec les services, et de manière exponentielle lorsque vous ajoutez des chefs de produit, des délais et des calendriers mal alignés.

Voici les anti-modèles les plus courants qui apparaissent dès le début.

• 1. Limites arbitraires des services

En théorie, on voit souvent des suggestions visant à diviser les applications par domaine de logique métier : service utilisateurs, service produits, service commandes, etc. Ces suggestions s'inspirent souvent des concepts de conception orientée domaine ou d'architecture propre, qui ont du sens à grande échelle, mais qui, dans les produits en phase de démarrage, peuvent rigidifier prématurément la structure, avant que le produit lui-même ne soit stable ou validé. Vous vous retrouvez alors avec :

• Des bases de données partagées
• Des appels interservices pour des workflows simples
• Un couplage déguisé en « séparation »

Dans le cadre d'un projet, j'ai vu une équipe séparer les utilisateurs, l'authentification et l'autorisation en services distincts, ce qui a compliqué le déploiement et rendu difficile la coordination des services pour toutes les opérations API qu'ils développaient.

En réalité, la logique métier ne correspond pas directement aux limites des services. Une séparation prématurée peut rendre le système plus fragile et souvent difficile à modifier rapidement.

Il vaut mieux isoler les goulots d'étranglement de manière chirurgicale, en se basant sur les difficultés réelles de mise à l'échelle et non sur l'élégance théorique.

Lorsque j'ai coaché des équipes en phase de démarrage, nous avons parfois utilisé des indicateurs internes ou des commutateurs de déploiement pour simuler de futures divisions de services, sans charge opérationnelle immédiate. Cela a donné aux équipes produit et ingénierie la possibilité d'explorer les limites de manière organique, avant de se fixer sur une infrastructure prématurée.

À retenir : ne divisez pas en fonction de la théorie, mais en fonction des goulots d'étranglement réels.

• 2. Prolifération des référentiels et des infrastructures

Lorsque vous travaillez sur l'application, les éléments suivants sont généralement importants :

• Cohérence du style de code (linting)
• Infrastructure de test, y compris les tests d'intégration
• Configuration de l'environnement local
• Documentation
• Configuration CI/CD

Lorsque vous travaillez avec des microservices, vous devez multiplier ces exigences par le nombre de services. Si votre projet est structuré comme un monorepo, vous pouvez vous simplifier la vie en disposant d'une configuration CI/CD centrale (lorsque vous travaillez avec GitHub Actions ou GitLab CI). Certaines équipes séparent les microservices en référentiels distincts, ce qui rend beaucoup plus difficile le maintien de la cohérence du code et du même ensemble de configurations sans effort ou outils supplémentaires.


Pour une équipe de trois personnes, c'est brutal. Le changement de contexte entre les référentiels et les outils allonge le temps de développement de chaque fonctionnalité livrée.

Atténuer les problèmes en utilisant des monorepos et un seul langage de programmation

Il existe différentes façons d'atténuer ce problème. Pour les projets en phase initiale, la chose la plus importante est de conserver votre code dans un monorepo. Cela garantit qu'il n'existe qu'une seule version du code en production, et il est beaucoup plus facile de coordonner les revues de code et de collaborer pour les petites équipes.

Pour les projets Node.js, je recommande vivement d'utiliser un outil monorepo tel que nx ou turborepo. Les deux :

• Simplifient la configuration CI/CD entre les sous-projets.
• Prennent en charge la mise en cache de la compilation basée sur un graphe de dépendances.
• Vous permettent de traiter les services internes comme des bibliothèques TypeScript (via les importations ES6).

Ces outils permettent de gagner du temps qui serait autrement consacré à l'écriture de code de liaison ou à la réinvention de l'orchestration. Cela dit, ils présentent de réels inconvénients :

• Les arbres de dépendances complexes peuvent se développer rapidement.
• L'optimisation des performances CI n'est pas triviale.
• Vous aurez peut-être besoin d'outils plus rapides (comme bun) pour réduire les temps de compilation.

En résumé : des outils tels que nx ou turborepo offrent aux petites équipes la vitesse du monorepo, à condition que vous soyez prêt à investir pour les maintenir propres.

Lors du développement de microservices basés sur Go, il est judicieux, dès le début du développement, d'utiliser un seul espace de travail Go avec la directive replace dans go.mod. À terme, à mesure que le logiciel évolue, il est possible de séparer sans effort les modules Go dans des référentiels distincts.

À retenir : un monorepo avec une infrastructure partagée vous fait gagner du temps, vous apporte de la cohérence et vous permet de garder votre santé mentale.

• 3. Développement local défaillant = vitesse défaillante

Si vous avez besoin de trois heures, d'un script shell personnalisé et d'un marathon Docker juste pour exécuter votre application localement, vous avez déjà perdu en vitesse.

Les premiers projets souffrent souvent des problèmes suivants :

• Documentation manquante
• Dépendances obsolètes
• Hacks spécifiques au système d'exploitation (bonjour les configurations réservées à Linux)

D'après mon expérience, lorsque je recevais des projets d'anciennes équipes de développement, ceux-ci étaient souvent développés pour un seul système d'exploitation. Certains développeurs préféraient travailler sur macOS et ne se souciaient pas de rendre leurs scripts shell compatibles avec Windows. Dans mes anciennes équipes, j'avais des ingénieurs qui travaillaient sur des machines Windows, et il fallait souvent réécrire les scripts shell ou comprendre et rétroconcevoir entièrement le processus permettant de faire fonctionner l'environnement local. Avec le temps, nous avons standardisé la configuration de l'environnement sur tous les systèmes d'exploitation de développement afin de réduire les frictions liées à l'intégration, un petit investissement qui a permis de gagner des heures par nouvel ingénieur. C'était frustrant, mais cela nous a appris une leçon durable sur l'importance de faire fonctionner le code sur n'importe quel ordinateur portable utilisé par votre nouveau développeur.

Dans le cadre d'un autre projet, un développeur solo avait créé une configuration de microservices fragile, dont le workflow consistait à exécuter des conteneurs Docker montés sur un système de fichiers local. Bien sûr, l'exécution de processus sous forme de conteneurs sur un ordinateur fonctionnant sous Linux a un petit coût.

Mais l'intégration d'un nouveau développeur front-end avec un ancien ordinateur portable Windows s'est transformée en cauchemar. Il a fallu lancer dix conteneurs juste pour afficher l'interface utilisateur. Tout était défectueux (volumes, réseau, compatibilité des conteneurs) et la configuration était très mal documentée. Cela a créé un point de friction majeur lors de l'intégration.

Nous avons fini par bricoler un proxy Node.js qui imitait la configuration nginx/Docker sans conteneurs. Ce n'était pas très élégant, mais cela a permis au développeur de débloquer la situation et de commencer à contribuer.


À retenir : si votre application ne fonctionne que sur un seul système d'exploitation, la productivité de votre équipe est à deux doigts du désastre.

Conseil : dans l'idéal, visez git clone <repo> && make pour que le projet fonctionne localement. Si ce n'est pas possible, il est indispensable de maintenir à jour un fichier README contenant des instructions pour Windows/macOS/Linux. De nos jours, certains langages de programmation et chaînes d'outils ne fonctionnent pas bien sous Windows (comme OCaml), mais la pile moderne largement répandue fonctionne très bien sur tous les systèmes d'exploitation couramment utilisés ; limiter votre configuration locale à un seul système d'exploitation est souvent le signe d'un sous-investissement dans l'expérience développeur.

• 4. Inadéquation technologique

Au-delà de l'architecture, votre pile technologique détermine également le degré de difficulté des microservices : tous les langages ne sont pas adaptés à une architecture de microservices.

• Node.js et Python : excellents pour les itérations rapides, mais la gestion des artefacts de construction, des versions de dépendances et de la cohérence d'exécution entre les services devient rapidement difficile.
• Go : compilation en binaires statiques, temps de construction rapides et faible surcharge opérationnelle. Plus naturel lorsque la division est vraiment nécessaire.

Il est très important de choisir la bonne pile technologique dès le début. Si vous recherchez la performance, vous pouvez vous tourner vers la JVM et son écosystème, ainsi que sa capacité à déployer des artefacts à grande échelle et à les exécuter dans des architectures basées sur des microservices. Si vous effectuez des itérations très rapides et prototypez rapidement sans vous soucier de la mise à l'échelle de votre infrastructure de déploiement, Python est un bon choix.

Il arrive souvent que les équipes se rendent compte que leur choix technologique pose des problèmes importants qui n'étaient pas apparents au départ, et qu'elles doivent payer le prix de la refonte du back-end dans un autre langage de programmation (comme ces développeurs qui ont été contraints de faire quelque chose pour le code Python 2 hérité et ont migré vers Go).

Mais au contraire, si vous en avez vraiment besoin, vous pouvez relier plusieurs langages de programmation à l'aide de protocoles tels que gRPC ou la communication asynchrone par messages. Et c'est souvent la meilleure solution. Lorsque vous en arrivez au point où vous souhaitez enrichir votre ensemble de fonctionnalités avec des fonctionnalités d'apprentissage automatique ou des tâches basées sur ETL, il vous suffit de construire séparément votre infrastructure basée sur l'apprentissage automatique en Python, en raison de son riche écosystème de bibliothèques spécifiques au domaine, dont aucun autre langage de programmation ne dispose naturellement. Mais de telles décisions doivent être prises lorsque l'effectif est suffisant pour justifier cette entreprise ; sinon, la petite équipe sera éternellement entraînée dans la complexité sans fin de la connexion de plusieurs piles logicielles entre elles.

À retenir : adaptez la technologie à vos contraintes, et non à vos ambitions.

• 5. Complexité cachée : communication et surveillance

Les microservices introduisent un réseau invisible de besoins :

• Découverte des services
• Gestion des versions des API
• Réessais, disjoncteurs, solutions de secours
• Traçage distribué
• Journalisation et alertes centralisées

Dans un système monolithique, un bug peut être une simple trace de pile. Dans un système distribué, la question est « pourquoi le service A échoue-t-il lorsque le déploiement de B est en retard de 30 secondes par rapport à C ? » Vous devrez investir massivement dans votre pile d'observabilité. Pour le faire « correctement », vous devrez instrumenter vos applications de manière spécifique, par exemple en intégrant OpenTelemetry pour prendre en charge le traçage, ou en vous appuyant sur les outils de votre fournisseur de cloud comme AWS XRay si vous optez pour un système sans serveur complexe. Mais à ce stade, vous devez complètement délaisser le code de l'application pour vous concentrer sur la mise en place d'une infrastructure de surveillance complexe qui permettra de vérifier si votre architecture fonctionne réellement en production.

Bien sûr, certaines instruments d'observabilité doivent être mises en place sur des applications monolithiques, mais c'est beaucoup plus simple que de le faire de manière cohérente pour un grand nombre de services.

Conseil : comprenez que les systèmes distribués ont un coût. Ils impliquent de relever toute une série de nouveaux défis techniques.

Quand les microservices ont du sens

Malgré les difficultés mentionnées avec les microservices, il existe des cas où le découplage au niveau des services est en fait très avantageux. Il existe des cas où cela aide vraiment :

• Isolement de la charge de travail : un exemple courant serait les meilleures pratiques AWS sur l'utilisation des notifications d'événements S3 — lorsqu'une image est chargée sur S3, déclencher un processus de redimensionnement d'image/OCR, etc. Pourquoi est-ce utile ? Nous pouvons découpler des bibliothèques de traitement de données obscures dans un service auto-isolé et créer une API axée uniquement sur le traitement d'images et la génération de résultats à partir des données téléchargées. Vos clients en amont qui téléchargent des données vers S3 ne sont pas couplés à ce service, et la mise en place d'un tel service est moins coûteuse en raison de sa relative simplicité.
• Besoins de scalabilité divergents : imaginez que vous développez un produit d'IA. Une partie du système (API web) qui déclenche les charges de travail ML et affiche les résultats passés n'est pas gourmande en ressources, elle est légère, car elle interagit principalement avec la base de données. Au contraire, le modèle ML qui s'exécute sur des GPU est en fait lourd à exécuter et nécessite des machines spéciales avec prise en charge GPU et configuration supplémentaire. En séparant ces parties de l'application en services distincts s'exécutant sur différentes machines, vous pouvez les faire évoluer indépendamment.
• Exigences d'exécution différentes : — Supposons que vous disposiez d'une partie du code hérité écrite en C++. Vous avez deux choix : le convertir comme par magie dans votre langage de programmation principal ou trouver des moyens de l'intégrer à une base de code. En fonction de la complexité de cette application héritée, vous devrez écrire du code de liaison, implémenter des réseaux/protocoles supplémentaires pour établir des interactions avec ce service, mais en fin de compte, vous devrez probablement séparer cette application en tant que service distinct en raison d'incompatibilités d'exécution. J'irais même plus loin en disant que vous pourriez également écrire votre application principale en C++, mais en raison des différentes configurations de compilateur et des dépendances de bibliothèque, vous ne pourriez pas facilement compiler le tout en un seul binaire.

Les grandes organisations d'ingénierie ont été confrontées à des défis similaires. Par exemple, l'équipe d'ingénieurs d'Uber a documenté son passage à une architecture de microservices orientée domaine, non pas par souci de pureté théorique, mais en réponse à la complexité réelle entre les équipes et aux limites de mise à l'échelle. Leur article est un bon exemple de la façon dont les microservices peuvent fonctionner lorsque vous disposez de la maturité organisationnelle et des frais généraux opérationnels nécessaires pour les prendre en charge.

Dans le cadre d'un projet, qui se trouve être également un projet immobilier, nous disposions du code d'une équipe précédente qui exécutait des charges de travail analytiques basées sur Python et chargeait des données dans une base de données MS-SQL. Nous avons constaté qu'il serait inutile de construire une application Django par-dessus. Le code avait différentes dépendances d'exécution et était assez isolé, nous l'avons donc conservé séparément et ne l'avons revisité que lorsque quelque chose ne fonctionnait pas comme prévu. Cela a fonctionné pour nous, même pour une petite équipe, car ce service de génération d'analyses était une partie qui nécessitait rarement des modifications ou de la maintenance.

À retenir : utilisez les microservices lorsque les charges de travail divergent, et pas seulement parce qu'ils semblent propres.

Conseils pratiques pour les startups

Si vous lancez votre premier produit, voici la stratégie que je vous recommande :

• Commencez par une approche monolithique. Choisissez un framework courant et concentrez-vous sur la mise en place des fonctionnalités. Tous les frameworks connus sont largement suffisants pour créer une API ou un site web et répondre aux besoins des utilisateurs. Ne suivez pas la mode, restez fidèle à une approche classique ; vous vous en remercierez plus tard.
• Un seul dépôt. Ne vous embêtez pas à diviser votre code en plusieurs dépôts. J'ai travaillé avec des fondateurs qui voulaient séparer les dépôts afin de réduire le risque que les sous-traitants copient la propriété intellectuelle, une préoccupation légitime. Mais dans la pratique, cela a ajouté plus de friction que de sécurité : des builds plus lents, une CI/CD fragmentée et une mauvaise visibilité entre les équipes. La protection marginale de la propriété intellectuelle ne valait pas la peine de ralentir les opérations, d'autant plus que les contrôles d'accès appropriés au sein d'un monorepo étaient plus faciles à gérer. Pour les équipes en phase de démarrage, la clarté et la rapidité ont tendance à être plus importantes que les gains théoriques en matière de sécurité.
• Configuration locale ultra simple. Faites le travail de préparation. Si cela demande plus de temps, soyez très précis sur les étapes, enregistrez une vidéo/Loom et ajoutez des captures d'écran. Si votre code doit être exécuté par un stagiaire ou un développeur junior, ils risquent de se heurter à un obstacle et vous passerez du temps à leur expliquer comment résoudre le problème. J'ai constaté que le fait de documenter tous les problèmes possibles pour chaque système d'exploitation permettait d'éviter de passer du temps à expliquer pourquoi certaines choses ne fonctionnaient pas dans une configuration locale.
• Investissez tôt dans le CI/CD. Même s'il s'agit d'un simple HTML que vous pourriez simplement copier manuellement sur un serveur, vous pouvez automatiser cette opération et vous fier au contrôle de source avec CI/CD pour le faire. Lorsque la configuration est correctement automatisée, vous n'avez plus à vous soucier de votre infrastructure d'intégration continue et vous pouvez vous concentrer sur les fonctionnalités. J'ai vu de nombreuses équipes et fondateurs, lorsqu'ils travaillent avec des équipes externalisées, faire souvent des économies sur le CI/CD, ce qui a pour conséquence de démoraliser l'équipe et de l'agacer avec des processus de déploiement manuels.
• Divisez de manière chirurgicale. Ne divisez que lorsque cela permet clairement de résoudre un goulot d'étranglement douloureux. Sinon, investissez dans la modularité et les tests à l'intérieur du monolithe : c'est plus rapide et plus facile à maintenir.

Et surtout : optimisez la vitesse de développement.

La vitesse est l'oxygène de votre startup. Les microservices prématurés font lentement fuir cet oxygène, jusqu'au jour où vous ne pouvez plus respirer.

À retenir : commencez simplement, restez pragmatique et ne divisez que lorsque vous y êtes obligé.

Si vous optez pour une approche basée sur les microservices

J'ai eu des projets basés sur les microservices créés plus tôt qu'ils n'auraient dû l'être, et voici les recommandations que je pourrais donner à ce sujet :

• Évaluez votre pile technique qui alimente votre architecture basée sur les microservices. Investissez dans des outils d'expérience développeur. Lorsque vous disposez d'une séparation basée sur les services, vous devez désormais réfléchir à l'automatisation de votre pile de microservices, en automatisant la configuration à la fois dans les environnements locaux et de production. Dans certains projets, j'ai dû créer une CLI distincte qui effectue des tâches administratives sur le monorepository. L'un de mes projets comprenait 15 à 20 déploiements de microservices et, pour l'environnement local, j'ai dû créer un outil CLI permettant de générer dynamiquement des fichiers docker-compose.yml afin de permettre aux développeurs habituels de démarrer le système en toute transparence à l'aide d'une seule commande.
• Concentrez-vous sur des protocoles de communication fiables pour la communication entre les services. S'il s'agit de messagerie asynchrone, assurez-vous que vos schémas de messages sont cohérents et standardisés. S'il s'agit de REST, concentrez-vous sur la documentation OpenAPI. Les clients de communication inter-services doivent implémenter de nombreux éléments qui ne sont pas prêts à l'emploi : réessais avec recul exponentiel, délais d'expiration. Un client gRPC basique typique vous oblige à prendre en compte manuellement ces éléments supplémentaires pour vous assurer de ne pas souffrir d'erreurs transitoires.
• Assurez-vous que votre configuration de tests unitaires, d'intégration et de bout en bout est stable et évolutive en fonction du nombre de séparations au niveau des services que vous introduisez dans votre base de code.
• Dans le cadre de projets plus modestes utilisant des charges de travail basées sur des microservices, vous opterez probablement par défaut pour une bibliothèque partagée avec des aides communes afin d'instrumenter votre observabilité et votre code de communication de manière cohérente. Il est important de garder votre bibliothèque partagée aussi petite que possible. Tout changement majeur oblige à reconstruire tous les services dépendants, même s'ils ne sont pas liés.
  
  
  
• Intéressez-vous à l'observabilité dès le début. Ajoutez des journaux JSON structurés et créez divers identifiants de corrélation pour le débogage une fois votre application déployée. Même les aides de base qui fournissent des informations de journalisation riches (jusqu'à ce que vous ayez équipé votre application de fonctionnalités de journalisation/traçage appropriées) permettent souvent de gagner du temps pour comprendre les flux d'utilisateurs instables.

En résumé : si vous optez toujours pour les microservices, vous devez comprendre à l'avance le coût que cela représentera en termes de temps de développement et de maintenance supplémentaires pour que la configuration soit viable pour tous les ingénieurs de votre équipe.

À retenir : si vous acceptez la complexité, investissez pleinement pour la rendre gérable.

Conclusion

Les microservices prématurés sont un coût que vous ne pouvez pas vous permettre. Restez simple. Restez en vie. Ne divisez que lorsque la douleur le rend évident.

Survivez d'abord. Évoluez ensuite. Choisissez le système le plus simple qui fonctionne et gagnez chaque couche de complexité que vous ajoutez.

Source : "Microservices Are a Tax Your Startup Probably Can’t Afford"

Et vous ?

Pensez-vous que ces recommandations sont crédibles ou pertinentes ?
Quel est votre avis sur le sujet ?

Voir aussi :

Les microservices ne sont pas le problème. Ce sont les personnes incompétentes qui le sont, par Dmitry Non

Lors de la conception de systèmes logiciels, faites la chose la plus simple qui puisse fonctionner, par Sean Goedecke

Développement de logiciels à long terme, par Bert Hubert