Met de komst van virtualisatie zijn we in de positie gekomen dat we steeds efficienter gebruik kunnen maken van reken-, opslag- en netwerkcapaciteit. Hypervisors beloofden ons dat de verspilling omlaag zou gaan en dat servers wel tot 70 tot 80 procent benut zouden worden. De introductie van deze abstractielaag bovenop bare metal was pure winst.
Waar deze mogelijkheid als eerste werd gewaardeerd door de softwareontwikkelaars – en testers binnen organisaties, geldt hetzelfde feitelijk voor de abstractielagen die direct of indirect het gevolg zijn van het concept virtualisatie. Ook de cloud was een welkome aanvulling voor developers en hetzelfde kan gezegd worden van containers, om maar niet te beginnen over serverless computing. Deze abstractlagen dienen vrijwel zonder uitzondering om sneller tot een resultaat te komen en om efficiënter gebruik te maken van de (hardware)resources.
Tegelijkertijd vindt er een omgekeerd effect plaats, namelijk dat er (onnodig) veel overhead gecreëerd wordt. Veel capaciteit wordt opgeslurpt door de extra lagen in een hedendaagse it-infrastructuur. Hieraan liggen twee oorzaken ten grondslag:
– Er is steeds meer opslag-, reken-, en geheugencapaciteit beschikbaar, en de kosten daarvan gaan omlaag. Dat betekent dus dat ontwikkelaars ‘makkelijker’ omgaan met die resources.
– Door het gebrek aan behoefte aan optimalisaties, is er meer ruimte voor abstractie, ook voor ontwikkelaars. ‘Vroeger’ was het een uitdaging om programmatuur zo efficiënt en klein mogelijk te maken. Er waren (en zijn) competities om met zo min mogelijk resources zo veel mogelijk te doen. (Lees: https://www.theverge.com/circuitbreaker/2016/5/11/11656690/fermi-paradox-demoscene-explore-space-64k)
Die motivatie is grotendeels weg, en aangezien ontwikkelaars (gelukkig) vaak lui zijn, worden steeds meer taken gestandaardiseerd en kunnen programmeurs zich beroepen op libraries, toolkits en ontwikkelframeworks. Daarmee is zeker het doel van een kortere ontwikkelcyclus gediend. Aan de andere kant… Die frameworks blijven groeien en leveren uiteindelijk overhead op overhead op, waardoor operating systems en applicaties steeds meer ‘fluff’ bevatten. Een kleine illustratie; het meest recente iPhone IOS operating system is 9gb groot. Vergelijk dat eens met Windows 95 (ja, dat heb ik nog meegemaakt), waarvoor je destijds met 20mb al een voldoende ruimte had. Naast de overhead die abstractielagen met zich meebrengen, is er ook nog de ‘lock in’. Als gebruiker van een sterk geabstraheerde it-ifrastructuur ben je gebonden aan de mogelijkheden én de beperkingen van de onderliggende platformen.
Mijn punt is, dat organisaties moeten nadenken waar het zin heeft om abstractie toe te passen – en in welke vorm. Dus: waar kan de complexiteit verminderd worden, en hoe kunnen it-ers nadenken over of dingen kleiner en efficiënter ingericht kunnen worden. Een ‘kale’ machine heeft geen overhead voor virtualisatie, container-management en andere zware management tooling en servers. Wel zal er veel meer kennis nodig zijn op specifieke onderdelen, die zorgen dat het bare metal-systeem lastiger te managen is.
Die balans vinden is belangrijk. Zo is serverless computing goed toe te passen voor tijdelijke inzet van middelen om te testen en om te spelen, maar niet voor video transcoding. Daar is bare metal nog steeds de beste oplossing, omdat daarmee de beste performance gehaald wordt. Daarnaast is het zo, dat de beste optie voor een organisatie afhankelijk is van de fase waarin deze zich bevindt. Netflix begon bijvoorbeeld met een eigen serverpark en migreerde naar een AWS infrastructuur. Dropbox deed het omgekeerde.
De keuze voor de meest geschikt infrastructuur en de mate van abstractie is gekoppeld aan de kernactiviteit van de organisatie, de opbrengst van de it-er versus die van de abstractielaag en de keuze schaalbaarheid versus controle.
In de praktijk zullen veel middelgrote en grote ondernemingen richting een hybride infrastructuur op basis van bare metal, cloud en andere varianten bewegen. Daarbij gaan interconnects een steeds belangrijkere rol spelen om de verschillende onderdelen soepel met elkaar te laten communiceren. Technisch is dat al goed te realiseren door de komst van orchestratie-tooling die bare metal en cloud aanspreekt op dezelfde manier, waardoor je keuzes kunt maken, en applicaties kunt verplaatsen naar waar deze het beste renderen.
Het is belangrijk om ontwikkelaars en beheerders scherp te houden en uit te dagen om onnodige overhead, ook op infrastructuur-niveau, te vermijden. Ook al is een traditionele it-infrastructuur minder ‘cool’ dan cloud, container of serverless.
