Die vraag spookte ook constant door ons hoofd toen we een nieuw ‘Controle Centrum’ ontwierpen voor Adésys. Deze fabrikant en leverancier van alarmmelders en telemetriesystemen levert onder de productnaam ‘Severa Webmeters’ alarmmelders die bijvoorbeeld iedere seconde een melding doorsturen naar een centrale server. Die informatie - over bijvoorbeeld de luchtvochtigheid in een ruimte of de windsnelheid op een bepaalde locatie - kan vervolgens via een webportal worden uitgelezen.
Waar één melder al een hele berg aan informatie kan genereren, geldt dat zeker voor duizend of tienduizend melders die iedere seconde een meetpunt afgeven. De uitdaging is dan om een platform te ontwikkelen dat de ‘stortvloed’ aan data kan verwerken en opslaan en overzichtelijk kan presenteren. En dan volstaat het niet om terug te grijpen naar de standaard methodieken en hulpmiddelen.
Een goed voorbeeld van een ‘nieuw gereedschap' is de database die wordt gebruikt voor de opslag van de gegevens, oftewel het opbouwen van het archief. Door de grote ‘record sets’ zou een relationele database - gebruikelijk in de webwereld - niet de juiste performance opleveren. Daarom is in dit geval gekozen voor een NoSQL-database (Riak). Om het opslaan van gegevens in goede banen te leiden, bepaalt een loadbalancer waar de melder een meetpunt af kan geven. De ontvangen meetpunten worden in een message queue (op basis van RabbitMQ) geplaatst zodat ze door verschillende andere onderdelen van het platform parallel verwerkt kunnen worden. Voor de robuustheid van het platform wordt in plaats van één fysieke server gebruikgemaakt van meerdere virtuele servers die draaien in de Elastic Compute Cloud van Amazon en elkaar kunnen opvangen. Hiermee is ook de verticale schaalbaarheid geregeld: een hogere belasting is eenvoudig op te vangen door meer virtuele servers in te schakelen. Hierdoor is het ‘Adésys Controle Centrum’ schaalbaar tot boven de honderdduizend melders.
Naast een NoSQL-database wordt ook nog gebruikgemaakt van een relationele database (RDS van Amazon) voor het opslaan van een subset van de data die wordt getoond in de ‘WebMeter Portal’. Bij het bouwen van de portal was de grote uitdaging om data overzichtelijk en realtime te tonen. Een overzichtelijke presentatie wordt gerealiseerd door de data aan de ‘achterkant’ van de portal te verwerken tot gemiddelde waarden. Om continu de actuele standen te laten zien, wordt gebruikgemaakt van een ‘single-page applicatie’ die is gebouwd met AngularJS van Google. Een dergelijke applicatie toont als het ware een dashboard binnen een webpagina waarop actuele waarden direct worden getoond. Dit kan worden vergeleken met de werking van bijvoorbeeld Gmail, waar een nieuwe mail direct wordt getoond zonder dat het nodig is om de pagina te verversen.
Het resultaat is een robuust en schaalbaar platform dat in staat is meldingen in realtime en overzichtelijk te presenteren; een resultaat dat is neergezet door gebruik te maken van ‘bleeding edge'-technologie die ook weer kan worden toegepast binnen nieuwe projecten. Tot op het moment natuurlijk dat er weer een beter hulpmiddel beschikbaar is voor de oplossing van een probleem. Want wie niet alert is op nieuwe ontwikkelingen heeft binnen de kortste keren weer een hamer in handen.
Reacties
Misschien handig als in de buzzword bingo even de definitie van 'Bleeding Edge'gegeven wordt:
Bleeding edge technology is a category of technologies so new that they could have a high risk of being unreliable and lead adopters to incur greater expense in order to make use of them. The term bleeding edge was formed as an allusion to the similar terms "leading edge"
Ik weet dat stilstand achteruitgang is maar roekeloosheid kan leiden tot ondergang.
Ewout, dat klopt toch ook.
Tom doet zijn best een een snelle en stabiele database op te tuigen.
En om vervolgens zowel performance als reliability onderuit te halen maakt het gebruik van zoiets totaal zinloos als rabbitmq. je zou haast denken dat het hele spul met dotNet bij elkaar geklikt is.....mischien wel java.... brrrr koude rillingen en zo.
Leuk artikel dat wel ;) en eens een leuke ICT toepassing die niet al eens ooit door het halve dorp is uitgevoerd.
robuust en bleeding edge is inderdaad nogal strijdig.
@pascal
Laten we eerst eens afwachten of sprake is van hier en daar een ongelukkige woordkeuze.
In dit geval lijkt de term “bleeding edge” inderdaad wat ongelukkig gekozen te zijn. We hebben hier vooral mee willen uitdrukken dat we gebruik maken van de nieuwste technieken. Maar uiteraard met inachtneming van de risico’s. De technologie is inmiddels wel behoorlijk volwassen.
Wat ik veel belangrijker vind aan het verhaal is dat we hier mee uit proberen te drukken dat je als klant er bij ons op kunt vertrouwen dat we op zoek gaan naar de juiste technologieën en methodieken om een vraag op te pakken en hierbij ook de relatief nieuwe technieken niet schuwen. Wij gaan niet uit van een zelf ontwikkeld product, waarmee we alles “op kunnen lossen” door voor de basisproduct maatwerk te ontwikkelen. Wij kunnen onafhankelijk adviseren over een passende oplossing.
Wat we regelmatig zien is dat bedrijven in eerste instantie begonnen zijn met het baseren van hun product of dienstverlening op een softwareproduct van een ander bedrijf. Een oplossing die op basis van een bestaand product gerealiseerd wordt, is over het algemeen op de korte termijn goedkoper, omdat er niet meer betaald hoeft te worden voor de ontwikkeling van deze basis. In de meeste gevallen bestaan de kosten uit een licentie op het gebruik en het benodigde “maatwerk” om de basis geschikt te maken. Hier wordt door de leverancier over het algemeen graag aan meegewerkt.
In veel gevallen veranderen na verloop van tijd de behoeften van het bedrijf en is er meer maatwerk nodig. Hier gaat het vaak al wringen. Voor dit maatwerk worden vaak hoge kosten berekend en zijn de leveranciers vaak niet op toegerust en in sommige gevallen niet in geïnteresseerd, omdat het niet in de roadmap past of dat de capaciteit ontbreekt. Wat ooit een voordeel leek, keert zich na enige tijd al weer tegen je.