Moderne software draait vaak niet als één enkel, massief programma, maar als een verzameling kleine, onafhankelijke onderdelen die microservices worden genoemd. Deze onderdelen communiceren voortdurend met elkaar, zoals een team van specialisten die briefjes aan elkaar doorgeven om een complex probleem op te lossen. Om dit team soepel te laten verlopen, moeten de computers die hen hosten automatisch hun kracht aanpassen. Als er te veel mensen tegelijkertijd een website bezoeken, moet het systeem onmiddellijk meer werkers toevoegen. Als het verkeer afneemt, moet het werkers ontslaan om geld te besparen. Deze automatische aanpassing wordt autoscaling genoemd. Momenteel wachten de meeste systemen tot ze een probleem zien—zoals trage reactietijden—voordat ze reageren. Deze reactie duurt enkele minuten, een vertraging die aanvoelt als een eeuwigheid in de digitale wereld, wat gebruikers lag of fouten laat ervaren. Bovendien hebben de mensen die deze systemen beheren vaak geen duidelijk, direct overzicht van hoeveel geld elke specifieke aanpassing kost, wat het moeilijk maakt om prestaties af te wegen tegen het budget.

Een team van onderzoekers van Multimedia University in Maleisië heeft een nieuw systeem ontwikkend dat ontworpen is om beide problemen tegelijkertijd op te lossen. Ze noemen hun framework ST-KEDA. In plaats van te wachten tot het verkeer piekt en dan te reageren, probeert dit systeem de piek te voorspellen voordat deze plaatsvindt. Het houdt ook een lopende telling bij van de kosten voor elke actie die het onderneemt, waardoor het beslissingen kan nemen die geld besparen zonder snelheid op te offeren. De onderzoekers testten dit systeem op twee real-world voorbeelden van complexe software: een online winkel met elf verschillende services en een treinkaartjessysteem met achtenveertig services. Hun bevindingen tonen aan dat door vooruit te kijken en de financiële impact van elke beweging te begrijpen, het systeem de infrastructuurkosten met meer dan een derde kan verlagen en tegelijkertijd het aantal keren drastisch vermindert dat het hectisch werkers toevoegt en verwijdert.

De kern van het probleem ligt in de manier waarop huidige systemen zoeken naar problemen. Standaardtools monitoren de huidige werklast van de computer, zoals hoe druk de processors zijn. Wanneer de werklast een bepaalde lijn overschrijdt, beveelt het systeem meer computerkracht aan. Echter, de tijd die het kost om de piek op te merken, de behoefte te berekenen, een nieuwe computer te vinden, de noodzakelijke software te downloaden en de nieuwe werker op te starten, is aanzienlijk. In de tests van de onderzoekers duurde dit hele proces gemiddeld bijna vijf minuten. Tijdens die periode is het systeem overbelast en lijden gebruikers eronder. De nieuwe aanpak, ST-KEDA, verandert de strategie van reageren naar anticiperen. Het kijkt naar de geschiedenis van verkeerspatronen om te raden wat er in de volgende paar minuten zal gebeuren.

Om deze gissingen nauwkeurig te maken, breekt het systeem de complexe geschiedenis van het verkeer eerst af in eenvoudigere, begrijpelijke stukken. Stel je een lawaaierige opname voor van een drukke straat; deze bevat het gestage gezoem van het verkeer, het ritmische patroon van de spits en plotselinge, scherpe geluiden zoals een claxon. De onderzoekers gebruikten een wiskundige techniek om deze verschillende ritmes van de ruis te scheiden. Ze ontdekten dat door deze aparte patronen te bestudelen—de constante trends, de dagelijkse cycli en de plotselinge pieken—de computer het verkeer veel beter kon begrijpen dan door alleen naar de ruwe, chaotische data te kijken. Deze scheiding stelde de voorspellingsmotor in staat om de onderliggende structuur van de vraag te zien in plaats van alleen de chaos.

Het systeem gebruikt vervolgens een geavanceerd leermodel dat begrijpt hoe de verschillende onderdelen van de software van elkaar afhankelijk zijn. In een microservice-architectuur triggert het ene deel vaak een ander deel. Bijvoorbeeld, een gebruiker die op "kopen" klikt, kan een controle van de voorraad triggeren, wat vervolgens weer een betalingsproces trigt. Als het systeem een piek in "kopen"-klikken voorspelt, weet het dat de voorraad- en betaalservices ook meer kracht nodig zullen hebben, nog voordat die services tekenen van drukte vertonen. Door deze verbindingen in kaart te brengen, kan het systeem de gehele keten van services gelijktijdig voorbereiden. Dit voorkomt de lag die optreedt wanneer één deel klaar is, maar het volgende deel nog aan het opstarten is.

Cruciaal is dat dit systeem niet alleen om snelheid geeft; het geeft ook om de prijs. Cloud computing-diensten rekenen per minuut voor elke computerprocessor en geheoeneenheid die wordt gebruikt. De onderzoekers bouwden een laag in hun systeem die de kosten van elke schaalbeslissing in bijna real-time berekent. Waar traditionele facturen dagen kunnen duren voordat ze arriveren, schat dit systeem de kosten binnen enkele seconden na een wijziging in. Het weet precies hoeveel een nieuwe computerinstantie de komende uur zal kosten. Hierdoor kan het systeem een afweging maken: het kan besluiten om geld te besparen door het aantal werkers iets lager te houden, waarbij een zeer kleine kans op een vertraging wordt geaccepteerd, of het kan meer uitgeven om perfecte snelheid te garanderen. De onderzoekers testten een instelling waarbij het systeem prioriteit gaf aan het besparen van geld, en het slaagde erin de totale kosten voor het draaien van de online winkel met 34,7 procent te verlagen.

De resultaten van de tests waren opmerkelijk. Vergeleken met het standaard reactieve systeem verminderde de nieuwe aanpak de tijd die nodig was om zich aan te passen aan nieuw verkeer van bijna vijf minuten naar slechts acht seconden. Deze snelheid betekende dat het systeem zelden achterliep. De onderzoekers maten ook zoiets als "flapping", wat gebeurt wanneer een systeem overreageert, te veel werkers toevoegt, ze vervolgens onmiddellijk weer verwijdert, en ze dan weer toevoegt. Dit constante schakelen is verspillend en onstabiel. Het nieuwe systeem verminderde dit chaotische gedrag met 96,6 procent, wat zorgde voor een veel soepeler verloop. Wanneer het systeem de mogelijkheid kreeg om kostenoverwegingen te negeren en zich alleen op prestaties te richten, daalde het aantal trage reacties naar slechts 2 procent, een significante verbetering ten opzichte van de 8 procent van het standaard systeem.

De studie onthulde ook dat de specifieke componenten van hun ontwerp allemaal noodzakelijk waren. Wanneer ze de mogelijkheid om verkeerspatronen af te breken verwijderden, werden de voorspellingen minder nauwkeurig. Wanneer ze het begrip van hoe de services met elkaar verbonden waren verwijderden, faalde het systeem in het tijdig voorbereiden van de downstream-delen van de keten. En wanneer ze de kostenregistratie verwijderden, kon het systeem niet langer de slimme afwegingen maken die leidden tot dergelijke aanzienlijke besparingen. De onderzoekers vonden dat de beste balans werd bereikt wanneer het systeem werd afgesteld om zowel om kosten als om snelheid te geven, waarbij een minimale toename in trage reacties werd geaccepteerd om enorme financiële besparingen te realiseren.

Dit werk demonstreert dat het beheren van complexe softwaresystemen niet een spel van achtervolgen hoeft te zijn. Door een diep begrip te combineren van hoe verkeerspatronen evolueren, hoe verschillende softwareonderdelen op elkaar leunen en exact hoeveel elke beslissing kost, is het mogelijk om deze systemen efficiënter en goedkoper te draaien. De onderzoekers testten hun ideeën op twee verschillende soorten applicaties, wat suggereert dat de aanpak robuust genoeg is om verschillende soorten werklasten aan te kunnen. Hoewel het systeem in een specifieke cloudomgeving is getest, bieden de principes van het voorspellen van de vraag en het integreren van kosten in de besluitvormingslus een duidelijk pad vooruit voor iedereen die grote digitale diensten beheert. De toekomst van cloud computing gaat niet alleen over het hebben van meer kracht, maar over weten precies wanneer en hoe je die kracht moet gebruiken.