Rapid elasticity (snelle elasticiteit) is het vermogen van de cloud om capaciteit snel, vaak automatisch, beschikbaar te stellen en weer vrij te geven, zodat resources meegroeien en meekrimpen met de vraag. NIST noemt het een van de vijf essentiële kenmerken van cloud computing. Voor de gebruiker lijkt de beschikbare capaciteit onbeperkt: hij kan elke hoeveelheid op elk moment afnemen en weer teruggeven.
Belangrijkste punten
- NIST SP 800-145 definieert het als capaciteiten die "elastisch kunnen worden toegewezen en vrijgegeven, in sommige gevallen automatisch, om snel naar buiten en naar binnen te schalen in verhouding tot de vraag" (eigen vertaling).
- Beide richtingen tellen. Capaciteit vrijgeven als de vraag daalt, maakt van elasticiteit een kostenbesparing.
- In de praktijk gebeurt dit met auto scaling: metrics, schalingsbeleid, minimum- en maximumgrenzen en een load balancer.
- Elasticiteit is kortetermijn en automatisch. Schaalbaarheid is het vermogen om op lange termijn te groeien. Een cloudworkload heeft beide nodig.
- Het werkt alleen als de applicatie ervoor is gebouwd: stateless servers, externe opslag van sessies en een database die kan meekomen.
De NIST-definitie, woord voor woord
Het Amerikaanse National Institute of Standards and Technology schreef de definitie die de meeste studieboeken en certificeringsexamens gebruiken. In NIST Special Publication 800-145, The NIST Definition of Cloud Computing luidt die als volgt (het origineel is Engels, de Nederlandse vertaling eronder is van ons):
"Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time."
In het Nederlands: capaciteiten kunnen elastisch worden toegewezen en vrijgegeven, in sommige gevallen automatisch, om snel naar buiten en naar binnen te schalen in verhouding tot de vraag. Voor de afnemer lijken de capaciteiten die beschikbaar zijn voor toewijzing vaak onbeperkt en kunnen ze op elk moment in elke hoeveelheid worden afgenomen.
De andere vier essentiële kenmerken zijn on-demand self-service, brede netwerktoegang, resource pooling en measured service. Elk zinsdeel in de definitie heeft een praktische betekenis:
- "Toegewezen en vrijgegeven": capaciteit gaat zowel uit als terug. Een systeem dat alleen groeit, is schaalbaar maar niet elastisch.
- "In sommige gevallen automatisch": automatisering is gebruikelijk maar niet verplicht. Iemand die op "voeg vijf servers toe" klikt en ze binnen minuten krijgt, valt nog steeds onder de definitie.
- "Naar buiten en naar binnen": de definitie beschrijft horizontale schaling, het toevoegen en verwijderen van instances, en niet het vergroten of verkleinen van één machine.
- "In verhouding tot de vraag": capaciteit hoort de werkelijke belasting te volgen, niet een prognose van maanden geleden.
- "Lijken onbeperkt": de pool van de aanbieder is zo groot dat één klant zelden de rand haalt, al gelden accountquota nog steeds.
Hoe werkt het in de praktijk?
Cloudaanbieders leveren elasticiteit via auto scaling-diensten. AWS Auto Scaling "monitort uw applicaties en past de capaciteit automatisch aan om stabiele, voorspelbare prestaties te behouden tegen de laagst mogelijke kosten" (eigen vertaling). Azure en Google Cloud bieden gelijkwaardige diensten voor groepen virtuele machines, containers en databases.
Een typische opzet heeft vijf onderdelen:
- Metrics zoals cpu-gebruik, requests per target of wachtrijlengte, elke minuut of vaker verzameld.
- Beleid dat zegt wanneer er moet worden ingegrepen: de cpu rond 50% houden, twee instances toevoegen als de wachtrij een drempel passeert, of elke werkdag om 08:00 capaciteit toevoegen.
- Grenzen: een minimum om beschikbaar te blijven en een maximum om de kosten te begrenzen.
- Provisioning vanuit een template of image, zodat nieuwe instances identiek zijn en snel starten.
- Een load balancer die verkeer naar nieuwe instances stuurt zodra de health checks slagen en ze leegloopt voordat ze worden verwijderd.
Het Azure Well-Architected Framework van Microsoft wijst op het ontwerpgevolg: virtuele machines uitschalen "vereist een aparte load balancer, afhandeling van clientverzoeken en extern opgeslagen state" (eigen vertaling). Elasticiteit is net zozeer een ontwerpeigenschap van de applicatie als een functie van het platform.
Rapid elasticity versus schaalbaarheid
Schaalbaarheid zegt of een systeem meer belasting aankan als het meer resources krijgt. Elasticiteit zegt of het die resources snel en automatisch krijgt en weer vrijgeeft naarmate de belasting verandert.
| Schaalbaarheid | Elasticiteit | |
|---|---|---|
| Tijdsbestek | Groei op lange termijn | Minuten tot uren |
| Richting | Meestal omhoog | Naar buiten en weer naar binnen |
| Typische aanleiding | Bedrijfsgroei, nieuwe markten | Verkeerspieken, dagelijkse en seizoenspatronen |
| Belangrijkste voordeel | Groeien zonder herontwerp | Prestaties op de piek, lagere kosten buiten de piek |
Voor een overzicht van de opties voor grotere organisaties, waaronder auto scaling-groepen voor VM's, containers en serverless, leest u onze gids over elastische schaalbaarheid in cloud computing.
Voorbeelden
- Verkoopacties in de retail. Een webshop schaalt de web- en checkoutlaag uit voor een Black Friday-campagne en de week erna weer terug naar normaal.
- Seizoensbedrijven. De boekings- en webcamsites van een skigebied krijgen het meeste verkeer in een paar wintermaanden.
- Mediareleases. Een streaming- of nieuwsdienst voegt capaciteit toe als een populaire release of een nieuwsbericht een piek veroorzaakt.
- Batchanalyse. Een financieel team draait maandafsluitingsrapporten een uur op honderden cores in plaats van dagen op een paar servers.
- Ontwikkeling en test. Testomgevingen starten voor een belastingstest of pull request en worden daarna verwijderd.
Het seizoensgeval is echt bij Opsio-klant Branäsgruppen, een van de grootste skigebiedgroepen van Zweden, met tot 15.000 skiërs per dag in de piek. De on-premises VMware-omgeving moest voor elke vraagpiek met de hand worden opgeschaald en de prestaties daalden tot dat gebeurd was. Na de verhuizing naar AWS beschrijft de casus Branäsgruppen web-frontends, middleware en databaselagen die nu automatisch uitzetten en krimpen met de seizoensvraag.
Voordelen en grenzen
De voordelen zijn direct: u betaalt alleen tijdens de piek voor piekcapaciteit, gebruikers krijgen consistente reactietijden en niemand hoeft voor een campagne met de hand servers toe te voegen.
De grenzen zijn even praktisch:
- Opstarttijd. Nieuwe virtuele machines hebben tijd nodig om op te starten en warm te draaien. Zeer scherpe pieken vragen om speelruimte, vooraf opgewarmde capaciteit of serverless.
- De datalaag. Webservers schalen makkelijk, relationele databases niet. Plan read replicas, caching of een managed database die schaalt.
- Quota. Accountlimieten op instances of gelijktijdigheid kunnen het uitschalen stoppen. Verhoog ze voor bekende pieken.
- Kostenverrassingen. Een bug of botverkeer kan u snel laten uitschalen. Stel altijd een maximum en budgetmeldingen in.
- Licenties. Software die per server of per core wordt gelicentieerd, staat kortlevende instances mogelijk niet toe.
Heeft uw workload het? Een snelle check
- Kan elke afzonderlijke server worden beëindigd zonder dat gebruikers hun sessie of gegevens verliezen?
- Is er een schalingsbeleid met geteste minimum- en maximumgrenzen?
- Daalt de capaciteit na een piek echt? Bekijk de grafiek van het aantal instances van vorige maand.
- Is de database belastingsgetest bij piekverkeer, en niet alleen de weblaag?
- Zijn de servicequota hoog genoeg voor de grootste verwachte piek?
Als meerdere antwoorden "nee" zijn, wordt de workload in de cloud gehost maar is die nog niet elastisch. De teams van Opsio voor AWS managed service en cloud consulting beoordelen en verhelpen deze tekortkomingen als onderdeel van architectuurwerk.
Veelgestelde vragen
Wat is rapid elasticity in cloud computing?
Het is een van de vijf essentiële kenmerken van cloud computing volgens NIST: capaciteit kan snel, soms automatisch, worden toegewezen en vrijgegeven om met de vraag uit en in te schalen, en lijkt voor de gebruiker onbeperkt.
Wat is een voorbeeld van rapid elasticity?
Een webwinkel die op een gewone dag vier webservers draait, tijdens een verkoopcampagne automatisch naar twintig schaalt en na afloop weer terugkeert naar vier. De extra zestien servers betaalt de winkel alleen zolang ze draaien.
Wat is het verschil tussen elasticiteit en schaalbaarheid?
Schaalbaarheid is het vermogen om meer belasting aan te kunnen door resources toe te voegen, meestal op lange termijn. Elasticiteit is het snel, vaak automatisch toevoegen en verwijderen van die resources naarmate de vraag stijgt en daalt.
Is rapid elasticity hetzelfde als auto scaling?
Niet helemaal. Elasticiteit is het kenmerk, auto scaling is de meest gebruikelijke manier om het te leveren. Volgens de NIST-definitie gebeurt toewijzing "in sommige gevallen automatisch", dus snel handmatig schalen telt ook mee, maar in de praktijk automatiseren cloudteams het.
Waarom is elasticiteit belangrijk in cloud computing?
Omdat het de keuze wegneemt tussen betalen voor ongebruikte capaciteit en tekortkomen op de piek. U dimensioneert op de vraag van nu, schaalt uit als die stijgt en weer in als die daalt.
Gerelateerd lezen
Geschreven door

Hoofd Innovatie
Jacob leidt innovatie bij Opsio en is gespecialiseerd in digitale transformatie, AI, IoT en cloud-gedreven oplossingen die complexe technologie omzetten in meetbare zakelijke waarde. Met bijna 15 jaar ervaring werkt hij nauw samen met klanten om schaalbare AI- en IoT-oplossingen te ontwerpen, leveringsprocessen te stroomlijnen en technologische strategieën te creëren die duurzame groei en blijvende zakelijke impact stimuleren.
Redactionele richtlijnen: Dit artikel is geschreven door de hierboven vermelde cloudspecialist. We herzien het wanneer de technologie of regelgeving waarover het gaat verandert; de datums op deze pagina tonen de laatste update. Opsio is redactioneel onafhankelijk.