Je propose de parler du moment où les microservices sont nécessaires et quand non. Spoiler: cela dépend du projet.

Nous, développeurs de logiciels, avons un métier assez intéressant. Nous pouvons coder en toute sécurité toute la journée, puis lire un article sur quelque chose - et cela remet en question tout notre travail, car certains Netflix a dit à XYZ.

Juste comme ça, à cause de l'opinion d'une personne ou d'une entreprise, vous commencez à douter de tout ce que vous faites depuis de nombreuses années, même si tout fonctionnait parfaitement.

Vous n'êtes pas Google (sauf si vous êtes Google)

Lorsque nous lisons HackerNews et d'autres sites d'actualités, nous voyons souvent des messages techniques de Google, Netflix, Amazon et Facebook, et ils aiment parler du nombre de centaines ou de milliers de services qu'ils lancent. Ils parlent des avantages de faire les choses à leur façon. C'est une tendance des dernières années.

Mais avouons-le. Il est peu probable que vous ayez 1000 développeurs qui travaillent sur un projet massif avec plus de 10 ans d'histoire.

Ce n'est pas parce que Google le fait que vous devez le faire non plus.

Nous travaillons dans une galaxie complètement différente. Google est confronté à des problèmes que nous ne rencontrerons probablement jamais, mais en même temps, nous pouvons faire des choses que Google ne peut pas.

Comment la plupart des projets logiciels démarrent-ils?

De nombreux projets commencent avec une seule personne qui fait tout le travail. Il y a un million d'exemples, mais jetons un coup d'œil à Shopify. Initialement, le service codait Tobias Lyutke (il était basé sur Ruby on Rails et fonctionne, soit dit en passant, sur rails).

Pensez-vous que Tobias était hésitant, réfléchissant minutieusement à l'architecture idéale pour les microservices, avant d'écrire la première ligne de code?

Enfer non. Je n'étais pas présent lors du développement de la première version de Shopify, qui n'était à l'origine qu'une boutique en ligne pour le snowboard, mais si Tobias me ressemble (un développeur typique), le processus ressemblait à ceci:

1. Apprenez de nouvelles technologies tout en écrivant le produit original.
2. Écrivez un code plutôt non standard (méchant), mais pleinement fonctionnel.
3. Voyez comment tout fonctionne ensemble et soyez excité.
4. Refactorisez comme "brûler avec le feu" et améliorez le code en cas de problème.
5. Répétez ce cycle lors de l'ajout de nouvelles fonctionnalités et du démarrage dans un environnement de production.

Cela peut sembler un cycle très simple, mais il m'a fallu environ 20 ans de programmation pour comprendre à quel point il est profond.

Vous ne devenez pas meilleur en tant que programmeur, réfléchissant théoriquement aux paramètres optimaux avant d'écrire la première ligne de code. Vous devenez meilleur en écrivant beaucoup de code avec l'intention absolue et explicite de remplacer presque tout ce que vous écrivez par un meilleur code, dès que vous commencez à rencontrer de vrais problèmes.

Le code d'origine que vous avez remplacé n'est pas une perte de temps ni d'efforts. Au fil du temps, cela vous aide beaucoup à améliorer votre niveau. Ceci est un ingrédient secret.

Parlez des abstractions de code

En tant que développeurs, nous avons tous entendu l'expression «SEC: ne vous répétez pas», et dans l'ensemble, il est raisonnable de ne pas refaire le travail. Mais cela vaut souvent la peine.

Il vaut la peine de répéter lorsque vous essayez d'abstraire quelque chose sans une compréhension complète et de créer ce qu'on appelle une abstraction qui fuit.

Je fais habituellement le travail trois fois avant de penser à refactoriser du code et à supprimer les doublons. Souvent, ce n'est qu'après la 4e ou la 5e fois que je prends certaines mesures.

Vous devez vraiment voir plusieurs fois comment vous dupliquez le code dans différentes situations avant qu'il ne devienne clair quoi traduire exactement en variables et supprimer des endroits où ce code a été écrit à l'origine.

Niveaux d'abstraction, du code intégré aux bibliothèques externes:

1. Écrivez le code en ligne.
2. Dupliquez le code à plusieurs endroits différents.
3. Extraire le code en double dans la fonction, etc.
4. Utilisez ces abstractions pendant un certain temps.
5. Découvrez comment ce code interagit avec un autre code.
6. Extraire des fonctionnalités générales dans la bibliothèque interne.
7. Pendant longtemps, utilisez la bibliothèque interne.
8. Comprenez vraiment comment toutes les pièces s'assemblent.
9. Créez une bibliothèque externe (open source, etc.), si cela a du sens.

Le fait est que vous ne pouvez pas «inventer» une bonne bibliothèque ou un bon framework. Presque tous les outils très efficaces que nous utilisons aujourd'hui proviennent de projets réels. Là, notre outil préféré est extrait de cas réels d'utilisation interne.

Rails est un excellent exemple. DHH (auteur de Rails) ne s'est pas réveillé un jour et a dit: «Oh! Il est temps de créer les répertoires modèles /, contrôleurs / et vues /! ".

Non. Il a développé Basecamp (le vrai produit), puis certains modèles sont apparus, et ces modèles ont été généralisés puis extraits de Basecamp dans Rails. Ce processus est toujours en cours aujourd'hui, et à mon avis, c'est la seule raison pour laquelle Rails reste si réussi.

C'est une tempête idéale d'abstractions très bien gérées (lire: non développées théoriquement) combinées à un langage de programmation qui vous permet d'écrire du code attrayant. Cela explique également pourquoi presque tous les frameworks comme «Rails, uniquement en XYZ» ne fonctionnent pas. Ils ignorent les composants clés de la chaîne d'abstraction et pensent qu'ils peuvent simplement dupliquer Rails.

Des abstractions aux microservices

Pour moi, les microservices ne sont qu'un autre niveau d'abstraction. Ce n'est pas nécessairement l'étape 10 de la liste ci-dessus, car toutes les bibliothèques ne sont pas conçues pour les microservices, mais au niveau conceptuel, cela semble être le cas.

Les microservices ne sont pas là où vous commencez, tout comme vous ne tenteriez pas immédiatement de créer la bibliothèque open source externe parfaite avant d'écrire au moins une ligne de code. En ce moment, vous ne savez même pas ce que vous développez.

Une architecture basée sur des microservices est ce qu'un projet peut transformer au fil du temps lorsque vous rencontrez de vrais problèmes.

Peut-être ne rencontrerez-vous jamais ces problèmes, et beaucoup d'entre eux peuvent être résolus différemment. Jetez un œil à Basecamp et Shopify. Ils fonctionnent tous les deux comme des applications monolithiques.

Je pense que personne ne les appellera petits, bien qu'ils ne fonctionnent pas à l'échelle de Google.

Shopify gagne 17 millions de dollars par mois sur monolith

À la mi-2018, Shopify a annoncé publiquement que plus de 600 000 magasins en ligne opéraient sur leur plate-forme.

Shopify est une application SaaS qui a le tarif le moins cher de 29 $ par mois, et j'ai le sentiment que de nombreuses entreprises choisissent le tarif de 79 $ par mois. Dans tous les cas, même si 600 000 clients ont utilisé le plan le moins cher pour 29 $, cela représente un revenu de 17,4 millions de dollars par mois uniquement sur la ligne SaaS de leur entreprise.

L'application Basecamp est une autre excellente application monolithique. Ce qui est intéressant à propos de Basecamp, c'est qu'ils ne comptent qu'une cinquantaine d'employés, et seuls certains d'entre eux sont des développeurs de logiciels travaillant sur le produit principal.

Je veux dire que vous pouvez aller TRÈS loin sans descendre dans le lapin des microservices. Ne créez pas de microservices comme ça.

Quand faut-il utiliser les microservices?

Tout dépend de votre décision. C'est juste une de ces choses où vous ne googlez pas "microservices contre monolith". Si vous avez vraiment besoin de microservices, vous le savez déjà.

Mais il peut y avoir une situation où vous avez un tas de développeurs qui sont les mieux adaptés pour travailler sur des parties individuelles de l'application. La présence de dizaines d'équipes travaillant isolément sur divers composants du produit est l' une des raisons raisonnables de l'utilisation des microservices.

Gardez à l'esprit que si vous avez une petite équipe qui se développe lentement au fil du temps, vous pouvez commencer avec un ou deux microservices. Dans une telle situation, vous ne devriez probablement pas casser le monolithe à la fois en 100 microservices, à partir d'une carrière.

Le jeu en vaut-il la chandelle?

Il convient également de mentionner que la transition vers les microservices s'accompagne de son propre ensemble de problèmes. Vous changez un problème pour un autre, vous devez donc peser les avantages et les inconvénients de savoir si le jeu vaut la chandelle spécifiquement pour votre projet.

L'un des principaux problèmes est le suivi. Soudain, vous obtenez un tas de services qui peuvent être écrits sur différentes piles technologiques, exécutés sur plusieurs machines - et vous avez besoin d'un moyen de les suivre en détail.

C'est une tâche difficile, car idéalement, nous souhaiterions que tous les microservices utilisent un seul service de surveillance.

Vous ne voulez probablement pas développer vos propres outils, car cela en soi peut se transformer en un travail à part entière. C'est la raison du succès d'entreprises telles que LightStep . C'est l'un des services de surveillance les plus intéressants que j'ai rencontrés.

Leur produit est davantage axé sur les applications à grande échelle (on comprend pourquoi), mais il fonctionne également pour les petits projets. J'ai récemment entendu parler d'eux car ils ont été présentés lors du Cloud Field Day 4 .

En tout cas, le suivi n'est qu'une des nombreuses difficultés, mais j'ai décidé de le mentionner car c'est l'un des problèmes les plus douloureux.

Réflexions finales

Fondamentalement, j'ai écrit cet article pour deux raisons:

Il y a deux semaines, j'ai visité Cloud Field Day 4 et j'ai accidentellement participé à un podcast de groupe sur un sujet connexe. Il devrait sortir dans quelques mois, mais ici je voulais m'attarder sur certains points.

Deuxièmement , en tant qu'auteur de cours en ligne, je reçois beaucoup de questions sur la façon de créer mes propres applications.

De nombreux développeurs «se figent», essayant de décomposer leurs applications en services isolés avant même d'avoir écrit la première ligne de code. Il vient au point que dès le début, ils essaient d'utiliser plusieurs bases de données pour les composants d'application.

Ce moment les empêche d'avancer, et en tant que collègue de développement, je sais combien il est difficile de rester coincé dans l'indécision (je l'ai eu!).

Soit dit en passant, je travaille actuellement sur une application SaaS assez grande - une plate-forme pour l'hébergement de cours personnalisés. En ce moment, je travaille seul sur un projet et vous pouvez être sûr que je viens d'ouvrir l'éditeur et que j'ai commencé à écrire du code dès le premier jour.

Je vais enregistrer le projet en tant qu'application complètement monolithique, jusqu'à ce qu'il soit logique d'implémenter des microservices, mais mon instinct me dit qu'un tel moment ne viendra jamais.

Qu'en pensez-vous? Faites le moi savoir dans les commentaires.