Molte lezioni apprese nelle aziende più grandi non sono direttamente applicabili al primo stack di una startup. Nella fase iniziale di esplorazione di un prodotto, è necessario ottimizzare la distribuzione per velocità, costi e facoltatività. La facoltatività si riferisce alla velocità con cui è possibile modificare le direzioni all'interno di una determinata architettura.
Un'azienda in fase di espansione o estrazione dello sviluppo di prodotti può usare un’architettura orientata ai servizi o di microservizi. Questo tipo di architettura di distribuzione raramente è adatta a una startup che non ha ancora trovato una collocazione di prodotto/mercato o una trazione commerciale.
Per uno stack per startup di base, è meglio una progettazione monolitica semplice. Questa progettazione limita il tempo impiegato per la gestione dell'infrastruttura, offrendo al contempo ampi margini di scalabilità man mano che la startup acquisisce più clienti.
Potenziali casi d'uso
Questo articolo presenta un esempio di un semplice stack per startup di base e ne illustra i componenti.
Architettura
Una startup, Contoso, ha creato un prototipo di applicazione con un back-end Ruby on Rails e un front-end React scritto in TypeScript. Il team di Contoso ha eseguito varie demo sui portatili. Ora desidera distribuire l'app per le prime riunioni di vendita con i clienti.
Nota
Le scelte tecnologiche disponibili in Ruby, React e TypeScript sono solo illustrative. Questa architettura di avvio si applica allo stesso modo a molti altri linguaggi e framework.
Anche se l'app è articolata, non ha ancora bisogno di un'architettura complessa basata su microservizi. Contoso ha optato per una progettazione monolitica semplice che include i componenti dello stack per startup consigliati.
Scaricare un file di Visio di questa architettura.
Flusso di dati
In questa architettura dello stack per startup di base:
- Servizio app di Azure fornisce un server app semplice per distribuire applicazioni scalabili senza configurare server, servizi di bilanciamento del carico o altre infrastrutture. servizio app supporta le distribuzioni di contenitori come nell'esempio qui e supporta anche distribuzioni senza contenitore per ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP o Python.
- Database di Azure per PostgreSQL è un servizio di database di Azure per un sistema di gestione di database relazionali open source (RDBMS) leader del settore. È possibile concentrarsi sullo sviluppo dell'applicazione anziché sulla gestione dei server di database. Azure dispone anche di servizi di database gestiti per SQL, MySQL, MariaDB, MongoDB, Apache Cassandra, Gremlin e Redis.
- Rete virtuale di Azure segmenta il traffico di rete e protegge i servizi interni dalle minacce di Internet. I server app usano l’integrazione della rete virtuale per comunicare con il database senza esposizione a Internet.
- GitHub Actions crea integrazione continua e distribuzione continua (CI/CD) nella gestione del codice sorgente. GitHub Actions include un ampio supporto per linguaggi diversi e una solida integrazione con i servizi di Azure.
- Archiviazione BLOB di Azure archivia gli asset statici e sposta il carico dai server app.
- Frontdoor di Azure con WAF accelera e protegge la distribuzione di contenuti agli utenti tramite una rete per la distribuzione di contenuti globale (CDN) e web application firewall.
- Monitoraggio di Azure monitora e analizza quanto accade nell'infrastruttura dell'applicazione.
Componenti dello stack per startup di base
Uno stack complesso può generare bug che richiedono un'attenzione costante. Un'architettura sofisticata potrebbe influire negativamente sulla creazione del prodotto. I bug non sono causati dalla complessità, ma con uno stack complesso è più facile che siano presenti dei bug. Non tutte le architetture sofisticate sono uno spreco di energie, ma possono costituire uno spreco di risorse se non si è ancora trovata una collocazione di prodotto/mercato. Il primo stack per startup deve essere semplice e non rappresentare un ostacolo, in modo da potersi concentrare sullo sviluppo di prodotti.
Il diagramma semplice seguente illustra lo stack per startup di base consigliato. Questi componenti sono sufficienti per lanciare il prodotto e distribuirlo ai clienti. Per l'80% delle startup, questo stack è tutto ciò che serve per testare le ipotesi di base integrate nel prodotto. Le startup che lavorano in ambienti altamente regolamentati, apprendimento automatico o Internet delle cose (IoT) potrebbero richiedere più componenti.
Rete CDN
Con pochi clienti iniziali, una rete CDN potrebbe sembrare prematura. Tuttavia, l'aggiunta di una rete CDN a un prodotto già in produzione può avere effetti collaterali imprevisti. Pertanto, è consigliabile implementare una rete CDN sin dall’inizio. Una rete CDN memorizza nella cache il contenuto statico più vicino ai clienti e fornisce un’interfaccia dietro la quale è possibile eseguire l'iterazione di API e architettura.
Server app
Il codice deve essere eseguito. Idealmente, questa piattaforma dovrebbe semplificare le distribuzioni, richiedendo al contempo il minor input operativo possibile. Il server app deve essere ridimensionato orizzontalmente, ma possono essere effettuati alcuni interventi di ridimensionamento manuale mentre si è ancora in fase di esplorazione.
Come per la maggior parte dei componenti di questo stack, il server app deve essenzialmente essere eseguito autonomamente. Tradizionalmente, il server app era una macchina virtuale o un'istanza del server Web in esecuzione su un server bare metal. È ora possibile esaminare le opzioni PaaS (Platform-as-a-Service), ad esempio servizio app sopra e i contenitori, per rimuovere il sovraccarico operativo.
Contenuto statico
La gestione di contenuto statico dal server app spreca risorse. Dopo aver configurato una pipeline CI/CD, il lavoro per compilare e distribuire asset statici con ogni versione è molto semplice. La maggior parte dei framework Web di produzione distribuisce asset statici con CI/CD, quindi conviene iniziare seguendo questa procedura consigliata.
Database
Una volta che l'app è in esecuzione, è necessario archiviare i dati in un database. Nella maggior parte dei casi, un database relazionale è la soluzione migliore. Un database relazionale ha diversi meccanismi di accesso e la velocità di una soluzione testata nel tempo. I database relazionali includono database SQL di Azure, Database di Azure per PostgreSQL e Database di Azure per MariaDB. Alcuni casi d'uso necessitano di un database di documenti o NoSQL come MongoDB o Azure Cosmos DB.
Aggregazione di log
Se si verificano errori nell'app, si vuole dedicare meno tempo possibile alla diagnosi del problema. Aggregando i log e usando la traccia delle applicazioni fin dall'inizio, il team può concentrarsi sui problemi. Non è necessario accedere a un file nel server app e controllare attentamente i log per ottenere i dati di monitoraggio.
CI/CD
La mancanza di distribuzioni ripetibili e rapide è uno dei peggiori impedimenti a procedere velocemente quando si esegue l'iterazione di un prodotto. Una pipeline CI/CD configurata correttamente semplifica il processo di distribuzione del codice nel server app. Con distribuzioni rapide e semplici i risultati del lavoro sono immediatamente visibili. L'integrazione frequente evita basi di codice divergenti che causano conflitti di unione. I concetti e le tecniche sono gli stessi per la maggior parte dei progetti compilati usando un Dockerfile.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Andrew Harvey | CTO e Startup Advocate
Altri contributori:
- Nick Ward | Cloud Solution Architect