základy platformy Azure pro startupy

Tento článek poskytuje rychlou orientaci z pohledu startupu napříč pěti základními pilíři platformy: výpočetními prostředky, sítěmi, úložištěm, kontejnery a daty. Pro každý pilíř získáte krátkou rozhodovací tabulku, která přiřazuje vaši situaci k výchozí službě, a také poznámku, kdy je vhodné tuto volbu znovu posoudit s tím, jak váš startup roste.

V tomto článku se dozvíte, jak

Vyberte správné výpočetní, síťové a úložné služby Azure pro vaši etapu.
Rozhodněte se, jestli je Azure Kubernetes Service správnou platformou kontejneru pro vaši fázi a co použít, pokud ne.
Vyberte jednotnou datovou platformu pro relační, dokumentové, vektorové a analytické úlohy.
Použijte malou sadu výchozích nastavení pro náklady, spolehlivost a zabezpečení, která obstojí i při růstu.
Rozpoznejte signály, které vám napoví, že výchozí volba už přestala být užitečná.

Předpoklady

Aktivní předplatné Azure.
Azure CLI nainstalované a přihlášené. Chcete-li se přihlásit, spusťte az login.
Přístup vlastníka nebo přispěvatele k alespoň jedné skupině prostředků
Znalost úvodní stránky portálu Azure je užitečná, ale nevyžaduje se.
Základní obeznámenost se základy Azure (oblasti, předplatná a skupiny prostředků).

Proč je to důležité pro startupy

Při počátečním spuštění nejsou náklady na nesprávnou volbu infrastruktury fakturou. Je to týden, který ztratíte migrací z nevhodné služby poté, co jste kolem ní vybudovali své řešení. Pět pilířů v tomto článku jsou právě ty oblasti, kde se důsledky špatně zvolené výchozí volby obvykle kumulují: nesprávně zvolená výpočetní platforma ovlivní vaši pipeline nasazení; nesprávná databáze omezí váš datový model; nesprávná síťová topologie vám zablokuje získání prvního podnikového zákazníka. K tomu, abyste mohli tyto volby dobře zvolit, nepotřebujete tým platformy, inženýr pro spolehlivost webu ani odborníka na finanční operace. Potřebujete výchozí nastavení, které je dostatečně dobré pro nasazení, a jasný signál, který vám řekne, kdy je potřeba se k němu vrátit. Pokud je váš startup v programu Microsoft for Startups, stejná výchozí nastavení vám umožní využít vaše kredity efektivněji a zachovají vám nárok na pokročilé výhody i později.

Výpočetní výkon: kde běží váš kód

Azure má více než tucet výpočetních služeb. Dobrá zpráva: pro většinu úloh v rané fázi se tři z nich týkají toho, co potřebujete.

Vaše situace	Výchozí služba Azure	Proč	Znovu se vrátit, když
Webová aplikace nebo HTTP API, jedna nebo dvě služby, chcete spravované běhové prostředí	Azure App Service (Linux)	Nevyžaduje se žádné sestavení kontejneru. Integrované protokoly TLS, vlastní domény, sloty nasazení a automatické škálování Tarify Free a Basic jsou dost levné na provozování testovacího prostředí, i když sloty a automatické škálování vyžadují tarif Standard nebo vyšší.	Chcete spustit více než jen několik služeb, potřebujete samostatné škálování jednotlivých služeb nebo potřebujete sidecary.
Funkce řízená událostmi, plánovaná úloha nebo obslužná rutina webhooku	Azure Functions (plán využití)	Platba za provedení Lze škálovat až na nulu. Bindingy odstraňují potřebu většiny propojovacího kódu pro fronty, bloby a triggery HTTP.	Buď studené starty zvyšují latenci vnímanou uživateli, nebo překročíte limity tarifu Consumption.
Kontejnerizované mikroslužby, chcete runtime s pevně danými konvencemi, aniž byste museli spravovat Kubernetes.	Azure Container Apps	Založené na Kubernetes s automatickým škálováním založeným na KEDA, ale cluster nespravujete. Dapr je k dispozici jako volitelná integrace. Zahrnuje škálování na nulu, revize a příchozí přenos HTTPS.	Potřebujete řízení na úrovni clusteru, vlastní plánovač nebo pokročilé sítě.
Dlouhotrvající dávkové trénování, trénování GPU nebo lift and shift existující úlohy virtuálního počítače	Virtuální počítače Azure	Úplné řízení operačního systému. Škálovací sadu virtuálních počítačů použijte, pokud potřebujete horizontální škálování.	Provozní režie spojená se záplatováním a správou image začíná zpomalovat vydávání.
Jste si jisti, že potřebujete Kubernetes (viz část 4, než to budete předpokládat)	Služba Azure Kubernetes	Spravovaná řídicí rovina. Vyhovuje týmům, které už mají prostředí Kubernetes nebo konkrétní požadavky na platformu.	Informace o rozhodovacích kritériích pro AKS najdete v části Kontejnery.

Tip

Začněte se službou App Service pro vaši první webovou aplikaci určenou pro uživatele a Azure Functions pro všechno, co je řízené událostmi. Pokud necháte bezstavovou aplikaci a zapíšete konfiguraci do proměnných prostředí, můžete přejít na Azure Container Apps nebo Azure Kubernetes Service později beze změny kódu aplikace.

Volba mezi kontejnerovými aplikacemi a App Service

Container Apps a App Service se překrývají. Rozhodující kritérium: pokud už vaše aplikace běží jako kontejnerová image a chcete škálování po jednotlivých službách (jiný počet replik pro webovou vrstvu než pro pracovní proces), vítězí Container Apps. Pokud je vaše aplikace jedním webovým procesem a nechcete udržovat soubor Dockerfile, služba App Service vyhraje.

Caution

Zvažte Azure Kubernetes Service, pokud máte jasné požadavky, které nejsou splněny jednoduššími možnostmi. I když nabízí silnou flexibilitu a kontrolu, přináší také další provozní aspekty (jako jsou upgrady, nastavení velikosti fondu uzlů, konfigurace příchozího přenosu dat a správa certifikátů). Pokud se něco zavede příliš brzy, týmy často zjistí, že tráví více času správou platformy než vývojem produktových funkcí.

Síťové připojení: co nastavit první den

Většina úloh v rané fázi Azure nepotřebuje virtuální síť každý den. App Service, Functions, Container Apps a většina spravovaných databází poskytují veřejné koncové body s protokolem TLS, které jsou bezpečné k zveřejnění, pokud nastavíte ověřování správně. Přidávání síťové složitosti předtím, než k tomu máte důvod, je na Azure nejběžnější formou předčasné optimalizace.

Vaše situace	Výchozí přístup	Proč	Znovu se vrátit, když
Úplně nová aplikace, veřejný webový provoz, zatím žádné požadavky na dodržování předpisů	Použijte veřejný koncový bod s protokolem TLS. Žádná virtuální síť.	Nejnižší provozní režie. Služba App Service, Container Apps a spravované databáze za vás zpracovávají protokol TLS. Pro ověřování použijte Microsoft Entra ID.	Váš první podnikový zákazník požádá o privátní připojení.
Potřebujete privátní připojení mezi aplikací a spravovanou databází.	Integrace virtuální sítě na straně výpočetních prostředků, privátní koncový bod na straně databáze	Provoz probíhá na páteřní síti společnosti Microsoft. Žádná veřejná expozice databáze. Stejná spravovaná služba, žádná změna aplikace	Od prvního dne, pokud zpracováváte chráněná data; jinak až když si to vyžádá audit nebo zákazník.
Potřebujete jeden veřejný vstupní bod, který zastřešuje více backendů a zajišťuje směrování, ukončování TLS a webový aplikační firewall.	Azure Front Door (globální) nebo Azure Application Gateway (regionální)	Front Door přidá globální síť pro doručování obsahu a ukládání do mezipaměti edge. Application Gateway je místní možnost nativní pro virtuální síť.	Integrované TLS a směrování služby App Service už vám nestačí.
Potřebujete odchozí statické IP adresy (například seznam povolených platebních procesorů).	Brána NAT připojená k vaší virtuální síti	Předvídatelná odchozí IP adresa. Vyžaduje mnoho rozhraní API třetích stran.	Dodavatel ho vyžaduje. Nepřidávejte ho spekulativním způsobem.
Víceregionální nebo víceúčtová topologie	Partnerské propojení virtuálních sítí nebo Azure Virtual WAN	Tady začíná skutečná síťová architektura. Nespadá do působnosti většiny týmů ve fázi zkoumání.	Multi-region je skutečný požadavek, nikoli aspirace.

Important

Než se začnete zabývat izolací sítě, zabezpečte Microsoft Entra ID a přiřazení rolí v rámci předplatného. Většinu bezpečnostních incidentů v Azure v malých společnostech způsobuje identita s příliš širokými oprávněními, nikoli vystavení sítě. Pro přístup technických týmů používejte skupiny Microsoft Entra ID a nepřidělujte roli Vlastník na úrovni předplatného.

Úložiště: objekty blob, soubory a disky

Azure Storage je jeden typ prostředku (účet úložiště), který zpřístupňuje čtyři datové služby: objekty blob, soubory, fronty a tabulky. Při rozhodování o úložišti aplikací se téměř vždy vybíráte mezi objekty blob (úložiště objektů), soubory (spravované sdílené složky) a spravovanými disky (blokové úložiště připojené k virtuálnímu počítači).

Co ukládáte	Výchozí služba Azure	Proč	Znovu se vrátit, když
Soubory nahrané uživatelem, vygenerované reporty, logy, artefakty modelu, zálohy	Azure Blob Storage (horká vrstva)	Úložiště objektů. Levné, odolné, škálovatelné až na petabajty. Data, která často nečtete, později přesuňte do vrstvy cool nebo archivní vrstvy.	Potřebujete sémantiku souboru POSIX nebo náhodné čtení i zápis do jednoho souboru z více počítačů.
Sdílený systém souborů připojený několika virtuálními počítači nebo kontejnery	Azure Files (Standard) nebo Azure NetApp Files (vysoká propustnost)	Sdílené svazky SMB (Server Message Block) nebo NFS (Network File System). Nepoužívejte je pro obsah, který spadá do modelu blobů.	Začnete používat sdílenou složku jako frontu nebo databázi. Přechod na správnou primitivu
Disky pro virtuální počítač	Premium spravované disky SSD v2	Nastavitelný výkon, dobrý poměr ceny a výkonu pro aplikační disky. Disk SSD úrovně Premium v2 nelze použít jako disk s operačním systémem; spárujte ho s SSD úrovně Premium (v1) nebo SSD úrovně Standard pro operační systém. Disk SSD úrovně Standard je přijatelný pro úlohy s nízkou propustností.	Potřebujete sdílené blokové úložiště napříč virtuálními počítači (použijte Azure Elastic SAN nebo Azure NetApp Files).
Prostředky statického webu (sada jednostrákových aplikací, marketingový web, dokumentace)	Azure Storage hostování statických webů + Azure Front Door	Static Web Apps je moderní výchozí nastavení: integrované vlastní domény, bezplatné spravované tls, globální distribuce, GitHub Actions CI/CD a integrované ověřování. Statický web ve službě Storage + Front Door je stále použitelný pro velmi levná nasazení, ale ve výchozím stavu nepodporuje vlastní hlavičky ani autentizaci.	Přidáte stránky vykreslené serverem. Přejděte na App Service nebo Container Apps.

Note

Účty úložiště mají omezený limit 250 na oblast na předplatné (500 na žádost). To je pro začínající týmy víc než dost. Chybou, které je třeba se vyhnout, je vytvářet jeden účet úložiště pro každou mikroslužbu; místo toho je seskupujte podle prostředí (produkčního, přípravného, vývojového) a podle způsobu přístupu (horkého, studeného, archivního).

Poznámka k zálohám

možnosti redundance účtu úložiště Azure Backup (Místně redundantní úložiště, zónově redundantní úložiště, geograficky redundantní úložiště) se dají ladit na účet a na disk. Místně redundantní úložiště (LRS) je v pořádku pro vývoj a přípravu. Pro produkční data použijte zónově redundantní úložiště (ZRS). Geograficky redundantní úložiště přidává náklady a není náhradou za zotavení po havárii na úrovni aplikace.

Kontejnery a Azure Kubernetes Service

Azure nabízí tři způsoby spouštění kontejnerů v produkčním prostředí: Azure Container Apps, Azure Container Instances a Azure Kubernetes Service. Odpovídají různým velikostem týmů a ochotě zvládat provozní nároky.

Vaše situace	Výchozí služba Azure	Proč	Když to začíná bolet
Máte image kontejnerů a chcete spravovaný modul runtime s příchozím přenosem dat HTTPS, škálováním na nulu a revizemi.	Azure Container Apps	Bezserverová platforma v Kubernetes s automatickým škálováním KEDA, ale cluster nevidíte ani nespravujete. Plaťte za to, co běží. Vhodné, dokud nenarazíte na požadavky na úrovni clusteru. Dapr je k dispozici jako integrace s výslovným souhlasem.	Potřebujete vlastní plánovače, pokročilé sítě (více karet síťového rozhraní, vlastní moduly plug-in Container Network Interface) nebo konkrétní operátory Kubernetes.
Chcete spustit jeden kontejner jako jednorázovou úlohu nebo krátkou dávku.	Azure Container Instances	Nejrychlejší cesta z image do spuštěného kontejneru Žádná orchestrace. Účtuje se za každou sekundu běhu.	Potřebujete cokoli podobného sítě služeb nebo automatické škálování nad rámec jednoho kontejneru.
Kubernetes už provozujete jinde nebo ji vaše architektura aplikace skutečně vyžaduje.	Služba Azure Kubernetes	Spravovaná řídicí rovina. Použijte vlastní pooly uzlů, síťový plugin, Ingress controller a stack pro observabilitu.	První den. Naplánujte průběžné aktualizace (dílčí verze vydávaná každé 4 měsíce), optimalizaci fondu uzlů a správu certifikátů.
Nejste si jistí, jestli potřebujete Kubernetes.	Container Apps prozatím	V případě potřeby můžete znovu sestavit Azure Kubernetes Service později. Migrace bezstavové kontejnerizované aplikace je otázkou několika dnů, nikoli týdnů.	Máte konkrétní potřebu (ekosystém operátorů, zásady na úrovni clusteru), které můžete pojmenovat. „Zajištění do budoucna“ není konkrétní potřeba.

Kdy absolvovat AKS

Přejděte na Azure Kubernetes Service (AKS) pokud platí alespoň dvě z těchto hodnot:

Provozujete více než deset služeb se společným životním cyklem a podobnými požadavky na síťovou komunikaci.
Potřebujete vlastní řadiče, sidecary nebo definice vlastních prostředků (CRD), které Container Apps nezpřístupňuje.
Potřebujete hlubokou integraci virtuální sítě s přísným vynucováním zásad.
Standardizujete ekosystém open source založený na Kubernetes (Argo, Istio, KEDA atd.).

Pokud používáte AKS, postupujte podle architektury standardních hodnot AKS. Referenční informace o Microsoft Azure Well-Architected Frameworku a standardních hodnotách AKS společně pokrývají požadované výchozí hodnoty zabezpečení, škálování a upgradu.

Výchozí nastavení AKS pro malý tým

Setting	Výchozí	Proč
Velikost uzlu	systémový fond Standard_D4s_v5, uživatelský fond Standard_D8s_v5	Předvídatelné ceny a výkon pro obecné úlohy
Automatizovaný škálovač clusteru	Enabled	Vyhněte se placení za nečinné uzly
Identita úloh	Enabled	Nahrazuje pod identity a integruje se s Microsoft Entra ID
doplněk Azure Policy	Enabled	Bezplatné mantinely (žádné privilegované kontejnery, povinné popisky)
Přehledy kontejnerů	Enabled	Metriky a protokoly první třídy v Azure Monitor
Soukromý shluk	Zapnuto pro produkční prostředí	Řídicí rovina dosažitelná pouze z virtuální sítě

Azure Container Registry

Bez ohledu na to, jakou výpočetní platformu vyberete, uložte image do Azure Container Registry. Úroveň Basic stačí pro týmy v rané fázi. Pokud chcete jednoduchost, použijte samostatný registr pro každé prostředí (produkční, přípravný) nebo jeden registr s samostatnými úložišti a řízením přístupu na základě role.

Datová platforma: relační, dokument, vektor, analýza

Rozhodnutí o datových platformách jsou pravděpodobně trvalá. Schéma, které nasadíte v prvním měsíci, ovlivní podobu všech funkcí v příštích dvou letech. Vyberte výchozí nastavení, které je dostatečně flexibilní pro růst produktu, a odolejte pokušení předem vybrat specializovanou databázi pro funkci, kterou jste ještě nevytvoili.

Vaše úloha	Výchozí služba Azure	Proč	Znovu se vrátit, když
Transakční data aplikací (uživatelé, objednávky, obsah) se známým relačním schématem	Azure Database for PostgreSQL (flexibilní server)	Vyspělý, široce srozumitelný, silný ekosystém rozšíření (včetně pgvectoru pro vkládání). Vrstva s možností navýšení výkonu je dostatečně levná pro vývoj a staging.	Vzory zápisu do více regionů nebo hyperškálového čtení. Zvažte Azure Cosmos DB pro PostgreSQL.
Provozní data s flexibilním schématem, globální distribuce, předvídatelná čtení v řádu jednotek milisekund	Azure Cosmos DB (rozhraní API NoSQL)	Ve výchozím nastavení je více oblastí. Bezserverová vrstva je dostatečně levná na to, aby se s ní dalo začít. Na návrhu oddílů záleží; Přečtěte si pokyny k klíči oddílu před odesláním.	Vynucujete relační spojení prostřednictvím aplikační vrstvy. PostgreSQL je pravděpodobně správná odpověď.
Vyhledávejte ve strukturovaném i nestrukturovaném obsahu, včetně generování rozšířeného o vyhledávání	Azure AI Vyhledávač	Hybridní hledání klíčových slov a vektorů Integruje se s Azure OpenAI Service a Cosmos DB. Úroveň Free existuje pro vytváření prototypů.	Překračujete limity indexů pro jednotlivé úrovně (Standard 1 je běžný bod pro přechod na vyšší úroveň).
Vektorové embeddingy pro funkci generování rozšířeného o vyhledávání	Začínáme s pgvectorem v PostgreSQL nebo Azure AI Vyhledávač	Vyhněte se samostatné vektorové databázi pro první verzi funkce načítání. Dozvíte se, co skutečně potřebujete (filtrování, hybridní vyhledávání, škálování) z reálného využití.	Analyzovali jste vzorce čtení a omezení odůvodňují specializovaný nástroj.
Analytika, tvorba sestav a ad hoc dotazy nad produkčními daty	Azure Database for PostgreSQL replika jen pro čtení (Prozkoumat), Microsoft Fabric (Rozbalit a extrahovat)	Replika pro čtení stačí pro většinu analytických úloh ve fázi průzkumu. Microsoft Fabric je moderní analytická platforma, jakmile vám to přestane stačit.	Vaše repliky pro čtení nestíhají nebo obchodní zainteresované strany potřebují samoobslužné analytické rozhraní.
Ukládání vrstvy do mezipaměti před databází	Azure Cache for Redis (úroveň Basic)	Standardní primitiva ukládání do mezipaměti. Je levné to přidat později; nepřidávejte to jen pro jistotu.	Uvidíte jasný vzorec horkého čtení, který databázi nasytí. Před přidáním změřte.

Important

Vyberte jednu výchozí databázi a zůstaňte na ní tak dlouho, dokud budete moct. Tým o patnácti inženýrech, který provozuje PostgreSQL, Cosmos DB, Redis, AI vyhledávání, frontu a grafovou databázi, si omylem nadělil práce za celý platformní tým.

Kde Azure OpenAI Service zapadá

Azure OpenAI Service není datová platforma, ale sdílí stejný rozhodovací rytmus. Většina startupů, které vytvářejí funkci využívající generativní AI, začíná s jedním nasazením modelu (nedávným modelem pro dokončování chatu) v jednom regionu a s AI Search nebo pgvector pro vyhledávání. Nepotřebujete vyhrazený kanál pro vyladění, bránu modelu ani více nasazení, dokud vám využití neřekne, že je chcete přidat.

Co tento článek popisuje (a co ne)

Téma	V tomto článku:	Kdy ji přidat
Správa identit a přístupu nad rámec základů	Ne	Den 1 pro nastavení Microsoft Entra ID. Podmíněný přístup a Privileged Identity Management při přezkumu bezpečnosti informací.
Infrastruktura jako kód (Bicep, Terraform)	Ne	Když se ruční změny v portálu začnou rozcházet napříč prostředími. Obvykle v době, kdy přidáváte stagingové prostředí.
Kanály průběžné integrace a průběžného nasazování	Ne	První den. GitHub Actions nebo Azure DevOps Pipelines, oboje je v pořádku.
Pozorovatelnost (protokoly, metriky, trasování)	Ne	Application Insights od prvního dne. Azure Monitor sešity, když máte únavu upozornění.
Správa nákladů	Ne	Nastavte rozpočet na úrovni předplatného na den 1. Označte prostředky pomocí prostředí a vlastníka od začátku.
Dodržování předpisů (SOC 2, ISO 27001, HIPAA)	Ne	Když se zákazník zeptá. Microsoft Defender for Cloud má řídicí panel dodržování předpisů, který mapuje kontroly k prostředkům Azure.
Zotavení po havárii a více oblastí	Ne	Když náklady na hodinu výpadku překročí technické náklady druhé oblasti.

Pokud už výchozí nastavení platformy nestačí

Tyto signály růstu vám říkají, že konkrétní výchozí nastavení vyžaduje úmyslnější nahrazení:

V App Service nebo Container Apps jste nasadili více než pět různých služeb a škálování jednotlivých služeb se stává každodenní obavou. Podívej se na Azure Kubernetes Service.
Měsíční Azure faktura roste rychleji než měsíční výnosy za dva měsíce po sobě. Je čas na kontrolu Cost Managementu a analýzu rezervovaných instancí nebo plánů úspor.
Vaše virtuální síť teď zahrnuje více předplatných nebo oblastí. Podívejte se na Azure Virtual WAN a topologii typu hub-and-spoke.
Jedna instance PostgreSQL nemůže obsahovat vaši pracovní sadu v paměti a repliky pro čtení nezavírají mezeru. Podívejte se na Cosmos DB for PostgreSQL nebo horizontálně dělenou architekturu.
Analytické dotazy v produkční databázi mají výrazně vliv na latenci aplikace. Přesuňte analýzy do Microsoft Fabric.
Pro stejný vzor přístupu používáte v každém prostředí více než dva účty úložiště. Konsolidovat.
Přidali jste třetí zemi, kde máte platící zákazníky. Čas vyhodnotit druhou oblast, geograficky redundantní úložiště a strategii směrování služby Front Door.