Published by

Il y a 3 mois -

Temps de lecture 8 minutes

Pourquoi et comment développer sa plateforme IoT avec l’approche Cloud Native ?

Une plateforme IoT est caractérisée par des problématiques de gestion d’équipements hétérogènes, de traitements et de stockage de grandes masses de données. Par conséquent, il est nécessaire de concevoir une plateforme à partir d’une architecture évolutive et flexible. Certaines entreprises optent pour une architecture monolithique qui n’est pas adaptée aux problématiques précédentes. Cet article vous montrera comment il faut, dès le départ, s’inspirer des grands fournisseurs de cloud et concevoir une application avec une approche Cloud Native (ou native pour le cloud) associée à une architecture en microservices. De plus, combinée à la technologie de conteneurs Linux orchestrée par un système open source tel que Kubernetes, nous montrerons comment vous gagnerez une plus grande liberté de choix des technologies, des environnements de développement et des langages de programmation, idéale dans un contexte de collaboration d’équipes agiles.

Les grands fournisseurs de cloud AWS, Microsoft Azure et GCP – fournissent des outils très performants pour une telle architecture. Alors pourquoi Kubernetes, un outil plus complexe à mettre en oeuvre, est-il une alternative intéressante ? Tout d’abord, choisir un cloud c’est être dépendant d’une entreprise (cloud lock-in en Anglais). De plus, certaines entreprises ne souhaitent pas migrer vers un cloud étranger pour éviter d’être espionnées, comme le permet par exemple la loi américaine avec le Cloud Act. Enfin, Kubernetes connait un tel succès qu’il est désormais disponible en service managé dans les principaux cloud français (OVHCloud et Scaleway), d’où l’intérêt de cette suite d’articles.

Dans un autre article à venir, nous vous montrerons au travers d’un projet de station agricole connectée, comment il est possible de construire une plateforme IoT conçue à partir des concepts précédents et de solutions open source telles que Kubernetes, Apache Spark, MinIO, Elasticsearch… Alors restez avec nous !

Cloud Native : de quoi parle-t-on ?

Cloud Native est une approche pour construire et exécuter des applications qui exploitent les avantages du modèle de livraison du cloud computing. Il s’agit donc de savoir comment créer et déployer des applications et non pas où. Ainsi, ces applications peuvent être livrées aussi bien dans un cloud public que privé.

L’approche Cloud Native, définie par la CNCF, se caractérise par l’utilisation d’architectures en microservices, de la technologie de conteneurs, de livraisons en continu, de pipelines de développement et d’infrastructure exprimés sous forme de code (Infrastructure As a Code), une pratique importante de la culture DevOps. Cette approche accélère donc le développement de logiciels et favorise la création d’applications résilientes et évolutives. Tout cela est résumé dans l’image suivante :

Les quatre fondements de l’approche Cloud Native (Source : pivotal)

 

Préoccupons-nous à présent de l’architecture qui est le socle d’une application. Dans l’approche Cloud Native, celle-ci est en microservices.

Pourquoi passer d’une architecture monolithique à une architecture en microservices ?

Une architecture monolithique classique (voir l’image ci-dessous) est souvent découpée en trois modules : un module pour l’interface utilisateur, un pour la logique métier et un dernier pour l’accès à la base de données (BDD). De plus, la base de code est souvent unique, ce qui fait qu’avec le temps le code devient très volumineux, difficile à tester, à maintenir et à faire évoluer. Cette architecture n’est donc pas dans les standards de qualité logicielle où la rapidité de développement de nouvelles fonctionnalités et leur déploiement sont essentielles.

L’architecture en microservices, quant à elle, a été pensée pour des applications logicielles complexes et volumineuses. Elle découpe une application en services indépendants, connectés les uns aux autres avec un contrat d’interface utilisant des protocoles comme HTTP/HTTPS, WebSockets, AMQP, etc. Chacun de ces services se concentre sur l’achèvement d’une fonctionnalité ou plusieurs fonctionnalités proches. Cette architecture est idéale pour un système vivant et évolutif où les développeurs choisissent plus facilement les technologies, les environnements de développement et les langages de programmation. En outre, le code est beaucoup moins volumineux, et donc plus simple à tester, à maintenir et à faire évoluer.

Comparaison entre architecture monolithique et architecture en microservices

Chacun chez soi et les microservices seront bien gardés !

Aujourd’hui, on choisit de plus en plus de déployer et d’exécuter une application sur un même ensemble de serveurs physiques appelé cluster, il en va de même pour les microservices. Les exécuter sans les isoler les uns à coté des autres amène à des interférences sur les bibliothèques concurrentes, la bande passante, la gestion des resources CPU et mémoire. Il est alors nécessaire d’isoler les services les uns des autres. Deux technologies sont principalement utilisées pour l’isolation de service: la virtualisation de machine et la conteneurisation.

La technologie de virtualisation de machine consiste à créer et exécuter sur un même serveur physique des versions virtuelles de machines réelles, appelées machines virtuelles. Pour cela, une machine virtuelle contient un système d’exploitation complet avec ses pilotes, des fichiers binaires ou des bibliothèques, ainsi que l’application elle-même. Chaque machine virtuelle s’exécute sur un hyperviseur (voir image ci-dessous), qui s’exécute à son tour sur un système d’exploitation hôte, qui lui-même fait fonctionner le matériel du serveur physique. Il s’agit d’une technologie robuste qui a fait ses preuves, cependant chaque ajout d’une machine virtuelle consomme une grosse partie de la mémoire (plusieurs Go) du serveur physique, car chaque machine virtuelle embarque un système d’exploitation. Ainsi, l‘utilisation de machines virtuelles ne semble donc pas être la méthode la plus optimisée pour exécuter des microservices.

Dans le cas de la technologie de conteneurisation, seul l’environnement d’exécution est virtualisé, et non le système d’exploitation. Ce qui crée donc une version virtuelle légère, appelée conteneur, d’une machine réelle. Contrairement à une machine virtuelle qui embarque un système d’exploitation, un conteneur s’appuie sur le système d’exploitation du serveur physique tout en embarquant les bibliothèques nécessaires à l’exécution de l’application. Un conteneur étant généralement plus petit, il est alors possible d’exécuter beaucoup plus de conteneurs que de machines virtuelles sur un même serveur physique. Par conséquent, il est plus avantageux et conseillé d’utiliser la technologie de conteneurisation pour accueillir des microservices.

 

Comparaison entre virtualisation et conteneurisation (source : docker.com)

Un orchestrateur pour les gouverner tous

Après avoir développé (et bien sûr testé) son application sous forme de microservices, il est temps de les déployer sur un cluster de serveurs. Bien évidemment, la livraison ne se fait pas manuellement mais à l’aide d’un pipeline CI/CD avec des outils comme GitLab, GitHub Actions ou Jenkins. Et c’est après cela qu’intervient la notion d’orchestrateur de conteneurs. Il s’agit d’un système installé dans le cluster qui est en charge de la gestion du déploiement, du cycle de vie, du redémarrage automatique en cas de panne, de la communication réseau et de la scalabilité en fonction de la sollicitation des microservices. Ainsi, il nous suffit de transmettre à l’orchestrateur l’image du microservice qui sera alors déployé et géré par celui-ci.

Les principaux systèmes open source d’orchestrateurs de conteneurs sur le marché actuel sont :

Kubernetes a remporté cette guerre des orchestrateurs. Preuve de son succès, les deux autres concurrents américains, Amazon et Microsoft, fournissent, en plus de leur propre solution d’orchestration de conteneurs, une solution managée de Kubernetes. En France, OVHCloud et Scaleway proposent également une solution managée de Kubernetes.

 

if serverless: my_function = my_service

Nous savons maintenant qu’il est possible de déployer nos microservices via un orchestrateur de conteneurs. Mais en l’absence d’une gestion fine et correcte des ressources, il est tout à fait possible d’avoir des microservices qui s’exécutent en permanence, alors même qu’ils ne sont pas sollicités. Hors une exécution « inutile » amène une augmentation des coûts injustifiés. Cela nous amène donc à présenter le concept de serverless où les fonctions (c’est-à-dire des parties du code de l’application globale) sont traitées en tant que service (Function as a Service – FaaS). Le service ne s’exécute que s’il y a une nouvelle entrée ou évènement (fichier, message ou requête HTTP) à traiter.

Les principaux fournisseurs de cloud (AWS, Microsoft Azure, GCP) ont été les premiers à proposer sous forme de service managé la possibilité de fournir uniquement le code de la fonction, et c’est le service qui est en charge d’encapsuler l’application au sein d’un conteneur ou d’une machine virtuelle et d’en gérer le cycle de vie. Le service n’est facturé que pour la quantité de ressources utilisées lors de l’exécution du code. Chez AWS il s’agit du service Lambda, et de Functions chez Microsoft Azure et GCP.

Depuis peu, cette solution existe en open source comme Knative de Google, Openwhisk incubé par IBM et Red Hat, OpenFaas récemment repris par VMWare ou encore Fissions de Platform9.

Conclusion

Ce premier article a été l’occasion d’aborder l’approche Cloud Native et nous a permis de voir qu’il était intelligent de l’utiliser pour construire une plateforme IoT. Nous avons parlé de microservices, de conteneurs et d’orchestrateurs. Des concepts que nous allons retrouver dans notre second article, où nous expliquerons avec plus de détails techniques comment les utiliser dans le développement d’une application au travers d’un projet de station agricole connectée.

Published by

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.