On parle d’une application monolithique lorsque les 3 couches interface d’utilisateur, traitement et accès aux données, sont regroupées en un seul composant. 

 

Contrairement à ce qu’on peut penser, une application monolithique présente aussi des avantages. Il est très fréquent actuellement de trouver des idées reçues qui définissent les architectures monolithiques comme étant obsolètes, mais ce n’est pas du tout la réalité. Tout dépend du cas d’utilisation, du budget et de la taille des équipes de développement. Même les entreprises qui sont aujourd’hui des modèles d’innovation comme NetFlix, Uber, Google, Amazon ou Facebook ont démarré sur des architectures monolithiques durant plusieurs années. Les questions liées aux architectures microservices sont posées sur la table lorsque l’activité de l’entreprise connaît un succès.


https://www.redhat.com/en/topics/microservices/whtraductionat-are-microservices

Comme il est plus facile de mettre en place une architecture monolithique, il est plus intéressant de démarrer un nouveau projet en adoptant une architecture monolithique et en concentrant tout effort sur la partie business pour la réussite du projet. Je pense que ce type de mindset est maintenant très fréquent chez les entrepreneurs.

 

“Si mon application tombe à cause du succès de mon business, c’est parce que j’ai réussi et il faut que je passe à l’étape suivante. “

 

Cas Airbnb: Lorsque l’équipe s’agrandit vite

 

Jessica Tai, développeur chez Netflix, nous explique, lorsqu’elle rejoignait Airbnb en 2014, l’équipe était composée de 90 personnes, tout tenait dans un seul étage d’immeuble. 4 ans après, l’équipe tourne autour de 2000 développeurs, dans plusieurs immeubles et dans plusieurs villes.  La question était comment “onboarder” chacun des 2000 développeurs tout en étant productif. La réponse était naturellement de migrer vers une architecture distribuée. 

 

Avec une architecture monolithique, vous imaginez bien tout le contexte qu’un nouveau développeur doit connaître avant même de produire une ligne code. Avec une architecture monolithique, chaque nouveau développeur de NetFlix devrait être formé plusieurs mois, comprendre toute la logique Business de NetFlix et forcément utiliser le langage de programmation déjà choisi par les anciens de l’équipe. Un autre aspect est la responsabilité qu’il faut pour qu’un développeur applique un petit nouveau changement qui impactera tout le système, ce qui ajoute ainsi un stress supplémentaire.

 

 

Cas NetFlix: Lorsque l’activité connaît un grand succès:

 

Netflix a été créé en 1997. 10 ans après, en 2007 NetFlix annonce le lancement de sa plateforme de Streaming qui connaît un très grand succès juste quelques mois après. En Août 2008, une corruption de base de données avec leur architecture monolithique entraîne un arrêt de l’activité pendant 3 jours. Cet événement pousse Netflix à migrer vers AWS.

 

La plateforme de Streaming connaît un très grand succès, avec une demande des utilisateurs très difficile à suivre. 

Netflix veut trouver un moyen pour que l’infrastructure et les applications puissent suivre cette demande grandissante. La solution liée à l’infrastructure était de tout migrer vers le Cloud et supprimer petit à petit les datacenters. La solution liée aux applications était d’adopter une architecture distribuée pour répondre plus vite à la demande des utilisateurs.

 

Les deux exemples, AirBNB et NetFlix, montrent juste que le choix d’une architecture dépend toujours du contexte lié à la taille de l’équipe, au budget et au succès du projet.