Microsoft Tech Days 2015 – Jour 2
Moins d’annonces d’évolutions .NET, une journée plus orientée architecture.
Sécurité, cloud, et données privées
Cette présentation est en deux parties: les questions générales, puis le positionnement Azure
Axes d’analyse des risques
Commençons par une classification des différents types de Cloud, basée sur là où s’arrête la responsabilité du fournisseur:
- IaaS: Le client achète des VMs (exemple typique: Digital Ocean) et est responsable du déploiement de tous les composants logiciels et applications
- PaaS: Le fournisseur met à disposition la couche middleware (ex: serveurs Apache), l’utilisateur n’a plus qu’à déployer ses applications (exemple typique: Cloudbees). L’utilisateur a moins de responsabilités qu’avec une IaaS, mais dans certains cas cette facilité peut devenir un inconvénient (migrations forcées).
- SaaS: Le fournisseur prend en charge toute la stack, du matériel aux applications. L’utilisateur est un simple consommateur (exemple typique: Salesforce).
Les principaux risques du passage au Cloud sont:
- sécurité
- protection des données
- conformité légale/réglementaire (compliance)
Les risques encourus par les données sont évidemment différents selon qu’elles soient publiques, internes, ou confidentielles.
Le positionnement Azure
MS se positionne comme vendeur de tous les types de cloud: public, privé, hybride. Comment entendent-ils se différencier? Leur argumentaire est fondé sur les éléments suivants:
Conformité aux standards
Et en particulier ISO 27018. J’avoue ne pas être à même de juger de la pertinence de cet argument. Certains standards ne prouvent pas grand-chose sur la qualité du service fourni par les entreprises (par exemple ISO 9001 est souvent un argument commercial alors qu’il concerne la gestion interne de l’entrprise).
D’un autre côté Azure est de toute façon de bonne facture technique. Mais on peut quand même avoir des surprises, par example le SqlServer Azure a des limitations qui font échouer des scripts d’import fonctionnant sur SqlServer natif. Dans l’ensemble Azure est une offre très compétente techniquement, pas d’inquiètude à ce sujet. Attention quand même à bien comprendre les implications du SLA (calculer l’indisponibiité consécutive maximale admise, et imaginer qu’elle se produise pendant la période d’activité maximale – Noël par exemple pour du e-commerce), car à moins d’être un VIP, le SLA peut être à double tranchant.
Transparence
On peut par exemple savoir précisément où sont hébergées nos données. D’autre part MS s’affiche comme simple sous-traitant des traitements, et promet par exemple à ce titre de ne pas utiliser les données à ses fins propres.
Enfin, l’intervenant aborde spontanément LA question à laquelle tout le monde pense: quid du fait que le gouvernement américain prétend désormais accéder aux données hébergées par des entreprises US, même si elles sont stockées en Europe, sans avoir à passer par les voies normales de la coopération internationale?
MS a récemment refusé de transmettre les données demandées par un juge de New York, et plus généralement les entreprises américaines s’inquiètent de la perte de confiance provoquée par ces exigences. La procédure judiciaire est encore en cours (mon pifomètre: MS va gagner).
Par contre, la louable résistance de MS concerne une demande provenant du circuit judiciaire normal (et donc publique..). Qu’en est-il des demandes provenant des procédures d’exception, qui elles restent secrètes? (FISA court, national security letters, révélations Snowden).
Sur ce sujet, autant l’entreprise française lambda peut à mon avis utiliser Azure sans paranoïa, autant il n’est (par exemple) pas envisageable qu’une entreprise du secteur de la défense en fasse de même. Une entreprise en compétition avec une entreprise US ne devrait-elle pas se méfier? Ou se situe la frontière?
Makers + IOT : une nouvelle révolution industrielle?
Le logiciel s’insinue partout aussi irrésistiblement que l’eau. D’un autre côté, les programmeurs fabriquent de plus en plus d’objets physiques. Ce double mouvement va-t-il conduire à des changements profonds, et dans quel sens?
Le mouvement des Makers
Le premier orateur est l’organisateur de Makers Faire France. Maker Faire Paris 2015 se tiendra les 2 & 3 mai lors de la 111e édition de Foire de Paris
Le terme “makers” désigne la fabrication à petite échelle, par des individus ou des petits groupes. Si ce mouvement est en train d’exploser, c’est grâce à la démocratisation de quelques technologies clef depuis quelques années:
Les technologies clefs
L’impression 3D
Elle permet de produire des objets en plastique sans avoir besoin d’un moule, qui est très coûteux. Cela rend possible la fabrication de faibles volumes, impossible à amortir sinon.
Les cartes de prototypage
Les Arduino et RaspberryPi sont bien connues des programmeurs. Leur petit prix et leur faible encombrement permet de les embarquer dans des objets physiques de petite taille.
La combinaison des deux
Parmis ces utilisations on peut citer la domotique et la robotique. Un des meilleurs examples est le Français Gaël Langevin et son robot InMoov, fabriqué par impression 3D et contrôlé par un simple Arduino.
Nicolas Huchet, amputé d’un bras, a désormais un bras bionique low-cost fabriqué avec cette technologie:
Les lieux
Traditionnellement, les Fab labs sont des lieux communautaires mis à disposition gratuitement (mais forcément avec les contraintes de partage associées). Ils peuvent être d’associations, d’universités, d’entreprises, ..
Un autre type de lieux, payant celui-là, existe désormais: les Tech shops, dont parle le deuxième intervenant (Usine IO). Il peut s’avérer par exemple plus adéquat pour une entreprise ne souhaitant pas partager son travail.
Les places de marché
A part les salons, les places de marché sont surtout sur internet. Evidemment les makers qui n’ont pas les moyens d’investir dans un moule de production plastique peuvent encore moins avoir une boutique physique. Quelques exemple montrent que ce marché existe également:
En Europe, le mouvement était plutôt originaire d’Italie, mais il va probablemnt exploser cette année, j’irai probablement à la pêche aux idées porte de Versailles.
Analyser sa maison à l’aide de Apache Storm: Big data en temps réel
Certains domaines métier nécessitent une analyse big data en temps réel:
- gestion des stocks
- détection de fraudes
- gestion des bouchons
- ..
Les technologies mises en oeuvres sont proches quelque soit le domaine, cette présentation prend un exemple volontairement simpliste de suivi d’indicateurs domotiques pour les illustrer.
Cette présentation a battu le record du nombre de technologies au mètre carré, je ne peux donc pas tout détailler, mais je vais essayer de reprendre les idées les plus intéressantes.
Matériel
Le capteur de température/hygrométrie est un Enocean, car cette marque a l’avantage d’être sans fil, sans pile, et d’être bien documentée. Il envoie à intervalle régulier ces informations à un Raspberry Pi local. Chaque maison est donc équipée d’un capteur Enocean et d’un Raspberry. Le raspberry héberge une application Node.js qui transmer les données des capteurs vers les traitements.
Architecture initiale
Dans le prototype initial, l’application Node.js envoyait les données vers un serveur central, qui réalisait les traitements et exposait une application web pour consulter les résultats. Mais cette architecture:
- N’est pas scalable
- Ne protège pas contre la perte d’informations (ne serait-ce qu’en cas de reboot du serveur).
Queue de messages
Dans l’architecture présentée, l’application Node.js n’envoie plus directement vers le serveur de traitement mais vers une queue Azure Event Hub, qui:
- Stocke les messages, ce qui permet d’éviter la perte de données
- Peut recevoir jusqu’à 10^6 événements par seconde, et ne constitue donc pas un goulot d’étranglement
Cette queue est pollée par l’étage suivant de l’architecture, Apache Storm.
Apache Storm
Storm est un système de traitement en temps réel distribué (master node/worker nodes comme hadoop).
Une chaîne de traitement est un graphe qui connecte des primitives Storm:
- Un tuple est un quanta de données; ici les tuples contiennent les mesures relevées par les capteurs
- Un Stream est un stream infini de tuples
- Un Spout est une source de streams; ici il y a 1 spout, qui polle la queue Azure Event Hub
- Un Bolt est un processeur de stream; ici le premier Bolt de la chaîne est un parseur, qui transforme un Stream de JSON en Stream d’objets
- Une topologie connecte les Spouts et les Bolts:
protected StormTopology buildTopology(EventHubSpout eventHubSpout, SimpleHBaseMapper mapper) { TopologyBuilder topologyBuilder = new TopologyBuilder(); // Name the spout 'EventHubsSpout', and set it to create // as many as we have partition counts in the config file topologyBuilder .setSpout("EventHub", eventHubSpout, spoutConfig.getPartitionCount()) .setNumTasks(spoutConfig.getPartitionCount()); // Create the parser bolt, which subscribes to the stream from EventHub topologyBuilder .setBolt("Parser", new ParserBolt(), spoutConfig.getPartitionCount()) .localOrShuffleGrouping("EventHub") .setNumTasks(spoutConfig.getPartitionCount()); topologyBuilder .setBolt("DeviceData", new DeviceDataBolt(), spoutConfig.getPartitionCount()) .fieldsGrouping("Parser", "dataDeviceStream", new Fields("timestamp", "deviceid", "datas")) .setNumTasks(spoutConfig.getPartitionCount()); topologyBuilder .setBolt("Average", new AverageBolt(), spoutConfig.getPartitionCount()) .fieldsGrouping("Parser", "averageStream", new Fields("timestamp", "deviceid", "datas")) .setNumTasks(1); topologyBuilder .setBolt("Alert", new AlertBolt(), spoutConfig.getPartitionCount()) .fieldsGrouping("Parser", "alertStream", new Fields("timestamp", "deviceid", "datas")) .setNumTasks(spoutConfig.getPartitionCount()); // Create the HBase bolt, which subscribes to the stream from Parser topologyBuilder .setBolt("HBase", new HBaseBolt("SensorData", mapper).withConfigKey("hbase.conf"), spoutConfig.getPartitionCount()) .fieldsGrouping("Parser", "hbasestream", new Fields("timestamp", "deviceid", "datas")) .setNumTasks(spoutConfig.getPartitionCount()); return topologyBuilder.createTopology(); }
Le code est disponible sur GitHub.
Lambda architecture
Cette architecture consiste en gros à réaliser à la fois un traitement en temps réel et un archivage des données moyennées. Ici le terme lambda n’a rien à voir avec les lambdas de la programmation fonctionnelle.
Les deux pattes du lambda évoquent plutôt le double aiguillage des données d’entrée:
Traitement temps réel
Le Bolt d’alerte envoie par websocket des notifications lorsque événement anormal est détecté
Traitement différé
Un Bolt moyenne les mesures par groupe de 10 tuples. Le Bolt de stockage archive ensuite dans HBase.
Production de dashboards
Hive et HBase sont intégrés, ce qui permet d’utiliser des requêtes HiveQL pour requêter les données stockées dans HBase. Le front présente les résultats de ces requêtes avec utilise Google Charts et D3.js
Applications multiplateformes avec Cordova, HTML 5, et JS
Cordova est l’ex PhoneGap, donné à la fondation Apache. Il va plus loin que ce dernier avec une interface CLI assez simple, illustrée par la demo:
- cordova create <projet>
- cordova platform add android
- cordova platform add browser
- cordova run browser
- ..
Cordova utilise WebView sur android et ios, mais est supporté nativement sur windows phone.
Les fonctionnalités spécifiques au mobile nécessite l’installation d’un plugin. Sans IDE, l’installation d’un plugin se fait en recherchant le plugin sur internet puis en utilisant la CLI: cordova plugin add org.apache.cordova.camera
Visual Studio a un bon support de Cordova:
- installe tout (le SDK android, java, ..)
- pas besoin de chercher le nom des plugins sur internet
- fournit un émulateur android
- debug à partir d’un seul outil (mais sur ios, nécessite l’installation de vs-mda-remote)
- tout cela intégré avec l’utilisation de Typescript