Oui, j’ai dis “Fog Computing”
Dans mon précédent billet j’ai expliqué le «pourquoi» de Fog Computing. http://bit.ly/1Cp87wP. Ici, je vais me focaliser sur certains aspects du «comment».
Rappelons ce dont on parle: Fog est un complément du Cloud Computing. Par l’embarcation des applications dans les éléments réseau (commutateurs, routeurs, caméras,…) à proximité des objets on peut contourner les défis réseau (délai, bande passante, volume des données,…).
Comme on peut imaginer, il y a plusieurs défis techniques auxquels il faut faire face pour que Fog Computing se développe. J’en ai choisi deux pour le sujet de ce billet.
- Comment embarquer des applications dans les éléments réseau
- Comment attirer une communauté de développeurs d’applications
La virtualisation permet d’embarquer les applications dans les éléments réseau
Le CPU, la mémoire et le stockage des éléments réseau doivent être partagés en toute sécurité entre l’application et le logiciel de base des éléments réseau (le logiciel de base et le logiciel de routage, de commutation etc). Par sécurité, je veux dire que l’application ne peut pas influer sur le fonctionnement de l’élément de réseau et vice-versa. Pour réaliser ce partage on peut s’inspirer des techniques de virtualisation des serveurs qui sont assez bien rodées.
Une approche consiste à installer un hyperviseur sur l’élément réseau et de packager l’application avec son OS dans un VM. C’est une approche tout à fait convenable, mais l’hyperviseur consomme des ressources ce qui pourrait être problématique pour des applications lourdes. Il y aussi une dépendance entre un VM et le type de CPU utilisé dans l’élément réseau. Etant donné la diversité de CPUs utilisés dans les éléments réseau (ARM, X.86, PowerPC,…) cette dépendance peut devenir onéreuse car il faudrait construire un VM pour chaque type de CPU.
Une autre approche est d’utiliser la technologie « Linux Containers » (LXC) qui évite l’hyperviseur et la dépendance avec le CPU. La « portabilité » est en effet un des points fort de LXC ainsi qu’une consommation de ressources plus faible d’un hyperviseur.
Au final, je crois que nous allons voir les deux approches sur le marché en fonction de la taille de l’application et du type d’élément réseau.
Faciliter le développement des applications est la clef pour attirer les développeurs.
Il y quelques semaines Cisco a acheté une entreprise de 43 personnes appelée Tropo qui fournit un service de Cloud Communications (appels mobile, SMS etc.) – sujet éloigné de Fog et l’IdO, mais un très bel exemple de comment attirer une communauté de développeurs – 200,000 en l’occurrence! Pour cela, ils ont rendu très facile le développement, le test et le déploiement des applications de communications.
Avec Tropo un développeur peut utiliser le langage de programmation de son choix (Python, Java, etc.) et il dispose des APIs pour automatiser les taches les plus courantes (placer un appel, recevoir un appel, envoyer un SMS,…). Tropo fournit un environnement de test des applications et elle peut même héberger l’application – tout est fait pour faciliter la tâche des développeurs.
Pour que le Fog Computing se développe il faut faire pour Fog Computing ce que Tropo a fait pour Cloud Communications et il faut aller plus loin. Certains des challenges techniques sont décrits ci-dessous.
- La modélisation / abstraction des objets : il est important de normaliser les modèles des objets pour éviter la nécessité d’écrire la même application plusieurs fois.
- PaaS pour Fog / objets : il faut simplifier la communications avec les objets et les actions courantes. Il faut coordonner les accès aux objets entre les différentes applications qui souhaitent y accéder.
- Coordination entre le Fog et le Cloud : certaines applications doivent être distribuées entre le Cloud et le Fog – la partie « lourde » dans le Cloud et la partie « lite » (temps réel) dans le Fog.
Les instances comme l’Industriel Internet Consortium travaillent activement sur les réponses à ces chalenges (www.industrialinternetconsortium.org)
Cisco IOX est le socle de la solution Fog Computing de Cisco
Le socle de notre solution Fog est « IOx » qui virtualise nos éléments réseau pour permettre le partage du CPU, mémoire et stockage entre le logiciel de base des éléments réseau (IOS) et les applications. Le mode « VM » décrit ci-dessous est disponible dès aujourd’hui et le mode « Containeur LXC » est actuellement en beta test.
Deux exemples d’applications Fog développés sur des équipements Cisco sont ceux d’Itron et d’OSIsoft.
Itron (fabriquant de compteurs électriques intelligents). Itron a développé des applications Fog pour aider les producteurs d’électricité comme BC Hydro à assurer la lecture, la surveillance et le pilotage de millions de compteurs.
OSIsoft (créateur de solutions pour la surveillance des processus industriels). OSIsoft est un leader dans l’IdO Industrielle depuis 35 ans. Fog aide OSIsoft à rendre leurs solutions plus performantes et mois onéreuses.
Cisco IOT System répond aux besoins des développeurs
Afin de faciliter le développement des applications Fog (et des applications IdO de façon générale) Cisco a annoncé le 29 juin le « Cisco IoT System ». Le Cisco IoT System intègre des fonctions existantes (dont IOX) dans une architecture évolutive pour répond aux besoins des développeurs maintenant et dans le futur.
« Cisco IOx Middleware Services » complète IOx. Ce PaaS fournit un ensemble d’APIs et fonctionnes pour faciliter le développement des applications dans le Cloud et dans le Fog (avec la coordination entre les deux). On trouve également le « Cisco Fog Director » qui assure le déploiement et la gestion du cycle de vie des applications depuis un point central.
Pour les informations sur Cisco IoT System rdv au cisco.com/go/iotsystem
Je reviendrai sur le Fog Computing et Cisco IoT System dans mes billets futurs, mais mon prochain thème abordera un autre sujet d’actualité dans le monde IdO – les réseaux dits « Low Power, Wide Area » – LPWA.
