Kernarchitektur des Startup-Stacks
Viele Lektionen, die Sie in größeren Unternehmen lernen, gelten nicht direkt für den ersten Stapel eines Startups. In der ersten Erkundungsphase eines Produkts müssen Sie die Bereitstellung für Geschwindigkeit, Kosten und Optionalität optimieren. Optionalität bezieht sich darauf, wie schnell Sie Richtungen innerhalb einer bestimmten Architektur ändern können.
Ein Unternehmen in den Erweiterungs - oder Extraktphasen der Produktentwicklung kann eine dienstorientierte oder Microservices-Architektur verwenden. Diese Art von Bereitstellungsarchitektur ist selten für einen Start geeignet, der noch keine Produkt-/Marktanpassung oder kommerzielle Traktion gefunden hat.
Für einen kernen Startstapel ist ein einfaches monolithisches Design am besten geeignet. Dieser Entwurf begrenzt die Zeit für die Verwaltung der Infrastruktur und bietet ausreichend Möglichkeiten, um zu skalieren, da der Start mehr Kunden gewinnt.
Potenzielle Anwendungsfälle
In diesem Artikel wird ein Beispiel für einen einfachen Kernstartstapel dargestellt und die zugehörigen Komponenten erläutert.
Architektur
Ein Start, Contoso, hat einen Anwendungsprototyp mit einem Ruby on Rails-Back-End und einem React-Front-End erstellt, das in TypeScript geschrieben wurde. Das Contoso-Team hat Demos auf ihren Laptops ausgeführt. Jetzt möchten sie ihre App für ihre ersten Kundenverkaufsbesprechungen bereitstellen.
Hinweis
Die technologieauswahl hier von Ruby, React und TypeScript ist nur illustrativ. Diese Startarchitektur gilt gleichermaßen für viele andere Sprachen und Frameworks.
Die App ist zwar ehrgeizig, benötigt aber noch keine komplexe, mikroservicegesteuerte Architektur. Contoso hat sich für ein einfaches monolithisches Design entschieden, das die empfohlenen Startstapelkomponenten enthält.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Datenfluss
In dieser kernen Startstapelarchitektur:
Azure App Service bietet einen einfachen App-Server, um skalierbare Anwendungen bereitzustellen, ohne Server, Lastenausgleichsgeräte oder andere Infrastruktur zu konfigurieren. Der App-Dienst unterstützt Containerbereitstellungen wie im Beispiel hier und unterstützt auch containerlose Bereitstellungen für ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP oder Python.
Azure Database for PostgreSQL ist ein Azure-Datenbankdienst für ein führendes relationales Open-Source-Datenbankverwaltungssystem (RDBMS). Sie können sich nicht auf die Verwaltung von Datenbankservern, sondern auf die Entwicklung Ihrer Anwendung konzentrieren.
Azure verfügt außerdem über verwaltete Datenbankdienste für SQL, MySQL, MongoDB, Apache Cassandra, Gremlin und Redis.
Zusätzlich zu verwalteten Angeboten umfasst azure Marketplace Datenbanken, die in Startup-Architekturen verwendet werden, wie z. B. CockroachDB, Neon Serverless Postgres und SQLite.
Azure Virtual Network segmentt Netzwerkdatenverkehr und hält interne Dienste vor Internetbedrohungen geschützt. Ihre App-Server verwenden die Integration virtueller Netzwerke , um mit der Datenbank zu kommunizieren, ohne dass das Internet ausgesetzt ist.
GitHub Actions erstellt kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) in Ihre Quellcodeverwaltung. GitHub Actions verfügt über umfassende Unterstützung für verschiedene Sprachen und eine starke Integration in Azure-Dienste.
Azure Blob Storage speichert statische Ressourcen und verschiebt die Last von den App-Servern weg.
Azure Front Door mit WAF beschleunigt und sichert die Inhaltsübermittlung an Benutzer über ein globales CdN (Content Delivery Network) und eine Webanwendungsfirewall.
Azure Monitor überwacht und analysiert, was in der Infrastruktur Ihrer Anwendung passiert.
Kernkomponenten des Startstapels
Ein komplexer Stapel kann Fehler generieren, die eine ständige Aufmerksamkeit erfordern. Eine anspruchsvolle Architektur kann das Erstellen Ihres Produkts beeinträchtigen. Fehler werden nicht durch Komplexität verursacht, aber ein komplexer Stapel erleichtert das Versenden von Fehlern. Nicht alle komplexen Architekturen sind eine Energieverschwendung, aber sie verschwenden Ihre Ressourcen, wenn Sie noch kein Produkt/Markt gefunden haben. Ihr erster Startstapel sollte einfach sein und aus Dem Weg gehen, damit Sie sich auf die Produktentwicklung konzentrieren können.
Das folgende einfache Diagramm zeigt den empfohlenen Kernstartstapel. Diese Komponenten reichen aus, um Ihr Produkt vor Ort und in die Hände Ihrer Kunden zu bringen. Für 80 Prozent der Startups ist dieser Stapel alles, was Sie benötigen, um die grundlegenden Hypothesen zu testen, die in Ihr Produkt integriert sind. Startups, die in maschinellem Lernen, Internet of Things (IoT) oder stark regulierten Umgebungen arbeiten, erfordern möglicherweise mehr Komponenten.
CDN
Mit wenigen Kunden zu Beginn scheint ein CDN möglicherweise vorzeitig zu sein. Das Hinzufügen eines CDNs zu einem Produkt, das bereits in der Produktion ausgeführt wird, kann jedoch unerwartete Nebenwirkungen haben. Es ist am besten, ein CDN im Vorfeld zu implementieren. Ein CDN speichert statische Inhalte näher an Ihren Kunden und bietet eine Fassade, hinter der Sie ihre APIs und Ihre Architektur durchlaufen können.
App-Server
Ihr Code muss irgendwo ausgeführt werden. Im Idealfall sollte diese Plattform Bereitstellungen vereinfachen und gleichzeitig die möglichst geringstmögliche Betriebseingabe erfordern. Der App-Server sollte horizontal skaliert werden, aber einige manuelle Skalierungseingriffe sind in Ordnung, während Sie sich noch in der Erkundungsphase befinden.
Wie die meisten dieser Stapel sollte der App-Server im Wesentlichen selbst ausgeführt werden. Traditionell war der App-Server ein virtueller Computer oder eine Webserverinstanz, die auf einem Bare-Metal-Server ausgeführt wird. Jetzt können Sie nach Plattform-as-a-Service-Optionen (PaaS) wie app Service oben und Containern suchen, um den Betriebsaufwand zu beseitigen.
Statischer Inhalt
Die Bereitstellung statischer Inhalte von Ihrem App-Server verschwendet Ressourcen. Nachdem Sie eine CI/CD-Pipeline konfiguriert haben, ist die Arbeit zum Erstellen und Bereitstellen statischer Ressourcen mit jeder Version trivial. Die meisten Produktionswebframeworks stellen statische Objekte mit CI/CD bereit, daher lohnt es sich, mit dieser bewährten Methode zu beginnen.
Datenbank
Sobald Ihre App ausgeführt wird, müssen Sie Ihre Daten in einer Datenbank speichern. In den meisten Fällen ist eine relationale Datenbank die beste Lösung. Eine relationale Datenbank verfügt über mehrere Zugriffsmethoden und die Geschwindigkeit einer zeittesteten Lösung. Relationale Datenbanken umfassen Azure SQL-Datenbank und Azure-Datenbank für PostgreSQL. Einige Anwendungsfälle benötigen eine Dokumentdatenbank oder NoSQL-Datenbank wie MongoDB oder Azure Cosmos DB.
Protokollaggregation
Wenn bei Ihrer App ein Fehler auftritt, möchten Sie so wenig Zeit wie möglich verbringen, das Problem zu diagnostizieren. Durch das Aggregieren von Protokollen und die Verwendung der Anwendungsablaufverfolgung von Anfang an helfen Sie Ihrem Team, sich auf die Probleme selbst zu konzentrieren. Sie müssen nicht auf eine Datei auf dem App-Server zugreifen und protokollieren, um Überwachungsdaten abzurufen.
CI/CD
Der Mangel an wiederholbaren und schnellen Bereitstellungen ist eine der schlimmsten Hindernisse für die Geschwindigkeit, wenn Sie auf ein Produkt iterieren. Eine gut konfigurierte CI/CD-Pipeline optimiert den Codebereitstellungsprozess auf Ihrem App-Server. Schnelle und einfache Bereitstellungen bedeuten, dass Sie die Ergebnisse Ihrer Arbeit schnell sehen. Bei der häufigen Integration werden unterschiedliche Codebasen vermieden, die zu Zusammenführungskonflikten führen. Die Konzepte und Techniken sind für die meisten Projekte, die Sie mit einer Dockerfile erstellen, identisch.
Beitragende
Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.
Hauptautor:
- Andrew Harvey | CTO und Startup Advocate
Andere Mitwirkende:
- Nick Ward | Cloud-Lösungsarchitekt