Arrêtez de passer au Cloud, au micro-service...

Publié le : 03/06/2023 à 03:40

Introduction : Un discours à contre-courant

Les clients sont de plus en plus regardants sur la qualité des prestations offertes. Pour relever ce challenge, les entreprises redoublent d'effort pour rendre leur Système d'Information (SI) plus performant, plus agile et plus résilient. De nombreux leviers sont disponibles : agir sur l'architecture logicielle, agir sur les composants (mise à l'échelle horizontale et/ou verticale), agir sur la proximité (déployer la solution au plus près du consommateur via des CDN ou des Edge locations)... Face à ces défis, il y a des propositions qui sont systématiquement et presque aveuglément faites par les grands cabinets de conseil à ces entreprises : il faut passer au

• Cloud Computing pour déployer plus rapidement et gagner en agilité
• A une architecture micro-services pour rendre les applications plus performantes, indépendantes et hautement scalables.

Mais pourquoi moi, qui ai pourtant baigné très tôt dans cet écosystème, je m'oppose aujourd'hui à son adoption systématique ? Lors de mon stage de fin d'étude en 2011 chez EDF, j'ai commencé ma carrière dans le Cloud Computing à un moment où les entreprises se posaient encore énormément de questions sur la viabilité, la sécurité et la pertinence de ce modèle. Mon rapport de stage a même été utilisé pour rédiger la première plaquette commerciale sur le Cloud Computing de l'entreprise DEVOTEAM. J'ai vu naître et grandir ces technologies, je connais leurs forces, mais je connais surtout les ravages qu'elles peuvent causer lorsqu'elles sont adoptées pour les mauvaises raisons. Cet article a pour but de démystifier ces tendances et de remettre le bon sens au centre des décisions d'architecture.

L'illusion des économies et la réalité financière

Les raisons des échecs des projets de migration vers le Cloud sont nombreuses, mais la problématique financière est sans doute la plus récurrente et la plus douloureuse.

Le piège du passage de CAPEX à OPEX et la méprise du 'Pay as you go'

Parmi les avantages systématiquement mis en avant pour justifier une migration vers le Cloud Computing, on cite très souvent le gain financier. En effet, la phrase choc et le mantra du modèle Cloud est 'pay as you go' : en d'autres termes, payez uniquement ce que vous consommez ! Sur le papier, le concept est séduisant car l'entreprise passe d'un modèle d'investissement en capital (CAPEX) à un modèle de dépenses opérationnelles (OPEX). Pour l'expliquer par des mots simples, les entreprises réduisent drastiquement le coût d'investissement initial (achat de serveurs, baies de stockage, réseau) au profit d'un coût lissé sur l'exploitation. De plus, le principe de débordement (Cloud Bursting) vendait la promesse d'absorber des pics d'activité exceptionnels.

Malheureusement, la réalité est plus cruelle. En se débarrassant totalement du on-premise pour aller vers le 100% Cloud public sans adaptation architecturale (le fameux "Lift and Shift"), les coûts s'envolent. Le 'pay as you go' implique que tout se paie : chaque appel API, chaque adresse IPv4 publique allouée, et surtout les transferts réseau sortants (egress fees) qui coûtent une fortune. L'infrastructure est souvent surdimensionnée par habitude des anciennes pratiques, créant des factures astronomiques.

L'émergence du FinOps : un remède ou un aveu d'échec ?

De nos jours, les budgets IT liés au Cloud explosent, ce qui a fait émerger une discipline entière : le FinOps (Financial Operations). En résumé : on vous avait promis des économies automatiques, mais finalement, vous avez besoin d'une équipe dédiée et d'outils d'analyse pour comprendre l'hémorragie financière. Attention, le FinOps est essentiel aujourd'hui, mais sa nécessité prouve que le Cloud demande une micro-gestion rigoureuse.

Par exemple, pour anticiper vos coûts avant même de déployer avec Terraform, l'utilisation d'outils en ligne de commande comme Infracost devient incontournable dans les pipelines CI/CD :

Besoin : Estimer précisément l'impact financier d'une modification d'infrastructure avant de la provisionner.
Avantage : Permet de faire du Shift-Left financier. En intégrant cette commande, les développeurs visualisent instantanément les coûts, évitant ainsi les mauvaises surprises sur la facture de fin de mois.

# Analyser l'estimation du coût du déploiement Terraform
infracost breakdown --path .

# Sortie générée :
# Project: .
# Name                           Monthly Qty  Unit         Monthly Cost
# aws_instance.web_app
#  ├─ Instance usage (Linux/UNIX)  730          hours        $34.60
#  └─ root_block_device
#      └─ Storage (gp2)            50           GB-months    $5.00
# Total Monthly Cost: $39.60

Le piège de l'architecture micro-services

L'autre grande tendance imposée par l'industrie est la migration systématique vers les architectures distribuées et les micro-services, souvent au détriment de la simplicité et de l'efficacité.

Anticipation excessive et sur-ingénierie

Beaucoup d'entreprises vivent dans l'anticipation irrationnelle, en voulant concevoir l'architecture d'un géant du web pour une application qui n'a encore que 100 utilisateurs. L'industrie impose l'idée qu'il faut obligatoirement passer aux micro-services pour être "scalable". Construire un système distribué complexe dès le premier jour est une violation directe du principe YAGNI (You Aren't Gonna Need It).

Les micro-services introduisent des défis majeurs invisibles de prime abord : latence réseau entre les conteneurs, complexité des transactions distribuées (nécessitant des patterns comme Saga), et obligation de mettre en place un outillage d'observabilité ultra-avancé. On se retrouve alors souvent à gérer un monolithe distribué : un ensemble de micro-services tellement couplés qu'ils doivent tous être mis à jour et déployés en même temps.

Le retour en grâce du Monolithe Modulaire

Si l'on regarde de plus près, des entreprises immenses comme Shopify ou Doctolib gèrent des charges colossales en s'appuyant sur des monolithes ! Il s'agit plus précisément de Monolithes Modulaires.

Dans un monolithe modulaire, le code métier est organisé exactement comme des micro-services (domaines stricts, isolation du code), mais au moment du déploiement, tout tourne dans un seul processus système. Les avantages sont énormes : pas de latence réseau entre les modules (simples appels de fonction en mémoire), un seul déploiement à gérer, et une base de données relationnelle centrale beaucoup plus simple à maintenir et sauvegarder. L'évolution vers les micro-services ne devrait être envisagée que lorsqu'un goulot d'étranglement précis apparaît ou que les équipes de développement deviennent trop nombreuses pour partager le même dépôt de code.

Conclusion : Le pragmatisme avant la tendance

En conclusion, l'objectif de cet article n'est pas de dire que le Cloud ou les architectures micro-services sont de mauvaises technologies à proscrire absolument. Ils ont leur utilité et répondent à des problématiques très spécifiques rencontrées par des organisations opérant à une échelle planétaire ou ayant des équipes de développement distribuées comptant des centaines d'ingénieurs.

Cependant, pour la grande majorité des entreprises (PME, ETI, et même de grands groupes), ces solutions apportent souvent plus de complexité, de coûts et de risques qu'elles ne résolvent de problèmes. Le choix d'une architecture technique et d'un modèle d'hébergement doit être dicté par le pragmatisme, l'analyse froide des besoins réels (et non fantasmés) et les compétences de l'équipe interne.

Commencer par un monolithe modulaire bien conçu, hébergé sur une infrastructure classique ou sur des serveurs dédiés (bare metal), est souvent le choix le plus judicieux, le plus économique et le plus performant. Si un goulot d'étranglement apparaît sur un module spécifique, alors il sera temps d'envisager d'extraire ce module pour en faire un micro-service indépendant. Arrêtons de suivre les modes technologiques aveuglément et recommençons à faire de l'ingénierie logicielle basée sur le bon sens et la valeur métier.