Cloud-native, IaaS, PaaS och SaaS förklarat

Molnet är ingen plats uppe i himlen. Det är frågan om hur mycket av maskinen du driver själv och hur mycket någon annan gör det.

Jag jobbar i skärningspunkten mellan produkt, GTM och AI som mjukvaruentreprenör. I samma stund som AI-agenter kör inne i ditt produktteam slutar frågan vara teori. Den avgör var dina agenter jobbar och hur snabbt.

Det här tar du med dig:

• Vad IaaS, PaaS och SaaS faktiskt betyder, i en mening per lager.
• Varför gränserna mellan dem sedan länge suddats ut.
• Varför molnarkitektur spelar roll när agenter kör på din sida.

Min tes: de tre modellerna är tre lager i samma stack. Du behöver bara veta vilket du driver själv.

🧨 Tre lager, en stack

Den officiella definitionen kommer från NIST. I vardagen räcker tre enkla meningar.

IaaS, Infrastructure as a Service. Det understa lagret. Du hyr bara hårdvaran: beräkningskraft, lagring, nätverk, virtualiserat i ett datacenter. Operativsystemet och allt ovanför installerar du själv. Du hyr IT-infrastruktur och underhåll, inget annat.

PaaS, Platform as a Service. Mellanlagret. Här är det inte IT-administratören som kallas in, utan utvecklaren. Leverantören tillhandahåller miljön som ramverk och bestämmer programmeringsspråk, gränssnitt och datalagring. Du styr bara din egen kod och data, inte infrastrukturen under.

SaaS, Software as a Service. Det översta lagret, det bygger på de andra två. Du köper inte mjukvaran och du installerar den inte. Du hyr den som tjänst. Oftast räcker en enhet med internetuppkoppling och en webbläsare. Billig hårdvara på din sida, full beräkningskraft i datacentret.

En vardagsbild hjälper. IaaS är råytan: du hyr väggarna och inreder allt själv. PaaS är den utrustade verkstaden: du tar bara med ditt eget projekt. SaaS är den färdiga apparaten på abonnemang: slå på och använd.

🛠️ Varför gränserna suddas ut

Den prydliga lagertårtan är teori. I praktiken har gränserna suddats ut i åratal. Redan innan Azure erbjöd virtuella maskiner 2012 var det ofta inte längre tydligt var IaaS slutar och PaaS börjar.

Riktiga projekt frågar inte efter modellen. De buntar ihop förmågor: ett API här, en komponent där, en tjänst ovanpå. Det är inte IaaS eller PaaS. Det är IaaS och PaaS och SaaS, ofta i samma projekt. Ovanpå det kommer hybridupplägget, som suddar ut även gränsen mot egen hårdvara on premises.

I början fick man fortfarande förklara och försvara PaaS. Snart handlade det bara om riktiga utvecklingsprojekt. Mognaden kring hybridmoln växte år för år. Där står vi i dag: inte en modell, utan en mix du sätter ihop med avsikt.

Dessutom sitter hela produktkategorier numera mellan lagren. Hanterade databaser, containertjänster, serverless-funktioner. Alla hybrider där leverantören tar på sig mer än vid rå infrastruktur och dikterar mindre än en hel plattform. Lagermodellen är användbar ändå. Den besvarar den enda frågan som räknas: vem driver vad.

🧭 Beslutspromenaden: ett bolag, tre svar

Ta ett B2B-mjukvarubolag med 30 personer. En produkt, ett litet team, ingen egen driftavdelning. Det är ett bra testfall för valet, lager för lager.

Rå infrastruktur är rimlig när du verkligen behöver kontroll. Säg att dina kunder i avtal bestämmer var data ligger och vem som har åtkomst. Eller att din produkt har runtime- eller hårdvarukrav som standardplattformar inte täcker. Då hyr du maskiner och driver resten själv. Priset: du behöver folk som kan och vill göra det. I bolaget med 30 personer betyder det snabbt att 2 av dem inte gör något annat än infrastruktur.

En plattform är rimlig när din flaskhals är utveckling, inte drift. För vårt bolag är det normalfallet. Teamet skriver kod, plattformen sköter servrar, skalning och patchar därunder. Du ger upp kontroll och får tillbaka fart. För ett produktteam utan egen drift är det nästan alltid rätt startpunkt.

Färdig mjukvara är rimlig för allt som inte differentierar dig. Mejl, CRM, systemet för din kunddata, bokföring, supportverktyget: hyr, bygg inte. Bolaget vinner inte en enda kund på att driva sin egen ärendehantering. Varje timme där är en timme som inte läggs på produkten.

Beslutspromenaden är alltså ingen trosfråga. Det är en fråga per system: differentierar det här oss? Om nej, köp så högt upp i stacken som möjligt. Om ja, ta så mycket kontroll som behövs och så lite egen drift som möjligt.

För bolaget med 30 personer ser utfallet ofta ut så här: själva produkten på en plattform, databasen som managed service, en bit rå infrastruktur för den enda kunden med specialkrav, ett dussin hyrda verktyg runt omkring. Exakt mixen från avsnittet innan. Ingen renlärighetsregel, utan en rad medvetna enskilda beslut.

⚖️ Tre avvägningar, i klartext

Bakom varje lagerval sitter samma 3 avvägningar. Kan du dem kan du placera vilken leverantörsslide som helst på några minuter.

Kontroll mot ansvar. Varje lager du driver själv lyder dig. Och det ringer dig när det går sönder på natten. Kontroll låter som frihet, vad det betyder är jour. Den ärliga frågan är inte "vill vi ha kontroll" utan "vill vi ha ansvaret som följer med".

Lock-in mot fart. Ju fler färdiga tjänster du använder, desto snabbare shippar du. Och desto djupare växer du in i en leverantör. Att byta blir dyrt, inte omöjligt. Misstaget är inte lock-in i sig. Misstaget är att ta på sig den omedvetet. Bygger du allt själv av rädsla för lock-in betalar du priset nu i stället för kanske senare.

Fast kostnad mot användningskostnad. Egen drift kostar pengar oavsett om någon använder din produkt eller inte. Användningsbaserade tjänster kostar lite vid liten last och växer med din framgång. För en ung produkt är det andra oftast bättre. Du betalar mycket först när du har kunder. I gengäld behöver du ha ögonen på fakturan, för användningskostnader växer i det tysta.

Ordningen spelar roll: bestäm först vad som differentierar dig, väg sedan avvägningarna per system. Gör du tvärtom debatterar du leverantörer i veckor och står ändå utan linje.

🤖 Varför det här spelar roll i agenternas tidsålder

Det är exakt här det blir konkret för mig. Jag bygger AI-native produktteam. Jag kallar det Get Multiplayer: hur människor och AI-agenter jobbar tillsammans. Ett hyperlean team, några få proffs plus agenter som kör dygnet runt. Tre i stället för trettio.

De här agenterna kör någonstans. Om det är på IaaS, PaaS eller anslutet som SaaS avgör latens, kostnad och datakontroll. Måste du hålla din kod, din Jira och din data i EU är lagervalet ingen teknisk fråga utan en compliancefråga.

För DACH-bolag är det ingen fotnot. Många B2B-kunder kräver i avtal att data stannar i EU eller i Schweiz. Det är normalfallet, inte undantaget. Alla 3 lager finns med europeiska regioner. Du måste bara kontrollera det vid valet i stället för att reparera i efterhand.

Ovanpå det kommer kontexten. En agent är bara så bra som sin grund. Den grunden är Context Engine: ditt bolags affärs- och kodkontext. Var den kontexten bor och hur agenterna når den är en fråga om molnarkitektur. Utan ren kontext är det garbage in, garbage out.

🧑‍💻 Vad betyder det här för ett litet produktteam?

Köp allt som inte differentierar dig som färdig tjänst. Driv så lite som möjligt själv. Och avgör lagerfrågan innan dina agenter kör, inte efter. För arkitekturen bestämmer vad dina agenter når och hur snabbt.

Det knyter an till poängen ovan. När AI-hjälpare väl jobbar inne i produkten räknas varje lagerbeslut dubbelt. Det bestämmer var din kod kör. Och det bestämmer om en agent når loggar, data och deployer utan att en människa klickar emellan.

Ett litet team har en fördel här: lite legacy. Du kan skära arkitekturen så att kontexten sitter på ett ställe och agenterna jobbar där. Hur ett sådant upplägg kommer ihop i praktiken visar jag i SaaS-produkt på 90 dagar och i Från vibe coding till agentic engineering.

Lagerfrågan är en del av product management, inte IT. Mer om det samlar jag i hubben för software product management.

🎢 Toppar, dalar, varning

✅ Vad som fungerar: lagren som mental modell. Fråga för varje tjänst: vilket lager driver jag själv, vilket driver någon annan. Det röjer det mesta av förvirringen.

❌ Vad som inte fungerar: att behandla modellerna som stela lådor. Verkligheten är blandad, hybrid och suddig. Väntar du på den prydliga tårtan planerar du förbi praktiken.

⚠️ Varning: låt inte din molnarkitektur uppstå av en slump. I samma stund som agenter kör på din sida avgör den fart, kostnad och var din data ligger.

Molnet är ingen plats uppe i himlen, det är ett beslut om vad du driver själv. I agenternas tidsålder blir det beslutet viktigare, inte mindre viktigt. Vill du sätta agenter i ditt produktteam som kan din kontext, ta en titt på teklens.ai.