Tous les avantages que j'ai cités avant restent valables pour ces servicesEnvoyé par Cafeinoman
- Déployables indépendamment
- Une équipe en charge du "service rendu" d'un microservice de A à Z => orientation produit et non projet
- Liberté de choix de la techno pour chaque microservice
- Scalabilité
- Meilleure tolérance aux pannes
- Décentralisation/Gouvernance
- etc.
Mais le concept derrière les micro-services n'est pas nouveau. Certains estiment même qu'il était déjà à l'oeuvre dans les années 70. C'est juste que ça revient en force actuellement parce que ça se marie très bien avec des pratiques comme continuous deployment et une façon de travailler dans les grosses boîtes où une équipe est en charge d'un petit bout du SI concernant un sous-domaine métier de A à Z.
C'est simplement que, à mon humble avis, plus il y a de monolithes dans le SI, et plus l'utilisation de microservices perd de son intérêt. Et là pour le coup, c'est du contexte de boulot : je suis tout seul à maintenir 4 monolithes et 1 site, en plus de l'admin réseau et de l'entretien du parc. Très sincèrement, je pense que du 100% microservice serait mieux maintenable et plus simple à faire évoluer...Je pense que tu t'en rends compte, mais la migration de cette architecture vers du full microservices est un chantier titanesque, surtout tout seul. Le bénéfice reste à évaluer. Si tu te retrouves à passer plus de temps à gérer et administrer l'infrastructure d'une foule de petits microservices existants et futurs (avec chacun leur pipeline de build/déploiement, leur environnement, leur stockage, etc.) que ce que tu aurais passé sur un monolithe, peut-être que ce n'est pas une bonne idée de pousser le curseur aussi loin.
Répondre avec citation
Partager