Många lärdomar som du lär dig i större företag gäller inte direkt för en startups första stack. I en produkts inledande utforskandefas måste du optimera distributionen för hastighet, kostnad och valfrihet. Valfrihet avser hur snabbt du kan ändra riktningar inom en viss arkitektur.
Ett företag i utvecklings - eller extraheringsfaserna för produktutveckling kan använda en tjänstorienterad arkitektur eller mikrotjänstarkitektur. Den här typen av distributionsarkitektur är sällan rätt för en startup som ännu inte har hittat produkt-/marknadsanpassning eller kommersiell dragkraft.
För en kärnstartsstack är en enkel monolitisk design bäst. Den här designen begränsar den tid som ägnas åt att hantera infrastrukturen, samtidigt som du kan skala när starten vinner fler kunder.
Potentiella användningsfall
Den här artikeln visar ett exempel på en enkel kärnstartsstack och diskuterar dess komponenter.
Arkitektur
En startup, Contoso, har skapat en programprototyp med en Ruby on Rails-serverdel och en React-klientdel skriven i TypeScript. Contoso-teamet har kört demonstrationer på sina bärbara datorer. Nu vill de distribuera sin app för sina första kundförsäljningsmöten.
Även om appen är ambitiös behöver den ännu inte någon komplex, mikrotjänstdriven arkitektur. Contoso valde en enkel monolitisk design som innehåller de rekommenderade komponenterna för startstacken.
Ladda ned en Visio-fil med den här arkitekturen.
Dataflöde
I den här kärnarkitekturen för startstacken:
- Azure App Service tillhandahåller en enkel appserver för att distribuera skalbara program utan att konfigurera servrar, lastbalanserare eller annan infrastruktur.
- Azure Database for PostgreSQL är en Azure-databastjänst för ett ledande relationsdatabashanteringssystem med öppen källkod (RDBMS). Du kan koncentrera dig på att utveckla ditt program i stället för att hantera databasservrar.
- Azure Virtual Network segmentar nätverkstrafik och håller interna tjänster skyddade mot internethot. Appservrarna använder integrering av virtuella nätverk för att kommunicera med databasen utan att exponeras för Internet.
- GitHub Actions skapar kontinuerlig integrering och kontinuerlig distribution (CI/CD) i din källkodshantering. GitHub Actions har omfattande stöd för olika språk och stark integrering med Azure-tjänster.
- Azure Blob Storage lagrar statiska tillgångar och flyttar belastningen från appservrarna.
- Azure Content Delivery Network (CDN) påskyndar innehållsleveransen till användare via ett globalt nätverk.
- Azure Monitor övervakar och analyserar vad som händer i programmets infrastruktur.
Viktiga komponenter för startstacken
En komplex stack kan generera buggar som kräver konstant uppmärksamhet. En sofistikerad arkitektur kan förringa skapandet av din produkt. Buggar orsakas inte av komplexitet, men en komplex stack gör det enklare att skicka buggar. Inte alla avancerade arkitekturer är slöseri med energi, men de slösar dina resurser om du ännu inte har hittat produkten / marknaden passar. Din första startstacken bör vara enkel och komma ur vägen, så att du kan koncentrera dig på produktutveckling.
Följande enkla diagram visar den rekommenderade startstacken för kärnor. Dessa komponenter räcker för att få din produkt från marken och i händerna på dina kunder. För 80 procent av nystartade företag är den här stacken allt du behöver för att testa de grundläggande hypoteserna som är inbyggda i din produkt. Nystartade företag som arbetar med maskininlärning, sakernas Internet (IoT) eller strikt reglerade miljöer kan kräva fler komponenter.
CDN
Med få kunder i början kan ett CDN verka förhastat. Men att lägga till ett CDN till en produkt som redan finns i produktion kan ha oväntade biverkningar. Det är bäst att implementera ett CDN i förväg. Ett CDN cachelagrar statiskt innehåll närmare dina kunder och tillhandahåller en fasad bakom vilken du kan iterera på dina API:er och din arkitektur.
Appserver
Koden måste köras någonstans. Helst bör den här plattformen göra distributionerna enkla, samtidigt som du behöver minsta möjliga driftindata. Appservern bör skalas horisontellt, men vissa manuella skalningsåtgärder är bra medan du fortfarande befinner dig i utforska-fasen.
Precis som de flesta i den här stacken bör appservern i princip köra sig själv. Traditionellt sett var appservern en virtuell dator eller en webbserverinstans som kördes på en bare metal-server. Nu kan du titta på paaS-alternativ (platform-as-a-service) och containrar för att ta bort driftkostnaderna.
Statiskt innehåll
Att hantera statiskt innehåll från appservern slösar resurser. När du har konfigurerat en CI/CD-pipeline är arbetet med att skapa och distribuera statiska tillgångar med varje version trivialt. De flesta produktionswebbramverk distribuerar statiska tillgångar med CI/CD, så det är värt att börja med att följa den här bästa praxisen.
Databas
När appen körs måste du lagra dina data i en databas. I de flesta fall är en relationsdatabas den bästa lösningen. En relationsdatabas har flera åtkomstmetoder och hastigheten för en tidstestad lösning. Relationsdatabaser omfattar Azure SQL Database, Azure Database for PostgreSQL och Azure Database for MariaDB. Vissa användningsfall behöver en dokumentdatabas eller NoSQL-databas som MongoDB eller Azure Cosmos DB.
Loggaggregering
Om något går fel med din app vill du ägna så lite tid som möjligt åt att diagnostisera problemet. Genom att aggregera loggar och använda programspårning från början hjälper du ditt team att fokusera på själva problemen. Du behöver inte komma åt en fil på appservern och porera över loggar för att hämta övervakningsdata.
CI/CD
Bristen på repeterbara och snabba distributioner är ett av de värsta hindren för hastighet när du itererar på en produkt. En väl konfigurerad CI/CD-pipeline effektiviserar koddistributionsprocessen på appservern. Snabba och enkla distributioner innebär att du ser resultatet av ditt arbete snabbt. Frekvent integrering undviker avvikande kodbaser som leder till sammanslagningskonflikter.
Distribuera det här scenariot
Begreppen och teknikerna är desamma för de flesta projekt som du skapar med hjälp av en Dockerfile.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Andrew Harvey | CTO och startrådgivare