Du har hört talas om uppskalning, men hur är det med nedskalning? Tänk dig att du har en applikation med tusentals användare uppkopplade samtidigt efter en stor marknadsföringskampanj. Du har planerat din infrastruktur så att den kan växa med efterfrågan. En trafikökning varar dock inte för evigt. Om du inte planerar ordentligt kan du bli kvar med massor av onödig infrastruktur efter rusningen, och om du inte använder den gör de extra servrarna ingenting annat än att kosta dig pengar.

Lösningen på detta problem är att göra din arkitektur elastisk såväl som skalbar – men vad exakt är elasticitet inom molntjänster?

Vi granskar noggrant nya inlägg från vår community en efter en för att se till att de uppfyller högkvalitativa design- och funktionalitetsstandarder.

Ett exempel på denna situation är om din webbapplikation visas på en webbplats som Hacker News eller Product Hunt. När detta händer är det troligt att du får en plötslig trafikökning. Om du inte kan skala upp är det troligt att din applikation kommer att lamslås under belastningen. Resultaten kan vara otroligt skadliga för ditt rykte – om folk inte kan använda din webbplats kan de inte se vad du har att erbjuda.

Skalbarhet kontra elasticitet

Elasticitet omfattar möjligheten att skala upp men också möjligheten att skala ner. Tanken är att du snabbt kan etablera ny infrastruktur för att hantera en hög trafikbelastning, som i exemplet ovan. Men vad händer efter den rusningen? Om du låter alla dessa nya instanser vara igång kommer din räkning att skjuta i höjden eftersom du kommer att betala för oanvända resurser. I värsta fall kan dessa resurser till och med ta ut intäkterna från den plötsliga rusningen. Ett elastiskt system förhindrar att detta händer. Efter en uppskalnings period kan din infrastruktur skalas ner igen, vilket innebär att du bara betalar för din vanliga resursanvändning och lite extra för perioden med hög trafik.