Size matters

Wellicht een herkenbaar scenario: je baas is naar een conferentie geweest en komt enthousiast terug. 'Wat ik nu gezien heb … zoiets wil ik ook graag voor onze organisatie!' Uiteraard sta je open voor verbetering en vernieuwing dus ga je vragen wat hij gezien heeft. Enige tijd later mag jij aan je baas uit gaan leggen dat wat hij gezien heeft niet haalbaar is. Waarom niet? Simpelweg omdat 'size matters'!

Wanneer je aan je baas gaat vragen wat hij gehoord en gezien heeft, passeren de bekende buzzwords als devops, continuous integration (ci) en whatever as a service de revue. De genoemde succesverhalen uit de conferentie waar hij was staan of vallen uiteraard met de invulling hiervan.

Continuous integration (ci)

Eén van de gedachtegangen achter ci is dat je snel terugkoppeling krijgt van de door jou aangebrachte wijzigingen op het source-code archief. Vaak wordt gesproken over vijf à tien minuten.

Deze tijdsindicatie wordt vaak genoemd, maar wat ik bijna altijd mis is de context. Over hoeveel regels broncode praten we hier; hoe groot zijn de deployment packages, wat voor rekencapaciteit heb je tot je beschikking, et cetera.

Daar waar de één praat over een deployment van enkele MB’s, heb ik afgelopen jaren in een omgeving gewerkt waar we in GB’s denken. En alhoewel het aantal regels source code (loc) misschien niet altijd een goede indicatie is, kun je op je klompen aanvoelen dat het bouwen van een product van 15 Mloc meer tijd gaat kost dan een app van, pak’m beet, 50 Kloc.

Dit wil overigens niet zeggen dat de concepten van ci niet bruikbaar zijn in grote omgevingen. Echter, sommigen staren zich blind op de richtlijn van tien minuten in plaats van de bruikbaarheid.

Bij één van de projecten waarvoor ik gewerkt heb, werd alles op alles gezet om maar onder die tien minuten te blijven. Bouw-optimalisatie, snellere pc’s, meer geheugen, hdd’s vervangen door ssd’s. De volgende stap was het clusteren van alle pc’s om zo een gedistribueerde build te kunnen doen. Met het groeien van de hoeveelheid code heeft men uiteindelijk toch de tien minutenwens moeten laten varen. Op dit moment bouwt hun product op zo’n 150 cpu’s in parallel in een tijd van ongeveer twintig minuten.  Het ci-concept is nog steeds van toepassing, alleen is het iets minder continu.

Geheugengebruik

Binnen de realtime informatieverwerking waar ik de afgelopen vijftien jaar gewerkt heb, is één van de  kwaliteitscriteria het geheugengebruik, en dan in het bijzonder geheugenlekkages. Immers, een geheugenlekkage kan vroeg of laat het systeemgedrag beïnvloeden, wat vervolgens tot ongewenste situaties kan leiden.

Het was voor mij dan ook een nieuwe ervaring te horen dat daar in een groot deel van de webservices-ontwikkelingen niet of nauwelijks naar gekeken wordt. Reden is dat met de dagelijkse (of vaker) deployments het systeem altijd opnieuw opgestart wordt, waardoor een geheugenprobleem niet de kans krijgt zich te manifesteren. Op zich een valide argument. Vanuit de ontwikkelsnelheid gezien biedt deze keuze ook zijn voordelen, immers, de ontwikkelaar heeft een zorg minder, en hoeft ook niet te testen op eventuele geheugenlekken.

Trekken we dit door naar eerder genoemde getallen over de grootte van een product, dan komt 1 geheugenlek op 50 KLOC overeen met 300 lekkages op 15 MLOC. Het voorkomen van dit soort lekkages is derhalve dan ook een behoorlijk harde eis in sommige embedded producten die je niet kunt laten varen omwille van sneller ontwikkelen.

Cloud based solutions

In het verlengde van het geheugengebruik bieden cloud based applicaties natuurlijk uitstekende mogelijkheden om dynamisch op te schalen, mocht het geheugengebruik alsnog toenemen.

Maar laten we realistisch blijven, je kunt niet alles in de cloud draaien. Daar waar koppelingen met (specifieke) hardware nodig zijn, en vertragingen tot een minimum gereduceerd dienen te worden wil je de software zo dicht mogelijk bij het ‘ijzer’ hebben draaien.

Even het geheugen uitbreiden, zoals je in de cloud kunt doen, is dan ook vaak een uiterste maatregel in  de embedded wereld. Niet zozeer vanwege de kosten van een geheugenmodule, maar vooral ook vanwege de logistiek er omheen.

Je zou uiteraard ook nog kunnen overwegen om het bouwen van je software in de cloud uit te laten voeren, en het resultaat telkens terug te halen naar jouw omgeving om te testen.  Stel dat  je voor één product iedere tien minuten een installatiepakket van 4 GB zou kunnen genereren, en je draait als organisatie meerdere projecten in parallel, dan heb je aardig wat bandbreedte nodig om dit alles van en naar de cloud te transporteren.

Size matters … maar gelukkig niet altijd

Gelukkig bestaat de wereld niet alleen uit grote complexe embedded software-producten, en zijn de genoemde methodieken voor heel veel doeleinden zéér goed bruikbaar. De grote uitdaging is om te kijken welke concepten voor jou omgeving bruikbaar zijn, en eventueel met welke aanpassingen. Binnen je project ruimte krijgen voor het doen van zulke aanpassingen is een andere discussie, waarover ik wellicht in de toekomst nog een artikel ga schrijven.