Grundläggande kunskaper om Azure-plattformen för startupföretag

Den här artikeln ger en snabb introduktion ur ett startup-perspektiv till fem grundläggande pelare i plattformen: beräkning, nätverk, lagring, containrar och data. För varje pelare får du en kort beslutstabell som kopplar din situation till en standardtjänst, samt en kommentar om när du bör ompröva det valet i takt med att din startup växer.

I den här artikeln får du lära dig hur du

Välj rätt Azure-beräknings-, nätverks- och lagringsgrundkomponenter för ditt skede.
Bestäm om Azure Kubernetes Service är rätt containerplattform för din fas och vad du ska använda i stället om det inte är det.
Välj en första dataplattform mellan relations-, dokument-, vektor- och analysarbetsbelastningar.
Använd en liten uppsättning kostnads-, tillförlitlighets- och säkerhetsstandarder som håller i takt med att du växer.
Identifiera de signaler som talar om för dig att ett standardval har vuxit ur dess användbarhet.

Förutsättningar

En aktiv prenumeration för Azure.
Azure CLI installerat och loggat in. Logga in genom att köra az login.
Ägar- eller deltagaråtkomst för minst en resursgrupp.
Det är bra att känna till Azure portalens landningssida, men det krävs inte.
Grundläggande kunskaper om Azure grunderna (regioner, prenumerationer och resursgrupper).

Varför detta är viktigt för nystartade företag

I ett nystartat företag är kostnaden för ett felaktigt val av infrastruktur inte själva räkningen. Det är veckan du förlorar på att migrera bort från fel tjänst efter att du har byggt din lösning kring den. De fem grundpelarna i den här artikeln är de där ett felaktigt valt standardvärde tenderar att förvärras: fel beräkningsplattform formar distributionspipelinen; fel databas begränsar din datamodell. fel nätverkstopologi blockerar din första företagskund. Du behöver inte ett plattformsteam, en platstillförlitlighetstekniker eller en specialist på finansiell verksamhet för att kunna göra dessa val på ett bra sätt. Du behöver ett standardval som är tillräckligt bra för att kunna lanseras, och en tydlig signal som talar om för dig när du ska ompröva det. Om ditt startupföretag är med i programmet Microsoft for Startups gör samma standardinställningar att dina krediter räcker längre och att du fortfarande kvalificerar dig för avancerade förmåner längre fram.

Beräkning: där koden körs

Azure har mer än ett dussin beräkningstjänster. Den goda nyheten: för de flesta tidiga arbetsbelastningar täcker tre av dem vad du behöver.

Din situation	Standardtjänst för Azure	Varför	Återbesök när
webbapp eller HTTP-API, en eller två tjänster, du vill ha en hanterad körningsmiljö	Azure App Service (Linux)	Inget containerbygge krävs. Inbyggd TLS, anpassade domäner, distributionsplatser och autoskalning. Gratis- och Basic-nivåer är tillräckligt billiga för att köra en testmiljö, men distributionsplatser och automatisk skalning kräver Standard eller högre.	Du vill köra mer än en handfull tjänster, behöver skalning per tjänst eller behöver sidovagnar.
Händelsedriven funktion, schemalagt jobb eller webhook-hanterare	Azure Functions (Förbrukningsplan)	Betala för varje körning. Skalar ner till noll. Bindningar eliminerar större delen av limkoden för köer, blobar och HTTP-utlösare.	Kallstarter försämrar svarstiden för användarna, eller så överskrider du gränserna för Consumption-planen.
Med containerbaserade mikrotjänster vill du ha en åsiktsbaserad körning utan att hantera Kubernetes	Azure Container Apps	Bygger på Kubernetes med KEDA-baserad autoskalning, men du hanterar inte klustret. Dapr är tillgängligt som en valfri integrering. Skala till noll, revisioner och HTTPS-ingress ingår.	Du behöver kontroll på klusternivå, en anpassad schemaläggare eller avancerade nätverk.
Tidskrävande batch-, GPU-träning eller lift-and-shift för en befintlig virtuell datorarbetsbelastning	Azure Virtual Machines	Fullständig operativsystemkontroll. Använd en skaluppsättning för virtuella datorer när du behöver horisontell skalning.	Den operativa belastningen från patchning och avbildshantering börjar bromsa leveranserna.
Du är säker på att du behöver Kubernetes (se avsnitt 4 innan du antar detta)	Azure Kubernetes Service	Hanterad styrplan. Passar team som redan har Kubernetes-erfarenhet eller specifika plattformskrav.	Se avsnittet Containrar för AKS-beslutsvillkor.

Tips/Råd

Börja med App Service för din första användarriktade webbapp och Azure Functions för allt händelsestyrt. Du kan flytta till Azure Container Apps eller Azure Kubernetes Service senare utan att ändra programkoden, om du behåller programmet tillståndslöst och skriver konfigurationen till miljövariabler.

Välja mellan Container Apps och App Service

Container Apps och App Service överlappar varandra. Det ärliga avgörandet: om din applikation redan körs som en containeravbild och du vill ha skalning på tjänstenivå (olika antal repliker för webblagret jämfört med arbetsprocessen), vinner Container Apps. Om ditt program är en enda webbprocess och du inte vill underhålla en Dockerfile vinner App Service.

Caution

Överväg Azure Kubernetes Service när du har tydliga krav som inte uppfylls av enklare alternativ. Även om det ger stark flexibilitet och kontroll, introducerar det även ytterligare driftsöverväganden (till exempel uppgraderingar, storleksändring av nodpooler, ingresskonfiguration och certifikathantering). Om de antas för tidigt får team ofta mer tid att gå in på plattformshantering än att skapa produktfunktioner.

Nätverk: vad du ska konfigurera på dag ett

De flesta tidiga Azure arbetsbelastningar behöver inte ett virtuellt nätverk på dag ett. App Service, Functions, Container Apps och de flesta hanterade databaser ger dig offentliga slutpunkter med TLS som är säkra att exponera, så länge du ställer in autentiseringen korrekt. Att lägga till nätverkskomplexitet innan du har en orsak är den vanligaste förtida optimeringen på Azure.

Din situation	Standardmetod	Varför	Återbesök när
Helt ny app, offentlig webbtrafik, inga efterlevnadskrav ännu	Använd den offentliga slutpunkten med TLS. Inget virtuellt nätverk.	Lägsta driftkostnader. App Service, Container Apps och hanterade databaser hanterar TLS åt dig. Använd Microsoft Entra ID för autentisering.	Din första företagskund ber om privat anslutning.
Du behöver en privat anslutning mellan din app och en hanterad databas	Integrering av virtuellt nätverk på beräkningssidan, privat slutpunkt på databassidan	Trafiken ligger kvar på Microsoft stamnät. Ingen offentlig exponering för databasen. Samma hanterade tjänst, ingen programändring.	Från dag ett om du hanterar skyddade data; annars när en granskning eller en kund frågar.
Du behöver en enda offentlig startpunkt som frontar flera serverdelar med routning, TLS-avslutning och en brandvägg för webbprogram	Azure Front Door (global) eller Azure Application Gateway (regional)	Front Door lägger till ett globalt nätverk för innehållsleverans och gränscachelagring. Application Gateway är det regionala alternativet internt för virtuella nätverk.	Du har vuxit ur App Service inbyggda TLS och routning.
Du behöver utgående statiska IP-adresser (till exempel en lista över tillåtna betalningsprocessorer)	NAT-gateway som är ansluten till ditt virtuella nätverk	Förutsägbar utgående IP-adress. Krävs av många API:er från tredje part.	En leverantör kräver det. Lägg inte till det spekulativt.
Topologi för flera regioner eller flera konton	Virtual network peering eller Azure Virtual WAN	Verklig nätverksarkitektur börjar här. Inte relevant för de flesta team i utforskningsfasen.	Flera regioner är ett verkligt krav, inte en strävan.

Important

Lås Microsoft Entra ID och dina prenumerationsrolltilldelningar innan du oroar dig för nätverksisolering. De flesta Azure säkerhetsincidenter hos små företag kommer från en identitet med överbehörighet, inte en nätverksexponering. Använd Microsoft Entra ID-grupper för åtkomst för teknikteamet och tilldela inte rollen Ägare på prenumerationsnivå.

Lagring: blobar, filer och diskar

Azure Storage är en enskild resurstyp (lagringskontot) som exponerar fyra datatjänster: blobar, filer, köer och tabeller. För beslut om programlagring väljer du nästan alltid mellan blobar (objektlagring), filer (hanterade filresurser) och hanterade diskar (blocklagring som är ansluten till en virtuell dator).

Vad du lagrar	Standardtjänst för Azure	Varför	Återbesök när
Användaruppladdade filer, genererade rapporter, loggar, modellartefakter, säkerhetskopior	Azure Blob Storage (frekvent åtkomstnivå)	Objektlagring. Prisvärda, robusta, kan skalas upp till petabyte. Använd cool- eller arkivnivåer senare för data som du sällan läser.	Du behöver POSIX-filsemantik eller slumpmässig lässkrivning i en enda fil från flera datorer.
Ett delat filsystem monterat av flera virtuella datorer eller containrar	Azure Files (Standard) eller Azure NetApp Files (högt dataflöde)	Delade volymer för servermeddelandeblock (SMB) eller NFS (Network File System). Undvik att använda dessa för innehåll som passar blobmodellen.	Du börjar använda en fildelning som en kö eller en databas. Flytta till rätt primitiv.
Diskar för en virtuell dator	Premium SSD v2 hanterade diskar	Justerbar prestanda, prisvärd prestanda för applikationsdiskar. Premium SSD v2 kan inte användas som OS-disk. parkoppla den med Premium SSD (v1) eller Standard SSD för operativsystemet. Standard-SSD är acceptabelt för arbetsbelastningar med lågt dataflöde.	Du behöver delad blocklagring mellan virtuella datorer (använd Azure Elastic SAN eller Azure NetApp Files).
Statiska webbplatstillgångar (enkelsidigt programpaket, marknadsföringswebbplats, dokumentation)	Azure Storage värdtjänst för statisk webbplats + Azure Front Door	Static Web Apps är den moderna standardinställningen: inbyggda anpassade domäner, kostnadsfri hanterad TLS, global distribution, GitHub Actions CI/CD och inbyggd autentisering. Statisk lagringswebbplats + Front Door fungerar fortfarande för mycket billiga installationer, men stöder inte anpassade rubriker eller autentisering internt.	Du lägger till server-renderade sidor. Flytta till App Service eller Container Apps.

Note

Lagringskonton har en mjuk gräns på 250 per region per prenumeration (500 per begäran). Det räcker gott och väl för team i ett tidigt skede. Misstaget att undvika är att skapa ett lagringskonto per mikrotjänst. gruppera efter miljö (produktion, mellanlagring, utveckling) och efter åtkomstmönster (frekvent, kall, arkiv) i stället.

En anteckning om säkerhetskopior

Azure Backup och redundansalternativ för lagringskonton (lokalt redundant lagring, zonredundant lagring, geo-redundant lagring) är justerbara per konto och per disk. Lokalt redundant lagring (LRS) är bra för utveckling och mellanlagring. Använd Zonredundant lagring (ZRS) för produktionsdata. Geo-redundant lagring tillför kostnader och ersätter inte haveriberedskap på programnivå.

Containrar och Azure Kubernetes Service

Azure har tre sätt att köra containrar i produktion: Azure Container Apps, Azure Container Instances och Azure Kubernetes Service. De motsvarar olika teamstorlekar och olika operativa ambitionsnivåer.

Din situation	Standardtjänst för Azure	Varför	När det börjar göra ont
Du har containeravbilder och du vill ha en hanterad körningsmiljö med HTTPS-ingress, skalning till noll och revideringar	Azure Container Apps	Serverlös plattform på Kubernetes med automatisk skalning av KEDA, men du ser eller hanterar inte klustret. Betala för det som används. Bra passform tills du når kraven på klusternivå. Dapr är tillgängligt som en opt-in-integrering.	Du behöver anpassade schemaläggare, avancerade nätverk (flera nätverkskort, anpassade plugin-program för containernätverksgränssnitt) eller specifika Kubernetes-operatorer.
Du vill köra en enda container som ett engångsjobb eller en kort batch	Azure Container Instances	Den snabbaste vägen från containeravbild till körande container. Ingen orkestrering. Debiteras per sekund av körningen.	Du behöver något som liknar ett servicenät eller automatisk skalning utöver en enda container.
Du använder redan Kubernetes någon annanstans, eller så kräver din programarkitektur verkligen det	Azure Kubernetes Service	Hanterad styrplan. Ta med egna nodpooler, plugin-program för nätverk, ingresskontrollant och observerbarhetsstack.	Dag ett. Planera för pågående uppgraderingar (delversion som släpps var fjärde månad), justering av nodpooler och certifikathantering.
Du är osäker på om du behöver Kubernetes	Container Apps för närvarande	Du kan bygga om på Azure Kubernetes Service senare om det behövs. Att migrera en tillståndslös containeriserad applikation tar dagar, inte veckor.	Du har ett konkret behov (operatörsekosystem, klusternivåprincip) som du kan namnge. ”Framtidssäkring” är inte ett konkret behov.

När du bör gå vidare till AKS

Flytta till Azure Kubernetes Service (AKS) när minst två av dessa är sanna:

Du kör mer än tio tjänster med delad livscykel och nätverksproblem.
Du behöver anpassade styrenheter, sidovagnar eller anpassade resursdefinitioner (CRD) som Container Apps inte exponerar.
Du behöver djup integrering av virtuella nätverk med strikt principframtvingande.
Du standardiserar på ett Kubernetes-baserat open-source ekosystem (Argo, Istio, KEDA och så vidare).

Om du använder AKS följer du arkitekturen för AKS-baslinje. Referensen Microsoft Azure Well-Architected Framework och AKS-baslinjen täcker tillsammans de standardinställningar för säkerhet, skalning och uppgradering som du vill använda.

AKS-standardinställningar för ett litet team

Inställningen	Standardinställning	Varför
Nodstorlek	Standard_D4s_v5 systempool, Standard_D8s_v5 användarpool	Förutsägbara pris-till-prestanda för allmänna arbetsbelastningar
Automatisk skalerare för kluster	Aktiverad	Undvik att betala för inaktiva noder
Arbetsbelastningsidentitet	Aktiverad	Ersätter poddidentitet, integrerar med Microsoft Entra ID
Azure Policy-tillägg	Aktiverad	Kostnadsfria skyddsräcken (inga privilegierade containrar, obligatoriska etiketter)
Containerinsikter	Aktiverad	Förstklassiga mått och loggar i Azure Monitor
Privat kluster	Aktiverad för produktion	Kontrollplanet kan endast nås från det virtuella nätverket

Azure Container Registry (containerregistertjänst från Azure)

Oavsett vilken beräkningsplattform du väljer lagrar du bilderna i Azure Container Registry. Basic-nivån räcker för tidiga team. Använd ett separat register per miljö (produktion, mellanlagring) om du vill ha hård isolering eller ett enskilt register med separata lagringsplatser och rollbaserad åtkomstkontroll om du vill ha enkelhet.

Dataplattform: relationell, dokument, vektor, analys

Beslut om dataplattform är de som mest sannolikt är permanenta. Schemat som du skickar i månad ett former varje funktion för de kommande två åren. Välj ett standardvärde som är tillräckligt flexibelt för att växa med produkten och motstå frestelsen att välja en specialiserad databas för en funktion som du inte har skapat ännu.

Din arbetsbelastning	Standardtjänst för Azure	Varför	Återbesök när
Transaktionsbaserade programdata (användare, beställningar, innehåll) med ett känt relationsschema	Azure Database for PostgreSQL (Flexibel server)	Mogna, allmänt förstådda, starka tilläggsekosystem (inklusive pgvector för inbäddningar). Burstable-nivån är tillräckligt billig för utveckling och staging.	Mönster för skrivning i flera regioner eller läsning i hyperskala. Överväg Azure Cosmos DB för PostgreSQL.
Schemaflexibla operativa data, global spridning, förutsägbara läsningar på ensiffriga millisekunder	Azure Cosmos DB (NoSQL API)	Flera regioner som standard. Serverlös nivå är tillräckligt billig för att börja på. Partitionsdesign spelar roll; läs vägledningen för partitionsnyckeln innan du skickar den.	Du tvingar relationssammanfogningar via applikationslagret. PostgreSQL är förmodligen rätt svar.
Sök i strukturerat och ostrukturerat innehåll, inklusive generering förstärkt med informationshämtning	Azure AI-sökning	Hybridnyckelord och vektorsökning. Integrerar med Azure OpenAI Service och Cosmos DB. Det finns en kostnadsfri nivå för prototyper.	Du överskrider indexgränserna per nivå (Standard 1 är en vanlig uppgraderingspunkt).
Vektorinbäddningar för en funktion för hämtningsförstärkt generering	Börja med pgvector i PostgreSQL eller Azure AI-sökning	Undvik en separat vektordatabas för den första versionen av en hämtningsfunktion. Du får lära dig vad du faktiskt behöver (filtrering, hybridsökning, skala) från verklig användning.	Du har karakteriserat dina läsmönster och begränsningarna motiverar en specialiserad motor.
Analys-, rapporterings- och ad hoc-frågor över produktionsdata	Azure Database for PostgreSQL läsreplik (Utforska), Microsoft Fabric (Expandera och extrahera)	En läsreplika räcker för de flesta analyser i utforskningsfasen. Microsoft Fabric är den moderna analysplattformen när du har vuxit ifrån det.	Dina läsrepliker kan inte hänga med, eller så behöver affärsintressenter en analysyta med självbetjäning.
Cachelagringslager framför en databas	Azure Cache for Redis (Basic-nivå)	Standardmekanism för cachelagring. Billigt att lägga till senare; lägg inte till spekulativt.	Du ser ett tydligt mönster för frekvent läsning som mättar databasen. Mät innan du lägger till.

Important

Välj en standarddatabas och stanna kvar på den så länge du kan. Ett team på femton ingenjörer som driver PostgreSQL, Cosmos DB, Redis, AI Search, ett kösystem och en grafdatabas har av misstag dragit på sig en arbetsbörda motsvarande ett helt plattformsteam.

Där Azure OpenAI Service passar

Azure OpenAI Service är inte en dataplattform, men den delar samma beslutsrytm. De flesta nystartade företag som skapar en generativ AI-funktion börjar med en modelldistribution (en nyligen genomförd chattmodell) i en enda region, plus AI Search eller pgvector för hämtning. Du behöver inte en dedikerad finjusteringspipeline, en modellgateway eller flera distributioner förrän användningen uppmanar dig att lägga till dem.

Vad den här artikeln beskriver (och vad den inte gör)

Topic	I den här artikeln	När du ska lägga till den
Identitets- och åtkomsthantering utöver grunderna	No	Dag ett för konfiguration av Microsoft Entra ID. Villkorlig åtkomst och Privileged Identity Management när du har en granskning av informationssäkerhet.
Infrastruktur som kod (Bicep, Terraform)	No	När manuella portaländringar börjar glida mellan miljöer. Vanligtvis runt den tidpunkt då du lägger till en stagingmiljö.
Pipelines för kontinuerlig integrering och kontinuerlig distribution	No	Dag ett. GitHub Actions eller Azure DevOps Pipelines är båda bra.
Observerbarhet (loggar, mått, spårningar)	No	Application Insights från dag ett. Azure Monitor-arbetsböcker när du har varningströtthet.
Kostnadshantering	No	Ange en budget på prenumerationsnivå på dag ett. Tagga resurser med miljö och ägare från början.
Efterlevnad (SOC 2, ISO 27001, HIPAA)	No	När en kund frågar. Microsoft Defender för molnet har en instrumentpanel för efterlevnad som mappar kontroller till Azure resurser.
Haveriberedskap och flera regioner	No	När kostnaden för en timmes stilleståndstid överskrider den tekniska kostnaden för den andra regionen.

När plattformens standardvärden inte längre räcker

Dessa tillväxtindikatorer visar att en specifik standardinställning behöver ett mer genomtänkt alternativ:

Du har distribuerat mer än fem distinkta tjänster på App Service eller Container Apps och skalning per tjänst blir ett dagligt problem. Titta på Azure Kubernetes Service.
Din månatliga Azure faktura ökar snabbare än dina månatliga intäkter två månader i rad. Dags för en granskning av kostnadshanteringen och en analys av Reserved Instance eller Savings Plan.
Ditt virtuella nätverk omfattar nu flera prenumerationer eller regioner. Titta på Azure Virtual WAN och en topologi med nav och eker.
En enskild PostgreSQL-instans kan inte lagra din arbetsuppsättning i minnet och läsrepliker stänger inte gapet. Titta på Cosmos DB för PostgreSQL eller en fragmenterad arkitektur.
Analysfrågor i produktionsdatabasen påverkar programmets svarstid märkbart. Flytta analys till Microsoft Fabric.
Du kör fler än två lagringskonton per miljö för samma åtkomstmönster. Konsolidera.
Du har lagt till ett tredje land med betalande kunder. Det är dags att utvärdera ytterligare en region, geo-redundant lagring och en routningsstrategi för Front Door.