Jusqu'à récemment, pour effectuer une petite modification sur une application web, il était nécessaire d'intervenir sur un bloc monolithique contenant tout le code source de l'application en question, impliquant souvent divers départements de l'entreprise, du contrôle qualité à l'administrateur système, jusqu'au marketing.

Cette approche - désormais traditionnellement appelée « monolithique » - est encore aujourd'hui la plus courante dans le domaine du développement d'applications web, mais tout semble indiquer qu'elle touche à sa fin.

Depuis des entreprises comme Netflix, parmi les premières à avoir emprunté cette voie, un processus de révolution a été lancé, impliquant l'ensemble du secteur IT, avec la déconstructions des systèmes monolithiques des services web en faveur des soi-disant microservices.

Mais que sont les microservices ? Et pourquoi les plus grandes entreprises IT du monde ont-elles abandonné les structures natives de leurs services pour adopter l'architecture des microservices ?

Microservices: le cas de Netflix

La plupart des entreprises concevaient leurs services web selon une structure unique - monolithique - permettant une mise au point rapide et une distribution facile du service. Ce système est encore parfaitement adapté aux besoins des petites entreprises ou de certaines startups, dont le cœur de métier est étroitement lié à l'activation et au déploiement de services et de produits toujours nouveaux.

Cependant, à mesure qu'un système informatique croît, le code devient plus complexe, tout comme les tâches de maintenance et de gestion du monolithe. De plus, face à une architecture monolithique, plus le système croît, plus la vitesse, l'agilité et la flexibilité des services sont affectées - des aspects cruciaux pour tout business ayant une activité web intense, comme un e-commerce ou un service de streaming.

C'est pourquoi les plus grandes entreprises IT du monde, à commencer par Netflix, mènent la transition historique vers l'architecture des microservices. Le cas de Netflix est significatif : l'entreprise a commencé le processus de migration de tous ses services vers le cloud en microservices en 2009, terminant l'opération seulement en 2011.

Deux années de travail ont permis à Netflix de développer plus de 1000 microservices et API Gateways qui gèrent quotidiennement plus de deux milliards de demandes de la part des utilisateurs. Il est bon de rappeler ici que Netflix est une entreprise avec plus de 200 millions d'utilisateurs à travers le monde, qui, selon les statistiques les plus récentes, passent plus de 165 millions d'heures - chaque jour - à "consommer" le contenu de la plateforme.

Le cas de Netflix, en plus d'être l'un des premiers exemples de succès dans la transition vers la nouvelle architecture, est emblématique de la relation importante entre la nouvelle forme des services et la migration des contenus vers les serveurs cloud.

Le besoin fondamental, à la base des deux processus, est celui de la scalabilité des services: Adrian Cockcroft, l'architecte cloud à l'origine de la transition chez Netflix, a clairement expliqué comment ce passage est devenu essentiel avec l'augmentation du nombre d'utilisateurs du service.

Il était impossible, explique Cockcroft, d'avoir suffisamment d'espace physique pour stocker toutes les données des nouveaux utilisateurs du service, qui était alors en train de croître vers les dimensions connues aujourd'hui.

La transition vers une configuration basée sur le cloud a permis, parallèlement, de diviser le gigantesque système Netflix en microservices. Mais que sont les microservices, et pourquoi la transition vers l'architecture des microservices est-elle désormais essentielle pour les entreprises IT en termes de scalabilité et d'implémentation des services ?

La scalabilité des services: microservices, modèle n-tier et API

Pour comprendre l'horizon dans lequel naît la nécessité toujours plus pressante de se confronter à l'architecture logicielle, il est nécessaire de partir d'un présupposé désormais clair : la diffusion des smartphones et autres dispositifs avec connectivité web a révolutionné à la fois l'utilisation côté utilisateur et les besoins de développement des applications web.

Jusqu'à il y a quelques années, une application web devait être capable d'interagir avec une seule entité à la fois, généralement le navigateur web. Aujourd'hui, nous accédons à différents services depuis des dispositifs très différents par usage et caractéristiques, raison pour laquelle la rapidité et la réactivité d'une application web sont aussi importantes que le produit lui-même.

Recourir à une architecture logicielle basée sur le modèle multi-tier, ou n-tier, où les différentes fonctionnalités correspondent à différents niveaux logiciels, est désormais une pratique courante pour les développeurs. Depuis le début des années 2000, les services three-tier sont construits, où les trois niveaux correspondent généralement à l'interface utilisateur, aux processus proprement dits et à l'archivage des données.

Mais le modèle à trois niveaux n'était pas conçu pour l'utilisation massive que nous faisons aujourd'hui des smartphones et de l'IoT. La transition vers l'architecture des microservices prévoit l'ajout d'au moins une autre couche, raison pour laquelle on parle de plus en plus souvent d'architecture four-tier ou n-tier.

La division de l'application en niveaux est rendue possible par les API (Application Programming Interface), petits éléments fonctionnels et indépendants du langage de programmation qui, exposés entre un niveau et l'autre, permettent la communication bidirectionnelle en temps réel entre deux niveaux, par exemple la base de données et l'interface de connexion d'une application.

Quels sont les quatre niveaux d'un tel système?

- **Client** : le premier niveau concerne encore l'interface utilisateur, qui peut être modifiée même complètement sans interférer avec les trois autres niveaux. De cette manière, il est possible d'offrir des services parfaitement réactifs et centrés sur une expérience utilisateur de qualité toujours croissante ;
- **Delivery** : le niveau delivery s'occupe d'optimiser la « livraison » des contenus et des services en fonction des informations reçues de l'utilisateur, de la puissance de la connectivité web aux spécifications du dispositif impliqué dans l'échange ;
- **Aggregation** : le niveau « agrégatif » est celui qui met en communication, en temps réel, les services et ressources internes et externes via les API. Par exemple, Netflix utilise les AWS (Amazon Web Services) pour le stockage en cloud de ses bases de données, c'est pourquoi il est nécessaire que le service Amazon et celui de Netflix puissent communiquer efficacement.
De nombreuses applications sur nos smartphones utilisent aujourd'hui des ressources externes en temps réel pendant que nous les utilisons : exactement comme Netflix, qui fait constamment appel aux services Amazon pour distribuer ses contenus aux millions d'utilisateurs dans le monde entier.

- **Services** : le dernier niveau, dans une architecture ainsi composée, est celui qui fournit aux autres niveaux les données et les fonctionnalités requises par l'application. Le niveau de service prend tout son sens dans le contexte de l'application d'une architecture de microservices : il s'agit en effet d'appliquer une sorte de moteur principal, indépendant des autres, à ces services qui sont essentiels pour la distribution du logiciel, comme le service de connexion ou le traitement des paiements par carte pour tout e-commerce.
Dans une architecture de microservices, chaque fonctionnalité a son propre petit moteur, et les éventuels dysfonctionnements d'un service unique (par exemple, la gestion de l'image de profil d'un utilisateur sur un site) n'affecteront pas le reste du système.

Voilà le sens ultime de la déstructuration d'un monolithe comme Netflix, et voilà le passage inévitable pour toute entreprise qui souhaite « scaler » ses services au-delà d'un certain seuil, pour que la proportion entre le nombre d'opérations et l'effort du système doive nécessairement changer de ratio.

Le système Netflix tel qu'il était en 2011 - juste avant la transition opérée par Cockcroft - nécessitait environ 100 développeurs employés dans la maintenance constante d'un monolithe de plus en plus grand et complexe. À l'époque, il comptait un peu moins de 30 millions d'utilisateurs.

Il est légitime de se demander si la croissance exponentielle de Netflix aurait été physiquement possible, sans la migration de l'ensemble du système vers une structure de microservices basée sur le cloud.