Du Monolithe au Serverless

L’évolution des système d’information à suivi l’augmentation du volume de data et les nouveaux besoins de l’entreprise. De la naissance du monolithe métier fonctionnant en silo qui ont conduit au SOA puis aux microservices, nous sommes arrivés aujourd’hui au Serverless. Flashback !

Avant l’an 2000

Dans cette période préhistorique de l’IT, les entreprises développent des applications afin de traiter les flux croissants d’information. Elles en profitent pour mieux contrôler leurs processus qu’ils soient administratifs, industriels ou commerciaux. 

A cette époque, chaque population d’utilisateur connaissait son propre métier et définissait ses processus. Un applicatif répondant à ses attentes et besoins était alors déployé. Très vite le problème du partage de données s’est posé. Comment faire pour l’équipe logistique puisse partager avec l’équipe de production ?

Le premier élément de réponse est venu des ERP (Enterprise Ressource Planning en Anglais ou Progiciel de Gestion Intégrée). Simplement, une seule et même application pour toutes les équipes. Il suffit de monter une seule énorme base de données et tout le monde partage la même information. Pas si simple ! Cela a soulevé tous les problèmes de qualité de la Data et autres.

En cette fin de 20ème siècle, la norme était de mettre en œuvre un « monolithe » répondant à chacun des besoins. Leur périmètre pouvait englober toute l’organisation ou seulement un groupe d’utilisateurs.

Ils prenaient plusieurs étapes d’un ou plusieurs processus, pour des utilisateurs définis et dans leur propre ensemble de données, d’où l’appellation « monolithe ». Cette époque est aussi le début de la « transformation digitale » des entreprises qui commencent à accumuler de la data et le besoin des outils pour l’exploiter se fait sentir. Les solutions de Business Intelligence, Intelligence Opérationnelle et Analytics voient alors le jour

monolithe

Le besoin de communication mène au SOA

Dans une entreprise, toutes le équipes travaillent toutes ensemble. En conséquence, il faut ouvrir les applications. Progressivement, le monolithe s’est désintégré. Pour pouvoir partager la donnée entre les différents applicatifs, les ETL (Extract Transform Load), des ESB (Enterprise Service Bus) et des EAI (Enterprise Application Integration) entrent en piste.

Puis, on se dit que pour aller plus vite et atteindre le temps réel les applications devraient communiquer directement : c’est la naissance du SOA («Service Oriented Architecture). Techniquement, dans ce type d’architecture une application est responsable d’un périmètre de l’activité et doit fournir aux autres, les informations et fonctionnalités associés à ce périmètre.

Les avantages sont multiples. Premièrement, l’architecture du SI est plus nette. Plus besoin de doublons dans les données comme dans fonctionnalités. Deuxièmement, les fonctionnalités seront mutualisées. C’est-à-dire qu’une nouvelle application n’aura pas besoin de prévoir les fonctions déjà gérées par d’autres applications, qu’il s’agisse de fonction techniques ou métier. 

Enfin, la SOA constitue le premier élément de modularité du SI. Les applications communiquent entre elles. A la volée quand elles en ont besoin.

La déconstruction du monolithe se poursuit avec les microservices

microservices monolithes

Les microservices sont une transposition du SOA au niveau de l’application métier elle-même. Dans cette optique, chaque fonction est vue de façon autonome. La fonction est considérée comme un service indépendant. De plus, les microservices communiquent entre eux via des protocoles spécifiques et standardisés.

A l’extrême, on peut presque considérer que chaque microservices est une application à part entière. Les faire évoluer, les déployer et les dimensionner se fait de façon simple et souple. 

Les microservices apportent quatre avantages principaux : rapidité, réduction des coûts, réactivité, évolutivité et performance. En cas de changement, il est possible de développer une mise à jour d’un microservice sans attendre, ni atteindre les autres. Ainsi on peut faire évoluer plus rapidement les fonctionnalités.

On va pouvoir allouer à chaque service la bonne quantité de ressources et non à toute l’application. In fine, on réduit les coûts d’infrastructure. En effet, en cas de panne, on identifie le microservices défaillant et on le corrige rapidement. Enfin, chacun des services étant indépendants, on peut mettre des équipes différentes sur un même projet, chacun travaillant dans son propre langage. 

Bref, les microservices ont tout pour plaire. Et si on pouvait trouver encore mieux ?

L’explosion du cloud conduit vers le Serverless

La proposition de valeur du cloud, c’est globalement de ne pas avoir à se soucier de l’infrastructure. Mais même dans le cloud, on peut avoir des pannes ou un manque de ressource machine. Voire des ressources non exploitées qu’il faudra quand même payer.

C’est là que le Serverless apparaît. L’idée est tout simplement de laisser le prestataire cloud gérer en totalité les ressources. Cette fois-ci, on oublie vraiment l’infrastructure. La planification devient inutile car le prestataire garantit qu’il répondra à la demande. Il va gérer de façon automatisée et dynamique les ressources qui vont être allouées aux diverses fonctionnalités et microservices.

Le Serverless s’inscrit dans son temps avec les besoins de modularité et de souplesse de l’IT. Les microservices avaient accéléré le déploiement. Sans l’infrastructure à gérer, on va encore plus vite. L’autre avantage évident, puisque c’est le prestataire qui gère, on doit avoir une meilleure performance et une plus grande disponibilité. Sur les coûts, les fournisseurs de Serverless (Firebase de Google, Amazon et Microsoft) ne font payer que ce qu’on consomme. 

Du côté des inconvénients on retrouve les coûts. Vu qu’ils sont variables, on va les garder à l’œil pour éviter qu’ils n’explosent.

L’autre limite actuelle au Serverless, c’est qu’il faut adapter son code à la plateforme et utiliser des fonctions mises à disposition par le prestataire. Ce qui rend le changement de prestataire compliqué. Même si des frameworks permettant d’être agnostique quant au cloud cible commencent à apparaître.

En conclusion : le Serverless n’est pas la fin du DevOps. Les mécaniques d’intégration et de déploiement continus restent d’actualité. Ce que cette technologie simplifie, c’est la partie OPS.