De 10 kostsammaste misstagen att undvika när du migrerar dina DevOps-verktyg till AWS

Mitt team har väglett företag genom den här resan många gånger och sett vilka misstag som görs.

För att hjälpa dig att undvika samma misstag har jag sammanställt de vanligaste och vad du kan göra för att undvika dem. Läs vidare och skydda dig mot misstag som kan leda till att du:

• Betalar för tjänster du varken behöver eller använder

• Behöver mer underhåll längre fram

• Flyttar samma gamla ineffektiviteter till molnet

• Går miste om funktioner som kan göra vardagen betydligt enklare

• Tar på dig extra arbete som du enkelt skulle kunna få som en managed service

Betalar för tjänster du varken behöver eller använder

Behöver mer underhåll längre fram

Flyttar samma gamla ineffektiviteter till molnet

Går miste om funktioner som kan göra vardagen betydligt enklare

Tar på dig extra arbete som du enkelt skulle kunna få som en managed service

Låt oss sätta i gång.

1. Flytta databaser till AWS utan att undersöka alternativa databasmotorer

Att bara flytta din befintliga databas till AWS utan att undersöka alternativ är det enklaste när du migrerar till molnet. Du tar helt enkelt din befintliga databas och flyttar den till molnet precis som den är.

Men det kan vara ett kostsamt misstag, eftersom du ofta kan använda andra databaser utan licenskostnader.

Ett exempel

Säg att du har en Microsoft SQL Server-databas. Genom att i stället använda en AWS-hanterad databastjänst som heter RDS kan du potentiellt spara tiotusentals dollar per år på bara en server.

Gör så här i stället

Undersök om det går att flytta din dyra databas till ett billigare alternativ. AWS erbjuder verktyg som hjälper dig med detta. Personligen gillar jag AWS Babelfish för Aurora PostgreSQL. Verktyget låter din applikation kommunicera med en AWS Aurora PostgreSQL-databas, även om applikationen har skrivits för Microsoft SQL Server, med små eller inga kodändringar.

AWS har även andra verktyg som hjälper dig med databasmigrering, till exempel AWS Schema Conversion Tool. De AWS-hanterade databaserna förvaltas helt av AWS, vilket frigör tid för dig, och de har dessutom många andra fördelar.

2. Migrera servrar till AWS som EC2-instanser utan att utvärdera vilka AWS-tjänster som kan användas

Migrera inte till EC2 om en lämplig managed eller serverless-tjänst kan göra samma jobb utan att du behöver underhålla och patcha en server. Minska komplexiteten när du kan.

Ett exempel

Om du använder en AWS RDS-databas sköter AWS patchning och redundans, om du aktiverar alternativet. Det finns förstås undantag som du behöver utvärdera.

Du riskerar att slösa pengar och resurser som hade kunnat användas bättre på annat håll. Tänk dig en tjänst i molnet som du aldrig behöver patcha, uppgradera eller underhålla, men som ändå kan utföra jobbet.

AWS erbjuder många managed services som kan göra din vardag enklare, och att inte utvärdera dem är ett misstag.

Gör så här i stället

För att undvika detta bör du titta på vilka managed och serverless-tjänster AWS erbjuder som kan göra din workload enklare att hantera. Se till exempel vad det skulle innebära för dig att använda managed databaser från AWS eller ett serverless Kubernetes-kluster från AWS.

Använder du en meddelandekötjänst? AWS har några olika managed lösningar som du kan överväga, vilket innebär att du inte behöver hantera några servrar för detta.

3. Att inte hantera dina kostnader

AWS kan snabbt bli dyrt om du inte övervakar kostnaderna noga. Kanske har dina utvecklare startat några dyra servrar för ett test och glömt att avsluta dem, eller så raderar du inte backuper på rätt sätt och kostnaderna fortsätter att öka.

Ett exempel

Tänk dig att du efter några månader inser att dina månadskostnader har ökat stadigt, men att ökningarna varje månad varit för små för att du skulle märka dem. Du upptäcker att resurser har blivit liggande och kostat pengar, när de egentligen borde ha raderats.

Nu har du en månadskostnad som är betydligt högre än tidigare eftersom du betalar för saker du inte använder.

Gör så här i stället

AWS har verktyg som kan hjälpa dig att övervaka dina kostnader och även varna dig om något verkar avvikande. Men du måste aktivera verktygen.

Det finns också tredjepartsverktyg som övervakar dina molnkostnader, ger dig rekommendationer och hjälper dig att hitta områden där du kan spara pengar.

Kanske har du några servrar som bara används måndag till fredag. Kan du stänga av dem över helgen för att spara pengar? Kom ihåg att du i AWS betalar för den tid som dina resurser körs. Om du stoppar en server betalar du alltså inte längre för den beräkningstiden.

En EC2 Windows-server är dessutom dubbelt så dyr som en EC2 Linux-server eftersom du betalar för en Windows-licens. Undvik om möjligt att använda Windows för att sänka kostnaderna.

Var inte rädd för att prova nya instanstyper, som AMD-baserade instanser eller AWS Graviton. AMD är generellt 5–10 % billigare än Intel, och du kan spara ännu mer genom att använda AWS Graviton om din applikation kan köras på ARM-processorer.

Benchmarka de olika instanstyperna med din applikation och se vad som fungerar för dig.

4. Att inte inse att kraven på instansstorlek kan förändras över tid

Vissa applikationer och tjänster använder inte auto-scaling, så du måste välja instanstyp och storlek. Men beräkningskraven för en server kan förändras över tid. Kanske hade en viss server hög belastning för några månader sedan, men har nu mycket låg belastning.

Det kan innebära att du betalar för en stor instans när en mindre skulle fungera utmärkt. Du betalar nu AWS mycket mer än nödvändigt, när något så enkelt som att minska serverns storlek kan halvera dina serverkostnader – eller sänka dem ännu mer!

Ett exempel

Kanske har du en AWS RDS-databas som du kan minska storleken på, eller en applikation som körs på en EC2-server och bara använder 10 % av de tillgängliga resurserna.

Gör så här i stället

Utvärdera dina instansstorlekar på nytt några gånger per år för att säkerställa att du inte betalar mer än du behöver. AWS har kostnadsfria verktyg för detta, och du kan även använda tredjepartsverktyg som hjälper dig att hantera instansstorlekar.

5. Att inte ta hänsyn till kostnaderna för dataöverföring

Dataöverföring kostar ofta pengar i AWS, beroende på källa och destination. Dataöverföring från internet till AWS är kostnadsfri, men det kostar när du skickar data, till exempel:

• från AWS till internet

• från en availability zone till en annan 

• till en annan AWS-region

från AWS till internet

från en availability zone till en annan 

till en annan AWS-region

Om du inte känner till detta när du börjar använda AWS kan du få en obehaglig överraskning när fakturan kommer. 

Ett exempel

Om du till exempel har en server on-premise som hämtar många terabyte data från AWS kan det bli dyrt.

Gör så här i stället

Uppskatta dina nätverkskostnader innan du börjar bygga. Kanske finns det ett bättre sätt att utforma din lösning. Kan servern som hämtar mycket data från AWS till on-premise flyttas till molnet?

6. Utvecklare driftsätter onödigt dyra tjänster och servrar

När du driftsätter en server eller tjänst i AWS är det mycket viktigt att dina utvecklare förstår kostnaderna för det de driftsätter.

Ett exempel

Om du driftsätter en Microsoft SQL Enterprise-server med 16 CPU-kärnor kostar den omkring 5 000 dollar per månad. Det finns många tjänster du kan driftsätta som kan konfigureras med stora instanser och kostsamma alternativ, till exempel mycket snabb men dyr lagring.

Gör så här i stället

Se till att dina utvecklare förstår kostnaden för det de driftsätter i AWS. I molnet är det enkelt att öka serverstorleken senare. Börja inte med en stor, överdimensionerad server som du kanske skulle göra on-premise.

Inför också varningar för oväntade kostnadsökningar, så att du kan upptäcka eventuella misstag innan det blir dyrt.

7. Att inte ha en solid och genomförbar plan

Gör en solid och genomförbar plan – hoppas på det bästa, men förbered dig på det värsta.

Ett exempel

Vissa företag börjar testa AWS, och det utvecklas till en POC. Den POC:en blir senare produktion. Nu har du sannolikt utvecklings-, validerings- och produktionsmiljöer blandade – och en riktig röra på händerna.

Gör så här i stället

Gör en plan och bygg en landing zone. Du behöver en stabil grund för att bygga och utveckla din miljö. Det är dyrare i början, men du slipper bygga om miljön senare. I slutändan sparar du pengar och får en säkrare miljö som följer beprövade metoder.

8. Att bli för fäst vid dina servrar/tjänster

Servrar och tjänster blir ofta kvar för länge eftersom det kanske finns något där som du behöver i framtiden.

Det gör att du betalar mer än nödvändigt. Ser du till kostnaderna över ett år blir det vanligtvis mycket pengar.

Namnge inte och bli inte för fäst vid dina servrar/tjänster. De är förbrukningsvaror. Våga avveckla dina värdefulla resurser.

Gör så här i stället

I AWS går det snabbt att återställa en server från en backup. Om du har servrar som du vill ta bort, vänta inte för länge med att avsluta dem du inte använder. Ta en backup och ta bort servern. För varje timme som servern fortfarande körs tillkommer onödiga kostnader.

9. Att inte förstå att (nästan) allt kostar något

En liten kostnad kan verka obetydlig, men när alla små kostnader läggs ihop blir det en stor räkning.

Ett exempel

Elastic IP är kostnadsfritt om det är kopplat till en NIC-/EC2-instans. Annars tillkommer kostnader varje timme.

• Några EBS-volymer som ligger kvar

• Några gamla snapshots

… var och en av dessa saker kanske inte kostar mycket, men tillsammans kan de snabbt uppgå till tusentals dollar.

Gör så här i stället

Se till att ta bort resurser så snart de inte längre behövs. Ett tredjepartsverktyg kan också hjälpa till genom att påminna dig om oanvända resurser.

10. Att inte inse att migreringen är ett utmärkt tillfälle att städa upp

Även om det kan vara lockande (och enklare) att flytta din nuvarande on-prem-miljö till molnet som den är, är detta ett perfekt tillfälle att städa upp och ta bort eller konsolidera onödiga eller överdimensionerade lösningar.

Ett exempel

Du kanske migrerar servrar som du inte ens använder. Kanske kan du bygga lösningen på ett annat sätt i AWS och därmed sänka kostnaderna betydligt.

Gör så här i stället

Passa på att ta bort servrar som inte behövs och optimera din miljö när du flyttar till molnet. Det här hänger ihop med några av de tidigare punkterna, men eftersom det är så viktigt (och så ofta förbises) förtjänar det en egen plats på vår lista.

Sammanfattningsvis

Efter att ha hjälpt så många företag att migrera sina DevOps-verktygskedjor till AWS har vi sett allt. Förhoppningsvis kan jag, genom att dela dessa vanliga misstag, hjälpa dig att undvika att lära dig läxan den hårda vägen.

Med Otto von Bismarcks ord:

”Endast en dåre lär sig av sina egna misstag. Den vise lär sig av andras misstag.”

Lycka till med migreringen!

Lyssna på podcasten här