"Keep it stupid simple", också känt som KISS-principen, är en princip som används för att beskriva en designprocess som fokuserar på enkelhet och att eliminera onödiga element. Det används vanligen inom mjukvaruutveckling för att säkerställa att koden som skrivs är läsbar och lättillgänglig. Dock, när det gäller viktiga aspekter som till exempel kostnader relaterade till molnet så verkar KISS-principen ha totalt glömts bort. Vem som helst som har använt AWS känner till detta allt för väl.

Hur blev det så här illa?

Varför är kostnad en sådan svår sak att greppa när det gäller AWS? Som den mest prominenta molnleverantören skulle man kunna tro att de skulle ha gjort det enkelt att begripa sin månadskostnad, men istället verkar det som att de medvetet har gjort det svårt för sina användare. En teori som ofta nämns är att kanske AWS använder sig av oklara priser för att försöka lura användare till att betala mer.

Personligen tror jag inte att detta är fallet. Om detta var sant så skulle det inte vara rimligt för AWS att lägga ner så mycket tid och energi på att skapa exempelvis kostnadsöversikter och "alerts". Men, oavsett vad anledning är, så är det värt att gräva djupare i eftersom det inte är ovanligt att jag hör från mindre bolag att de undviker molnet av den enkla anledningen att det är för svårt för dem att förutspå framtida kostnader.

Jag tror att någonting annat är i spel här, något mer komplext, något utan en tydlig lösning. Låt mig ställa läsaren en fråga vid det här tillfället: Hur mycket CPU använder du just nu på din personliga dator? 10 procent? 50 procent? Du behöver inte kolla, utan min poäng är snarare att det är oerhört svårt att uppskatta hur mycket CPU som krävs. På din personliga laptop kostar det förmodligen inte särskilt mycket, varken i elektricitet eller i allmänt slit på din dator, men ifall du har att göra med en superdator, så kan 50 % vara en fråga om flera miljoner dollar i kostnader.

Betala för det du använder?

"Pay for what you use" är en vanlig fras som ofta associeras med molnet. Detta är dock inte helt sant, utan en mer korrekt slogan hade varit något i linje med "pay for what you use or reserve". Detta är inte nyheter for någon som av misstag råkat skapa en EC2 i en oanvänd region och hittat den ett år senare. Med den nya sloganen i bakhuvudet, så kan du börja tänka på att optimera kostnaden för din applikation. För att att optimera dina kostnader i AWS behöver du minimisera mängden av reserverad data som inte används.

Vår genomgång för hur man optimerar sina AWS-kostnader

Hos oss på Altostruct har vi jobbat oerhört hårt med kostnadsoptimering och har kokat ner det till fyra steg som du kan följa för att direkt sänka dina kostnader.

1. Förstå ditt spenderande

"There is no such thing as a free coffee". Samma sak gäller för AWS tjänster. Ändringar kommer nästan alltid med någon form av kostnad, oavsett om det rör sig om timmar nedlagda på utveckling, prestanda eller användarupplevelsen. Därför är det första steget att identifiera och försöka förstå ditt spenderande. AWS erbjuder flera olika sätt att både analysera och visualisera ditt spenderande. Många tredje parter erbjuder kostnadserbjudanden för AWS, men vad vi har märkt är att använda Amazon QuickSight fungerar utmärkt som en inbyggd lösning. QuickSight fungerar oavsett storlek på projekt och ger dig en tydlig överblick.

Ytterligare ett hjälpsamt verktyg som kan hjälpa dig förstå vilken del av din applikation det är som driver upp kostnaderna är genom att använda "the built-in tagging system from AWS". Detta verktyg låter dig tagga resurser som senare kan användas för att kostnadsoptimera, vilket är extremt värdefullt om du arbetar med ett större projekt.

2. Rätt verktyg för rätt jobb

I nuläget erbjuder AWS över 200 tjänster. Å ena sidan är detta fantastiskt eftersom du ofta kan lita på att deras jobb håller när du bygger en applikation. Å andra sidan skulle man kunna argumentera för att detta är en av deras största brister. EC2, Fargate, LightSail och Lamda erbjuder alla enkla sätt att sätta upp en server, men skillnaden är att kostnaderna kan skilja dramatiskt mellan dem.

Här är en liten historia för att demonstrera hur att "tänka om" gällande en tjänst kan spara pengar. I ett våra projekt jobbade vi med en mikrotjänst som hämtade data varje natt. Den hämtade en hel del data och lagrade den i en annan tjänst. På grund av vissa tidsbegränsningar, så krävde just denna instans ganska mycket prestanda. När vi insåg att EC2 var oanvänd majoriteten av tiden, så insåg vi att Lambdas utlösare av en SQS kö skulle enkelt kunna hämta all data för en bråkdel av den nuvarande kostnaden. Efter denna implementation (som gjordes tack vare de tidigare nämnda tjänsterna), såg vi en drastisk minskning i kostnad, nämligen från 300 dollar till mindre än 4 dollar i månaden.

Tips: Om du är osäker på vilken tjänst du ska använda, tveka inte att fråga. AWS har utmärkt support med experter som är redo att svara på alla frågor du kan tänkas ha.

3. Automatisk uppskalning

När man nämner automatisk uppskalning tänker nog de flesta på att man skalar upp för att möta ett ökande användarbehov. Man kan dock argumentera för att en minst lika viktig aspekt av uppskalning är att det kan sänka dina kostnader. Genom att utnyttja automatisk uppskalning kan du dramatiskt minska mängden oanvända resurser. Du kan på sätt minska dina kostnader samtidigt som du fortfarande kan hosta en snabb applikation för dina kunder. Det ska sägas att automatisk uppskalning kan vara komplicerat att sätta upp, men det genererar ofta fantastiska resultat.

En sak att ha i åtanke när du implementerar någon form av automatisk uppskalning är faktumet att olika tjänster varierar en del beroende på hur svårt det är att implementera uppskalningen. Lambda erbjuder till exempel automatisk uppskalning från start. Detta jämfört med EC2 som kräver lite mer eftertänksamhet. En bra tumregel är att desto mer "skött" tjänsten är, desto lättare är det att sätta upp en form av automatisk uppskalning.

4. Lagra data

Slutligen ska vi sluta undersöka datakraft och istället vända blicken mot data. Det finns två sätt att sänka kostnaderna för lagrad data: Ta bort den eller ändra lagringssättet. Den första är ganska självförklarande: om du tar bort onödig data så behöver du inte betala för den. S3 erbjuder ett sätt att automatiskt ta bort data efter en viss tidsperiod via tjänsten storage lifecycle. Detta är ett otroligt bra verktyg ifall du har mycket timlig data (som t.ex. loggar) som inte behöver finnas kvar längre än en viss tidsperiod.

Om man inte har möjligheten att radera data, så är ett annat alternativ att ändra hur du lagrar den. Behöver du verkligen lagra all din transaktionella data i en databas? I många fall can data flyttas till ett annat format som t.ex. en datasjö, vilket kommer substantiellt sänka kostnaden.

Om du är osäker på hur du bör lagra din data så är en bra början att se över hur ofta du behöver tillgång till den. Om du behöver tillgång till den flera gånger om dagen kanske en databas är rätt val för dig. Om inte, så kanske en datasjö kombinerat med Redshift är en bättre lösning. Om du väldigt sällan behöver tillgång till den så kanske S3 glacier är den optimala lösningen.

Några sista ord

Som vi kan se är principen "Keep it stupid simple" långt ifrån sann när det gäller kostnader i molnet. Det finns ett flertal aspekter som behöver has i åtanke. Men goda nyheter, det finns hopp. Med rätt verktyg och eftertänksamhet gällande dina unika behov och efterfrågningar så är kostnadsoptimering väl inom räckhåll. En bra början kan vara att applicera de fyra steg som tagits upp i denna artikel. På så sätt är du på bra väg mot en ljusare, och framförallt billigare, framtid i molnet!