Avez-vous lu l'excellent essai "Death by a thousand microservices" ? Je suis d'accord avec tout ce qui y est dit. Cependant, j'aimerais souligner que les microservices ne sont pas un problème en soi. De même, je ne pense pas que les monolithes soient nécessairement mieux adaptés la plupart du temps, même pour les petits produits. En fait, personnellement, je préfère les services (en évitant intentionnellement le terme "micro"
à un énorme monolithe dans le cadre du travail.Le vrai problème, je pense, est le manque de compétences en ingénierie et le manque d'intérêt dans les entreprises. C'est ce qui crée des systèmes complexes sur lesquels personne ne peut travailler efficacement.
Incompétence
Le monde de l'ingénierie logicielle est incroyablement influencé par le battage médiatique. Les microservices sont à la mode (même si je pense que les gens sont maintenant prêts pour la prochaine tendance).
En fait, j'adore le fait que nous soyons si prompts à adopter de nouvelles technologies. Cela rend la profession intéressante. Si je n'aimais pas explorer, je n'aurais pas eu autant d'expérience avec des technologies complètement différentes et j'aurais été un bien plus mauvais programmeur (travaillant probablement avec le même framework PHP russe pourri avec lequel j'ai commencé mon parcours professionnel).
Cependant, l'adoption d'une nouvelle technologie (révolutionnaire) signifie que nous passons de seniors à juniors. Oui, nous appliquons les connaissances et les techniques que nous avons apprises jusqu'à présent, mais parfois elles ne sont pas très transférables. Rappelez-vous lorsque Scala a gagné en popularité et que les gens ont remarqué que le code qu'il contenait était soit un charabia mathématique trop "intelligent", soit simplement du Java avec une syntaxe différente.
Les entreprises partent souvent du principe qu'en recrutant des "personnes intelligentes", celles-ci se débrouilleront toutes seules. Ce n'est pas le cas (voir aussi le "complexe de l'intello" ci-dessous). Le fait d'être intelligent ne garantit pas que l'on puisse résoudre n'importe quel problème. L'expérience est probablement le bien le plus précieux (et l'expérience elle-même doit être de grande qualité, ce qui est aussi une perle rare) et nous y renonçons lorsque nous adoptons une nouvelle technologie. Nous nous rendons volontairement incompétents.
Bien sûr, certaines personnes sont très compétentes dans ce domaine. Mais parviennent-elles à éduquer d'autres personnes et à les amener à exploiter correctement la technologie ? Non.
Exemple : Apache Kafka et les systèmes dirigés par les événements
Aujourd'hui, les recherches sur Google concernant "apache kafka" se multiplient. De nombreuses entreprises, en particulier des startups, l'utilisent (il suffit de faire une recherche sur LinkedIn ou sur certains sites d'offres d'emploi). De nombreuses personnes que j'ai rencontrées s'indignent (et ont ce regard condescendant de pitié sur leur visage) lorsque je l'appelle un bus d'événements. "Non, ce n'est pas un bus d'événements, c'est une plateforme de streaming et de stockage d'événements", "Alors c'est un bus d'événements qui ne se débarrasse pas des messages ?", "Non, vous ne comprenez pas, laissez-moi vous réexpliquer". La vérité est que de nombreuses entreprises ne l'utilisent même pas pour le streaming d'événements, mais plutôt comme une file d'attente de messages qu'elles peuvent rejouer si quelqu'un foire. Dans mon entreprise actuelle, il est même utilisé avec des schémas Avro littéralement comme une alternative à GRPC avec protobuff. Quel est l'intérêt ? Autant utiliser HTTP.
Les personnes qui l'introduisent ont souvent (mais pas toujours) un discours convaincant et donnent l'impression de comprendre pourquoi il est utile et comment l'utiliser efficacement. Le problème, c'est que même si c'est vrai, les personnes qu'ils embauchent ou qu'ils dirigent ne le comprennent pas. Kafka n'existait pas vraiment il y a dix ans, alors où pourrais-je trouver de l'expérience dans ce domaine ?
Si quelqu'un a utilisé des marteaux et des clous toute sa vie et que vous lui donnez des vis et un tournevis, il dira simplement "oh, c'est un marteau plutôt pourri, mais le travail est un travail" et commencera à enfoncer la vis dans le bois avec le manche. Si vous voulez qu'ils l'utilisent correctement, investissez dans leur formation ou, au moins, tenez-les par la main jusqu'à ce qu'ils soient compétents. Les gens font-ils cela ? Pas vraiment, sauf s'il s'agit d'une très petite équipe d'ingénieurs où tout le monde travaille en étroite collaboration (et même dans ce cas, ce n'est pas nécessairement une habitude). Et n'oubliez pas les équipes où les responsables techniques n'ont aucune idée de ce qu'ils font non plus.
En fait, j'adore les architectures basées sur kafka. Pour moi, c'est comme un meilleur SNS AWS (si je ne suis pas celui qui le met en place et le maintient). Cependant, si je vois cela dans une description de poste, il y a de fortes chances que l'entreprise l'utilise mal et que ce soit une nuisance dans votre travail quotidien plutôt qu'un outil qui vous aide.
Ne pas s'en faire
Si vous suivez mon exemple avec un marteau et un tournevis, vous vous demanderez peut-être pourquoi ne pas trouver vous-même le temps d'en apprendre davantage. Après tout, vous pouvez passer une heure ou deux par jour à lire quelque chose tout en étant payé (et c'est toujours utile à l'entreprise).
Eh bien, parce que la plupart des gens ne se soucient pas suffisamment de s'améliorer. Oui, les programmeurs sont censés apprendre tout le temps bla-bla et toutes ces conneries que les gens disent aux débutants sur Reddit. La vérité, c'est que la plupart ne le font pas.
Il y a aussi une autre catégorie de personnes. De bons ingénieurs (parfois même brillants) qui savent exactement ce qu'ils font, mais qui ne se soucient tout simplement pas assez de faire ce qu'il faut, de guider les autres pour qu'ils fassent ce qu'il faut. Pour eux, ils ont une tâche à accomplir, ils la résolvent et ils sont payés. Il n'y a plus d'extras. L'entreprise peut brûler en enfer pour ce qu'elle en a à faire. J'en ai rencontré quelques-uns. Ils sont incroyablement perspicaces lors d'une conversation informelle, mais très silencieux et s'ennuient en réunion.
La culture du "rien à foutre" est une maladie. Elle empoisonne tout ce qui l'entoure. À un moment donné, tout le monde cesse d'essayer d'améliorer les choses. Ils se contentent de suivre le courant. C'est comme la merde dans les égouts (comme disait mon professeur). C'est l'une des raisons pour lesquelles je recommande toujours aux jeunes de changer de travail au moins une fois par an. Il est préférable d'apprendre des bribes de choses à différents endroits plutôt que de rester bloqué à un seul.
Cela se traduit également par des révisions de code. Et la prise de décision. Et l'embauche. Les personnes incompétentes embauchent d'autres personnes incompétentes qui, à leur tour, participent à l'embauche. C'est exponentiel. J'ai parfois l'impression qu'il faut mettre en place un système de confinement et développer un vaccin contre ce phénomène.
Le "complexe de l'intello"
Soyons honnêtes, ingénieurs, la plupart d'entre nous ne sont pas intelligents. On nous a simplement fait croire que nous l'étions. Savoir coder ou ouvrir un terminal et utiliser git grep ne vous rend ni intelligent ni instruit. Dans le meilleur des cas, cela fait de vous une personne adjacente compétente en matière de technologie.
Dans de nombreux pays, les personnes qui étudient les STEM sont même considérées comme plus intelligentes que celles qui étudient les sciences sociales (vous comprenez ? plus intelligentes haha, je m'en étonne parfois). La vérité, c'est que les gens sont des idiots, quels que soient leurs intérêts, leurs passe-temps et leur travail. Le fait d'être ingénieur (même expérimenté) ne vous rend pas intelligent, pas plus que vos décisions.
Je soulève cette question parce que je pense que le fait d'avoir un "complexe de l'intello" nous pousse souvent à :
- Compliquer les choses à l'excès. Construisons un bot Slack avec 10 conteneurs Lambdas Haskell différents sur AWS qui se parlent via SNS et qui sont déployés en continu via Circle CI avec les données d'utilisation qui tombent dans Athena. Maintenant, nous n'avons plus besoin de choisir nous-mêmes l'animateur du standup, cela se fera automatiquement tous les matins à 8h !
- Attacher des noms différents à la même chose. Adaptateur ? Traducteur ? Façade ? Délégateur ? Décorateur ? Pont ? Ah, vous voulez dire la chose que nous pouvons appeler simplement un wrapper ? Oui, on pourrait dire que l'important est le contexte, mais pourquoi ne pas expliquer d'abord le problème que vous essayez de résoudre au lieu de passer pour un ringard avec votre terminologie fantaisiste ? Pensez-y également la prochaine fois que vous qualifierez votre système basé sur Kafka de "dirigé par les événements" (est-ce vraiment le cas ?).
- Voir des problèmes qui n'existent pas. Oui, nous avons besoin d'évoluer beaucoup, suivons l'exemple de Twitter et utilisons Java et Scala parce que nous aurons certainement les mêmes problèmes d'évolution à l'avenir dans notre application de niche que seuls quelques milliers de professionnels utiliseront. Et quand ce futur arrivera, nous serons comme "psych ! nous sommes prêts pour vous". En fait, Java est trop lent et trop vieux, utilisons Elixir. Nous avons un tas de développeurs Ruby, ils sauront certainement comment construire des systèmes avec, c'est à peu près Ruby de toute façon, juste plus rapide et plus fonctionnel.
- Et ainsi de suite. Je m'éloigne du sujet
Ne pas être intelligent est tout à fait acceptable (je ne le suis certainement pas). Il faut juste éviter d'être stupide. Et nous devons faire preuve d'humilité et ne pas nous laisser aveugler par notre ego. Si nous reconnaissons que nous ne sommes pas intelligents, nous pouvons commencer à revenir à l'essentiel en restant simples. Si nous ne sommes pas assez intelligents pour prédire les problèmes à venir, nous ne devrions même pas essayer. Résolvons plutôt les problèmes au fur et à mesure qu'ils se présentent et faisons de notre mieux pour garder les choses propres et flexibles (voir les décisions concernant les portes à double sens). Ce serait une décision intelligente.
P.S. Par coïncidence, en écrivant cette section, j'ai vu une question sur Reddit à propos de la toxicité dans la culture du génie logiciel (malheureusement, le contexte a été supprimé par les mods). L'un des points mentionnés était la culture qui consiste à essayer d'être le plus intelligent dans la pièce. Cela arrive souvent (j'ai moi-même péché).
Compétence
Alors, comment naviguer dans ce monde d'incompétence et de battage médiatique qu'est le génie logiciel ? J'aimerais connaître la réponse. Je vais essayer d'apporter quelques réflexions.
Systèmes SOLID
Nous avons tous entendu parler des principes SOLID. Cependant, j'ai remarqué que les gens les associent presque toujours à la POO en particulier et les rejettent complètement lorsqu'ils en parlent dans le contexte d'autres langages ou de la conception de systèmes. En fait, vous n'imaginez pas le nombre de fois où j'ai été corrigé (c'est-à-dire remis à ma place lol) lors de réunions lorsque j'ai mentionné SOLID en dehors du contexte orienté objet. En réalité, si l'on y réfléchit bien, chaque principe s'applique aussi bien à l'ensemble du système qu'à une base de code particulière.
Comme nous le disons souvent, la programmation consiste à diviser un problème en plusieurs problèmes plus petits et à les résoudre un par un. Cependant, il ne s'agit pas seulement de problèmes. Il en va de même pour les systèmes et les organisations (voir la loi de Conway). À tous les niveaux (y compris organisationnel), les systèmes doivent être divisés en unités plus petites. Et à chaque niveau, un système bien divisé en unités aura les caractéristiques définies par les principes SOLID.
- Principe de la responsabilité unique. Une unité doit avoir une responsabilité claire et la maîtriser en permanence.
- Au niveau du code, cela signifie que votre bibliothèque/module/classe/fonction/etc. ne doit avoir qu'un seul objectif.
- Au niveau du système, cela signifie la même chose pour les microservices. Toutefois, dans la pratique, il importe peu qu'un service ait de multiples responsabilités tant qu'elles sont fournies sous la forme d'API distinctes et indépendantes. Fondamentalement, un service est simplement une unité infrastructurelle/jonction pour les API qui se situent à un niveau d'abstraction supérieur.
- Au niveau organisationnel, cela signifie que l'équipe doit avoir un rôle clair. Dans les équipes techniques, cela signifie s'occuper de projets spécifiques, idéalement dans un domaine spécifique (ce qui est difficile à réaliser).
- Principe ouvert-fermé. L'unité doit être ouverte à l'extension, mais fermée à la modification. Personnellement, j'inclus également dans cette catégorie le principe de "composition plutôt que de modification".
- Vos structures de données doivent être rétrocompatibles (au niveau du code et du système).
- Vos services/API doivent permettre de construire par-dessus, mais ne doivent pas pouvoir être modifiés. Cela est lié au principe de la responsabilité unique. Exemple : un service de paiement ne doit fournir que des fonctions de déplacement d'argent. La logique commerciale liée à un produit particulier doit exister en tant qu'API distincte faiblement couplée utilisant le service de paiement d'origine.
- Au niveau organisationnel, le rôle de l'équipe ne doit pas changer au fil du temps. Si, à un moment donné, ce rôle devient obsolète, l'équipe doit être dissoute et une nouvelle équipe doit être créée avec un nouvel objectif clair. Dans les équipes techniques, cette notion est également étroitement liée à la propriété du code.
- Principe de substitution de Liskov. Toutes les sous-classes doivent pouvoir être utilisées à la place de leurs parents. Ce principe semble très spécifique à la POO. Mais non.
- Au niveau du code, cela signifie que lorsque vous avez deux unités qui implémentent la même interface, vous devez vous assurer que les deux sont utilisables dans toutes les situations où l'interface est requise. Il ne suffit pas toujours de fournir la même structure/méthode/etc. Gardez cela à l'esprit lors de la conception, de l'implémentation et de l'utilisation des interfaces.
- Au niveau du système, c'est exactement la même chose. Je veux dire que API signifie littéralement "interface de programmation d'application"
- Au niveau de l'organisation, les équipes ne devraient pas s'appuyer sur d'autres équipes, mais plutôt sur le travail qu'elles effectuent. Cela semble assez évident, mais les processus de communication sont parfois très inefficaces. Comment recevez-vous normalement le travail des autres équipes ? Envoient-ils un ticket JIRA ? En parlent-ils d'abord à votre manager ou à votre responsable technique ? Comment les priorités sont-elles établies ? Comment les délais, les estimations et les mises à jour sont-ils communiqués ?
- Principe de séparation des interfaces. Les unités ne doivent pas dépendre d'autres unités qu'elles n'utilisent pas.
- Au niveau du code, cela signifie essentiellement que A utilisant B ne devrait pas avoir à utiliser C directement juste parce que B l'exige. Exemple simple : Je ne devrais pas avoir à accéder aux informations d'identification de la base de données et à établir une connexion avec elle simplement parce que je veux récupérer un utilisateur spécifique. Cela devrait être fait ailleurs (où et comment exactement dépendra de la base de code exacte).
- Au niveau du système, c'est à peu près la même chose.
- Au niveau de l'organisation, c'est encore une fois une question de communication. Je ne devrais pas avoir à traiter avec des personnes non pertinentes et à sauter des cerceaux pour obtenir quelque chose d'une autre équipe.
- Principe d'inversion de la dépendance. Les unités ne doivent pas dépendre les unes des autres, mais plutôt des abstractions (interfaces, contrats).
- Au niveau du code, vous ne voulez pas utiliser d'autres unités directement. Ce n'est pas toujours pratique, par exemple en Ruby, c'est généralement plus pratique et n'a pas vraiment d'inconvénients. Par exemple, dans un langage comme Java, l'utilisation directe d'autres unités peut conduire à des tests maladroits/mauvais. Je pense que je reformulerais le principe comme "l'interface d'abord, l'implémentation ensuite" ; il est difficile d'établir des règles de codage spécifiques sur ce point.
- Au niveau du système, là encore, la communication entre les services doit reposer sur des contrats, car les services internes ont tendance à changer. Parfois, les services sont même remplacés.
- Au niveau de l'organisation, c'est exactement la même chose. Les contrats concernent des personnes spécifiques.
Cette section s'est avérée beaucoup plus volumineuse que je ne l'avais prévu et ne me semble toujours pas complète. Mais bon.
Monolithe vs services vs code
Quelle est la différence entre un monolithe et plusieurs services ? La communication. Considérez ces deux unités liées :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | module Authorisation
def allowed?(user, action)
check_database
end
end
module Users
def freeze(user)
if !can_freeze_users?(current_user)
return auth_error
end
do_it_mf
end
def can_freeze_users?(user)
check_permission(user, :freeze_users)
end
end |
Un code monolithique tout à fait normal, n'est-ce pas ? Et si je vous disais que les unités ne proviennent pas de la même base de code ? Le premier module est en fait un service distinct. Qu'est-ce qui a changé ?
La véritable différence entre les bases de code monolithiques et les bases de code orientées services réside dans la manière dont vous appelez les API.
| Code : | Sélectionner tout |
1 2 3 4 5 6 | # Monolithic
Authorisation.allowed?(user, :freeze_users)
# Service-oriented
# makes HTTP/GRPC/etc request
AuthorsationApiClient.allowed?(user.id, :freeze_users) |
Dans un système orienté service asynchrone, la communication sera moins directe et la mise en œuvre exacte dépendra du contexte. Vous devrez probablement conserver localement une copie des permissions de l'utilisateur en vous abonnant à un journal des modifications.
Pour en revenir à l'incompétence, l'une des raisons pour lesquelles je préfère les architectures orientées services est que je préfère posséder quelques petits services que personne en dehors de mon équipe ne peut toucher afin d'en avoir le contrôle total. Je ne fais pas confiance aux autres et je préfère qu'ils ne touchent pas à mes affaires. Lorsque tout le monde possède tout (et c'est ce qui se passe souvent dans les bases de code monolithiques), rien ne se fait.
De plus, les partisans des monolithes disent souvent qu'un monolithe correctement écrit peut toujours être facilement retiré. C'est vrai. Cependant, quelles sont les chances que votre organisation ait été suffisamment compétente pour écrire un tel monolithe ?
Pensez à l'expérience du développeur
Nous parlons toujours de l'UI/UX, de l'obsession du client, du travail à rebours - de nombreuses entreprises volent ces principes à Amazon. Ce à quoi les gens ne pensent pas toujours, c'est que le client n'est pas toujours le même que le client de l'entreprise.
Lorsque vous écrivez du code ou créez un projet, vos collègues (et vous-même) deviennent également vos utilisateurs. En effet, ils travailleront sur le code que vous venez d'écrire. Ils le liront, ils le modifieront. Pensez à l'ergonomie pour vos utilisateurs.
Sera-t-il facile de tester votre système/service ? Est-il facile de l'exécuter localement ? Peut-on repérer et résoudre facilement les problèmes de production ? Avons-nous besoin de documentation ? Existe-t-il un moyen clair de résoudre des problèmes spécifiques (le code existant doit encourager l'écriture d'un bon code).
KISS
Keep it simple. Ce n'est pas parce que le reste de votre organisation complique les choses à l'extrême que vous devez le faire. Lorsqu'il s'agit d'une question de système, vous devriez probablement en parler à votre responsable technique afin qu'il puisse faire face à toute contestation. Il est votre meilleur ami (ou du moins devrait l'être) lorsqu'il s'agit de traiter avec des personnes extérieures.
Faites preuve de bon sens à tout moment. Et apprenez à reconnaître les décisions concernant les portes à sens unique ou à double sens et agissez en conséquence, s'il vous plaît.
Doubler et se lancer à corps perdu n'est pas une bonne chose
Ce n'est pas parce qu'un service ou un monolithe semble être une bonne idée qu'il faut aller jusqu'au bout. Il est toujours possible de mélanger les choses. Je pense que les gens adoptent souvent la position du "tout ou rien". Mais ce n'est pas pratique et c'est souvent dangereux. Nous devons toujours faire preuve de bon sens. Par ailleurs, vous avez peut-être remarqué que de nombreuses startups ont soudainement décidé de passer aux services. Lorsqu'elles le font de manière radicale, la situation devient incontrôlable. Il vaut mieux le faire progressivement et l'initiative doit être supervisée par quelqu'un de compétent.
Il n'y a pas de honte à ajouter des fonctionnalités supplémentaires à votre "microservice". Veillez simplement à ce que ces fonctionnalités ne s'enchevêtrent pas avec les éléments existants. Vous pourrez toujours les extraire plus tard si vous en avez besoin (spoiler alert : YAGNI).
Propriété
Responsabilité unique et principes d'ouverture et de fermeture - prenez la responsabilité de quelques services et ne laissez personne y toucher. Idéalement, ne les touchez même pas vous-même. Toutes les demandes de changement ou de fonctionnalités doivent passer par un canal de communication spécifique pour arriver dans votre backlog. S'il y a plusieurs urgences, eh bien, tant pis, dites-leur d'aller se faire foutre. Non, nous ne nous soucions pas de vos indicateurs de performance. Nous avons les nôtres.
Si vous les laissez toujours vous refiler des tâches "urgentes", ils continueront à le faire. Prenez position de temps en temps. Faire des compromis en permanence ne fera que ralentir le travail à l'avenir et l'entreprise ne sera pas en mesure d'évoluer (j'en ai vu de nombreux exemples).
L'appropriation est mon plus gros problème sur mon lieu de travail actuel. Il y a 3 équipes différentes qui travaillent sur mes dépôts. C'est quoi ce bordel ? Récemment, j'ai jeté un coup d'œil au code et je n'ai pas reconnu certaines parties. Certains changements ont même perturbé notre équipe (pas trop, heureusement).
Cela crée beaucoup de problèmes à différents niveaux.
- Motivation. Vous êtes plus enclin à vous préoccuper des choses sur lesquelles seule votre équipe travaille. Vous voulez que tout soit propre et net. Cela vous appartient. Cela disparaît lorsque la propriété est partagée. Et non, appeler un service le vôtre, mais laisser d'autres personnes travailler dessus n'est pas de la propriété. Comme je l'ai dit plus haut (mais je suis presque sûr qu'Aristote l'a dit en premier), si tout appartient à tout le monde, rien n'est pris en charge.
- Manque de communication. Lorsqu'il n'y a pas de véritable propriété, les personnes concernées ne sont souvent pas suffisamment impliquées dans la prise de décision. Leur capacité d'attention est également réduite du fait qu'elles sont impliquées dans beaucoup de choses (parfois non pertinentes).
- Excès de communication. Oui. Certaines personnes concernées ne sont pas suffisamment impliquées, tandis que d'autres, totalement hors sujet, le sont plus souvent. Cela réduit la qualité des réunions et renforce le besoin d'en organiser d'autres. Par conséquent, le manque de communication entraîne également un excès de communication.
- Vitesse de dépréciation des connaissances. Si les choses sur lesquelles les personnes travaillent sont modifiées trop souvent par des personnes différentes, leur compréhension globale du système s'en trouve affectée. Toutes les connaissances que vous accumulez se détériorent plus rapidement. Ce que vous savez aujourd'hui ne sera plus vrai demain. Cela n'est pas vrai lorsque vous n'avez besoin de connaître que vos parties du système et que tous les changements passent par vous et votre équipe.
- Incapacité d'estimer et délais serrés. Parce que tout le monde peut apporter des changements partout, la direction fixe des délais et attend des estimations dans le contexte d'une seule équipe. Et si la date d'estimation est trop éloignée dans le temps, ils ajoutent simplement des personnes au problème (2 femmes peuvent accoucher en 4,5 mois). Le problème est qu'en travaillant sur le même sujet, les gens se marchent sur les pieds, ce qui crée des blocages supplémentaires et des conversations inutiles. De plus, en raison de la dépréciation des connaissances, l'équipe ne peut même pas estimer correctement le temps que prendrait le travail dans un service spécifique. Lorsque l'appropriation est claire, vous contactez les équipes concernées et elles vous donnent des estimations plus ou moins précises sur leur propre travail et les bloqueurs potentiels.
- Le code merdique fait boule de neige. En rapport avec la motivation. Vous êtes-vous déjà retrouvé à devoir ajouter des tests ou une fonction supplémentaire à un fichier rempli de code merdique sans pouvoir vraiment écrire le vôtre correctement parce que vous devez suivre le même modèle ? Oui, c'est ça. Le fait de ne pas être propriétaire d'une chose crée de plus grosses boules de neige. Les gens s'en moquent et sont parfois incapables de confirmer qu'un code merdique n'est pas merdique pour une raison précise. Cela ralentit évidemment la livraison des futures fonctionnalités du produit. De plus, cela rend encore moins possible la transition vers vos précieux microservices "corrects" et vous vous retrouvez dans un état de demi-mesure où vous avez essayé de vous lancer à fond, mais n'avez pas réussi. Un code de mauvaise qualité entraîne encore plus de code de mauvaise qualité. De manière exponentielle.
- Coût des ressources humaines. Tout ce qui précède conduit à devoir embaucher plus de personnes, et à ce que plus de personnes partent (et qu'il faille les remplacer). Des équipes bien organisées travailleront de manière beaucoup plus efficace. Peu importe que vous embauchiez des développeurs brillants ou non, si vous ne pouvez pas les gérer correctement.
Je me rends compte aujourd'hui qu'en raison de l'effet papillon/domino sur l'ensemble de l'organisation et des produits, je pourrais écrire cette liste pendant longtemps. Je vais donc m'arrêter.
La gouvernance
J'ai mentionné précédemment que vous pouvez avoir de brillants architectes qui travaillent pour vous, mais qu'ils ne serviront à rien s'il n'y a personne pour donner vie à leurs plans.
Il ne suffit pas de dire aux gens "nous allons être dirigés par les événements". Vous devez vous assurer qu'ils comprennent ce que cela signifie et qu'ils s'y conforment. Comment y parvenir ? Je n'en sais rien.
Je pense qu'une hiérarchie plus stricte pourrait aider : les architectes dirigent les chefs d'équipe et les chefs d'équipe dirigent leurs propres équipes et rendent compte aux architectes. Les responsables de l'ingénierie devraient être à l'origine de l'application de la hiérarchie. Oui, cela semble restrictif. Mais nous sommes une organisation et non une bande d'individus, nous devons travailler efficacement ensemble et non pas seuls.
Si vous ne vous souciez pas de l'entreprise, souciez-vous de vous-même. Et prenez la parole
Honnêtement, je comprends l'attitude du "rien à foutre". Après tout, ce n'est pas votre entreprise qui est en jeu. Mais vous ne voulez certainement pas vous contenter de passer la journée. Vous n'avez certainement pas envie de travailler sur du code merdique et d'effectuer des tâches merdiques pour le compte d'un idiot de manager qui veut atteindre quelques KPI.
Ne vous préoccupez pas de la réussite de l'entreprise. Pensez plutôt à votre propre confort. Que pourrions-nous changer pour que vous vous sentiez un peu mieux ? Identifiez ces problèmes et parlez-en.
Oui, il n'est pas facile de s'exprimer. Parfois, vous voulez éviter la confrontation. Dans ce cas, trouvez une personne à qui vous pouvez en parler. La personne qui n'évite pas la confrontation. Qui peut essayer de faire bouger les choses. Il peut s'agir de votre supérieur hiérarchique. Ou le chef d'équipe. Ou même quelqu'un qui n'a rien à voir avec vous ou votre équipe. Mais vous devez en parler à quelqu'un. Si vous ne le faites pas, tout restera comme avant.
Comme on dit dans le métro londonien : voyez-le, dites-le, c'est réglé.
Conclusion
Je comprends que le titre est sévère et que l'essai l'est parfois aussi. Telle est la vie. Toutes les opinions sont les miennes.
J'ai aussi l'impression d'avoir donné l'impression que tous les problèmes venaient d'ingénieurs stupides. Ce n'est pas du tout le cas. En moyenne, les ingénieurs sont, eh bien, moyens. C'est pourquoi tous ces gens sur LinkedIn qui quittent leur emploi et disent à quel point les personnes avec lesquelles ils ont travaillé sont intelligentes me font grincer des dents.
Non, par incompétence, j'entends l'incompétence au sein des organisations. Et c'est lorsque des personnes incompétentes les dirigent que les dégâts sont les plus importants. Une gestion inefficace entraîne des travailleurs inefficaces. Le génie logiciel est facile (dites à tous les gardiens élitistes d'aller se faire foutre). C'est un métier simple qui n'est pas très différent de la serrurerie. Il n'y a pas de romantisme. Il n'est pas nécessaire d'être un génie pour être compétent dans ce domaine. Il n'est même pas nécessaire d'avoir fait des études. Mais si votre organisation est défectueuse, votre travail le sera aussi. Un poisson pourrit par la tête. Nous devons donc régler les problèmes par le haut et non par le bas.
Source : "Microservices aren't the problem. Incompetent people are", par Dmitry Non, ingénieur logiciel
Et vous ?
Quel est votre avis sur le sujet ?Et vous ?
Python est facile. Go est simple. Simple != Facile, Python et Go ont des qualités distinctes qui peuvent se compléter, par Preslav Rachev, ingénieur en informatique « Passer à une approche basée sur les microservices présente clairement des avantages d'ingénierie », estime O'Reilly en marge de son enquête Microservices Adoption in 2020 Ce que tout programmeur doit savoir #1 : L'idempotence, par Berkan Sasmaz, ingénieur logiciel 
