3 raisons de construire des systèmes monolithiques

Et oui, je veux dire exprès.

Recommander une architecture monolithique de nos jours, c'est un peu comme prescrire une saignée pour de la fièvre, mais écoutez-moi. À long terme, pour garantir l'évolutivité, la facilité de maintenance, l'agilité et toutes les autres fonctionnalités positives (y compris la santé mentale), vous souhaiterez probablement développer et déployer votre application sur une architecture de microservices. Mais si vous créez une nouvelle application, votre entreprise et votre équipe de développement ne sont peut-être pas encore prêtes à affronter la complexité ironique de la décomposition d'un système en services simples. La rapidité et le temps de mise sur le marché peuvent l'emporter sur l'élégance… et c'est ok!

La première raison de construire un système monolithique est d'aider à apprivoiser les inconnues. Prenez n'importe quel livre ou article sur la mise en route des microservices, et il décrira un processus pour décomposer un système en services de composants. Mais si vous débutez, vous n'avez pas encore de système à briser. Il peut être assez difficile de déterminer les exigences dont vous avez besoin dans le système, encore moins d'essayer de décomposer ces exigences en un ensemble de services à couplage lâche avec des interfaces bien définies. Avec le niveau d'inconnues à un démarrage typique, la probabilité d'obtenir cette analyse même près de la droite est très faible.

La prémisse principale derrière l'essor des méthodologies de style agile est de permettre la découverte des exigences par incréments car il est presque impossible de tout savoir à l'avance. De même, il est beaucoup plus facile de discerner les services de composants d'un système lorsque vous avez une version tangible ou deux à portée de main. Alors d'abord, commencez juste! Construisez le système initial sans vous soucier de savoir si vous le faites correctement… il n'y a pas de «bon» à ce stade. L'art consiste à trouver l'équilibre entre continuer à renforcer la fonctionnalité et commencer à séparer les services définis à mesure que le brouillard se dissipe, idéalement avant d'accumuler une abondance de dettes techniques. Abordée avec réflexion et intention, cette approche incrémentale de l'architecture sera plus rapide et plus efficace que d'essayer de bien faire les choses avant de savoir quoi que ce soit.

Une deuxième raison de considérer une architecture monolithique est si l'équipe n'est pas prête. Même une fois que le système est assez bien défini, la décomposition d'un système en services de composants n'est pas toujours simple. Vaut-il le risque de casser cette énorme routine java (chaque système en a une) qui est devenue incontrôlable? Lorsque vous envisagez un service, comment petit est assez petit? Alors que la recommandation normale est de continuer jusqu'à ce que le service ne fasse qu'une chose de manière logique, dans le monde des mégadonnées à grande vitesse, par exemple, trop petit peut avoir de graves conséquences sur les performances.

Le point principal est qu'il y a toujours des compromis à considérer, et l'équipe a besoin de la bonne compétence pour équilibrer ces décisions avec succès. Si votre équipe est nouvelle dans les microservices, il est logique d'investir dans la formation, à temps pour que l'équipe puisse l'explorer, et peut-être dans l'embauche de nouvelles compétences dans le mix. Comme peu d'entreprises peuvent se permettre d'arrêter le développement pour se recycler, l'équipe devra probablement continuer à construire en utilisant leurs pratiques traditionnelles dans l'intervalle. Bien que cela nécessitera quelques retouches plus tard, vous vous retrouverez probablement avec un meilleur résultat que si l'équipe avance totalement sans préparation. Croyez-moi, il y a aussi beaucoup de retouches dans les tentatives de microservices de première version non formées.

Enfin, un système monolithique peut être votre chemin le plus rapide vers le marché, et dans de nombreux cas, cette vitesse est plus importante que l'architecture parfaite. Pour de nombreuses entreprises, en particulier les startups travaillant avec un financement limité, la vente est primordiale pour la survie. Bien que les microservices vous rendront la vie plus facile, cette facilité s'accompagne d'un coût initial que vous pourriez avoir besoin de plus de maturité pour supporter. Une bonne architecture de microservices est d'une simplicité élégante, mais elle n'est ni facile, ni rapide, ni accidentelle. Il existe de nombreux exemples de microservices à grande échelle, matures et à grande échelle aujourd'hui - y compris Twitter, Amazon, Spotify, LinkedIn - mais il y a une raison pour laquelle ils ont tous commencé comme des applications monolithiques et ont ensuite évolué. Ne laissez jamais la poursuite de la perfection technique entraver la réussite d'une entreprise. Une architecture pragmatique signifie que les choix technologiques doivent répondre aux besoins de l'entreprise, et non l'inverse.

Bien que cela doive aller de soi, avoir l'opposé de chacun de ces scénarios est une excellente raison de NE PAS construire une architecture monolithique. Si votre application est déjà assez bien définie, votre équipe connaît bien les microservices et votre entreprise a le temps et l'argent à consacrer aux cycles de développement, alors vous devez absolument investir dans une architecture de microservices. Les avantages à long terme de cette voie sont bien connus et bien documentés à ce stade. Mais si vous n'y êtes pas encore, ça va. Reconnaissez votre état actuel, planifiez votre chemin et répétez avec intention - vous améliorerez toujours votre situation, et avec le temps, vous vous retrouverez avec une architecture digne de la technologie prête à suivre les pivots de votre entreprise.

Suivez ici pour plus de contenu génial