Fondamenti della piattaforma Azure per startup

Questo articolo offre un orientamento rapido con un obiettivo di avvio su cinque pilastri fondamentali della piattaforma: calcolo, rete, archiviazione, contenitori e dati. Per ogni pilastro, trovi una breve tabella decisionale che collega la tua situazione a un servizio predefinito, oltre a una nota che indica quando rivedere questa scelta man mano che la tua startup cresce.

In questo articolo si apprenderà come

• Scegli le primitive di calcolo, rete e archiviazione di Azure più adatte per la tua fase.
• Decidere se servizio Azure Kubernetes è la piattaforma contenitore appropriata per la fase e cosa usare invece se non lo è.
• Selezionare una prima piattaforma dati tra carichi di lavoro relazionali, documenti, vettori e analisi.
• Applica un numero limitato di impostazioni predefinite in termini di costi, affidabilità e sicurezza che restano valide man mano che cresci.
• Riconoscere i segnali che indicano una scelta predefinita ha superato la sua utilità.

Prerequisiti

• Una sottoscrizione di Azure attiva.
• Il interfaccia della riga di comando di Azure installato e connesso. Per accedere, eseguire az login.
• Accesso proprietario o collaboratore in almeno un gruppo di risorse.
• La familiarità con la pagina di destinazione del portale di Azure è utile ma non necessaria.
• Conoscenza di base dei concetti fondamentali Azure (aree, sottoscrizioni e gruppi di risorse).

Perché questo aspetto è importante per le startup

All'avvio iniziale, il costo di una scelta errata dell'infrastruttura non è la fattura. È la settimana che perdi a migrare via dal servizio sbagliato dopo averci costruito tutto intorno. I cinque pilastri di questo articolo sono quelli in cui un valore predefinito scelto male tende a complicarsi: la piattaforma di calcolo sbagliata modella la pipeline di distribuzione; il database errato vincola il modello di dati; la topologia di rete errata blocca il primo cliente aziendale. Non è necessario un team di piattaforma, un ingegnere dell'affidabilità del sito o uno specialista delle operazioni finanziarie per fare queste scelte in modo ottimale. È necessario un valore predefinito sufficiente per la spedizione e un segnale chiaro che indica quando rivederlo. Se la tua startup fa parte del programma Microsoft for Startups, le stesse impostazioni predefinite ti consentono di sfruttare più a lungo i crediti e di rimanere idoneo ai vantaggi avanzati in seguito.

Calcolo: posizione in cui viene eseguito il codice

Azure ha più di una dozzina di servizi di calcolo. La buona notizia: per la maggior parte dei carichi di lavoro in fase iniziale, tre di essi riguardano ciò che serve.

La tua situazione	Servizio di Azure predefinito	Perché	Ricontrolla quando
App Web o API HTTP, uno o due servizi, si vuole un runtime gestito	Servizio app di Azure (Linux)	Non è richiesta alcuna build del container. TLS predefinito, domini personalizzati, slot di distribuzione e scalabilità automatica. I piani Free e Basic sono abbastanza economici da consentire l’esecuzione di un ambiente di staging, sebbene gli slot e la scalabilità automatica richiedano il livello Standard o superiore.	Vuoi eseguire più di una manciata di servizi, hai bisogno della scalabilità per servizio o hai bisogno di sidecars.
Funzione guidata dagli eventi, processo pianificato o gestore webhook	Funzioni di Azure (piano a consumo)	Pagamento per esecuzione. Si ridimensiona fino a zero. I binding eliminano gran parte del codice collante per code, blob e trigger HTTP.	Gli avvii a freddo penalizzano la latenza percepita dall'utente oppure si superano i limiti del Piano a consumo.
Microservizi containerizzati, vuoi un runtime con convenzioni predefinite senza gestire Kubernetes	App contenitore di Azure	Basato su Kubernetes con scalabilità automatica basata su KEDA, ma non si gestisce il cluster. Dapr è disponibile come integrazione facoltativa. Sono inclusi la scalabilità fino a zero, le revisioni e l'ingress HTTPS.	È necessario un controllo a livello di cluster, un'utilità di pianificazione personalizzata o una rete avanzata.
Batch a esecuzione prolungata, training GPU o trasferimento in modalità lift-and-shift di un carico di lavoro di macchina virtuale esistente	Macchine virtuali di Azure	Controllo completo del sistema operativo. Usare un set di scalabilità di macchine virtuali quando è necessaria la scalabilità orizzontale.	Il sovraccarico operativo della gestione delle patch e delle immagini di sistema inizia a rallentare il rilascio.
Si è certi di aver bisogno di Kubernetes (vedere la sezione 4 prima di presupporre questo)	Servizio Azure Kubernetes	Piano di controllo gestito. Adatta a team che hanno già esperienza con Kubernetes o requisiti specifici di piattaforma.	Consultare la sezione Contenitori per i criteri decisionali di AKS.

Tip

Inizia con App Service per la tua prima app Web destinata agli utenti e con Funzioni di Azure per tutto ciò che è basato su eventi. È possibile passare a App contenitore di Azure o servizio Azure Kubernetes in un secondo momento senza modificare il codice dell'applicazione, se si mantiene la configurazione senza stato dell'applicazione e si scrive la configurazione nelle variabili di ambiente.

Scegliere tra Container Apps e App Service

Container Apps e App Service si sovrappongono. Il fattore decisivo, senza giri di parole: se l'applicazione è già eseguita come immagine container e si desidera una scalabilità per servizio (con un numero di repliche diverso per il livello web rispetto al worker), vince Container Apps. Se l'applicazione è un singolo processo Web e non si vuole mantenere un Dockerfile, il servizio app vince.

Caution

Prendere in considerazione servizio Azure Kubernetes quando si hanno requisiti chiari che non sono soddisfatti da opzioni più semplici. Sebbene offra una forte flessibilità e controllo, introduce anche considerazioni operative aggiuntive(ad esempio aggiornamenti, dimensionamento del pool di nodi, configurazione in ingresso e gestione dei certificati). Se adottato troppo presto, i team spesso trovano più tempo per passare alla gestione della piattaforma rispetto alla creazione di funzionalità del prodotto.

Rete: cosa configurare il giorno 1

La maggior parte dei carichi di lavoro in fase iniziale Azure non richiede una rete virtuale al giorno 1. Il servizio app, le funzioni, le app contenitore e la maggior parte dei database gestiti offrono endpoint pubblici con TLS sicuri da esporre, purché l'autenticazione sia impostata correttamente. L'aggiunta di complessità di rete prima di avere un motivo è l'ottimizzazione prematura più comune in Azure.

La tua situazione	Approccio predefinito	Perché	Ricontrolla quando
Nuova app, traffico Web pubblico, nessun requisito di conformità ancora	Usare l'endpoint pubblico con TLS. Nessuna rete virtuale.	I costi operativi più bassi. Il servizio app, le app contenitore e i database gestiti gestiscono TLS automaticamente. Usare Microsoft Entra ID per l'autenticazione.	Il primo cliente aziendale richiede la connettività privata.
È necessaria una connessione privata tra l'app e un database gestito	Integrazione della rete virtuale nel livello di calcolo, endpoint privato nel livello di database	Il traffico rimane sulla spina dorsale di Microsoft. Nessuna esposizione pubblica per il database. Stesso servizio gestito, nessuna modifica dell'applicazione.	Dal primo giorno se si gestiscono dati protetti; altrimenti quando lo richiede un audit o un cliente.
È necessario un unico punto di ingresso pubblico che faccia da front-end a più back-end con routing, terminazione TLS e un firewall per applicazioni web	Frontdoor di Azure (globale) o gateway applicazione di Azure (regionale)	Frontdoor aggiunge una rete per la distribuzione di contenuti globale e la memorizzazione nella cache perimetrale. Application Gateway è l'opzione regionale nativa della rete virtuale.	Non ti bastano più il TLS e il routing integrati di App Service.
Hai bisogno di indirizzi IP statici in uscita (ad esempio, una lista di indirizzi consentiti di un gestore di pagamenti)	Gateway NAT collegato alla rete virtuale	IP in uscita prevedibile. Richiesto da molte API di terze parti.	Un fornitore lo richiede. Non aggiungerlo in via speculativa.
Topologia multi-area o multi-account	Peering di rete virtuale o rete WAN virtuale di Azure	L'architettura di rete reale inizia qui. Fuori ambito per la maggior parte dei team in fase di esplorazione.	La multi-regione è un'esigenza concreta, non un obiettivo.

Importante

Blocca Microsoft Entra ID e le assegnazioni di ruolo nella sottoscrizione prima di occuparti dell'isolamento di rete. La maggior parte degli incidenti di sicurezza in Azure nelle piccole aziende deriva da un'identità con autorizzazioni eccessive, non da un'esposizione della rete. Usate i gruppi di Microsoft Entra ID per l'accesso del team di ingegneria e non assegnate il ruolo "Owner" a livello di sottoscrizione.

Archiviazione: BLOB, file e dischi

Archiviazione di Azure è un singolo tipo di risorsa (l'account di archiviazione) che espone quattro servizi di dati: blob, file, code e tabelle. Per le decisioni relative all'archiviazione delle applicazioni, è quasi sempre possibile scegliere tra BLOB (archiviazione oggetti), file (condivisioni file gestite) e dischi gestiti (archiviazione a blocchi collegata a una macchina virtuale).

Elementi archiviati	Servizio di Azure predefinito	Perché	Ricontrolla quando
File caricati dall'utente, report generati, log, artefatti del modello, backup	Archiviazione BLOB di Azure (livello di accesso caldo)	Archiviazione oggetti. Economico, durevole, scalabile fino a petabyte. Usa in seguito i livelli ad accesso sporadico o di archiviazione per i dati a cui non accedi spesso.	È necessaria la semantica del file POSIX o la scrittura casuale in un singolo file da più computer.
Un file system condiviso montato da più macchine virtuali o contenitori	File di Azure (Standard) o Azure NetApp Files (velocità effettiva elevata)	Volumi condivisi SMB (Server Message Block) o NFS (Network File System). Evitare di usarli per il contenuto adatto al modello BLOB.	Si inizia a usare una condivisione file come coda o un database. Passare alla primitiva destra.
Dischi per una macchina virtuale	Dischi gestiti SSD Premium v2	Prestazioni regolabili, buon rapporto prezzo-prestazioni per i dischi per applicazioni. L'unità SSD Premium v2 non può essere usata come disco del sistema operativo; associarlo a SSD Premium (v1) o SSD Standard per il sistema operativo. L'unità SSD Standard è accettabile per carichi di lavoro a bassa velocità effettiva.	È necessaria l'archiviazione a blocchi condivisa tra macchine virtuali (usare SAN di Elastic in Azure o Azure NetApp Files).
Asset di siti Web statici (bundle di applicazioni a pagina singola, sito di marketing, documentazione)	Archiviazione di Azure hosting di siti Web statici + Frontdoor di Azure	App Web statiche è l'impostazione predefinita moderna: domini personalizzati predefiniti, TLS gestito gratuito, distribuzione globale, GitHub Actions CI/CD e autenticazione predefinita. Il sito Web statico di archiviazione e Frontdoor funziona ancora per configurazioni a basso costo, ma non supporta in modo nativo intestazioni o autenticazioni personalizzate.	Aggiungi pagine renderizzate sul server. Passare a App Service o a Container Apps.

Note

Gli account di archiviazione hanno un limite flessibile di 250 per area per sottoscrizione (che può essere impostato su 500 per richiesta). È più che sufficiente per i team nelle fasi iniziali. L'errore da evitare è la creazione di un account di archiviazione per ogni microservizio; raggruppare per ambiente (produzione, gestione temporanea, sviluppo) e per modello di accesso (ad accesso frequente, ad accesso sporadico, archivio).

Nota sui backup

Backup di Azure e le opzioni di ridondanza dell'account di archiviazione (archiviazione con ridondanza locale, archiviazione con ridondanza della zona, archiviazione con ridondanza geografica) sono ottimizzabili per ogni account e per disco. L'archiviazione con ridondanza locale è adatta per lo sviluppo e la gestione temporanea. Usa l'archiviazione con ridondanza della zona (ZRS) per i dati di produzione. L'archiviazione con ridondanza geografica aggiunge costi e non sostituisce il ripristino di emergenza a livello di applicazione.

Contenitori e servizio Azure Kubernetes

Azure offre tre modi per eseguire i contenitori nell'ambiente di produzione: App contenitore di Azure, Istanze di Azure Container e servizio Azure Kubernetes. Corrispondono a diverse dimensioni del team e propensioni operative.

La tua situazione	Servizio di Azure predefinito	Perché	Quando inizia a ferire
Sono disponibili immagini del contenitore e si vuole un runtime gestito con ingresso HTTPS, scalabilità a zero e revisioni	App contenitore di Azure	Piattaforma serverless in Kubernetes con scalabilità automatica KEDA, ma non viene visualizzato o gestito il cluster. Paga solo per ciò che utilizzi. Va bene finché non si incontrano requisiti a livello di cluster. Dapr è disponibile come integrazione con consenso esplicito.	Sono necessari utilità di pianificazione personalizzate, funzionalità di rete avanzate (più schede di interfaccia di rete, plug-in dell'interfaccia di rete di Contenitori personalizzati) o operatori Kubernetes specifici.
Si vuole eseguire un singolo contenitore come processo monouso o un batch breve	Istanze di Azure Container	Percorso più rapido dall'immagine al container in esecuzione. Nessuna orchestrazione. Addebitato per secondo di esecuzione.	È necessario disporre di qualsiasi elemento simile a una mesh di servizi o di scalabilità automatica oltre un singolo contenitore.
Utilizzi già Kubernetes altrove oppure l'architettura della tua applicazione lo richiede davvero	Servizio Azure Kubernetes	Piano di controllo gestito. Usa i tuoi pool di nodi, il plug-in di rete, il controller Ingress e il tuo stack di osservabilità.	Primo giorno. Pianificare gli aggiornamenti in corso (versione secondaria rilasciata ogni 4 mesi), l'ottimizzazione del pool di nodi e la gestione dei certificati.
Non si è certi se è necessario Kubernetes	App contenitore per il momento	È possibile ricompilare in servizio Azure Kubernetes in un secondo momento, se necessario. La migrazione di un'applicazione containerizzata senza stato richiede giorni di lavoro, non settimane.	Hai un'esigenza concreta che puoi definire (ecosistema di operatori, criterio a livello di cluster). “a prova di futuro” non è un’esigenza concreta.

Quando passare ad AKS

Passare a Servizio Azure Kubernetes (AKS) quando almeno due di queste sono vere:

• Esegui più di dieci servizi con un ciclo di vita condiviso e requisiti di rete comuni.
• Hai bisogno di controller personalizzati, sidecar o definizioni di risorse personalizzate (CRD) che Container Apps non espone.
• È necessaria un'integrazione approfondita della rete virtuale con un'imposizione rigorosa dei criteri.
• Si sta standardizzando un ecosistema di open source basato su Kubernetes (Argo, Istio, KEDA e così via).

Se adotti AKS, segui l'architettura di base di AKS. Il Microsoft Azure Well-Architected Framework e il riferimento alla baseline del servizio Azure Kubernetes coprono insieme le impostazioni predefinite di sicurezza, ridimensionamento e aggiornamento desiderate.

Impostazioni predefinite di AKS per un team piccolo

Setting	Impostazione predefinita	Perché
Dimensioni nodo	pool di sistema Standard_D4s_v5, pool di utenti Standard_D8s_v5	Rapporto prezzo-prestazioni prevedibile per i carichi di lavoro generici
Ridimensionamento automatico del cluster	Enabled	Evitare di pagare nodi inattivi
Identità del carico di lavoro	Enabled	Sostituisce l'identità dei pod, si integra con Microsoft Entra ID
Criteri di Azure componente aggiuntivo	Enabled	Vincoli gratuiti (niente container privilegiati, etichette obbligatorie)
Informazioni dettagliate sui contenitori	Enabled	Metriche e log di prima classe in Monitoraggio di Azure
Cluster privato	Attivato per la produzione	Piano di controllo raggiungibile solo dalla rete virtuale

Registro dei container di Azure

Indipendentemente dalla piattaforma di calcolo selezionata, archiviare le immagini in Registro Azure Container. Il livello Basic è sufficiente per i team in fase iniziale. Usare un registro separato per ambiente (produzione, gestione temporanea) se si vuole un isolamento rigido o un singolo registro con repository separati e il controllo degli accessi in base al ruolo se si vuole semplicità.

Piattaforma dati: relazionale, documento, vettore, analisi

Le decisioni relative alla piattaforma dati sono quelle che probabilmente saranno permanenti. Lo schema fornito al mese 1 forma ogni caratteristica per i due anni successivi. Scegli un valore predefinito sufficientemente flessibile da crescere con il prodotto e resisti alla tentazione di pre-selezionare un database specializzato per una funzionalità che non hai ancora compilato.

Carico di lavoro	Servizio di Azure predefinito	Perché	Ricontrolla quando
Dati dell'applicazione transazionale (utenti, ordini, contenuto) con uno schema relazionale noto	Database di Azure per PostgreSQL (server flessibile)	Maturo, ben conosciuto, con un solido ecosistema di estensioni (incluso pgvector per gli embedding). Il livello burstable è abbastanza economico per lo sviluppo e la pre-produzione.	Modelli di scrittura multiregione o di lettura su scala ipergrande. Prendere in considerazione Azure Cosmos DB per PostgreSQL.
Dati operativi con schema flessibile, distribuzione globale, letture prevedibili a singola cifra di millisecondi	Azure Cosmos DB (API NoSQL)	Multiregione per impostazione predefinita. Il livello serverless è abbastanza economico da iniziare. La progettazione delle partizioni è importante; leggi le linee guida sulla chiave di partizione prima del rilascio.	Stai forzando i join relazionali a livello di applicazione. PostgreSQL è probabilmente la risposta giusta.
Cercare tra contenuti strutturati e non strutturati, inclusa la generazione aumentata dal recupero	Ricerca di intelligenza artificiale di Azure	Parola chiave ibrida e ricerca vettoriale. Si integra con Servizio Azure OpenAI e Cosmos DB. Il livello gratuito esiste per la creazione di prototipi.	Hai superato i limiti degli indici per livello (Standard 1 è una comune opzione di aggiornamento).
Incorporamenti vettoriali per una funzionalità di generazione aumentata del recupero	Iniziare con pgvector in PostgreSQL o Azure AI Search	Evitare un database vettoriale separato per la prima versione di una funzionalità di recupero. Si apprenderà cosa è effettivamente necessario (filtro, ricerca ibrida, scalabilità) dall'utilizzo reale.	Hai caratterizzato i modelli di lettura e i vincoli giustificano un motore specializzato.
Analisi, creazione di report e query ad hoc sui dati di produzione	Database di Azure per PostgreSQL replica di lettura (Esplorazione), Microsoft Fabric (Espansione ed estrazione)	Una replica in lettura è sufficiente per la maggior parte delle attività di analisi nella fase di esplorazione. Microsoft Fabric è la moderna piattaforma di analisi quando quella soluzione non è più sufficiente.	Le repliche di lettura non riescono a tenere il passo oppure gli stakeholder aziendali hanno bisogno di una piattaforma di analisi self-service.
Livello di cache posto davanti a un database	cache di Azure per Redis (livello Basic)	Primitiva di memorizzazione nella cache standard. Economico da aggiungere in seguito; non aggiungere speculativamente.	Si nota un evidente pattern di lettura intensiva che sta saturando il database. Misura prima di aggiungere.

Importante

Selezionare un database predefinito e rimanere su di esso per tutto il tempo possibile. Un team di quindici ingegneri che gestisce PostgreSQL, Cosmos DB, Redis, la ricerca basata sull’IA, un sistema di code e un database a grafo si è accidentalmente ritrovato ad accollarsi un carico di lavoro da team di piattaforma.

Dove Servizio Azure OpenAI si adatta

Servizio Azure OpenAI non è una piattaforma dati, ma condivide lo stesso ritmo decisionale. La maggior parte delle startup che sviluppano una funzionalità di intelligenza artificiale generativa inizia con la distribuzione di un modello (un recente modello di completamento della chat) in una singola area geografica, oltre ad AI Search o pgvector per il recupero. Non è necessaria una pipeline di ottimizzazione dedicata, un gateway modello o più distribuzioni finché l'utilizzo non indica di aggiungerli.

Cosa descrive questo articolo (e cosa non lo fa)

Argomento	In questo articolo	Quando aggiungerlo
Gestione delle identità e degli accessi oltre le nozioni di base	No	Primo giorno per la configurazione Microsoft Entra ID. Accesso condizionale e Privileged Identity Management quando si dispone di una verifica della sicurezza delle informazioni.
Infrastruttura distribuita come codice (Bicep, Terraform)	No	Quando le modifiche manuali del portale iniziano a differenziarsi tra i vari ambienti. Di solito quando si aggiunge un ambiente di staging.
Pipeline di integrazione continua e di distribuzione continua	No	Primo giorno. GitHub Actions o pipeline di Azure DevOps sono entrambe appropriate.
Osservabilità (log, metriche, tracce)	No	Application Insights dal primo giorno. Workbook di Monitoraggio di Azure in caso di sovraccarico di avvisi.
Gestione dei costi	No	Imposta un budget a livello di sottoscrizione fin dal primo giorno. Assegnare tag alle risorse relativi all'ambiente e al proprietario fin dall'inizio.
Conformità (SOC 2, ISO 27001, HIPAA)	No	Quando un cliente chiede. Microsoft Defender per il cloud dispone di un dashboard di conformità che esegue il mapping dei controlli alle risorse Azure.
Ripristino di emergenza e più aree	No	Quando il costo di un'ora di inattività supera il costo di progettazione della seconda area.

Quando le impostazioni predefinite della piattaforma non sono più sufficienti

Questi segnali di crescita indicano che una specifica impostazione predefinita deve essere sostituita con una soluzione più ponderata:

• Sono stati distribuiti più di cinque servizi distinti in App Service o Container Apps e il dimensionamento per servizio sta diventando una preoccupazione quotidiana. Esamina servizio Azure Kubernetes.
• La fattura mensile Azure è in crescita più rapida rispetto ai ricavi mensili per due mesi in una riga. È il momento di una revisione della gestione dei costi e di un’analisi delle istanze riservate o dei piani di risparmio.
• La rete virtuale si estende ora su più sottoscrizioni o aree. Esamina rete WAN virtuale di Azure e una topologia hub-and-spoke.
• Una singola istanza di PostgreSQL non può mantenere in memoria l'insieme di lavoro e le repliche di lettura non colmano il divario. Esaminare Cosmos DB per PostgreSQL o un'architettura partizionata.
• Le query di analisi nel database di produzione influiscono notevolmente sulla latenza dell'applicazione. Spostare l'analisi in Microsoft Fabric.
• Stai utilizzando più di due account di archiviazione per ambiente per lo stesso modello di accesso. Consolida.
• È stato aggiunto un paese terzo con clienti a pagamento. È ora di valutare una seconda regione, l'archiviazione con ridondanza geografica e una strategia di routing con Front Door.

Note

Resistere alla tentazione di adottare gli strumenti della piattaforma aziendale in anticipo. La maggior parte dei pattern sopra citati (service mesh, architetture active-active multi-region, strumenti FinOps, operatori Kubernetes personalizzati) aumenta la complessità operativa e conviene solo su larga scala. Aggiungerli quando si dispone del team necessario per mantenerli, non prima.

Elenco di controllo di riferimento

Eseguire questa operazione una volta al mese per i primi sei mesi di Azure. Rileva la deriva più comune.

• Una sottoscrizione per ambiente (produzione, gestione temporanea, sviluppo) o una sottoscrizione con gruppi di risorse rigorosi per ogni ambiente. Non mescolare.
• Ogni risorsa viene etichettata con l'ambiente, il proprietario e il centro di costo (anche se oggi il centro di costo ha lo stesso valore per tutte).
• Un budget a livello di sottoscrizione con avvisi impostati al 50%, 80% e 100% dell'obiettivo mensile in Cost Management.
• I gruppi di Microsoft Entra ID, non i singoli utenti, detengono assegnazioni di ruolo sui gruppi di risorse. Nessun Proprietario attivo a livello di sottoscrizione.
• Application Insights o Monitoraggio di Azure è abilitato in ogni risorsa di calcolo di produzione.
• I backup del database di produzione vengono verificati da un test di ripristino documentato (almeno una volta).
• I segreti si trovano in Azure Key Vault, non nella configurazione dell'applicazione. Usare le identità gestite per il percorso tra le risorse di calcolo e Key Vault.
• Le immagini del contenitore vengono analizzate (Microsoft Defender per i contenitori o lo scanner predefinito del Registro di sistema).