Posts in Overzicht
IoT-technologie onderbenut in grote ondernemingen

Het internet of things (IoT) is voor veel organisaties en CIO’s nog wat diffuus en wordt vaak afgedaan als toekomstmuziek. Toch wordt IoT meer toegepast dan op het eerste gezicht lijkt, schrijven Martijn Smit, Jeroen Jacobs en Edwin van Nuil van Oblivion Cloud Control.

De essentie van IoT is dat eigenlijk alles, hoe klein ook, verbonden is met internet om gegevens en data te verzamelen of om een apparaat decentraal te besturen. Toepassingen van IoT zijn gericht op twee gebieden. Veruit de meeste toepassingen hebben dataverzameling en analytics tot doel. In mindere mate richten IoT-toepassingen zich op decentrale sturing. Uit deze twee toepassingsgebieden zijn tal van strategisch inzetbare IoT-toepassingen te bedenken voor organisaties.

IoT is een enabler en biedt nieuwe mogelijkheden voor organisaties. Processen, services en data die nooit voorhanden waren, zijn mogelijk dankzij IoT-technologie. Toegepaste IoT draagt dan ook vaak strategisch bij aan innovatie, procesoptimalisatie of financieel voordeel/omzet. Zo realiseren organisaties dankzij IoT bijvoorbeeld nieuwe diensten, businessmodellen en omzetstromen of wordt het engagement met klanten verbeterd, verreikt of verbreed. In de categorie financieel draagt IoT veelal bij door minimalisatie van verspilling of verbetering van uitnuttig van middelen.

Meer richting de interne processen kan gedacht worden aan zaken als verbetering van veiligheid en optimalisatie van bedrijfsprocessen. Een voorbeeld van een strategische toepassing is een kantoorinrichting- en meubilair fabrikant die door sensoren in de bureaustoel een unieke werkplekbeleving aan zijn klanten kan aanbieden, maar daarmee ook gegevens terugstuurt over gebruik. Een ander voorbeeld is een verzekeraar die data verzamelt uit de databus van de auto en met additionele sensoren, en hier een dynamische korting op de verzekeringspremie baseert.

Sensoren zoals temperatuur, licht, beweging, vochtigheid, kleur, stroomsterkte, enzovoorts, zijn op zichzelf niet nieuw. Ze worden al decennialang toegepast in de elektromechanische industrie en zijn er voor de meest bijzondere toepassingen. De hoeveelheid en intensiteit van de toepassing zijn wel nieuw.

IoT-architectuur

Alvorens we verder op praktische IoT-toepassingen ingaan, beschrijven we eerst de basiselementen van een IoT-ketenarchitectuur. Grofweg is een IoT-architectuur opgebouwd uit vier elementen. Het IoT-device zelf, de connectiviteit, een IoT-platform, en de businessapplicatie. De architectuur en zijn functies zijn weergegeven in figuur 1. We verklaren de onderdelen nader.

Figuur 1. IoT-keten en architectuur

Figuur 1. IoT-keten en architectuur

IoT-device

Elk IoT-device bevat drie kernfuncties: één (of meerdere) sensor(en) voor metingen in de fysieke wereld, een lokale simpele processingunit, en de communicatie het netwerk in. Veelal heeft een sensor een lokale aansturing en logica (low-power MCU/SoC) nodig om waarnemingen te verwerken en alleen relevante waarneming te verzenden via de communicatiemodule (WPAN/LPWAN) naar een IoT-Platform.

IoT-connectiviteit

Connectiviteit van de IoT-devices naar het IoT-platform kenmerkt zich als WPAN en LPWAN. WPAN omvat de bekende protocollen als wifi, bluetooth, Thread en/of ZigBee.

LPWAN staat voor low power wide area network en omvat protocollen als LoRa, Sigfox, NB-IoT, LTE-M. LoRa (WAN) is een open standaard die wereldwijd wordt toegepast in zowel publieke als private netwerken. De NB-IoT- en LTE-M-netwerken worden door telecomproviders in gelicenseerd spectrum aangeboden en hebben een aantal voordelen. De grootste voordelen van deze LPWAN-protocollen zijn het lage dataverbruik, geringe batterijverbruik, encryptie en grote reikwijdte. Dit maakt toepassingen mogelijk met kleine devices op locaties zonder elektriciteit of WPAN-connectiviteit.

Connectiviteit wordt geboden door een netwerk als KPN’s LoRaWAN, T-Mobile NB-IoT of door een private-owned LoRaWAN-gateway, die daarna bijvoorbeeld over het internet de communicatie naar achterliggende platformen verzorgt.

IoT-platform

  • Het IoT-Platform heeft grofweg drie functies:

  • Het ontvangen en verwerken van ruwe berichten van de decentrale IoT-devices.

  • Het near-time transformeren van ruwe data naar uitwisselbare informatie voor achterliggende systemen als een datawarehouse of een event-bus.

  • Het managen van de IoT-devices zoals onboarding en provisioning.

Het IoT-platform is IoT-connectivity agnostisch. Dat wil zeggen dat devices langs verschillende WPAN/LPWAN- of zelf WAN/LAN-routes kunnen worden opgenomen.

Businessapplicaties

De businessapplicaties zijn systemen als datawarehouses, analyse/BI-tooling, log-collectors en bijvoorbeeld webbased bedieningsapplicaties om vanuit een vriendelijke interface opdrachten naar apparaten te kunnen sturen. Domotica bijvoorbeeld.

Uitdagingen bij IoT

Anders dan reguliere IT-toepassingen kent het IoT een aantal specifieke uitdagingen. Kenmerkend zijn de hoeveelheid en de aard van de IoT-devices. Devices zijn lang niet altijd eigendom van de aanbieder van een IoT-dienst, worden door diverse vendors op eigen specs in elkaar gezet, en hebben zo hun technische beperkingen.

Zo is stroomverbruik van het device en connectiviteit een schaarste en lang niet altijd vanzelfsprekend. Apparaten moeten dus in sommige toepassingen mogelijk lange tijd op een batterij kunnen functioneren en het IoT-platform moet met downtime en communicatiewindows van apparaten kunnen omgaan. Vanuit de architectuur is zo’n IoT-platform bovendien zwaar asynchroon opgezet.

DEVICES ZIJN LANG NIET ALTIJD EIGENDOM VAN DE AANBIEDER VAN EEN IOT-DIENST

Het is dus belangrijk de embedded software hiermee adequaat te laten omgaan. Ook bieden sommige IoT-platformen (zoals dat van Amazon Web Services) een framework om via shadow/twin designpatterns een IoT-device naar de achterliggende systemen virtueel beschikbaar te houden, én andersom.

Een andere uitdaging is security. Welke data bevat het device? Hoe gevoelig is deze? En hoe is de data lokaal beschermd? Maar ook het transport van deze data via connectiviteit naar de achterliggende platformen, incluis het IoT-Platform. Met de actualiteit van de GDPR is het essentieel om de veiligheid en privacy goed op orde te hebben in de totale keten van de IoT-toepassing.

Beheerbaarheid en kostprijs zijn andere gebieden die aandacht behoeven. In dit kader bieden cloudplatformen als Amazon Web Services en Azure tal van diensten om beheer en dataverwerking in een opex-model beheersbaar en efficiënt te realiseren. Ter illustratie zijn in het kader de belangrijkste IoT-diensten weergeven van Amazon Web Services.

IoT-casus energiemanagement

Nu de architectuur- en IoT-specifieke uitdagingen zijn geschetst, duiken we in enkele cases uit de praktijk. Een woningcoöperatie had de afgelopen jaren veel van haar woningen en flats voorzien van zonnepanelen. Om zicht te houden op de energieopbrengsten waren ze op zoek naar een meetsysteem. Echter, de betrouwbaarheid moest hoog zijn en de daadwerkelijk opgewekte energie meten. Dus geen ‘net feed-in’, maar gerealiseerde opwek zonder afhankelijkheid van het type omvormer. Ook onafhankelijkheid van de lokale internet/wifi-verbinding van de bewoners was geen optie.

Gekozen werd om een extra kWh-meter achter de omvormer te plaatsen met een universele ModBus/RS485-interface. Een collector (MCU) las vervolgens digitaal de meterstand en stuurde een UP-bericht over LPWAN. Eigen LoRaWAN-gateways werden gebruikt op de hogere gebouwen voor omliggende woningen. Deze gateways connecteerden via 4G met het internet en stuurden de data door naar de IoT-Stack in de AWS-public cloud. Daar vond verdere verwerking van de data plaats en landde de data in een datawarehouse waar een webinterface heldere analyses visualiseerde.

Op deze manier had de coöperatie uniform inzicht met een betrouwbaar en kosteneffectief netwerk, los van vendor lock-in en vendordatasilo’s. Inzet van private LoRa bespaarde aanzienlijk in de connectiviteitskosten in vergelijking met de inzet van 4G per locatie. Daarbij bood het netwerk de mogelijkheid om in het gebied andere zaken te meten, zoals temperatuur en fijnstof. (Zie figuur 2 voor de visuele weergave van de architectuur.)

Figuur 2. IoT-architectuur casus 1

Figuur 2. IoT-architectuur casus 1

IoT-casus gladheidbestrijding

Een andere casus betreft een publieke instelling die weerdata (temperatuur en vochtigheid) onder, op en boven de grond wilde verzamelen over een zeer verspreid gebied. Vervolgens is met hulp van analytics tooling voorspeld of er (preventief) gestrooid diende te worden tegen gladheid. De meetpunten werden verspreid over het terrein. Daarbij was echter de uitdaging dat er geen kabels aangebracht konden worden om in connectiviteit en elektriciteit te voorzien. Low power IoT-devices brachten de oplossing. Ook het optuigen van een privaat netwerk met een eigen gateway was niet mogelijk, dus werd besloten om het KPN LoRaWan-netwerk te gebruiken. De data-events kwamen vanaf het KPN-netwerk het AWS IoT-platform in. Daar werd de ruwe data vervolgens getransformeerd en ging deze richting DWH voor verdere verwerking en BI.

Klaar voor IoT?

De mogelijkheden van IoT alsook twee praktische casussen inspireren mogelijk om na te gaan denken over de waarde die IoT binnen de organisatie kan leveren. Het denken vanuit de functionele gebieden data-analytics en decentrale sturing vormt daarbij een goed startpunt. Start na het idee vervolgens klein met een proof of concept. Dankzij de public-cloud-IoT-diensten die vandaag de dag beschikbaar zijn, kun je zonder al te grote startinvesteringen aan de slag. Met slechts enkele IoT-devices ben je al vertrokken.

Denk wel vanaf de start aan de architectuur van de hele IoT-keten en toets aan de hand van de eerder in dit artikel genoemde IoT-uitdagingen. Houd rekening met het ontstaan van vendorsilo’s. Data moet kunnen vloeien. Denk ook een paar stappen vooruit zodat de IoT-keten klaar is voor uitbreiding of nieuwe toepassingen. Dat zorgt voor een haalbare en schaalbare IoT-oplossing bij uiteindelijke realisatie.

Martijn Smit is softwarearchitect en IoT-consultant en realisator van de twee beschreven casussen, Jeroen Jacobs is cloudconsultant, en Edwin van Nuil is managing director bij AWS consultancy-firma Oblivion Cloud Control.

(Dit artikel is eerder verschenen in December 2018 in IT Executive)

Serverless, game changer in cloud computing

 Door: Jeroen Jacobs & Edwin van Nuil  

Cloud computing heeft de afgelopen jaren al menig (IT) organisatie aanzienlijke verbeteringen gebracht als het gaat om wendbaarheid, efficiency, innovatie en daarmee concurrentievoordeel voor de organisatie. Applicatieservers die initieel in gehuurde en gemanagede datacenters draaien, worden massaal verschoven naar public platformen als Amazon Web Services, Google Cloud Platform en Microsoft Azure. Hoewel deze shift vaak nog vooral gericht is op rehosten van servers, zijn de resultaten in zin van efficiency, flexibiliteit en wendbaarheid, alsook innovatie, al enorm. De volgende shift in cloud computing gaat echter niet meer over servers, maar is “Serverless”.

Als we de afgelopen twee decennia terug in de tijd kijken, zien we eigenlijk een continue run om dezelfde applicatiefunctionaliteit op steeds minder fysieke hardware te kunnen laten draaien. Deze trend ontstond begin jaren 2000 met de opkomst van virtualisatietechnologie gedreven door VMware. Door meer servers op één fysieke server te draaien werd enorm veel efficiency behaald en dat evolueerde zo jaren door.

De volgende grote stap was de start van public cloud computing. In 2006 lanceerde Amazon Web Services hun public cloud computing platform, in de begin jaren veelal gericht op Infrastructure as a Service diensten. In plaats van servers gevirtualiseerd op een eigen infrastructuur draaien, al dan niet in eigen of gehuurd datacenter, werd ingezet op grotere schaalvoordelen met hogere efficiency en wendbaarheid tot gevolg. Langzamerhand verschoof de focus breder van Infrastructure as a Service naar Platform as a service. Softwareontwikkelaars en applicatiearchitecten gingen daarop cloud-native denken, designen en implementeren. Ook de CIO binnen de enterprise ging serieus nadenken over een cloudstrategie.

Het cloud-native denken groeide door naar applicatiearchitectuur op basis van microservices waarbij in plaats van één grote monolithische applicatie, de functionaliteit werd opgeknipt in kleinere applicatie services die een samenhang hebben met elkaar. Deze kleinere functies kunnen vervolgens zelfstandig draaien, schalen en ontwikkeld worden. De populariteit van microservices ging hand in hand met containerization (Docker) waarbij deelfunctionaliteiten van een applicatie in containers gingen draaien. De laatste stap in deze evolutie is gezet met de lancering van Amazon Web Services Lambda. AWS Lambda is de grondlegger van de event based serverless computing wat we vandaag de dag “serverless” noemen.

De ontwikkeling van fysieke servers naar serverless

De ontwikkeling van fysieke servers naar serverless

Over Serverless

Serverless lijkt wellicht een vreemde benaming, want een cloudservice provider gebruikt uiteraard nog steeds servers, echter is er voor de afnemer van de serverless dienst geen zorg meer voor het inrichten en managen van de onderliggende servers. Eigenlijk is dit net zo als bij Platform as a Service diensten als bijvoorbeeld managed databases. Waar het bij serverless om draait is het verwerken/draaien van applicatiecode in programeertalen als bijvoorbeeld Ruby, Python of PHP. Bijkomend is, dat het verwerken van de applicatiecode gebeurt op basis van een trigger. Wat een trigger kan zijn is zeer breed variërend van het ontvangen van een upload van een file, het ontvangen van een email, scheduled event tot een API Request of trigger vanaf een andere serverless functie.

Vertaald naar applicatiearchitectuur is het gedachtengoed van serverless om net zoals bij microservices, applicaties op te bouwen uit businesslogic. De businesslogic definieer je in events en functies. Een event triggert een functie en een functie is simpel weg een stukje applicatiecode wat door het onderliggende cloudplatform wordt uitgevoerd.

Serverless georiënteerde applicaties zijn meestal niet uitsluitend gebouwd uit serverless diensten als bijvoorbeeld AWS Lambda. Naast applicatiecode draaien hebben meeste applicaties ook  behoefte aan bijvoorbeeld een stukje storage wat in gevuld kan worden met object storage als AWS S3 of NoSQL database storage met AWS DynomoDB en komen triggers ook vanaf extern waardoor de AWS API Gateway een oplossing kan zijn.  

Serverless is de game changer in cloud computing

Serverless cloud computing is absoluut de game changer in softwareontwikkeling en cloud computing. Doordat er geen servers meer nodig zijn voor het uitvoeren van applicatiecode vervallen veel van de nadelen die nog steeds bij cloud computing gelden. Software developers zijn hierdoor in staat om nog sneller te kunnen ontwikkelen en vooral ook hun tijd te kunnen besteden aan business requested features. Op de gebieden pay per use, beheer en schaalbaarheid worden de grootste voordelen behaald.

Ultime pay per use belofte ingelost

Ondanks dat Infrastructure as a Service diensten worden geleverd met een pay per use belofte,  betalen we in de praktijk eigenlijk nog steeds vaak teveel doordat servers veel idle time hebben. Ondanks dat zelfs tot op seconde kan worden afgenomen, blijft er altijd idle time. De regie om te schalen ligt namelijk bij de applicatie-developer, inframan of in het mooiste geval geautomatiseerd in de applicatie, maar schalen gaat nog steeds in eenheden van steeds een hele server. Daarentegen, wordt bij serversless eigenlijk alleen aangerekend naar de troughput die wordt verwerkt tot op honderden milliseconden nauwkeurig. U kunt zich voorstellen hoe veel efficiënter applicaties kunnen werken dan wanneer dit op een server of meerdere servers zou moeten draaien. 

Beheer(kosten)

Omdat we geen servers hebben, hoeven we geen medewerkers of derde partij meer te betalen om ze te provisionen, te onderhouden en te monitoren. Geen OS patching en hardening meer en ook geen gedoe met OS lifecycle managementprojecten. Buiten de besparing in effort, reduceert dit ook nog eens een aanzienlijk risico die alle changes en upgrades continue met zich meebrengen.  

Schaalbaarheid

Serversless computing wordt als hoog beschikbare dienst aangeboden. Er hoeft dus niet nagedacht te worden hoe de uitvoering van de applicatiecode op infrastructureel niveau hoog beschikbaar wordt gemaakt. Ook voor schaalbaarheid geldt dit mechanisme. De cloudprovider draagt continue zorg voor voldoende resources om de applicatiecode uit te kunnen voeren. Capaciteit is er gewoon en geen zorg meer van de developer.

Voorbeeld van de architectuur van een serverless applicatie

Voorbeeld van de architectuur van een serverless applicatie

Serverless in de praktijk

Sinds de lancering van Serverless met AWS Lambda, en later ook de equivalenten Azure Functions en Google Cloud Functions, groeit de toepassing van serverless enorm hard. Ook bij onze klanten zijn we eigenlijk direct al in 2014 gestart met het toepassen van serverless. We zagen al snel toepassing voor het bouwen van maatwerkfuncties binnen het AWS cloudplatform zelf. Het automatiseren van reguliere beheerscripts, controlefuncties en checks ‘serverless‘ oplossen is inmiddels dan ook een absolute standaard geworden bij onze cloud implementaties. Zo gebruiken we bijvoorbeeld AWS Lambda scripts om op basis van een gescheduled event backups van de Amazon EC2 IaaS dienst te maken en om virtuele EC2 servers buiten kantooruren af te sluiten om kosten te besparen.

Een andere recente case is een integratie tussen een HR systeem en een cloud identity platform. Het doel is om HR data gesynchroniseerd te krijgen naar het cloud identity platform. Dit sync proces loopt enkele keren per dag en leent zich daarom prima om serverless met python scripts op te lossen. De integratie kost de organisatie nauwelijks geld omdat het run proces qua resources zeer efficiënt is. Een laatste voorbeeld is een organisatie waarbij grote delen van de webapplicatie wordt vervangen door AWS Lambda functies. Technisch is het mogelijk de gehele applicatie zonder servers te laten draaien. Dat is ook voor deze applicatie de visie waar we naartoe werken. 

Niet alleen maar rozengeur en maneschijn

Het toepassen van serverless in het applicatielandschap is absoluut interessant, maar kent ook enkele nadelen. Het vereist nieuwe competenties binnen IT en een andere manier van applicaties architectuur. Bestaande applicaties moeten effectief omgebouwd worden om ze geschikt te maken voor serverless. Daarnaast is lock-in een belangrijk punt. Hoe meer gebruik wordt gemaakt van de bouwstenen van de cloudprovider, hoe meer de lock-in op het platform. Ditzelfde geldt voor het security vraagstuk. Door het runnen van code direct op het cloudplatform leggen we een belangrijk deel van de securitymaatregelen bij de cloudprovider. Tot slot performance, monitoring en debugging kan beperkter zijn. Serverless applicaties reageren anders en hebben een vorm van latency tussen functies. Qua monitoring en debugging zitten we met serverless ver boven het OS niveau en hebben we daarmee ook geen toegang tot OS level tooling en metrics. Ook hier zijn we aangewezen op wat de cloudprovider ons out of the box te bieden heeft. 

Toch een serverloze toekomst

Ondanks de nadelen leveren de voordelen veel meer op in termen van efficiency, wendbaarheid en innovatiesnelheid. ‘Serverless’ is naar onze visie eigenlijk geëvolueerd tot de eerste vraag bij het cloudnative migreren of bouwen van nieuwe cloudapplicaties. Vaak wordt serverless ingezet in een deel van de totale applicatieoplossing, aangevuld met diensten als API Gateways en PaaS diensten als databases, storage maar ook Docker en eventueel IaaS. De serverless trend en adoptie ontwikkelt zich naar verwachting de komende jaren hard door. Op zichzelf niet zo vreemd, want serverless is eigenlijk een veel betere en logischere manier om cloudresources te consumeren. Trends als Cloudnative, DevOps, Data analytics, Machinelearning en IoT zullen voor serverless, belangrijke drivers zijn en tot nieuwe innovatieve mogelijkheden en hoge efficiency leiden.

Over de auteurs

Jeroen Jacobs is Cloud Consultant & Projectleider bij Oblivion Cloud Control B.V. jeroen@oblcc.com; Edwin van Nuil is Managing Director bij Oblivion Cloud Control B.V. edwin@oblcc.com  

Oblivion Cloud Control B.V. richt zich op cloudvraagstukken en is één van de Amazon Web Services Nederlandse Consulting partners van het eerste uur. Naast Amazon Web Services tevens implemenatiepartner van complementaire platformen en diensten als onder meer Okta Identity en TrendMicro.

(Dit artikel is eerder gepubliceerd in CIO Magazine, Januari 2018)

De verschuiving naar Serverless

Las Vegas, november 2014, AWS Re:Invent. Amazon Web Services lanceert AWS Lambda, een cloudservice gebaseerd op event based computing, die de pay-per-use-belofte en applicatiearchitecturen naar een volgend niveau weet te tillen. Inmiddels is serverless de eerste vraag bij elke cloud-native-applicatietransformatie.

In de jaren negentig zette virtualisatietechnologie de markt op zijn kop. De ‘next big thing’ die volgde was in 2006 de lancering van public cloud computing, primair Infrastructure- as-a-Service-diensten. Vervolgens wonnen Platform-as- a-Service-diensten terrein en gingen applicatiearchitecten daarop cloud-native-denken, -ontwerpen en -implementeren. Vanuit het cloud-native-gedachtengoed, ontstond de applicatiearchitectuur op basis van Microservices. De populariteit van Microservices werd verder gedreven door containerization (Docker). Applicaties worden opgebroken in kleinere functies die zelfstandig draaien, schalen en ontwikkeld worden. De laatste stap in deze evolutie is event based serverless computing, ook wel serverless geheten.

Het gedachtegoed van serverless is om applicaties op te bouwen uit businesslogic in events en functies. Een event triggert een functie, wat simpelweg een stukje applicatiecode is die door het onderliggende cloudplatform wordt uitgevoerd. Voordeel: geen inframanagement en schaalbaarheidsvraagstukken meer, maar simpelweg functies, in de vorm van code, die met onderlinge logica een applicatie(onderdeel) vormen, gefactureerd per honderd milliseconden runtime. Extreem efficiënt in beheer- en rekenkosten. Sinds de lancering van serverless met AWS Lambda, en later ook de Azure- en Google-equivalenten, groeit de toepassing van serverless enorm.

Direct na de lancering van Lambda zagen we al snel een toepassing voor het bouwen van maatwerkfuncties binnen het AWS Platform zelf. Het automatiseren van beheerscripts, controlefuncties en checks serverless oplossen, is dan ook een absolute best practice geworden. Inmiddels is serverless geëvolueerd tot de eerste vraag bij het cloud-native-migreren van applicaties. Vaak wordt serverless ingezet in een deel van de totale applicatieoplossing, aangevuld met API Gateways en PaaS-diensten als databases, storage maar ook Docker en IaaS. De serveless-trend zal komende jaren naar verwachting hard doorzetten. Trends als cloud-native-migreren, DevOps en IoT zullen hierbij belangrijke drivers zijn en tot nieuwe innovatieve mogelijkheden en hoge efficiency leiden.

Het toepassen van serverless in het applicatielandschap is absoluut interessant, maar vereist ook nieuwe competenties, te bereiken door experimenteren en/of ervaring. Vraagstukken rondom security, omgaan met lock-in en het containerization versus serverless op applicatieonderdelen zijn key om goed beantwoord te hebben als je serieus wil gaan toepassen. Mooi advies hierbij: start small, experiment, learn and take the journey.

Door: Jeroen Jacobs, cloudconsultant bij Oblivion Cloud Control

(Dit artikel is eerder gepubliceerd in Computable Magazine in Januari 2018.)