Techorama 2015 – dag 2

Net als gisteren zal ik weer een aantal sessie semi-live samenvatten. Hopelijk haal ik het einde van de dag, de hoeveelheid informatie was gisteren al overweldigend 🙂

Internet of things, a road to success or absolute failure – Stefan Daugaard Poulsen

IoT is op het niveau van VB6 momenteel. Het is op het niveau van de hobbyisten.

De grote bedrijven barsten van de sensoren maar moet iedere dag achterhalen waarom bepaalde signalen niet meer doorgegeven worden.

Maar consumenten snappen het nog niet. Kijk, een bestuurbare lamp met meerdere kleuren is nog uit te leggen aan mijn ouders. Maar Stefan gaf ook een aantal voorbeelden van idIOTe devices (zoals de Ring).

IOT manifest:

  • Iot devices moeten voor zichzelf werken en beperkt connecties maken
  • De setup moet nihil zijn
  • Mijn Wifi moet niet vollopen
  • Het moet bruikbaar zijn
  • Het moet non-intrusive zijn
  • Het moet betrouwbaar zijn
  • Het moet echt iets toevoegen

Stefan gaf een aantal situaties:

– proximity, auto sensors (smoke detector, precision agriculture, sensors in bomen, early warning for earthquake, anti-diefstal, beveiliging)

– simple direct feedback (personal assistants, dynamische prijzen, versheid detective van fruit, assistentie bij werkzaamheden)

– excessieve feedback (handleidingen, augmentation, iets als hololens)

– mindchangers (tanden nog niet gepoetst, groepen mensen beïnvloeden, je geld beheren)

IoT moet dus een hoger doel nastreven om succesvol te worden.

Technieken? Denk aan security first, privacy second want vertrouwen is belangrijk

De devices moeten simpel zijn, het moet open zijn (als in open standaarden), autonoom, goedkoop, consument vriendelijk.

Dus de uitdagingen zijn: privacy, security, data verwerking, opslag en ‘futuristic thinking’, protocollen, ‘de laatste kilometer van de communicatie’, menselijke interactie

Voor nu?

Ga gave prototypes bouwen. Maar verleg focus van hardware naar interactie.

Big Cloud Workloads – Andy Cross

Azure is pas de laatste 18 maanden opeens populair. De vele jaren daarvoor werd het genegeerd, dat rare spul van MSFT.

WIN_20150513_104713

Azure is distributed. Als je met Jobs en Tasks gaat werken dan wordt het echt schaalbaar. Een taak van 24 uur op 1 machine zal ruim een uur op 24 machines duren (er is overhead en niet alles is schaalbaar).

En we moeten Grids en Clusters benoemen… gewoon een groepje van machines.

Maar fout-tolerant != retry logic en Distribution != Balanced

“Hand rolling” is niet de oplossing…

Wat we willen in High Performance Computation met 1000s cores. En iedere machine kan bij andere machines direct in het geheugen lezen en schrijven. Security moet dus op gehele cluster gezet worden, niet op een node.

Er zijn drie HPC classificaties: parameter sweep, soa en eventbus. Afhankelijk van workload op de clients kies je voor één van de drie.

HPC kan moeilijk omgaan met IO intensieve applicaties.

In Azure is er een HPC Pack beschikbaar. Zelfs Parametric Sweep wordt ondersteund. Er zijn wel keuzes te maken: wil je machines met of zonder zware communicatie netwerk aansluiting (InfiniBand).

Maar HPC is moeilijk.

Er is nu ook Azure Batch: Managed service voor zware berekeningen. Er is ook een SDK voor beschikbaar. Denk aan Blender rendering. Dit is ook op de TechEd gedemonstreerd.

Maar werkt dit ook met een Peta bytes aan data? Of megabytes per seconde aan doorvoer? Wel of niet gestructureerd? Met verschillende bestandsformaten of structuur?

Hadoop of beter bekend als HdInsight biedt hier ook een oplossing voor. Het is een open source oplossing voor Big Data. En er zijn ook SQL achtige talen om hier mee om te gaan (HiveQL en Spark-SQL).

Hadoop kan dus ook met streaming omgaan. Maar dit kan alleen op de Windows distributie, niet op Linux. Het Spark team ondersteunt het ook niet.

Kijk ook naar mBrace als je iets met big data wilt in c#.

En voor de toekomst zien er de taal R binnenkomen, MSFT heeft het bedrijf Rvolution Analytics overgenomen. Het kan zowel met Big Compute als met Big Data omgaan.

En R zal ook met Azure Batch om kunnen gaan.

Azure App Service; Building Workflows using Logic Apps – Sam Vanhoutte

Api Apps zijn simpele services. Volgens de spreker zou dit de Azure implementatie van microservices moeten zijn.

En in een bepaalde mate zijn de karakteristieken van Microservices ook op ApiApps te mappen.

Sam gaf al snel een demo over hoe een ApiApps aan te maken. De ApiDefinition in de apiapp.json was het meest opvallende. Want daarin is Swagger gedefinieerd als definitie van de api…

Kijk ook naar de configuratie van SwshBuckle. Daar is de UI voor eenvoudige testen te activeren.

In de toekomst zal het mogelijk zijn om je eigen ApiApp als een Nuget package in een gallerij te zetten. En dan kunnen andere deze kopen (of gratis krijgen als je dat wilt) en dan hosten ze die zelf, inclusief de configuratie die je ingebouwd hebt.

En automatic update is ook mogelijk. Als de maker een nieuwe versie van een apiapp aanlevert, dan wordt deze automatisch uitgerold op je eigen server. In de praktijk zal deze uitstaan. Want er kan een breaking change in zitten of de billing is aangepast…

Omdat de service met swagger opgeleukt is, kan MSFT ook heel makkelijk een client genereren voor zo’n service.

Een ApiApp heeft in zichzelf een Isolatedstorage voor ZEER eenvoudige opslag.

En je kunt de apiapp afhankelijk maken van een andere apiapp.

De gateway levert oauth security, dankjewel AMS!

LogicApps zijn workflows van gekoppelde apiapps. En deze kunnen binnenkort ook on-premise werken via Azure Stack.

WIN_20150513_121645

Het is een eenvoudige versie van Azure Biztalk maar er zijn nog steeds onderdelen van Biztalk beschikbaar zoals de EdiFact koppeling. Erg krachtig dus.

Logic Apps heeft ook een eigen taaltje om input en output te mappen en om keuzes te maken. De taal is nog erg beperkt. Geen idee hoe dit gaat lopen…

De volgende demo was dus logic apps. Hij liet zien hoe je in de portal een logic app kon aanmaken maar dit bleek ook via VS2013 / Azure SDK 2.6 te doen. Maar dan moest je wel de flow in json gaan intypen.

Er is ook beperkte flow beheersing mogelijk. Als een voorgaande stap fallt dan… Helaas is de flow erg spartaans en moet je ontzettend opletten welke stap van welke afhankelijk is.

Triggers kunnen zijn:

  • Recurrence
  • FTP
  • Api polling
  • Api App trigger
  • Webhooks
  • Conditionals

Debuggen kan met RequestBin om de output van de vorige stap te achterhalen.

Observaties van de spreker:

  • Het is goed toepasbaar voor lichte taken.
  • De kosten zijn moeilijk in te schatten.

Techorama 2015 – dag 1

De Techorama is een twee-daags congres in een bioscoop te Mechelen, België. Er zijn meerdere tracks naast elkaar, uiteenlopend van Mobile, IoT, Azure, Enz.

WP_20150512_001

Mijn aandacht gaat voornamelijk uit naar meer Azure kennis opdoen en ik zal van een aantal sessies een (semi) live verslag doen. Dit zal ongetwijfeld spelfouten en kromme zinnen opleveren maar dat heeft ook zijn charme (ahum).

De lokatie is overigens een bioscoop, dus we zitten de hele dag in het rode plush naar enorme beamerschermen te kijken.

De keynote is van Hadri Hariri en gaat over “The Silver Bullet Syndrome”.

Hari vindt de presentatie zelf niet zo informatief, maar dat viel gelukkig wel mee.

Hij begon met de voorlopers van WCF zoals Midas, Corba, Dcom, etc. En vertelde over het mooie ABC verhaal maar dat het snel omdraaide naar de configuratie hel. De belofte werd niet ingelost.

WIN_20150512_091834

Daarna werd Rest aangehaald en nu wordt er over MicroServices gepraat. Hoe klein moet een microservice zijn, bijvoorbeeld?

En hetzelfde gebeurde met DAL. Opeens moest xHibernate gebruikt worden. En nu zijn ORMs opeens slecht. CQRS is nu hot. Maar de DAL is niet het probleem. De onderliggende opslag is de belemmering. Wat is de silver bullet voor opslag? No sql?

En ook de silver bullet van ontwikkeltalen kwam naar voren.

Wij doen het zelf fout. Functionele talen zijn een oplossing voor OO. Maar Javascript neemt de wereld over (volgens tellingen in GIT).

Nu kwamen er een aantal pakketten voorbij: angular, react, etc. Wat is hype en waarom is het onstaan?

Maar er is geen conclusie. Er is geen zilveren kogel…

Waarom springen we steeds op de trein van nieuwe technologie?

Software is niet het doel voor ontwikkelaars. Het is de automatisering. Daar doen we het voor. Upgrades zijn niet ons doel. We willen betere automatisering. En onze drang tot innovatie maakt ons manisch om de nieuwste technologie te gebruiken.

Maar we moeten op de context letten. Als [groot bedrijf] overstapt naar een bepaalde technologie, moeten wij dat dan ook? Want zij proberen ook maar wat en kijkt wat er aan de muur blijft plakken.

Wij kunnen niet gokken. We moeten niet achter glimmende zaken aanrennen.

Of zijn we CV gedreven? Proppen we zo veel mogelijk technologie in onze projecten of denken we na hoe we voor de klant kunnen automatiseren op de veiligste, goedkoopste manier.

Evalueer dus wat anderen roepen. Waarom wil je iets nieuws gebruiken? Wat levert het je op?

Microsoft heeft op de stand fraaie stickers, een must have:

WP_20150512_002

En natuurlijk is er ook swag:

WP_20150512_003

SELECT value from DataStream – Alan Smith

Dit is een sessie van Alan Smith rond Azure EventHub en StreamInsight.

Het gaat om grote hoeveelheden data dit continue binnenkomt in een queue en over de tijd heen gecontroleerd moet worden. Denk aan een gemiddelde temperatuur van het afgelopen kwartier, het hele jaar door. En dat kunnen dus miljoenen berichten per seconde zijn.

WIN_20150512_102336

En dit willen we via een SQL achtige taal representeren.

Overigens kunnen we de invoer simuleren via de blob storage.

StreamAnalytics bewerkt het en de output wordt weer opgeslagen in SqlAzure of andere storage. Het is dus indikken en filteren.

Berichten kunnen Json, Csv of Avro zijn (de laatste komt van Apache).

Maak dus een job aan in StreamAnalytics. En geef voor de job de input op. Dit kan dus blobstorage of eventhub zijn. De output is dan ook te selecteren.

En schrijf daarna je query. Een query kan zijn:

Select driver, avg(speed) from telemetry group by SlidingWindow(second, 10), driver having speed > 100

Er werd gedemonstreerd hoe even een testbestand met jsonberichten werd gebruikt om de query te testen.

We willen dus door de tijd heen filteren. We hebben drie testen: Sliding interval, Tumbling interval en Hopping interval. Let op het aantal berichten wat de keuze kan opleveren. Sliding window kan een verdubbeling van data opleveren!

Maar let er op dat de test standaard niet de tijdsafhankelijkheid test. Maar we kunnen dit gelukkig wel forceren door de timestamp te definiëren.

En de ene query kan gefilterd worden als bron voor een andere query. Erg krachtig dus!

Leuk was dat het racespel van de Azure Bootcamp van enkele weken geleden ook door StreamAnalytics heen gehaald is en dus weten we van iedere speler de gemiddelde snelheid, maximum snelheid, etc. Waarom? We weten van iedere speler de plaats op de track, de stuurpositie, snelheid, etc. Dit kon ook gesimuleerd worden.

Job kunnen real time draaien maar het kan ook draaien alsof het enkele uren/dagen geleden is. De data wordt namelijk enige tijd bewaard in de eventhub. En je kunt ook starten waar je de vorige keer gestopt bent. Handig als je tussendoor de query wilt aanpassen.

Dit is erg interessant en vooral de export naar CSV voor Excel voor verdere verwerking was erg leuk om te zien.

The internet of your things – Jan Tielens

Deze sessie begon met een nogal algemene (saaie) opzet. Helaas moeten we nog even wachten op echt interessante zaken. Later dit jaar komen de Azure IoT Suite en de IoT Hub uit. Hiermee zijn algemene IoT vraagstukken zoals command&control, identiteit en dataoverdracht slim opgelost.

WIN_20150512_122454

De EventHub kwam iets te snel voorbeid. En StreamAnalytics is in de vorige sessie van Alan Smith in meer details uitgelegd.

De demo maakt de partition key en retention time zichtbaar van de EventHub.

De consoleapp demo rond de Raspberry pi met mono erop was wel erg interessant. Helaas werd niet helemaal getoond hoe de een bericht helemaal door het systeem doorgegeven werd tot aan de live rapportage.

Ook de Windows 10 IoT core demo op de Raspberry Pi2 was interessant.

Managing Azure Workloads with Chef – Rasmus Hald

Rasmus gaf al snel aan dat er DevOps hackatons in Amsterdam gaan komen, iets wat in Amerika al populair is.

WIN_20150512_133818

Het was een DevOps sessie hoewel Rasmus ook de tem ‘NoOps’ noemde, de doodsteek voor IT-Pro dus.

Infrastructure as Code gaat over de strijd tussen scale dimenties: # servers, bemensing, complexiteit en time-to-market.

Het gaat dus om het automatiseren van infrastructuur. En dat betekent dus ook complexe afhankelijkheden zichtbaar maken. En het moet fouttollerant zijn. En verschillende platformen moeten ondersteund worden. En ook Cloud resources moeten ondersteund worden.

Scripting heeft het voordeel dat het zelfdocumenterend is. En scripts is ook code dus zet dit in een versiebeheersysteem (inclusief auditing en workflow voor goedkeuring).

Dan Chef.

Een demo. Op zijn ontwikkelmachine stond de Cfef Dev kit en Azure Powershell. En er is een Chef server geplaatst… ergens… wellicht on premise.

Hij werkte dezelfde hoeveelheid werk af, met de hand, via knife (een cross platform shell script dos box (..)) en powershell. Was Chef de snelste? Daar leek het op..

De chef server werd geconfigureerd via een Manage Website (gratis tot vier nodes).

Chef valt uiteen in cookbooks en daar staan recipies in (in dit geval een aprate recipy per operating system).

In de omgevingen (Azure, on-premise, AWS) staan client nodes geconfigureerd.

In de checf recipy stond gewoon powershell geschreven omdat we naar Windows deployen. Niks nieuws leren dus… voor de andere omgevingen (Linux, AWS) werd knife gebruikt.

Maar we rollen dus een kookboek uit.

Kortom, waarom Chef als je ook Powershell kunt gebruiken? Nou, soms kan dat niet. Als je een gemixte omgeving hebt, dus geen windows-only, dan is Powershell niet toereikend. Als je ook met Amazon en Google of je eigen on-premise servers te maken hebt met daarop linux, dan wordt Powershell een uitdaging. Met Chef is dit eenvoudig.

In de nabije toekomst zal Chef nog verder geïntegreerd worden met Azure.

EF7, what have you done with my ORM? – Julie Lerman

.. is compleet herschreven

.. heeft de bekende interfaces/APIs

.. heeft betere interfaces/APIs

.. is not backwards compatible!

Het EF team heeft besloten door zo ontzettend veel technical dept om het framework compleet te herschrijven.

Want het team wilt ook niet-relationele platformen ondersteunen. En het kan ook op eenvoudige platformen draaien zoals Windows Phone en store apps.

De EDMX en de Object Context zijn hierdoor gesneuveld. Ook EntitySql en automatic migrations gaat verloren.

Sterker nog EF7 blijft nog even in preview/pre-release want ze lopen erg achter op schema en willen minimaal ASP.Net 5 en coreCLR ondersteunen: “Lean and Composable”.

Je kunt dus naast de EF7 core nuget package de gewenste andere packages ophalen. Wil je geen migrations? Dan hoef je die niet op te halen.

EF7 moet naast CoreCLR ook op de cross platform CLR gaan draaien (linux, ios, etc.). SqlLite en PostgreSql moeten ook ondersteund gaan worden. En ze willen In Memory data gaan ondersteunen. Fantastisch voor unittesten!

En ze willen ook Redis cache oppakken. En ze willen zelfs NoSQL gaan ondersteunen (Azure Table Storage is als POC ondersteund). WUT? Er zit toch een R van relational in ORM?

EnityModel, DbContext, Migrations, SaveChanges, Change tracking en LinQ2entities zal amper veranderen.

En dan nu de langverwachtte functionaliteit die niet kon zonder de enorme refactorslagen: Batch CUD, Unique constraints (maar dan wel goed), queries kunnen nu slimmer uitgebreid worden met eigen code (voorheen werd geprobeerd hier SQL van te maken), type conversions.

EF7 moet ook IOC vriendelijk maken.

Entiteiten kunnen ook een ‘schaduw toestand’ krijgen?? Hmm. Geen demo hiervan dus.

Maar EF6 blijft voorlopig nog wel even bestaan. En maak de keuze of de pijn van overstappen gerechtvaardigd is met de voordelen.

 

Introduction to Tessel combined with Azure EventHub

Last month, during the Azure Bootcamp, I was introduced in programming the Tessel.

This device is a fairly cheap IoT programming board and for me, the most remarkable feature was that it was running on JavaScript.

WP_20150425_004

Yes, everybody with the basic understanding of JavaScript can start programming the Tessel.

My main goal for  that day was putting some effort in Azure EventHubs but first I did the ‘hello world’ of the Tessel called Blinky.js

// Import the interface to Tessel hardware
var tessel = require('tessel');
// Set the led pins as outputs with initial states
// Truthy initial state sets the pin high
// Falsy sets it low.
var led1 = tessel.led[0].output(1);
var led2 = tessel.led[1].output(0);
setInterval(function () {
  console.log("I'm blinking! (Press CTRL + C to stop)");
  // Toggle the led states
  led1.toggle();
  led2.toggle();
}, 100);

It was not that intuitive to get this working (I had to install node.js etc) but the convenience of JavaScript is very nice. So just follow the scripted examples.

Then I tried out and combined two other hands-on labs:

These HOLs helped me to explore how I can send messages to the EventHub. And I was surprised how easy it was to send JSON data into the EventHub. And now I can imagine how the EventHub is just a VERY BIG bucket in which Azure MessageBus messages are off-loaded. And I can image how the data can be investigated by StreamInsight for a couple of days before the data gets steel and is deleted.

So finally, just for fun, I came up with this continuous probing and sending:

var https = require('https');
var crypto = require('crypto');
var climatelib = require('climate-si7020');
var tessel = require('tessel');
var climate = climatelib.use(tessel.port['A']);

climate.on('ready', function () {
  console.log('Connected to si7005');
});

climate.on('error', function(err) {
  console.log('error connecting module', err);
});

// Event Hubs parameters
console.log('----------------------------------------------------------------------');
console.log('Please ensure that you have modified the values for: namespace, hubname, partitionKey, eventHubAccessKeyName');
console.log('Please ensure that you have created a Shared Access Signature Token and you are using it in the code')
console.log('----------------------------------------------------------------------');
console.log('');

var namespace = 'SvdvEh-ns';
var hubname ='svdveh';
var deviceName = 'mytessel';
var eventHubAccessKeyName = 'SendRights';
var createdSAS = 'SharedAccessSignature sr=[...]';

console.log('Namespace: ' + namespace);
console.log('hubname: ' + hubname);
console.log('publisher: ' + deviceName);
console.log('eventHubAccessKeyName: ' + eventHubAccessKeyName);
console.log('SAS Token: ' + createdSAS);
console.log('----------------------------------------------------------------------');
console.log('');

var SendItem = function(payloadToSend){
  // Send the request to the Event Hub
  var options = {
    hostname: namespace + '.servicebus.windows.net',
    port: 443,
    path: '/' + hubname + '/publishers/' + deviceName + '/messages',
    method: 'POST',
    headers: {
      'Authorization': createdSAS,
      'Content-Length': payloadToSend.length,
      'Content-Type': 'application/atom+xml;type=entry;charset=utf-8'
    }
  };

  var req = https.request(options, function(res) {
    console.log('----------------------------------------------------------------------');
    console.log("statusCode: ", res.statusCode);
    console.log('----------------------------------------------------------------------');
    console.log('');
    res.on('data', function(d) {
      process.stdout.write(d);
    });
  });

  req.on('error', function(e) {
    console.log('error');
    console.error(e);
  });

  req.write(payloadToSend);
  req.end();
}

setImmediate(function loop () {
  climate.readTemperature('f', function (err, temp) {
    climate.readHumidity(function (err, humid) {
      console.log('Degrees:', temp.toFixed(4) + 'F', 'Humidity:', humid.toFixed(4) + '%RH');
      var payload = '{\"Temperature\":\"'+temp.toFixed(4)+'\",\"Humidity\":\"'+humid.toFixed(4)+'\"}';
      SendItem(payload);
      setTimeout(loop, 5000);
    });
  });
});

This code was enough to see how the EventHub was filled with data. I had no time to check out StreamInsight. But it seems very easy to write some SQL-like code to get the right information out of the hubs.

The biggest problem was the administration of all the namespaces, keys, connection strings and secrets of both the MessageBus and the EventHub. Sometimes I had to cut/copy/paste parts of connection strings but that was not that intuitive.

And the Tessel? It was real fun to play with. And the complete humidity/temperature sensor was easy to plug in (had to fix the code because it was referencing another module type). But somehow I missed the spider web of wires and components and the accidental reboots of the RaspberryPi 🙂

A special mention goes to the free service bus explorer. It was very exciting to see messages coming in live. Very useful for debugging too.

Raspberry Pi NoIR camera pictures by daylight

The Raspberry Pi is considered a great IoT device but it is was designed to let children find out how computers work.

And what is a better way to let them learn to develop programs if they can interact with electrical component for a fart detector, a grandpa scarer or a parent detector?

That last example uses the dedicated Raspberry Pi Camera (sold separately) but I like the Raspberry Pi concept so I bought one.

There are actually two camera’s. There is a regular one and a No Infra Red Filter one.

I bought the NoIR one so it could be used as a surveillance camera or just for fun, filming at night (My oldest son want to put the camera on a Nerf gun so he has a kill cam 😉 )

To get the camera running is not that difficult just follow this and that.

The pictures and movies are pretty good but the colours are terrible of course:

image image_without filter

Yes, I know, it’s for nigh vision.

And the camera can also record video for several seconds/minutes in H264 format. Although this an excellent quality for the price of this device, the format is not that handy. H264 has to be converted to another format before you can show it to your friends.

And this is possible on the Raspberry Pi itself.

So I changed the emaple code slightly to get MP4 instead of H264:

import picamera
from time import sleep
from subprocess import call

camera = picamera.PiCamera()

camera.start_recording('video2.h264')

sleep(10)

camera.stop_recording()

call(['MP4Box -add video2.h264 video2.mp4'], shell=True)

call(['rm video2.h264'], shell=True)

After the recording I convert the H264 into MP4 and delete the old video.

And now we have nice video from the Raspberry Pi in MP4 (which can be played within the browser of the Pi) with that very seventies polaroid effect.

An example is shown at :