Viele Lektionen, die Sie in größeren Unternehmen lernen, sind nicht direkt auf den ersten Stapel eines Startups anwendbar. In der ersten Phase der Erkundung eines Produkts müssen Sie die Bereitstellung im Hinblick auf Geschwindigkeit, Kosten und Optionalität optimieren. Optionalität bezieht sich darauf, wie schnell die Richtung innerhalb einer bestimmten Architektur gewechselt werden kann.
Ein Unternehmen, das sich in den Phasen Erweitern oder Extrahieren der Produktentwicklung befindet, könnte eine dienstorientierte oder Microservicearchitektur verwenden. Diese Art der Bereitstellung ist selten die richtige für ein Startup, das noch keine Produkt-/Marktanpassung oder kommerzielle Reichweite gefunden hat.
Für einen zentralen Startupstapel ist ein einfacher monolithischer Entwurf am besten geeignet. Dieses Konzept begrenzt den Zeitaufwand für die Verwaltung der Infrastruktur und bietet gleichzeitig die Möglichkeit zur Skalierung, wenn das Startup mehr Kunden gewinnt.
Mögliche Anwendungsfälle
In diesem Artikel wird ein Beispiel für einen einfachen grundlegenden Startupstapel vorgestellt und seine Komponenten werden erläutert.
Architektur
Das Startup Contoso hat einen Anwendungsprototyp mit einem Ruby on Rails-Back-End und einem in TypeScript geschriebenen React-Front-End erstellt. Das Contoso-Team hat Demos auf seinen Laptops ausgeführt. Jetzt möchten sie ihre App für ihre ersten Verkaufsgespräche mit Kunden bereitstellen.
Die App ist zwar anspruchsvoll, benötigt aber noch keine komplexe, Microservice-gesteuerte Architektur. Contoso hat sich für einen einfachen monolithischen Entwurf entschieden, der die empfohlenen Komponenten für den Startupstapel enthält.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Datenfluss
Folgendes gilt für diese grundlegende Stapelarchitektur für Startups:
- Azure App Service bietet einen einfachen App-Server für die Bereitstellung skalierbarer Anwendungen, ohne dass Server, Lastenausgleiche oder andere Infrastrukturen konfiguriert werden müssen.
- Azure Database for PostgreSQL ist ein Azure-Datenbankdienst für ein führendes Open-Source-Managementsystem für relationale Datenbanken (RDBMS). Sie können sich auf die Entwicklung Ihrer Anwendung konzentrieren, anstatt Datenbankserver zu verwalten.
- Azure Virtual Network segmentiert den Datenverkehr im Netzwerk und schützt die internen Dienste vor Bedrohungen aus dem Internet. Ihre App-Server verwenden eine virtuelle Netzwerkintegration für die Kommunikation mit der Datenbank, ohne sie im Internet verfügbar zu machen.
- GitHub Actions erstellt Continuous Integration und Continuous Delivery (CI/CD) für Ihre Quellcodeverwaltung. GitHub Actions bietet umfassende Unterstützung für verschiedene Sprachen und eine starke Integration in Azure-Dienste.
- Azure Blob Storage speichert statische Ressourcen und verlagert die Last nicht auf die App-Server.
- Azure Content Delivery Network (CDN) beschleunigt die Bereitstellung von Inhalten für Benutzer über ein globales Netzwerk.
- Azure Monitor überwacht und analysiert die Vorgänge in der Infrastruktur Ihrer Anwendung.
Grundlegende Komponenten des Startupstapels
Ein komplexer Stapel kann zu Fehlern führen, die ständige Aufmerksamkeit erfordern. Eine anspruchsvolle Architektur kann vom Erstellen Ihres Produkts ablenken. Fehler werden nicht durch Komplexität verursacht, aber ein komplexer Stapel gestaltet es einfacher, dass Fehler ausgeliefert werden. Nicht alle anspruchsvollen Architekturen stellen eine Energieverschwendung dar, aber sie verschwenden Ihre Ressourcen, wenn Sie noch nicht die Produkt-/Marktanpassung gefunden haben. Ihr erster Startupstapel sollte einfach sein und Sie nicht ablenken, sodass Sie sich auf die Produktentwicklung konzentrieren können.
Das folgende einfache Diagramm zeigt den empfohlenen grundlegenden Startupstapel. Diese Komponenten reichen aus, um Ihr Produkt auf den Weg zu bringen und es in die Hände Ihrer Kunden zu geben. Für 80 Prozent der Startups reicht dieser Stapel aus, um die grundlegenden Hypothesen zu testen, die in ihr Produkt integriert wurden. Startups, die in den Bereichen maschinelles Lernen, Internet der Dinge (IoT) oder in stark regulierten Umgebungen arbeiten, benötigen möglicherweise mehr Komponenten.
CDN
Da es zu Beginn nur wenige Kunden gibt, könnte ein CDN verfrüht erscheinen. Das Hinzufügen eines CDN zu einem bereits in Produktion befindlichen Produkt kann jedoch unerwartete Nebeneffekte haben. Am besten ist es, ein CDN im Voraus zu implementieren. Ein CDN speichert statische Inhalte näher bei Ihren Kunden und bietet eine Fassade, hinter der Sie Ihre APIs und Ihre Architektur weiterentwickeln können.
App-Server
Ihr Code muss irgendwo ausgeführt werden. Idealerweise sollte diese Plattform die Bereitstellung einfach gestalten und dabei so wenig wie möglich an betrieblichem Aufwand erfordern. Der App-Server sollte horizontal skaliert werden, aber ein gewisser manueller Eingriff in die Skalierung ist angemessen, solange Sie sich noch in der Erkundungsphase befinden.
Wie der größte Teil dieses Stapels sollte sich auch der App-Server im Wesentlichen selbst ausführen. Traditionell war der App-Server ein virtueller Computer oder eine Webserverinstanz, die auf einem Bare-Metal-Server ausgeführt wurde. Jetzt können Sie auf PaaS-Optionen (Platform as a Service) und Container zurückgreifen, um den operativen Mehraufwand zu beseitigen.
Statischer Inhalt
Die Bereitstellung statischer Inhalte von Ihrem App-Server verschwendet Ressourcen. Sobald Sie eine CI/CD-Pipeline konfiguriert haben, ist das Erstellen und Bereitstellen von statischen Ressourcen bei jedem Release trivial. Die meisten Webframeworks in der Produktionsumgebung stellen statische Ressourcen mit CI/CD bereit, sodass es sich lohnt, sich zunächst an dieser bewährten Methode zu orientieren.
Datenbank
Sobald Ihre App ausgeführt ist, müssen Sie Ihre Daten in einer Datenbank speichern. Für die meisten Fälle ist eine relationale Datenbank die beste Lösung. Eine relationale Datenbank bietet mehrere Zugriffsmethoden und die Geschwindigkeit einer bewährten Lösung. Zu den relationalen Datenbanken gehören Azure SQL-Datenbank, Azure Database for PostgreSQL und Azure Database for MariaDB. Einige Anwendungsfälle benötigen eine Dokumentdatenbank oder NoSQL-Datenbank wie MongoDB oder Azure Cosmos DB.
Protokollaggregation
Wenn bei Ihrer App Probleme auftreten, möchten Sie so wenig Zeit wie möglich mit der Diagnose des Problems verbringen. Indem Sie Protokolle aggregieren und von Anfang an die Nachverfolgung von Anwendungen verwenden, helfen Sie Ihrem Team, sich auf die eigentlichen Probleme zu konzentrieren. Sie müssen nicht auf eine Datei auf dem App-Server zugreifen und Protokolle durchforsten, um Überwachungsdaten zu erhalten.
CI/CD
Der Mangel an wiederholbaren und schnellen Bereitstellungen ist eines der schlimmsten Probleme für die Geschwindigkeit bei der Iteration eines Produkts. Eine gut konfigurierte CI/CD-Pipeline rationalisiert den Prozess der Bereitstellung von Code auf Ihrem App-Server. Eine schnelle und einfache Bereitstellung bedeutet, dass Sie die Ergebnisse Ihrer Arbeit schnell präsentiert bekommen. Durch häufige Integration werden abweichende Codebasen vermieden, die zu Konflikten bei der Zusammenführung führen.
Bereitstellen dieses Szenarios
Die Konzepte und Verfahren sind für die meisten Projekte, die Sie mithilfe einer Dockerfile erstellen, die gleichen.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Andrew Harvey | CTO and Startup Advocate