Qu’est-ce qu’une application monolithique ?

La première étape de la migration des applications monolithiques vers Kubernetes

 Kris Nova
2 Févr. 2018 * 4 min de lecture

Tout au long de ma carrière en génie logiciel, l’une des questions les plus précieuses que j’ai apprises à poser à un collègue est « Qu’est-ce que mean quelque chose signifie pour vous? ». Cela oblige l’autre ingénieur à évaluer leurs implications d’utiliser un certain mot. Suite au premier appel d’applications Monolithiques mobiles vers Kubernetes, je voulais passer quelques minutes à parler de ce qu’est une application monolithique. Ou du moins, ce que cela signifie pour moi.

C’est un espace intéressant qui nécessite une certaine attention. Bien que l’exploitation d’un microservice sans état sur Kubernetes soit relativement facile, l’exploitation d’une grande application avec état a encore un long chemin à parcourir. Comprendre ce qu’est une application monolithique sera la première étape pour faciliter le processus de migration.

Pour définir une application monolithique, nous devons d’abord comprendre les composants d’une application qui nous tiennent à cœur. Les trois composants qui nous intéressent seront l’interface utilisateur, la couche d’accès aux données et le magasin de données.

L’interface utilisateur est le point d’entrée de l’application, et est également le point du programme avec lequel un utilisateur interagira. Cela peut être une fonction main(), un site Web, un service Web ou divers autres points d’entrée.

La couche d’accès aux données est la couche du programme qui enveloppera un magasin de données. En règle générale, la couche d’accès aux données gère des problèmes tels que l’authentification avec un magasin de données et la désinfection des données avant qu’elles ne persistent dans le magasin de données.

Le magasin de données est la partie la plus fondamentale du système et est responsable du stockage d’informations arbitraires (données) et de leur récupération. Ce composant n’est généralement qu’une base de données.

Ces trois composants constituent un type d’application très courant appelé application avec état. Ce qui signifie que l’application stocke et manipule les données au fil du temps. Par conséquent, nous disons que l’application a un état. Plus important encore, que l’état de l’application peut changer avec le temps.

Dans le cas d’une application monolithique, on observe généralement plusieurs couches de l’application étroitement couplées entre elles. Dans l’exemple ci-dessous, nous pouvons voir que l’interface utilisateur et la couche d’accès aux données sont regroupées. Cela se fait généralement via un dépôt de code volumineux, et ces deux couches dépendront probablement de l’autre pour être en place afin de s’exécuter. De plus, l’interface utilisateur et les couches d’accès aux données sont généralement regroupées dans le même processus au moment de l’exécution. Ce qui signifie qu’ils communiquent sur le même système, en utilisant les ressources système (mémoire et cycles de calcul) pour interagir avec d’autres parties du système.

Au contraire, une application basée sur des microservices serait composée de petits composants modulaires qui peuvent facilement être désactivés. Cela offre un concept de composabilité pour un opérateur et est un signe que vous travaillez avec des microservices au lieu d’une application monolithique. L’exemple ci-dessous démontre une application flexible et modulaire. Notez que dans ce modèle, nous pouvons exécuter les composants plus petits indépendamment et utiliser un réseau pour connecter notre système ensemble. Cette approche est beaucoup plus évolutive.

Alors, qu’est-ce qu’une application monolithique? Il s’agit d’une application logicielle à un seul niveau dans laquelle l’interface utilisateur et le code d’accès aux données sont combinés en un seul programme sur une seule plate-forme. C’est aussi une application qui exécute plusieurs composants dans le même processus, sur le même système.

Pour aller de l’avant, nous cherchons à comprendre les nuances de la migration des applications monolithiques vers Kubernetes, et espérons que c’est une première étape précieuse de notre voyage. Comme le processus est relativement peu documenté, nous prévoyons de partager les leçons apprises, afin que tout le monde puisse en bénéficier.



+