Les API #2, vers une architecture agile

Si vous n’avez pas encore lu la première partie ? Je vous invite à suivre le lien suivant pour la consulter : Les API, partie #1.

Les API s’insèrent désormais dans la grande majorité des échanges intra et inter-applicatifs. Lors de notre première exploration, nous avons retracé l’historique de leur évolution dans les grandes lignes, puis montré que leur souplesse s’imposait de plus en plus dans l’architecture même des développements modernes à base de microservices.

Micro-Service aka Micro-simplicité

Le maitre mot en matière d’architecture applicative en microservices est simplicité. Elle se conçoit de nos jours pour faciliter les échanges entre processus et garantir un potentiel de croissance. Cette simplification se caractérise par des API qui offrent une "méta-manière" de dialoguer. On entendra par "méta", une façon macroscopique d'enrober la complexité. De plus, pour s’échelonner, les développements peuvent être fractionnés en microservices unitaires et répliqués en parallèle pour répondre à la croissance et une demande en charge spécifique.

Au final, le microservice est une sorte de cellule souche applicative. Il va se dupliquer et grossir, puis réduire, pour former une zone applicative adaptée à un moment t à une demande de traitement d'un backend. Du côté du front-end, on utilisera essentiellement des mécaniques traditionnelles de proxy et l'équilibrage des charges (load balancing) pour absorber et réguler le service. Le but, vous l'aurez compris, est de fluidifier l’expérience utilisateur via des interfaces idéalement adaptées au besoin métier.

Do you speak API ?

Au final, comme chaque microservice effectue ses échanges de manière normalisée via des API, peu importe le langage de programmation avec lequel ils sont réalisés. L’important est de formater les messages à échanger selon une syntaxe commune.

Alors qu’au 20ème siècle on envisageait un développement pratiquement mono-langage, de nos jours il est courant de trouver des microservices réalisés à l’aide de langages de programmation hétérogènes. La sélection se fait désormais en fonction de l'efficacité selon les traitements visés et non plus sur la maîtrise d'un atelier unique de développement. Ainsi, C#, Java, Python, Ruby ou encore Javascript peuvent par exemple se retrouver à dialoguer de manière transparente au sein d’une même application. L’abstraction intellectuelle nécessaire pour envisager de telles architectures est donc radicalement différente et surtout devient pluridisciplinaire. Pour se faire, de nouvelles méthodes et compétences se sont donc développées en matière de programmation, mais également comme nous allons le voir, du côté des infrastructures.

L’API a-t-elle transformé l’infrastructure ?

Dans le monde des infrastructures, le passage à l’apisation des échanges a bouleversé indirectement la donne. Puisque tout est désormais contrôlable par logiciel (sofware defined), pourquoi pas les éléments d’infrastructures ?

Lorsque qu’auparavant ont souhaitait démultiplier ou sécuriser une architecture, on réfléchissait à mettre en place des mécanismes matériels. On s'organisait autour des sujets de mise en grappe - cluster, matériel, voire applicatifs. L’affaire était pour ainsi dire réglée pourvu qu’on se puisse se limiter à 2 ou 3 sites. Aujourd’hui, la distribution des ressources dans le Cloud, la virtualisation et l’automatisation des allocations - sujet traité dans mon précédent article, ont littéralement gommé les freins inhérents aux mécanismes des clusters du paysage et les ont pour ainsi dire relégué au musée de l’informatique. La logique d’une infrastructure toujours plus abstraite a finalement aboutie au design du concept de conteneur, popularisé par le logiciel libre Docker. Environnement technologique virtualisé faisant abstraction du système d’exploitation, il saura exécuter aussi bien du code, que des exécutables interprétés ou non.

Vers une Architecture plus agile

Si la mise en cluster n’a pas disparue dans les entrailles du data center, elle est aujourd’hui renforcée par des architectures plus souples orchestrant conteneurs, microservices et une APIsation logicielle intensive. Cette nouvelle architecture s’applique à simplifier le dialogue entre ses parties stratégiques et sait les répliquer pour absorber sa charge de traitement automatiquement via un orchestrateur. Fort justement, cette automatisation fait l’objet de suites de logiciels pour organiser et canaliser la consommation des éléments d’infrastructures sous-jacents, qu’ils soient internes (sur cloud privé) ou externes (sur cloud public). De manière macroscopique, avec l'orchestration et l'automatisation des échanges par API, l’architecture devient donc plus agile et peut croitre ou décroitre selon les besoins instantanés.

Pour aller plus loin

Vous voilà désormais bien armé pour mieux comprendre le Système d’Information du 21ème siècle ! Je vous invite donc à plonger en complément au cœur des réseaux du futur et des nouvelles architectures dites Software Defined qui s’appliquent désormais au LAN ou au WAN. Ces dernières induisent une autre façon d’aborder l’IT et plus généralement les opérations d’une DSI. Vous pourrez également voir que la sécurité des échanges et l’étanchéité telle qu’on l’envisageait à base FireWall a également fortement évoluée, pour aller se greffer au cœur des mécaniques de conteneurisation / virtualisation en offrant une micro-segmentation à base applicative.

Bibliographie

• Retour d’expérience : Platform.Sh par Orange Business Services, la transformation digitale par le cloud
• Software Defined Container Orchestration
• Why are open APIs needed in a software-defined network?
• The Role of APIs in a Software Defined Datacenter
• Bien comprendre les Infrastructures Programmables et le Software Defined Datacenter
• Microservices and API Complexity – Inside and Out

 Thierry Gluzman - Orange Consulting

Consultant et Senior Manager au sein d'Orange Consulting, je m'intéresse plus particulièrement à la maturité technologique des entreprises.

J'accompagne les DSI à l'évolution des plans, SDSI ou feuilles de route. Pour cela, je propose des missions de challenge et d'audit de maturité technologiques où je fais intervenir nos experts technologiques, fonctionnels et nos chercheurs à la pointe de l'innovation.

Pour moi, faire évoluer votre stratégie en y insérant judicieusement l'innovation est un "must have", pour délivrer des services aux clients toujours plus adaptés et performants.

Rejoignez-nous chez Orange Consulting