Veel lessen die u in grotere bedrijven leert, zijn niet rechtstreeks van toepassing op de eerste stack van een startup. In de eerste verkenningsfase van een product moet u de implementatie optimaliseren voor snelheid, kosten en optioneel. Optioneel verwijst naar hoe snel u de richtingen binnen een bepaalde architectuur kunt wijzigen.
Een bedrijf in de uitbreidings - of extractfasen van productontwikkeling kan gebruikmaken van een servicegerichte of microservicesarchitectuur. Dit type implementatiearchitectuur is zelden geschikt voor een startup die nog geen product/markt passend of commercieel tractie heeft gevonden.
Voor een kernstartstack is een eenvoudig monolithisch ontwerp het beste. Dit ontwerp beperkt de tijd die nodig is om de infrastructuur te beheren en biedt voldoende mogelijkheden om te schalen naarmate het opstarten meer klanten wint.
Potentiële gebruikscases
In dit artikel vindt u een voorbeeld van een eenvoudige opstartstack voor kernen en worden de bijbehorende onderdelen besproken.
Architectuur
Een startup, Contoso, heeft een prototype van een toepassing gebouwd met een Ruby on Rails-back-end en een React-front-end die is geschreven in TypeScript. Het Contoso-team voert demo's uit op hun laptops. Nu willen ze hun app implementeren voor hun eerste verkoopvergaderingen van klanten.
Hoewel de app ambitieus is, heeft deze nog geen complexe, microservicegestuurde architectuur nodig. Contoso heeft gekozen voor een eenvoudig monolithisch ontwerp dat de aanbevolen opstartstackonderdelen bevat.
Een Visio-bestand van deze architectuur downloaden.
Gegevensstroom
In deze kernarchitectuur van de opstartstack:
- Azure-app Service biedt een eenvoudige app-server voor het implementeren van schaalbare toepassingen zonder servers, load balancers of andere infrastructuur te configureren.
- Azure Database for PostgreSQL is een Azure-databaseservice voor een toonaangevend opensource relationeel databasebeheersysteem (RDBMS). U kunt zich concentreren op het ontwikkelen van uw toepassing in plaats van databaseservers te beheren.
- Azure Virtual Network segmentert netwerkverkeer en houdt interne services beschermd tegen internetbedreigingen. Uw app-servers gebruiken integratie van virtuele netwerken om te communiceren met de database zonder blootstelling aan internet.
- GitHub Actions bouwt continue integratie en continue implementatie (CI/CD) in uw broncodebeheer. GitHub Actions biedt uitgebreide ondersteuning voor verschillende talen en sterke integratie met Azure-services.
- Azure Blob Storage slaat statische assets op en verplaatst de belasting van de app-servers.
- Azure Content Delivery Network (CDN) versnelt de levering van inhoud aan gebruikers via een wereldwijd netwerk.
- Azure Monitor bewaakt en analyseert wat er gebeurt in de infrastructuur van uw toepassing.
Belangrijkste opstartstackonderdelen
Een complexe stack kan fouten genereren die constante aandacht vereisen. Een geavanceerde architectuur kan aftrekken van het bouwen van uw product. Bugs worden niet veroorzaakt door complexiteit, maar een complexe stack maakt het eenvoudiger om bugs te verzenden. Niet alle geavanceerde architecturen zijn een verspilling van energie, maar ze verspillen uw resources als u nog geen product/markt passend hebt gevonden. Uw eerste opstartstack moet eenvoudig zijn en uit de weg gaan, zodat u zich kunt concentreren op productontwikkeling.
In het volgende eenvoudige diagram ziet u de aanbevolen kernstartstack. Deze onderdelen zijn voldoende om uw product van de grond te krijgen en in handen van uw klanten te krijgen. Voor 80 procent van de startups is deze stack alles wat u nodig hebt om de basishypotheses te testen die in uw product zijn ingebouwd. Start-ups die werken in machine learning, internet of things (IoT) of sterk gereglementeerde omgevingen vereisen mogelijk meer onderdelen.
CDN
Met weinig klanten aan het begin lijkt een CDN misschien voortijdig. Het toevoegen van een CDN aan een product dat al in productie is, kan echter onverwachte bijwerkingen hebben. Het is raadzaam om een CDN vooraf te implementeren. Een CDN slaat statische inhoud dichter bij uw klanten op en biedt een gevel waarachter u uw API's en uw architectuur kunt herhalen.
App-server
Uw code moet ergens worden uitgevoerd. In het ideale geval moet dit platform implementaties eenvoudig maken, terwijl de minst mogelijke operationele invoer is vereist. De app-server moet horizontaal worden geschaald, maar een aantal handmatige schaalaanpassingen is prima terwijl u zich nog in de verkenningsfase bevindt.
Net als bij de meeste van deze stack moet de app-server zichzelf in wezen uitvoeren. Traditioneel was de app-server een virtuele machine of een webserverexemplaren die worden uitgevoerd op een bare-metalserver. U kunt nu kijken naar PaaS-opties (Platform-as-a-Service) en containers om operationele overhead te verwijderen.
Statische inhoud
Het leveren van statische inhoud van uw app-server verspilt resources. Zodra u een CI/CD-pijplijn hebt geconfigureerd, is het werk voor het bouwen en implementeren van statische assets met elke release triviaal. De meeste webframeworks voor productie implementeren statische assets met CI/CD, dus het is de moeite waard om te beginnen met het afstemmen op deze best practice.
Database
Zodra uw app wordt uitgevoerd, moet u uw gegevens opslaan in een database. In de meeste gevallen is een relationele database de beste oplossing. Een relationele database heeft meerdere toegangsmethoden en de snelheid van een op tijd geteste oplossing. Relationele databases omvatten Azure SQL Database, Azure Database for PostgreSQL en Azure Database for MariaDB. Sommige gebruiksvoorbeelden hebben een documentdatabase of NoSQL-database nodig, zoals MongoDB of Azure Cosmos DB.
Logboekaggregatie
Als er iets misgaat met uw app, wilt u zo weinig mogelijk tijd besteden aan het diagnosticeren van het probleem. Door logboeken samen te voegen en toepassingstracering vanaf het begin te gebruiken, helpt u uw team zich te concentreren op de problemen zelf. U hoeft geen toegang te krijgen tot een bestand op de app-server en logboeken te pororeren om bewakingsgegevens op te halen.
CI/CD
Het ontbreken van herhaalbare en snelle implementaties is een van de ergste belemmeringen om te versnellen wanneer u een product herhaalt. Een goed geconfigureerde CI/CD-pijplijn stroomlijnt het implementatieproces voor code op uw app-server. Snelle en eenvoudige implementaties betekenen dat u snel de resultaten van uw arbeid ziet. Regelmatige integratie vermijdt uiteenlopende codebasissen die leiden tot samenvoegingsconflicten.
Dit scenario implementeren
De concepten en technieken zijn hetzelfde voor de meeste projecten die u bouwt met behulp van een Dockerfile.
Bijdragers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Andrew Harvey | CTO en Startup Advocate