Decouverte de la plateforme IoT Amazon Web Services

Transcript

Bonjour à toutes et à tous, très heureux de vous retrouver pour une nouvelle série de webinaires live après quelques épisodes préenregistrés pour cause de summit et de déplacement. Nous sommes à nouveau en direct depuis nos nouveaux locaux à la Défense. Il ne fait pas beau aujourd'hui, vous avez bien fait de ne pas aller à la plage et d'écouter nos webinaires sur IoT. Ou peut-être que vous les écoutez depuis la plage. Si c'est le cas pour certains, faites-le nous savoir, on sera jaloux. Au programme aujourd'hui, donc, deux webinaires sur IoT. Un premier webinaire où j'aborderai les deux services IoT d'AWS, donc AWS IoT, le bien nommé, et puis un service plus récent, qui a été annoncé à reInvent l'année dernière et qui est globalement disponible depuis deux semaines environ, qui s'appelle Greengrass. On va couvrir ces deux services d'un point de vue théorique dans le premier webinaire. Et dans le deuxième webinaire, on enchaînera une série de démonstrations IoT avec différents devices, mais on en parlera tout à l'heure. Ok, donc commençons par AWS IoT. On va d'abord rappeler très rapidement ce qu'est l'Internet des objets. On va ensuite évoquer quelques projets lancés par nos clients sur AWS, des projets IoT bien sûr. Ensuite on s'intéressera à la plateforme AWS IoT, on parlera de device, on parlera de SDK, on parlera un petit peu du protocole de communication qui est utilisé entre les devices et le gateway qui s'appelle MQTT, et puis on verra ensuite comment on peut envoyer dans le cloud vers les différents services de stockage à AWS, comment on peut envoyer des données qui proviennent de devices. Ensuite on parlera de Greengrass et on répondra ensuite évidemment comme d'habitude à vos questions avant d'enchaîner sur un deuxième webinaire qui sera dédié aux démonstrations. Parlons rapidement de l'Internet des objets. Qu'est-ce que c'est que l'Internet des objets ? Qu'est-ce que c'est qu'un objet finalement ? Un objet, c'est un équipement matériel dont la principale caractéristique est d'avoir peu de ressources. Alors qu'est-ce que ça veut dire peu de ressources ? Ça veut dire qu'on parle de quelques dizaines ou quelques centaines de kilo octets de mémoire, on parle d'un processeur peu puissant, on parle de peu voire pas de stockage local, on parle de connectivité réseau à faible débit voire intermittente voire même impossible. Donc vraiment des équipements qui sont petits, qui sont peu puissants et qui ne peuvent pas évidemment exécuter des systèmes d'exploitation traditionnels. Le deuxième point important de l'IoT, c'est l'effet masse, le volume de devices qu'on va déployer. On va déployer au sein d'un même projet des milliers, peut-être même des millions d'équipements. Pensez à des compteurs électriques, pensez à des capteurs d'incendie, pensez à des choses comme ça. Vraiment, un des équipements qu'on va déployer en très grande quantité. Le point suivant aussi, c'est que ce sont des devices qu'on va placer à différents endroits, parfois difficilement accessibles, des équipements techniques, des compteurs, des capteurs sur des vannes d'eau, des équipements industriels. On va donc les déployer un peu partout et on souhaite qu'ils puissent fonctionner pendant longtemps, voire pendant même des années, sans aucune intervention humaine. Donc il s'agit que ces équipements soient évidemment fiables, autonomes en énergie, etc. Contrairement à un ordinateur ou un serveur qu'on passe son temps à manipuler. Et bien sûr, la finalité de ces équipements, ça va être de collecter et d'envoyer des données, en permanence. Certains capteurs remonteront peut-être une mesure par seconde pendant toute leur vie, d'autres peut-être environ 4 mesures par jour, mais l'idée c'est vraiment que ces équipements, une fois déployés selon la période déterminée, remontent des flux de données vers un point de collecte et un point d'analyse central. Ces données-là, traditionnellement, vont être des petites quantités de données. On ne va pas parler de gigaoctets, on va parler de quelques octets, quelques dizaines d'octets. À chaque fois, des petits messages, peu structurés, qui vont remonter. Une fois de plus, pensez à un capteur d'incendie ou un capteur de température, peut-être qui va remonter toutes les secondes, toutes les 5 secondes, toutes les 10 minutes. Une mesure de température, quelque chose de très granulaire mais qui peut avoir évidemment une importance vitale. Donc le modèle que nos clients déploient finalement et le modèle de nos services c'est celui-ci, c'est un modèle où on va avoir des millions ou des dizaines de millions d'équipements partout dans le monde qui vont communiquer entre eux et communiquer vers le cloud en remontant des milliards de messages. Donc on est vraiment à une échelle extrêmement importante. Et bien sûr le problème de tout ça, ça va être de trouver l'aiguille dans la botte de foin. Imaginez un capteur de température, un capteur d'incendie qui remonte une donnée presque bouléenne, une donnée très très simple. Cette donnée unitaire, elle a peut-être une importance limitée. Par contre, ce qui est intéressant, c'est soit de chercher à agréger l'ensemble de ces données, soit de chercher les anomalies. Alors ici, il y a une anomalie. Donc voilà, elle ne saute pas aux yeux. Il y a peut-être des milliers, des dizaines de milliers d'équipements qui remontent cette donnée. Comment est-ce qu'on trouve l'aiguille dans la botte de foin ? Donc il faut une bonne loupe. Et voilà. Et effectivement, là, on voit que sur ce capteur on a une anomalie. Peut-être c'est une détection d'incendie, peut-être c'est une panne qui est en train de se produire sur un équipement ou un indicateur avancé qu'une panne va se produire. Vous voyez bien que dans cette masse de données très granulaire, très fine, il va falloir avoir les outils qui vont nous permettre de trouver l'aiguille dans la botte de foin. Et comme souvent, lorsqu'on parle de données, lorsqu'on parle de back-end, on aimerait avoir ce magnifique couteau suisse qui permet de tout faire, qui permet de gérer des bases de données relationnelles, SQL, qui permet de faire du NoSQL, qui permet de faire de la recherche full-texte, qui permet de faire du machine learning, etc., qui permet de tout faire. Et malheureusement, ça n'existe pas. En termes de back-end comme en termes de couteau suisse, les solutions qui viseraient à essayer de tout faire, généralement, sont peu efficaces lorsqu'on en a vraiment besoin. Ce couteau suisse qui existe vraiment et qui est disponible sur Amazon, pour l'anecdote, il est amusant, c'est un très bel outil de collection mais c'est sûrement pas un très bon tournevis et c'est sûrement pas une très bonne scie et c'est sûrement pas une très bonne paire de ciseaux donc quand on a vraiment besoin de la bonne paire de ciseaux ou du bon tournevis, il vaut mieux avoir un outil qui est spécialisé pour ça et finalement pour le stockage et l'analyse de données on va avoir le même constat donc pour ce qui est de l'analyse des données, du stockage et de l'analyse des données IoT, on va pas chercher à construire un système qui essaie de tout faire, on va essayer de spécialiser en fonction des cas. On en reparlera tout à l'heure. Alors parlons maintenant de quelques projets IoT qui tournent sur AWS. Le premier projet dont je souhaitais vous parler, c'est un projet d'une société que vous connaissez qui s'appelle Philips. Et Philips a une division importante dans le monde de la santé, ils font beaucoup d'équipements médicaux. Et en particulier ici, ils ont construit une architecture de collecte de données à domicile, qui se base sur un gateway qui est déployé chez les patients ou chez les personnes âgées, donc à domicile. Et ce gateway va permettre à tout un tas d'équipements de remonter des données, qui peuvent être des données environnementales sur l'environnement du patient, ou qui peuvent être des données vraiment liées à la santé du patient. Ça peut être un capteur cardiaque, ça peut être un bouton d'alerte pour signaler un problème, etc. Et donc, ils ont bâti sur AWS IoT toute une solution autour du gateway, autour des capteurs, qui ensuite remonte les données collectées vers le cloud AWS, vers les différents services de stockage et d'analyse pour efficacement prise de décision et lorsque c'est nécessaire pour envoyer des alertes vers la famille de la personne ou vers les services médicaux quand c'est nécessaire. Donc voilà un exemple de projet intéressant, plus d'informations sur les URL que j'ai indiquées. Deuxième projet très différent, c'est une société qui s'appelle John Deere. John Deere c'est un des leaders mondiaux des équipements agricoles, peut-être un peu moins connus en France, mais très très célèbres aux Etats-Unis. Et donc John Deere fabrique des tracteurs, des semeuses, etc. Vous allez me dire, qu'est-ce que vient faire l'IoT là-dedans ? Eh bien, ils ont équipé, en particulier leurs équipements, leurs semeuses, de plusieurs dizaines de capteurs IoT qui en permanence mesurent l'état du sol, l'humidité, etc. Ils vont remonter ces informations au cloud pour analyse. On va pouvoir tracer des cartes, on va pouvoir déterminer tout un tas d'informations très précises, très géolocalisées sur l'état des sols. Et lors des phases de semis, on va pouvoir optimiser les opérations, on va pouvoir optimiser l'espacement des semis, on va pouvoir utiliser optimiser la profondeur des semis en fonction de l'état du sol. C'est très technique, je cache pas que je suis pas un spécialiste du domaine, je vous invite à voir le témoignage de John Deere qui est en ligne qui explique à reInvent comment ils ont bâti cette plateforme. Ce qui est vraiment intéressant au-delà de l'optimisation du process agricole qui est important pour les agriculteurs et les consommateurs, c'est aussi l'émergence d'un nouveau business model pour John Deere qui passe d'un modèle finalement d'équipementier à un modèle de fournisseur de services puisque cette plateforme, c'est une plateforme SaaS à laquelle les agriculteurs s'abonnent pour recevoir les informations et optimiser leurs semis. Donc c'est vraiment à la fois un projet d'amélioration d'un process, mais c'est aussi un nouveau business pour John Deere qui passe du monde de l'industrie finalement au monde du service. Intéressant pour eux. Dernier projet dont j'avais envie de parler, alors on reste dans les véhicules à 4 roues mais un petit peu différents. Là il s'agit de la série 7 de BMW. Elle aussi est équipée d'un certain nombre de capteurs qui vont permettre de mettre à jour les cartes routières dynamiquement. L'ensemble de la flotte de série 7 collecte des informations sur la route, l'état du trafic, etc. On remonte tout ça au cloud pour analyse et permet à BMW ensuite de republier les cartes mises à jour. Ce qui est intéressant c'est la vitesse à laquelle ce service a été déployé. Il a été bâti en 6 mois à peine. Et une fois de plus je vous renvoie un témoignage de BMW sur notre site pour en savoir plus. Et puis un petit dernier pour la route. Alors encore un petit véhicule mais différent cette fois encore. C'est ce fameux aspirateur Roomba que vous connaissez sûrement, qui existe depuis plusieurs années. Mais dans sa dernière version, le Roomba est capable de cartographier votre appartement, votre maison. Et il est capable de découvrir et d'interagir avec des devices. Donc vous pourrez imaginer que si le Roomba rentre dans une pièce et se rend compte que la lumière est allumée, alors que manifestement personne n'est là, il pourrait éteindre la lumière, au contraire il pourrait décider d'allumer la lumière lorsqu'il sait que vous allez rentrer à la maison, etc. Donc un projet assez intéressant, au-delà de l'aspect cartographie pure, on a aussi la capacité à progressivement intégrer des devices supplémentaires et à construire des projets de domotique qui peuvent être assez intéressants. Alors il y en a plein d'autres, je ne voulais pas en citer trop, mais on a aussi Thermomix dans le monde de la cuisine, on a nos amis de Soitech à Grenoble qu'on salue, qui ont construit un équipement IoT intégré sur leur chaîne de production pour remplacer un équipement extrêmement coûteux et complexes d'un de leurs fournisseurs. Puis on a d'autres projets industriels chez SPS ou Siemens, Veolia en France dans le monde de l'eau. Et puis bien sûr Amazon Retail avec les fameux Dash Button que vous pouvez désormais acheter pour commander en un clic les produits du quotidien. Et on reparlera d'IoT Button tout à l'heure. Donc voilà, vous voyez des applications très différentes dans des mondes très différents, que ce soit du retail, que ce soit de l'industrie, que ce soit le monde de l'énergie, vraiment on voit une très belle adoption de l'IoT chez nos clients et avec de vrais projets. Alors parlons de la plateforme IoT. Donc la plateforme IoT, c'est avant tout la capacité à connecter des équipements vers une passerelle. Donc on va avoir un ensemble de SDK que vous allez installer sur vos équipements et qui vont donc permettre à ces équipements de dialoguer, d'envoyer et de recevoir des messages vers une passerelle qui est hébergée dans le cloud AWS. Évidemment la sécurité est toujours notre première priorité, que ce soit dans le cloud ou dans l'IoT, et tous ces devices devront posséder une identité, devront posséder un certificat, devront posséder une politique IAM, etc. pour pouvoir communiquer en toute sécurité. Donc toutes les communications sont authentifiées et chiffrées, que ce soit dans un sens ou dans l'autre. Donc ça, c'est vraiment la partie communication et ça va permettre aux devices de communiquer entre eux. Mais comme on l'a dit tout à l'heure, le point qui sans doute va nous intéresser le plus, c'est la capacité à remonter des données vers le cloud d'AWS. Donc pour ça, on va utiliser un moteur de règles qui va en permanence analyser les messages qui arrivent sur le gateway et en fonction de règles que vous allez définir, on verra tout à l'heure comment, vous pourrez envoyer les messages vers l'un de nos services, ça pourrait être S3, ça pourrait être Lambda, on verra tout à l'heure, ou vers une API tierce. Une dernière fonctionnalité qui est intéressante, c'est le Device Shadow. Le Device Shadow, c'est une image dans le cloud de votre device qui va permettre à des applications d'interagir avec votre device même s'il est éteint ou même s'il ne dispose pas de connectivité réseau. Donc ça, c'est un des grands problèmes de l'IoT, c'est qu'on peut avoir une connectivité intermittente pour tout un tas de raisons, mais d'un point de vue applicatif, c'est quelque chose qui est délicat à gérer. Donc une application ici n'aura pas à se poser de questions, elle interagira avec le device shadow et si le device est connecté, il lira l'état de ce shadow et il l'appliquera. S'il n'est pas connecté, lors de la reconnexion suivante, il pourra lire l'état du shadow et il décidera ou pas, en fonction de règles que vous définirez, d'appliquer l'état. Donc ça permet vraiment de séparer, de découpler les applications web, mobile, etc. a priori toujours connectées du monde de l'IoT qui lui pour plein de raisons peut être déconnecté. Et bien sûr comme d'habitude avec AWS tout ça est pilotable et configurable avec des API. Le prix d'AWS IoT est plutôt simple donc on facture par millions de messages donc on compte les messages entrants et les messages sortants un message c'est au maximum 512 octets et donc en fonction des régions on va de 5 à 8 dollars par million de messages. Notez bien que vous pouvez utiliser le free tier donc le niveau d'usage gratuit sur AWS IoT vous avez 250 000 messages gratuits par mois pendant 12 mois donc ça permet largement de tester c'est un service qui est quand même globalement assez économique. Alors rentrons un petit peu dans les détails maintenant. Les devices, nous en proposons toute une liste dont vous trouverez sur le site d'Amazon la liste des starter kits officiels validés avec nos partenaires hardware qui donc équipements qui marcheront directement et ce sans difficulté avec AWS IoT. Bien sûr, cette liste n'est pas restrictive. On dispose d'un ensemble de SDK que vous pourrez installer sur d'autres équipements. On a par exemple un SDK pour Arduino UNO, qui est une petite plateforme matérielle que j'utiliserai dans une démo tout à l'heure. Et puis ensuite, on a des SDK strictement logiciels comme JavaScript, C, Android, iOS et depuis un an maintenant on a rajouté Java et Python donc à partir du moment où vous avez un device qui est capable d'exécuter un de ces environnements là, si vous avez un petit Linux embarqué vous pouvez faire du Node.js ou du Python et bien ça suffit, vous pourrez vous connecter à IoT. Et pour les équipements un peu plus contraint à ce moment là le SDK en C est suffisant. On a vu tout à l'heure, il est important que les devices aient une identité et soient connus du Gateway. On a cette registry qui va contenir de manière déclarative l'ensemble des things, l'ensemble des objets qui ont le droit de communiquer avec le Gateway. Il faudra créer un certificat et c'est une étape obligatoire pour chaque objet afin de lui donner une identité. Il faudra lui créer une paire de clés qui permettront de sécuriser les communications. Et puis il faudra créer une politique IAM qui autorisera l'objet à se connecter au Gateway, à publier ou recevoir des documents, des messages dans tel ou tel fil de messages et le cas échéant à accéder à d'autres services. On retrouve finalement les concepts habituels d'AWS dans IoT. Pas de compromis sur la sécurité. Une fois que ces devices sont connectés, ils vont pouvoir dialoguer avec le Gateway et on va utiliser un protocole qui s'appelle MQTT. De fait, on va supporter trois modes de communication : MQTT sur HTTPS, MQTT sur WebSocket ou HTTPS nativement mais uniquement en mode publication, c'est-à-dire uniquement en envoi de messages vers le gateway. MQTT c'est un protocole industriel qui existe depuis longtemps maintenant, qui est standard et donc qui a été implémenté par AWS. L'avantage de ce protocole c'est qu'il est extrêmement léger par rapport à notamment HTTPS en termes de débit, en termes de consommation d'énergie, en termes d'utilisation de la bande passante, il est beaucoup plus efficace que HTTPS et donc par conséquent il est bien adapté pour des petits équipements peu puissants sur lesquels on a envie de préserver la batterie et sur lesquels on a envie également de préserver la bande passante qui peut être coûteuse. Bref, on a envie de faire attention à ça. Donc MQTT est un bon choix pour ces environnements. Le mode de fonctionnement de MQTT, c'est du publish-subscribe sur des files de messages qu'on va appeler des topics. Alors voici quelques exemples. On pourrait imaginer qu'un device envoie une alerte au gateway à destination d'un autre device. Imaginez par exemple un capteur de température qui envoie une alerte à une alarme, par exemple. On pourrait avoir un message qui part d'un device jusqu'au gateway pour atteindre une application, donc une publication d'informations vers une appli mobile qui pourrait être directement connectée sur le gateway. Ce scénario également paraît assez intéressant où on aurait l'agrégation de messages venant de différents devices, données qu'on publierait ensuite par exemple dans DynamoDB pour que des applications mobiles ou web consultent des informations, fassent des statistiques, etc. On pourrait aussi imaginer de faire l'opération dans l'autre sens. On pourrait par exemple configurer un device. Donc on pourrait avoir une application de configuration qui publie un message destiné à un device afin de, pourquoi pas, lire son statut ou changer un paramètre de configuration. On peut évidemment communiquer dans les deux sens. En termes de fiabilité, il y a deux modes de fonctionnement dans MQTT : un qui s'appelle QoS0, donc Quality of Service 0, où on va garantir finalement peu de choses. Si un message est perdu, eh bien il est perdu. Donc un message est délivré 0 ou 1 fois, il n'y a pas de retransmission. C'est un paramètre que vous pourrez positionner lorsque vous établissez la communication. On a un deuxième mode QoS1, où là on va gérer les transactions, gérer les erreurs donc on va acquitter chaque message et évidemment lorsqu'un message est publié et perdu, aucun acquittement ne sera reçu par l'émetteur et il réémettra ensuite son message donc là on a une fiabilité. Gardez bien à l'esprit qu'on double le nombre de messages donc en termes de facturation et bien ça fait deux fois plus de messages échangés mais c'est le prix de la fiabilité. Il y a un troisième mode qui est défini dans le standard MQTT qui s'appelle QoS2, qui est Exactly Once, où là où on garantit qu'un message n'est jamais, il n'est reçu une fois et une seule, donc pas plus d'une fois et pas moins d'une fois. Néanmoins, à cette heure, il n'est pas supporté par la plateforme AWS IoT. Donc vous avez le choix entre pas de fiabilité ou une fiabilité avec, dans certains cas, peut-être la possibilité que le message soit reçu plusieurs fois. Alors voyons maintenant comment dépasser finalement la frontière du gateway pour envoyer les données dans le cloud. Je l'ai mentionné tout à l'heure, pour faire ça on va définir des règles qui vont être paramétrées dans un moteur de règles. Le principe est assez simple, les messages arrivent sur le gateway, ils sont analysés par le moteur de règles en fonction des règles que vous avez définies et ces règles si elles sont effectivement validées, si la règle effectivement match un ou plusieurs messages que vous avez envoyé au gateway, la règle va enchaîner sur une action. Cette action ça va être d'envoyer le message à l'un des back-ends. Donc on a une intégration directe avec différents back-ends que vous voyez ici : S3, Dynamo, etc. Et Amazon Machine Learning, ce qui permet par exemple d'appeler Amazon Machine Learning à partir du moteur de règle pour faire une prédiction. C'est un sujet assez intéressant. Et puis dans le cas d'autres back-ends, comme RDS Glacier, là, on a une intégration indirecte où il faut passer par Lambda ou par S3 avant d'atteindre ces services. Et évidemment, comme on peut atteindre Lambda et SNS de manière directe, finalement, tout ce que vous pouvez brancher derrière Lambda ou SNS peut devenir une cible pour les messages. Donc, vous pourriez utiliser une fonction lambda pour appeler une API tierce ou utiliser SNS pour publier une notification dans une file de messages qui va ensuite être lue par une instance EC2, etc. Après, on retombe dans le modèle classique d'AWS. Ce qui est appréciable avec ce moteur de règles, c'est que les règles, vous allez les écrire en SQL standard. En fait, une règle, c'est faire un select sur un topic MQTT. On verra des exemples tout à l'heure. Vous allez utiliser la syntaxe SQL pour chercher finalement du contenu à l'intérieur des messages présents dans un topic. Et un peu comme dans une base de données où effectivement quand le select correspond à des lignes de la table, la base de données vous retourne une liste de lignes. Ici, c'est pareil, vous allez pouvoir récupérer un message par une sous-partie d'un message qui correspond à la règle SQL que vous aurez définie. Il y a du SQL et puis il y a pas mal de fonctions complémentaires autour de ça pour faire des opérations un peu plus compliquées, des opérations mathématiques, des choses comme ça, mais en tout cas ça reste du SQL standard. Et donc concrètement, on en verra un exemple dans le deuxième webinaire avec les démos. On peut imaginer un cas où effectivement on appuie sur un bouton, donc un bouton IoT qui a été connecté au gateway au travers d'un SDK, d'une clé, d'un certificat, etc. Le message va être envoyé au gateway IoT. Et puis on va avoir une règle. Une règle ici qui est une règle toute simple. Vous voyez, on fait « Select étoile from IoT button slash ». Donc, en gros, on va sélectionner tous les messages qui arrivent sur le topic du bouton. Ici, on ne filtre rien, mais on pourrait tout à fait dire qu'on veut les messages qui contiennent un champ précis ou une valeur précise. Et c'est, une fois de plus, en SQL standard. Donc, tous les messages qui vont matcher cette règle, ici tous les messages, vont être passés à une fonction lambda qui ensuite peut faire ce qu'elle a envie de faire avec, elle peut les écrire dans Dynamo, dans S3, les publier dans SNS, etc. C'est vraiment une façon hyper simple de connecter deux mondes qui sont très différents, le monde de l'IoT qui est un monde plutôt embarqué, assez spécifique, et puis finalement, le monde de l'IT traditionnel où on récupère des données, on les écrit dans un back-end et puis ensuite, on les traite, on les manipule et on n'est plus dans le monde de l'IoT, on est dans le monde de la data, on est dans le monde de l'IT traditionnel. Et tout ça grâce au moteur de règles. Donc voilà un panorama un petit peu large d'IoT. Je vous propose maintenant de passer sur Greengrass. Je bascule. Voilà, c'est reparti. Donc on a vu avec IoT finalement qu'il est assez aisé de connecter ses petits équipements au cloud. Et bon, je ne vais pas raconter, mais pour avoir travaillé pendant des années dans le monde de l'embarqué, jamais j'aurais rêvé de pouvoir aussi facilement prendre des petits équipements, des petits devices, j'ai un bouton IoT ici, je ne sais pas si on le voit à l'écran, on en verra d'autres tout à l'heure, et bien de prendre des petits équipements comme ça, et en quelques lignes de code, en quelques appels d'API, d'être capable de remonter leurs données vers un back-end et de faire du machine learning, etc. Donc super, j'espère que ça vous plaît. Néanmoins, il reste quand même un certain nombre de sujets à traiter et c'est l'objectif de Greengrass. Le fait est que la plus grande partie des données générées par des équipements n'atteint jamais le cloud et pour une raison qui est toute simple, c'est qu'il y a tout un tas d'équipements qui ne sont pas connectés au cloud. Des équipements qui pour des raisons techniques, des raisons de sécurité ou des raisons de coût ne sont pas connectés. Et pourtant ils collectent de la data qui peut être analysée localement mais qui ne remonte pas facilement au cloud. Il peut y avoir aussi des équipements qui sont dans des environnements extrêmement hostiles, ou en tout cas extrêmement isolés. Pensez à une mine en plein désert, ou effectivement à des cas extraterrestres au sens premier du terme. Pensez à un robot martien, ou un robot lunaire, ou ce genre d'environnement. Si on envoie des robots dans l'espace, c'est évidemment pour collecter de la donnée. Maintenant, ramener la donnée sur Terre, c'est compliqué. Ce n'est pas impossible, mais c'est compliqué, c'est long et c'est surtout extrêmement coûteux. Et donc, la plateforme AWS IoT telle qu'on l'a présentée tout à l'heure, on ne répond pas à ces sujets-là. La plateforme IoT, elle fonctionne, elle permet aux équipements de collecter de la donnée et de la remonter lorsqu'ils sont connectés. Mais si jamais ils ne sont pas connectés, ils ne pourront pas publier ou recevoir de messages. Ça échouera jusqu'à ce que la connexion revienne. Et c'est vraiment ce sujet-là que Greengrass essaie de résoudre. Et ce problème va rester. Il ne s'agit pas de se dire « oui, non mais ok, c'est un problème temporaire et puis dans quelques années, ce problème sera réglé ». Il y a un problème, effectivement, il y a les lois de la physique qui font que si vous avez déployé des équipements en Antarctique ou en plein milieu du Sahara, ça sera toujours loin et ça sera toujours compliqué d'atteindre le data center le plus proche ou la région AWS la plus proche. Donc il y aura toujours une distance, il y aura toujours la vitesse de la lumière et ça sera toujours problématique d'amener en temps réel ou de manière fiable des données vers un data center. Et puis même si c'est possible, il y a une raison de coût, il y a un facteur coût aussi, c'est que peut-être vous êtes en Antarctique ou au milieu du Sahara et vous avez un lien satellite, ce lien satellite, il vous coûte cher, et vous n'avez pas envie forcément de l'utiliser pour remonter de la donnée brute en permanence. Peut-être que vous avez envie de l'utiliser de manière économique, de manière intermittente, en ne remontant que des données agrégées. Et puis il peut y avoir une raison de privacy évidemment qui est de se dire la donnée brute elle ne doit pas quitter le territoire, le pays où elle a été générée donc il n'est pas question qu'elle soit remontée à un data center ou à une région distante. Donc on veut travailler localement et on veut ne remonter que des données agrégées par exemple. Et c'est vraiment ça une fois de plus que Greengrass essaie de faire. On a parlé d'IoT tout à l'heure, il y a vraiment trois parties dans l'IoT, il y a la partie device, le capteur, il y a la partie cloud, donc remonter des données vers le cloud, les stocker, les calculer, et puis ensuite il y a la partie analyse et utilisation, exploitation de cette donnée. Donc on a parlé il y a quelques instants de la partie IoT qui reste tout à fait valable, on a toujours ce gateway, on a toujours cette plateforme hébergée dans les différentes régions AWS. Mais on a envie maintenant, finalement, de pouvoir mener des projets IoT, j'ai envie de dire presque indépendamment du cloud, en étant à la frontière du cloud et en ayant la capacité, finalement, même sans connexion réseau ou avec une connexion extrêmement intermittente, on a envie de pouvoir traiter des données, de pouvoir les stocker, de pouvoir les agréger et ça c'est Greengrass. Greengrass c'est finalement amené à la frontière de l'edge, vraiment là où les devices sont déployés, amener la capacité à stocker et à traiter des données localement, permettre aux devices de communiquer entre eux localement, sans avoir à passer par un cloud qui peut être à des milliers de kilomètres de là et qui peut être une fois de plus indisponible parce que votre bande passante est limitée ou en panne ou quelles qu'en soient les raisons. Donc Greengrass, c'est vraiment étendre la capacité de vos équipements, ne plus les concevoir juste comme des capteurs un peu passifs qui ensuite communiquent vers un cloud pour stocker de la donnée. C'est vraiment la capacité à communiquer localement, stocker de la donnée localement, traiter de la donnée localement. C'est un service qui a été annoncé à reInvent l'année dernière et qui est disponible dans les quatre régions indiquées ici depuis une dizaine de jours maintenant. Donc c'est très frais. Donc les objectifs de Greengrass, c'est permettre au device de réagir localement aux données. Si un capteur capte une donnée, c'est évidemment un peu dommage de dire, bon, on va l'envoyer au cloud et puis on va l'envoyer dans un backend et puis il y a un modèle qui va tourner et puis on va décider s'il y a une alerte ou pas et puis s'il y a une alerte on va renvoyer un message etc. Là on veut que les devices finalement soient autonomes et puissent traiter localement leurs données et y répondre plus rapidement sur le terrain. Le deuxième point c'est qu'ils doivent être capables d'opérer en étant déconnectés pour les raisons que j'ai indiqué tout à l'heure. Si vous n'avez pas de connectivité réseau, ok, vos devices ils peuvent communiquer entre eux, ils peuvent travailler, ils peuvent agir et stocker la donnée qu'ils collectent. Le troisième point c'est de simplifier la programmation des équipements. Ces fonctions permettent de diagnostiquer et de corriger automatiquement les problèmes de configuration Wi-Fi, réduisant ainsi les appels au support et améliorant l'expérience utilisateur. Le cœur de Greengrass est le Greengrass Core, un logiciel installé sur un équipement suffisamment puissant pour servir de passerelle locale. Il gère la communication, les Device Shadows, la sécurité, et l'exécution des fonctions Lambda. Le Core se synchronise avec le cloud lorsque la connectivité est disponible. Il nécessite des ressources modestes, fonctionnant sur un Raspberry Pi ou un équipement similaire. Les dispositifs interagissent avec le Core via le SDK IoT sur le réseau local. Ce SDK, actuellement disponible en C++, permet aux dispositifs de communiquer entre eux et d'accéder aux fonctionnalités de Greengrass, comme l'exécution Lambda et la communication locale. Les dispositifs peuvent être petits ou grands, comme une éolienne, et le SDK a un faible poids, simplifiant l'accès aux fonctionnalités de Greengrass. Dans un groupe Greengrass, un Core et plusieurs dispositifs utilisant le SDK Greengrass s'échangent des messages et communiquent entre eux. Le Core se synchronise avec AWS IoT pour mettre à jour les dispositifs et les Device Shadows lorsque la connectivité est présente. Les fonctionnalités de Greengrass incluent la communication locale via un broker local, des Device Shadows locaux, et l'exécution de fonctions Lambda localement. Actuellement, seules les fonctions Lambda en Python 2.7 sont supportées, mais elles permettent aux dispositifs de fonctionner de manière isolée, de traiter les données localement, et de réduire la bande passante nécessaire. La sécurité est primordiale, avec une authentification mutuelle locale et vers le cloud. Le pricing inclut un niveau gratuit pour jusqu'à 3 dispositifs, des tarifs mensuels pour jusqu'à 10 000 dispositifs, et des options flexibles au-delà. Des ressources supplémentaires, comme des white papers et des articles de blog, sont disponibles pour approfondir les sujets d'IoT et de Greengrass. Le free tier d'AWS IoT offre 250 000 messages par mois et 3 dispositifs gratuits sur Greengrass, idéal pour prototyper et tester. Voilà, j'en ai terminé pour cette présentation d'AWS IoT et de Greengrass. Nous garderons les questions pour le deuxième webinar, où nous aurons plus de temps.