Oprichters Ambrero gaan ‘met de billen bloot’

Hoe interessant veel producten of diensten ook zijn, vaak zijn de ‘makers’ minstens zo interessant. Denk aan Elon Musk, Steve Jobs en – in iets mindere mate – Emile Ratelband. Hoe zit dat dan met onze eigen Bart en Jelle? Beschikken zij bijvoorbeeld net als genoemde iconen over voldoende daadkracht en besluitvaardigheid? Voor een antwoord op die vraag legden we de oprichters van Ambrero een reeks pittige dilemma’s voor.

‘Waar zouden ze zijn zonder de trein?’

De oprichting van Ambrero in januari 2005 kwam, voor diegenen die dat nog niet weten, min of meer toevallig tot stand. Bart Matthaei (34) kwam namelijk in 2004 tijdens zijn dagelijkse treinreis van Heerhugowaard naar Amsterdam in gesprek met een oude schoolvriendin. Die dame bleek bevriend met Jelle van den Berg die toen Interaction Design studeerde aan de HKU in Utrecht. Tijdens de levendige gesprekken die volgden, bleken er ondanks de vele verschillen tussen beiden qua achtergrond en persoonlijkheid ook voldoende overlap te zijn voor een goede klik. Ook al omdat ze op dezelfde school hadden gezeten en Bart nog les had gehad van Jelles vader.

Jeuk

Bart had toen al een paar jaar werkervaring als software-ontwikkelaar en systeem- en netwerkbeheerder bij webhosting partij Cyso. In die tijd ontwikkelde Bart ook een portaal waarmee klanten zelf konden kiezen uit een reeks diensten. Een paar jaar later begon het idee te jeuken om dit soort zaken voor meer klanten te doen en desnoods voor eigen rekening. Na de treinontmoeting en de vele gesprekken daarna trok hij met Jelle de stoute schoenen aan en was Ambrero een feit. Met VSM, een flitspaalfabrikant en enkele medische klinieken als eerste klanten kon het avontuur beginnen. Dat gebeurde aanvankelijk op een kamer bij Jelle thuis en daarna op zolder van de nieuwe woning van Bart in Alkmaar.

Dilemma’s

Het werkzame leven van Jelle (38) was tot dat moment blijven steken op ‘anemonen breken’ bij een bollenboer. Inmiddels gaat hij door het leven als UX Architect en directeur HR. Bart is op zijn beurt Consultant en directeur Finance en Commercie. Spijt van hun beslissing hebben ze geen moment gehad en eigen baas of loondienst is dan ook nooit meer een dilemma geweest. En waarom zou je ook met een goedlopend bedrijf en twintig man personeel? Nee, de dilemma’s komen uit heel andere hoek. Hier komen ze:

BartJelle
God of Darwin?Darwin Darwin
Apple of Microsoft?MicrosoftApple
Temptation Island of Jinek?JinekJinek
Strand of sneeuw?SneeuwSneeuw
Tesla of Volvo?VolvoTesla
Herman Finkers of Monty Python?Monty PythonHerman Finkers
Sleepless in Seattle of Silence of the Lambs?Silence of the LambsSilence of the Lambs
Heleen van Royen of Stephen King?Stephen KingStephen King
Alpha of Beta?BetaAlpha
Amstel of Hertog Jan?Hertog JanHertog Jan
Klassiek of modern?ModernKlassiek
Impulsief of terughoudend?ImpulsiefTerughoudend
Darten of golf?GolfDarten
All you can eat of à la carte?À la carteÀ la carte
Escape room of bowlen?Escape roomEscape room
Geld of aanzien?GeldAanzien
Praten of luisteren?LuisterenLuisteren

Nog meer weten? Bijvoorbeeld het antwoord op jouw eigen dilemma: Excelleren of consolideren? Je kunt Bart en Jelle bereiken op kopkoffie@ambrero.nl.

ambrerosoftware

IoT; een schaalbare architectuur maken voor een groot sensornetwerk

De afgelopen vijf maanden heb ik bij Ambrero mijn afstudeeropdracht mogen uitvoeren. Het doel was ‘’Het ontwerpen en implementeren van een proof of concept voor een schaalbare architectuur voor een groot sensornetwerk’’. De opdracht besloeg de onderwerpen: Internet of Things (IoT) en Big data. Tijdens mijn afstudeeropdracht heb ik veel geleerd en met deze blog wil ik deze kennis en een aantal tips delen.

De opdracht; proof of concept

Mijn opdracht: het maken van een proof of concept, het ontwerpen van een schaalbare dataverwerking voor een sensornetwerk.

Het sensornetwerk bestaat uit luchtkwaliteit-sensoren voor consumenten die data versturen via LoRaWAN. Het geeft consumenten inzicht in de luchtkwaliteit van hun eigen omgeving. Daarnaast dragen ze bij aan analyses over een specifieke regio.

De bedoeling is dat deze dataverwerking op drukke momenten opschaalt om de datastroom aan te kunnen. En dat het op rustige momenten weer terug schaalt zodat het efficiënt gebruik maakt van resources. Er zijn twee belangrijke eisen gesteld:

  • dataverwerking van minimaal 10.000 berichten per seconde
  • dataopslag van minimaal een jaar

Is mijn data eigenlijk Big data?

Veel data betekent automatisch Big Data. Deze aanname wordt vaak gemaakt waardoor er onnodig tijd wordt besteed aan speciale databases en frameworks. Terwijl deze niet altijd beter, soms zelfs slechter, presteren dan conventionele oplossingen.

Ik bepaal of mijn data Big data is aan de hand van de drie V’s van Big data; velocity, variety en volume. In de afbeelding hieronder zijn deze te zien en het toont de relaties tussen de drie V’s. Alles in de binnenste ring is geen Big data. Wanneer er één of twee V’s buiten de binnenste ring vallen kun je overwegen om onderzoek te doen naar speciale databases en frameworks. Vallen alle drie V’s erbuiten dan heb je te maken met Big data!

Ambrero blog IoT - The 3v's of Big Data

In mijn onderzoek is de velocity van de data; hoe vaak data wordt gebruikt tussen batch en interval. De variety is simpel, namelijk kleine berichtjes van 40kB. Het volume is echter erg groot, namelijk 10.000 berichten per seconde maal één jaar. Dat zijn ruim 300 miljard berichten met een grote van meer dat 13 terabyte. Er is dus een speciale oplossing nodig om efficiënt met de data om te gaan.

Het zoeken van de juiste componenten

Het is nog een hele zoektocht om de juiste analyse frameworks en databases te vinden voor deze applicatie. Het Big-Data landschap is namelijk enorm. Er zit altijd wel iets tussen wat goed werkt maar het vereist enig uitzoekwerk!

Uiteindelijk is mijn keuze gevallen op Apache Cassandra voor de database en Apache Flink voor het maken van analyses. Deze keuze heb ik op de volgende manier gemaakt:

1. Stel een lijst op van eisen

In het geval van het analyse framework zocht ik een framework met batch en stream analyse mogelijkheden.

2. Maak een lijst van frameworks en databases

Het is handig om voor iets te kiezen wat recent is en veel gebruikt wordt, de kans dat er genoeg informatie en ondersteuning beschikbaar is is dan groot. Maar ga ook niet gelijk voor de eerste de beste big-data database die bekend klinkt. Doe je onderzoek grondig.

3. Maak een vergelijking

Kijk welke databases/frameworks voldoen aan je eisen

  • Geen één gevonden? Zoek dan verder naar wat minder bekende oplossingen of kijk welke het dichtst in de buurt van je gestelde eisen komt.
  • Zijn het er meerdere kijk dan welke het best binnen de applicatie past.

Vaak weet je pas echt of een framework goed binnen de applicatie past nadat je er een tijdje mee gewerkt hebt. Zorg er dus voor dat er genoeg ruimte is om te wisselen van framework.

Ambrero IoT blog - Vergelijking frameworks

Het creeëren van snelheid

Om de applicatie schaalbaar te maken is deze verdeeld in losse componenten. Ontstaat er bij een component een knelpunt dan wordt deze meerdere keren gestart om zo het knelpunt te verhelpen. Binnen de dataverwerking wordt RabbitMQ gebruikt als messagbroker tussen de verschillende componenten. Zo is er geen harde koppeling tussen en kunnen ze onafhankelijk van elkaar schalen. Daarnaast bevatten slimme frameworks zoals Apache Flink interne schaling waardoor ze erg snel zijn.

Optimaliseren door isoleren

Maar hoe achterhaal je de oorzaak van een traag component? In een ideaal scenario schaalt een component lineair, verdubbelt het aantal instanties dan zal de snelheid ook verdubbelen. In veel gevallen zal de hardware van het systeem waarop de applicatie draait ervoor zorgen dat een lineare schaling net niet haalbaar is. Wanneer het veel afwijkt, wijst dit op een limitatie buiten het component.

Het vinden van deze limitaties, binnen het component en/of erbuiten is een kwestie van isoleren. Ik blijf doorgaan met het isoleren van delen van het component met externe connecties totdat de schaling nagenoeg linear was. Hierdoor vond ik de bottleneck.

Uiteindelijk moest ik de volgende optimalisaties uitvoeren voor Apache Cassandra en de PostgreSQL database:

1. Batch-writes voor de databases

Om efficiënt gebruik te maken van de database connectie is het handig om berichten niet één voor één weg te schrijven maar ze op te sparen en periodiek weg te schrijven.

2. Concurency voor Apache Cassandra

Bij speciale databases raad ik aan om eerst op te zoeken hoe zo’n database optimaal kan functioneren. In het geval van Apache Cassandra is concurency vereist om hoge snelheden te halen.

Het resultaat; 10.000 berichten per seconde

Inmiddels staat er een schaalbare applicatie die op een snelle en efficiënte manier data analyseert en verwerkt. Door het gebruik van slimme frameworks, efficiënte databases en schalende componenten kan deze dataverwerking nu 10.000 berichten per seconde verwerken. Daarnaast biedt het de gebruiker inzicht in de luchtkwaliteit en het aantal metingen per vierkante kilometer.

Ambrero IoT blog - Screenshot applicatie

Een bijkomend positief resultaat… ik heb een 9 behaald met mijn afstudeeropdracht!

Tips

  • Veel data betekent niet direct Big data!
  • Kies bij voorkeur voor bekende Big data frameworks/databases voor de beste ondersteuning maar onderzoek de keuze hierin.
  • Speciale frameworks/databases vereisen vaak een andere manier van werken, onderzoek dit.
  • Verdeel je applicatie in componenten en zorg ervoor dat componenten onafhankelijk van elkaar kunnen schalen voor efficiënte schaling.
  • Door te isoleren kom je erachter wat de bottlenecks van je applicatie zijn.
  • Blijf optimaliseren totdat een component nagenoeg linear schaalt.

Arnout Schekkerman
Eindejaarsstudent Technische Informatica – Hogeschool van Amsterdam

ambrerosoftware