Le Cloud, qu’il soit public, privé ou hybride, décrit un ensemble de services managés, utilisables de manière automatisée.
Le terme “Cloud native” décrit quant à lui un degré de maturité dans l'utilisation du cloud et en particulier la maximisation de son automatisation.
L’automatisation
L’automatisation est l’élément central d’une démarche Cloud native. Elle permet de gérer, sans intervention humaine, à la fois :
- une infrastructure dynamique (ex : varier le nombre de serveurs en fonction de la charge) ;
- les applications métier qui utilisent cette infrastructure (ex : maintenir un nombre prédéfini d'instances saines de l’application).
Le but premier est donc clairement d'accroître la disponibilité du système, mais cette maîtrise de l'automatisation a élargi du même coup le champ des possibles. En retirant une très grande partie des interventions manuelles et en permettant de gérer des configurations de plus en plus complexes, elle rend possible l'architecture "microservices" qui serait totalement irréalisable sinon et qui, comme nous allons le voir, est un facteur clé pour créer facilement et fréquemment de la valeur business.
Les microservices comme horizon
Pourquoi souhaiter une architecture qui introduit d'emblée une plus grande complexité technique que l’approche traditionnelle ? Parce qu'elle permet, paradoxalement, de limiter drastiquement la complexité sur le long-terme tout en garantissant la possibilité d'évoluer fréquemment et de manière incrémentale.
Pour la résumer, l'architecture dite "microservices" repose sur une multitude de petits modules logiciels à responsabilité limitée, déployables indépendamment et qui se composent grâce au réseau pour former un logiciel extrêmement souple et résilient.
Exemple d'architecture microservices pour une application de réservation de places de concert.
La liste des microservices :
- plusieurs “services de base” : user_profiles, venues, events, payments, notifications ;
- et “services métiers” : proceed_booking, cancel_booking, refund_booking
Les services de base exposent simplement une interface permettant de manipuler les entités qu’ils représentent sans présupposer la finalité de ces manipulations. Les services métiers utilisent quant à eux ces interfaces afin d'implémenter leur logique métier propre sans se soucier des détails d’implémentation des services de base.
Découper simplement un logiciel en petits morceaux ne suffit donc pas à créer une architecture microservices car les avantages qu’elle procure sont la conséquence directe de caractéristiques particulières :
- "petits modules" : disons assez petits pour pouvoir être entièrement réécrits sans crainte d’aléas de coût, de délai, de qualité, si besoin. On est alors libre du choix du langage de chaque service. On choisira en particulier celui qui correspond le mieux aux besoins actuels et à l’équipe engagée ;
- "à responsabilité limité" : c'est un facteur clé pour réduire la complexité et donc à la fois le temps de développement et le niveau de séniorité nécessaire ;
- "déployables indépendamment" : plusieurs équipes peuvent alors travailler en parallèle sans interférence.
L'humain au coeur des avantages procurés par cette architecture
Les développeurs peuvent travailler sereinement, sans crainte de casser une dépendance masquée par des milliers de lignes de code. Ils le font vite, dans le langage le plus adapté et sur des services dont la difficulté ou criticité est en accord avec leur degré de séniorité.
C'est l'architecture la plus inclusive : imaginez une offre de poste traditionnelle type "recherche développeur Java senior, 8 ans d'expérience minimum" devenir "recherche developpeur, tous langages et niveaux bienvenus" ! Sans que cela ne porte atteinte à la fiabilité du logiciel, bien au contraire.
Autre différence majeure avec l'approche traditionnelle : dans une architecture microservices, les développeurs mettent à disposition des services qui seront ensuite instanciés et agencés par les Ops en vue de créer le comportement souhaité (la distinction entre les deux se floute donc naturellement). Le logiciel n'est donc plus du code ayant besoin de l'infrastructure pour s'exécuter mais une configuration de l'infrastructure implémentée par l'exécution du code.
Ce renversement est rendu possible par les nouvelles capacités de programmation de l'infrastructure offerte par les outils de l'écosystème Cloud native. Vous souhaitez en savoir plus ? Cliquez ici pour un tour d'horizon.