Face à une accélération continue des besoins du système d’information, la mise en place d’une architecture dite Microservices devient un atout pour l’entreprise. Cette architecture a été inventée pour résoudre les difficultés causées par les gros projets dont la base de code unique et exponentielle pose des problèmes d’évolution, de fiabilité mais surtout d’innovation.
Microservice, qu’est-ce que c’est ?
Il repose en grande partie de la philosophie UNIX, qui prône « ne faire qu’une seule chose, et la faire bien ». Un Microservice peut être défini comme une unité logicielle qui correspond à une fonctionnalité précise, logique et cohérente du système. Il est autonome, a son propre langage de programmation, gère ses propres données et interagit avec les autres services par API. C’est donc un projet indépendant : chacun a son équipe, son calendrier, son organisation. Il est nécessaire d’aborder un Microservice sous 2 aspects : technique et organisationnel. Chaque unité fonctionnelle a sa propre pile technologique. Il faut donc des équipes pluridisciplinaires.
Un microservice, à quoi ça sert ?
- A éviter la refonte totale du système.
- A répondre à la complexité des gros projets dont l’interdépendance entre les différentes briques augmente avec le temps.
- A compléter les services Cloud émergents.
- A conserver la maîtrise fonctionnelle : chaque service a un cycle de vie et une durée de vie propres. Les données d’un service peuvent être mises à jour, consultées, traitées sans impacter les autres briques du système.
- A moderniser l’application.
- A innover sans risque : on peut modifier une fonction sans créer des effets de bord sur d’autres fonctions. On peut faire des test localement, mettre en place des scenari fonctionnels.
- A être scalable.
- A avoir un code source retravaillé (refactoré) ou réécrit complètement en fonction des nouveaux besoins.
« Design For Failure »
Ce système permet de limiter les risques de panne. Les applications conçues en « Design For Failure » fonctionnent en continu malgré les défaillances des systèmes ou des applications connectées. Le principe : le service fonctionne même si la qualité est dégradée.
L’exemple Netflix
Netflix fonctionne avec une plateforme d’exploitation à base d’images Amazon Web Services, qui exécute des containers Docker. Pour afficher une page, Netflix mobilise pas moins de 600 microservices. Il prône le « Design For Failure » préférant offrir à ses utilisateurs un service dégradé plutôt qu’inexistant.
Le projet Docker
- Docker est un logiciel open source, sous licence Apache 2.0. C’est la solution à la mode en ce moment !
- Il automatise le déploiement d’applications dans des conteneurs logiciels.
- Il permet de créer des environnements (appelés containers) de manière à isoler des applications.
Son intérêt :
- Léger donc rapide à lancer
- Mutualise un ou plusieurs serveurs
- Offre un plus gros potentiel en termes de ressources techniques (plus de puissance processeur, plus de mémoire vive, plus d’espace disque…)
- Gère des applications distribuées, avec des systèmes de clustering, et de l’externalisation de base de données, ou de tout autre composant application
En termes d’utilisation, un conteneur Docker peut être apparenté à une VM mais techniquement il en est très loin. Le conteneur Docker utilise directement les ressources de la machine hôte tout en étant isolé des autres conteneurs lancés sur la même machine. Un hyperviseur de type 2 va en revanche, mettre en guise de couche isolante, un système d’exploitation « invité ». C’est une isolation parfaite mais au prix de performances bien plus basses.
Ai-je besoin d’un microservice ?
- Oui, car je veux que mes équipes de développement aient chacune un périmètre fonctionnel restreint pour assurer des itérations courtes et par conséquent être Agile.
- Oui, car je veux que mes développeurs, grâce à une technologie de conteneur, puissent être au plus près de l’environnement de production et je ne veux plus entendre des « Ah ! Je ne comprends pas … ça marchait sur ma machine ! ».
- Oui, car je veux de la Haute Disponibilité et un système ZDD (Zero Downtime Deployment) pour assurer des cycles de livraison automatique (Continuous Deployment).
Les microservices et les conteneurs peuvent-ils être le concept de base pour vos développements ?
- Oui, car je veux que mon système ait la capacité de s’auto-réparer (Self-Healing) dans le cas où une ou plusieurs instances de microservice se trouvent défaillantes (elles seront automatiquement redéployées).
- Oui, car je veux que mes microservices (conteneurs) soient signés à chaque étape de ma chaine de production logicielle pour donner la garantie à mes clients qu’il n’y a pas eu de modifications du livrable par une entité tierce.
Envie d’en savoir plus ? Contactez-nous !
