Få saker kan lyfta lagandan för ett utvecklingsteam som när en applikation blir viral. Det är en underbar känsla, i vart fall tills man får se räkningen från molntjänsten. Vissa utvecklare anser att hanteringen av kostnaden för driften av applikationerna är upp till devops-gänget. Kodare utvecklar mjukvaran och lämnar över den till någon annan som får ta på sig bekymret att betala för driften. Men det här är så långt från sanningen man kan komma.

Smarta utvecklare vet att deras beslut om hur saker ska kodas kan göra stor skillnad för företagets resultat. Svällande kod är långsammare och kräver mer molnresurser för att köras. Att välja bättre algoritmer och skriva tightare kod handlar inte bara om prestanda. Välskriven kod är billigare att köra.

Utvecklare ser inte alltid kopplingen. Det är enkelt att skriva kod för din egen maskin där kostnaden för arbetsminnet och diskutrymmet betalades när datorn köptes. Om du har två terabyte diskutrymme kanske du inte märker hur mycket lagring din kod använder. Om en ny algoritm tar dubbelt så lång tid att köra kanske din dator inte ens blinkar, och hur många märker några extra millisekunder? Men, det är så gott som säkert att om du dubblar beräkningsbehovet kommer det att synas på molnfakturan.

Modern datoranvändning i molnet excellerar i att konvertera nyttjandet av resurser till rader på en faktura. Duktiga molnutvecklare förstår att de har makten att fatta klokare beslut när de skriver sin kod. Det kan röra sig om så enkla saker som att köra en profilerare för att finna kodens prestandamässigt svaga punkter eller att undvika onödig datalagring för att minska minnesanvändningen.

Här kommer tolv sätt att strömlinjeforma din kod så att den blir mer lättviktig, snabbare och billigare att köra.

1. Skriv snabbare kod

De flesta utvecklare lägger inte speciellt mycket tid på att optimera sin kod. Om den kör på bråkdelen av en sekund på deras laptop så märker de inte om den går 20, 30 eller 300 procent långsammare över tid. Men dessa skillnader uppstår miljontals gånger på servern. Noggrann profilering kan flagga de långsamma delarna av koden, och att skriva om dessa delar kan reducera antalet instanser din applikation behöver.

2. Minska ditt fotavtryck i RAM

Hur mycket arbetsminne som nyttjas är en viktig parameter för prissättningen av molninstanser. I många fall dubblas kostnaden om du bubblar arbetsminnet. Programmerare kan minska fotavtrycket i RAM genom att undvika att hålla data i minnet. Vissa strömningsalgoritmer som Stream classes i Java är designade för att arbeta med stora datafiler utan att ladda in dem i minnet. Apache DataSketches-projektet genererar approximerade svar för komplex big data-statistik utan att ta upp hela arbetsminnet.

Som en bieffekt kan försiktig RAM-konsumtion även snabba upp dina algoritmer. Ibland kan operativsystemet börja avlasta data till disk genom nyttjande av virtuellt arbetsminne. Detta förhindrar krascher, men det kan också dramatiskt slöa ned dina program.

3. Minska upplösningen på bilder och video

Att använda en lägre upplösning på bilder och för video kan betala sig på många sätt. För det första blir det billigare att lagra dem. För det andra kommer alla avgifter för dataexfiltration att bli lägre. För det tredje kommer applikationen att framstå som kvickare för användarna.

Alla statiska bilder bör minskas till att börja med. Frågan hur mycket bilderna ska minskas har inget enkelt svar, men när den visuella kvalitén blir tillräckligt dålig kommer användarna att märka det. Att hitta den rätta avvägningen är en designfråga som vissa programmerare inte är beredda att ta på sig.

Vissa applikationer som använder uppladdade bilder kan även skapa mindre tumnagelbilder och bilder med reducerad upplösning efter att de tagit emot bilderna. Verktyg som ImageMagik och format som WebP har utvecklats för detta syfte.

4. Dumpa onödig data

Många utvecklare är digitala hamstrar som lagrar information bara för att den kan komma till nytta i framtiden. De fyller tabeller med oändliga kolumner och tar aldrig bort raderna. Det extra datat kostar ingenting om du själv äger hårdvaran och hårddisken har har gott om utrymme. Men molnet tar betalt för allt. Kommer du verkligen behöva alla de där värdena i framtiden? Vill användaren ens ha så många detaljer? Om du dumpar en del av dina gamla data kommer du spara pengar på lagring och exfiltration.

5. Begränsa disklagringen

Att använda den lokala disklagringen i molninstanser är inte bara farligt, det kan även bli dyrt. Det lokala diskutrymmet är ofta utformat för att vara tillräckligt snabbt för att se till att operativsystemet kan köras effektivt. Många utvecklare skapar sin kod på en persondator med en eller flera terabyte lagringsutrymme.

Lagringen i molnmaskiner är sällan så billigt och lättillgängligt. Molntjänster tar ofta betalt för lagring rakt av utifrån storlek, så det bästa tillvägagångssättet är att använda så lite lagring som möjligt. Fundera på hur du kan minimera inte bara de temporära filer som din applikation skapar, utan också de systembibliotek och mjukvarupaket du behöver använda.

6. Rensa dina loggar

Loggfiler är toppen för att identifiera problem och hitta buggar under tiden mjukvaran utvecklas, men när den väl är satt i produktion behöver du inte behålla dem alla. All denna extra information täpper till antingen den lokala disken eller objektlagringen. När du utformar loggsystemet kan du konfigurera det så att det tar bort loggar med jämna mellanrum. Många loggpaket likt Log4j kan konfigureras så att de sparar minimalt antal loggar och ta bort dem i ett rullande schema.

7. Kör serverlöst

Prisplaner för serverlösa arkitekturer fakturerar endast när din kod körs, vilket kan bespara dig en hel del när arbetslasterna är intermittenta. Även applikationer med en konstant ström av användare har mer dötid än du kanske tror.

Många prisplaner för serverlös arkitektur belönar noggrann kodning och mycket höga prestanda med minimalt nyttjande av arbetsminnet. Faktureringsformeln räknar på responstiden i millisekunder och tar bara betalt för den tid som processorn är upptagen. Som utvecklare får du omedelbar återkoppling eftersom du kan spåra responstiden och direkt se hur förändringar i koden påverkar den.

Den serverlösa vägen är idealisk för mindre- och mer experimentella projekt och räkningen kan ofta bli så låg som några kronor per månad. Om vissa funktioner i din applikation bara körs ibland kan det vara vettigt att köra serverlöst.

8. Arkivera gamla data

När data blir äldre blir de också mindre efterfrågade. Du kan förutse det här genom att utforma din applikation så att den migrerar äldre data till en billigare plats. Vissa molntjänster tar mycket mindre betalt för så kallad kall lagring som kan ta minuter eller till och med timmar på sig att leverera bitarna.

Andra moln som Wasabi eller Backblaze specialiserar sig på arkivering av Amazon S3-objekt och tar avsevärt mindre betalt än de stora molnleverantörerna. I vissa fall tar de inte ens betalt för dataexfiltration. Att avlasta data så snart de inte längre har hög efterfrågan kan vara extremt kostnadseffektivt.

9. Förenkla din CSS-layout

Om du tittat på HTML-taggar som genererats av vissa ramverk så vet du hur löjligt krånglig layouten kan bli. Det är bara en massa DIV-taggar nästlade i DIV-taggar hela vägen ned, vilket kostar pengar att generera och leverera. En webbdesigner jag känner skryter om att skära ned på bandbreddskostnaden för detta med 30 procent, bara genom att skapa en enklare layout och använda CSS på ett klokare sätt.

10. Bygg statiska sajter

Vissa ramverk som React kräver en hel del beräkningskraft, speciellt om de använder funktioner som rendering på serversidan. All denna kod driver upp månadskostnaden för molnet. Den motsatta filosofin är att skapa en statisk sajt som byggs av kostnadsfria block av HTML, CSS och Javascript som skickas upp ord för ord från ett mellanlager. Att använda ett leveransnätverk (CDN) kan ytterligare snabba upp leveransen genom att flytta mellanlagret närmare användaren.

Olika ramverk omfamnar denna statiska filosofi. Jekyll, Hugo, Gridsome och Pelican är bara några exempel på verktyg som paketerar allt ditt innehåll i en uppsättning kompakta och oföränderliga filer. Du kan fortfarande bygga in personalisering i sidorna med hjälp av AJAX-anrop, men lejonparten av sajten genererar endast liten last på servrarna.

11. Externalisera beräkning och lagring

Allt eftersom webbläsarna blir mer kraftfulla gör vissa ramverk det enklare att flytta mer beräkning direkt till klienten. Bra Javascript- eller Webassembly-kod kan trycka ut mer av lasten till användarens maskin och bort från dina molnservrar.

Vissa utvecklare reducerar deras molnlager till knappt mer än en databas och lite affärslogik för att ta hand om autentisering. En vän till mig kör allt med statisk HTML och en version av PostgreSQL för serversidan med inbyggda procedurer som skickar ut JSON.

Webbläsare har också mer utvecklade möjligheter att lagra information lokalt genom standarder som HTML Web Storage och W3C Indexed Database API. Det handlar inte längre bara om korta strängar och kakor. Denna data är snabbare tillgänglig eftersom den inte färdas över internet och den ger användarna lite tröst i att veta att deras data inte lagras i en centraliserad, hackbar databas. Varför betala för datalagring och -exfiltration när data kan kostnadsfritt leva i användarens dator?

12. Utse en kostnadsingenjör

Vissa utvecklare specialiserar sig på att ta hand om databaser. Andra gillar att skapa snygga intryck med väldesignade framsidor. Nu när kostnaden för molntjänster är så flexibel har vissa team officiellt utsett en ”kostnadsingenjör” som hanterar kostnader och effektivitet.

En kostnadsingenjörs primära fokus är att se till att applikationskod körs renare, snabbare, lättare och därmed billigare. Att göra denna uppgift till en del av någons jobb är att skicka en signal om hur viktigt det är att hantera kodkostnad som en del av utvecklingsteamets roll och ansvar.