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.
Advertenties