Nous sommes en 2018 et il est (plus que) temps d'étudier de plus près ce nouveau paradigme popularisé par Martin Fowler et son équipe de Thoughtworks : les microservices.
En effet, nous avons tous en charge directement ou indirectement, une pièce de code, qui même si elle est correctement codée a besoin d'être corrigée, améliorée et maintenue dans le cadre de son exploitation et son intégration au sein du SI.
Ce type d'application est en règle générale nommée monolithe. Bien que ce terme ait une connotation négative de nos jours, celles-ci ont fait les beaux jours des directions techniques en proposant une architecture standard, robuste, fiable et intégrée. Généralement déclinées en plusieurs couches applicatives (présentation, business, repository...), ces applications avaient l'avantage d'être simple à développer et leur intégration dans le SI était aisée, car composée de peu de ressource finalement (un serveur web, un serveur d'application et une base de données).
Alors, pourquoi remettre en question l'architecture de ces applications dites "clé en main" ? Plusieurs réponses sont possibles : la maintenabilité, l'obsolescence des briques techniques utilisées, le manque de ressource capable de faire évoluer le produit, etc...
Je vous propose donc une petite réflexion sur le sujet, que vous pourrez retrouver sur le Wiki de Reservoir code et dans lequel je partage ma vision sur le sujet.
Introduction aux microservices
Bonne lecture,
En effet, nous avons tous en charge directement ou indirectement, une pièce de code, qui même si elle est correctement codée a besoin d'être corrigée, améliorée et maintenue dans le cadre de son exploitation et son intégration au sein du SI.
Ce type d'application est en règle générale nommée monolithe. Bien que ce terme ait une connotation négative de nos jours, celles-ci ont fait les beaux jours des directions techniques en proposant une architecture standard, robuste, fiable et intégrée. Généralement déclinées en plusieurs couches applicatives (présentation, business, repository...), ces applications avaient l'avantage d'être simple à développer et leur intégration dans le SI était aisée, car composée de peu de ressource finalement (un serveur web, un serveur d'application et une base de données).
Alors, pourquoi remettre en question l'architecture de ces applications dites "clé en main" ? Plusieurs réponses sont possibles : la maintenabilité, l'obsolescence des briques techniques utilisées, le manque de ressource capable de faire évoluer le produit, etc...
Je vous propose donc une petite réflexion sur le sujet, que vous pourrez retrouver sur le Wiki de Reservoir code et dans lequel je partage ma vision sur le sujet.
Introduction aux microservices
Bonne lecture,
Crédit photo : https://pixabay.com/fr/users/jackmac34-483877/
Commentaires