Quel est le quotidien de nos consultants en mission ? Quels sont les challenges techniques qu’ils doivent relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers le témoignage de nos consultants.

C’est très jeune que Nicolas s’est mis à faire travailler les machines à sa place. S’il a commencé à coder en C/C++, il est rapidement tombé dans Java. Linuxien convaincu, il a pendant longtemps écrit son code avec Vim avant de se résigner à utiliser Eclipse. Nicolas s’est ensuite intéressé au Cloud AWS, et il a notamment animé un atelier AWS Serverless lors de la ServerlessConf. Nicolas nous présente aujourd’hui son expérience d’accompagnement à la mise en place d’une architecture Cloud pour un projet IoT, qui a fait appel aux services IoT Core, AWS Lambda, DynamoDB, S3, Cognito, etc.

Peux-tu présenter le projet sur lequel tu travailles ?

Il s’agit mettre en place l’architecture Cloud pour un projet IoT. L’idée est d’apporter plus d’intelligence dans les boîtiers, et d’exploiter la puissance du Cloud pour apporter plus de valeur ajoutée en fournissant des services de monitoring et de pilotage à distance. Comme c’est souvent le cas avec l’IoT, l’objectif est de pouvoir remonter plus de données.

Quel est l’apport du Cloud sur ce projet ?

Nous sommes dans un département recherche & développement, donc il y a pas mal d’expérimentation et d’exploration, mais le choix du Cloud permet de répondre au besoin stratégique de proposer du software et de l’intelligence dans les boîtiers. Aujourd’hui le hardware n’est plus différenciant, il n’offre plus d’avantage concurrentiel, et le Cloud est un bon terrain pour innover.

Dans le détail, sur quoi travailles-tu ?

Je travaille uniquement sur l’infrastructure cloud, pas sur le logiciel embarqué. L’infrastructure IoT pour la réception et l’envoi de messages fait appel aux services AWS suivants : IoT core, Dynamo DB, S3, ECS, SNS, Cognito, API Gateway, Lambda. Toute l’infrastructure est serverless, en particulier les messages, seules quelques tâches plus longues sont sur EC2. Pour résumer, j’ai travaillé sur la stack AWS, sur l’API (en Python), et sur l’étude des coûts et des charges. L’optimisation des coûts se fait durant la phase d’architecture, mais aussi durant le run. Le monitoring de l’activité permet d’ajuster au mieux la solution. Si les coûts montent anormalement, il faut pouvoir le détecter et réagir rapidement.

Pourquoi avoir choisi une architecture Serverless ?

Nous avons recommandé une approche serverless parce que c’était la plus adaptée au contexte du client. D’un usage à l’autre, la charge est très variable: certains projets consomment beaucoup de messages,et il était donc important que la partie IoT soit complètement scalable. Pour la gestion des messages, nous devions aussi répondre au besoin de paiement à l’usage, donc le choix de serveurs classiques a été exclu, la souplesse offerte par le serverless permettait de répondre à cette demande. Nous avons estimé la charge, les types de messages concernés, et nous avons choisi l’architecture en conséquence

Quelle expérience avais-tu sur le Serverless ?

Je n’avais jamais travaillé sur ce sujet dans le cadre d’un projet client. J’ai trouvé qu’il était assez rapide de débuter sur le sujet, surtout dans l’environnement D2SI où nous somme encouragés à utiliser de nombreux outils d’automatisation (Terraform, et Chalice par exemple). Pour peu que l’on soit un peu curieux et que l’on acquière rapidement les process pour aller vite, il est assez simple de se lancer sur le Serverless. Le fait d’être chez D2SI aide beaucoup.

Qu’est-ce que ça a changé dans ta façon de travailler ?

A la base, je suis développeur, pas ops. Je n’avais donc pas la culture du contrôle et de la surveillance. Le serverless donne l’illusion que tout fonctionne tout seul, surtout quand on est développeur. On écrit une lambda, elle s’exécute, tout fonctionne bien. Mais parfois, ça ne marche pas, et si on n’a pas d’outil de monitoring, on ne voit pas les lambdas en erreur, on ne voit pas qu’on manque 50% des messages. Aujourd’hui je travaille différemment, gérer l’infrastructure implique de faire plus d’ops, et par conséquent, plus de monitoring, pour le bien de l’application.

Peux-tu détailler le schéma de données qui a été mis en place ?

En sortie, nous avons une API qui lit des données dans DynamoDB, puis les expose via une API Rest (Api Gateway). En entrée, un message arrive sur le broker IoT, et celui-ci est routé par une règle IoT dans la base DynamoDB, via une lambda qui vérifie le contenu. Ensuite on passe à la partie affichage, via l’API REST. L’API permet également de publier des messages sur le broker IoT pour les devices (AWS IOT fonctionne par topics, un peu comme sur un forum où on peut s’abonner pour recevoir des messages). Il y a évidemment une partie de gestion des droits, que nous traitons avec Cognito et IAM.

Qu’est-ce qui te plaît dans ce projet ?

Nous disposons d’une grande liberté dans nos choix techniques : le client nous donne des objectifs, à nous de trouver les solutions cloud pour y parvenir. En fonction des besoins, nous établissons nos choix d’infrastructure et de traitement des données. J’ai apprécié aussi de travailler sur des sujets comme le Serverless et l’IoT. En tant que développeur, j’aime faire du code. Mais quand on code en Java comme je l’ai longtemps fait, cela suppose de monter une JVM, un serveur Tomcat, etc. Cela peut devenir vite pénible, surtout quand on doit gérer les mises à jour, les versions de Java, les conflits entre les packages… Avec Lambda, il suffit de coder et AWS gère le reste, c’est un vrai confort de se concentrer sur son objectif et sur son code. Quant à l’IoT, c’est un sujet très intéressant, parce que l’IoT sera de plus en plus présent partout, et il faudra construire les infrastructures pour le supporter. L’IoT, c’est le futur !