Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel bietet einen schnellen Überblick aus der Perspektive von Start-ups über fünf grundlegende Säulen der Plattform: Rechenleistung, Netzwerke, Speicher, Container und Daten. Für jede Säule erhalten Sie eine kurze Entscheidungstabelle, die Ihre Situation einem Standarddienst zuordnet, sowie einen Hinweis darauf, wann Sie diese Wahl erneut überprüfen sollten, wenn Ihr Start-up wächst.
In diesem Artikel erfahren Sie, wie Sie
- Wählen Sie die richtigen Azure Compute-, Netzwerk- und Speichergrundtypen für Ihre Phase aus.
- Entscheiden Sie, ob Azure Kubernetes Service die richtige Containerplattform für Ihre Phase ist und was stattdessen verwendet werden soll, wenn dies nicht der Richtige ist.
- Wählen Sie eine erste Datenplattform für relationale, Dokument-, Vektor- und Analyseworkloads aus.
- Wenden Sie eine kleine Auswahl an Standardeinstellungen für Kosten, Zuverlässigkeit und Sicherheit an, die auch mit Ihrem Wachstum Bestand haben.
- Erkennen Sie die Signale, die Ihnen mitteilen, dass eine Standardauswahl ihre Nützlichkeit überwachsen hat.
Voraussetzungen
- Ein aktives Azure-Abonnement.
- Die Azure CLI ist installiert und angemeldet. Zum Anmelden führen Sie
az loginaus. - Besitzer- oder Mitwirkenderzugriff auf mindestens eine Ressourcengruppe.
- Vertrautheit mit der Azure Portal-Startseite ist hilfreich, aber nicht erforderlich.
- Grundlegende Kenntnisse mit Azure Grundlagen (Regionen, Abonnements und Ressourcengruppen).
Warum dies für Startups wichtig ist
Bei einem Startup in der Frühphase sind die Kosten einer falschen Infrastrukturentscheidung nicht das eigentliche Problem. Es ist die Woche, die Sie verlieren, wenn Sie von dem falschen Dienst wegmigrieren müssen, nachdem Sie alles darauf aufgebaut haben. Die fünf Säulen in diesem Artikel sind jene, bei denen sich eine schlecht gewählte Voreinstellung oft weiter verstärkt: Die falsche Compute-Plattform prägt Ihre Deployment-Pipeline; die falsche Datenbank schränkt Ihr Datenmodell ein; die falsche Netzwerktopologie blockiert Ihren ersten Enterprise-Kunden. Sie benötigen kein Plattformteam, einen Websitezulässigkeitstechniker oder einen Finanzbetriebsspezialisten, um diese Entscheidungen gut zu treffen. Sie brauchen eine Voreinstellung, die gut genug für die Auslieferung ist, und ein klares Signal, an dem Sie erkennen, wann Sie sie erneut überprüfen sollten. Wenn Ihr Start-up am Programm Microsoft for Startups teilnimmt, sorgen dieselben Standardeinstellungen dafür, dass Ihre Guthaben länger reichen und Sie später für erweiterte Vorteile qualifiziert bleiben.
Berechnen: Wo Ihr Code ausgeführt wird
Azure verfügt über mehr als ein Dutzend Computedienste. Die gute Nachricht: Für die meisten Early-Stage-Workloads decken drei davon das, was Sie benötigen.
| Ihre Situation | Standarddienst Azure | Warum? | Erneut prüfen, wenn |
|---|---|---|---|
| Web-App oder HTTP-API, ein oder zwei Dienste, möchten eine verwaltete Laufzeit | Azure App Service (Linux) | Kein Containerbuild erforderlich. Integrierte TLS, benutzerdefinierte Domänen, Bereitstellungsplätze und automatische Skalierung. Kostenlose und Basic-Tarife sind günstig genug, um eine Staging-Umgebung zu betreiben, allerdings erfordern Slots und die automatische Skalierung Standard oder höher. | Sie möchten mehr als nur eine Handvoll Dienste ausführen, benötigen eine Skalierung pro Dienst oder brauchen Sidecars. |
| Ereignisgesteuerte Funktion, geplanter Auftrag oder Webhook-Handler | Azure Functions (Verbrauchsplan) | Zahlung pro Ausführung. Skaliert auf Null. Bindungen entfernen den meisten Klebecode für Warteschlangen, Blobs und HTTP-Trigger. | Kaltstarts erhöhen Ihre nutzerseitige Latenz, oder Sie überschreiten die Grenzwerte des Consumption-Plans. |
| Für containerisierte Microservices möchten Sie eine Laufzeitumgebung mit klaren Vorgaben, ohne Kubernetes selbst verwalten zu müssen. | Azure Container Apps | Basiert auf Kubernetes mit KEDA-basierter automatischer Skalierung, aber Sie verwalten den Cluster nicht. Dapr ist als optionale Integration verfügbar. Skalierung auf null, Revisionen und HTTPS-Ingress sind enthalten. | Sie benötigen Steuerung auf Clusterebene, einen benutzerdefinierten Zeitplan oder erweiterte Netzwerke. |
| Lang laufender Batchauftrag, GPU-Training oder Lift-and-Shift einer vorhandenen Workload einer virtuellen Maschine | Azure Virtual Machines | Vollständige Betriebssystemsteuerung. Verwenden Sie einen Skalierungssatz für virtuelle Computer, wenn Sie eine horizontale Skalierung benötigen. | Der Betriebsaufwand für das Patchen und die Imageverwaltung beginnt, die Bereitstellung zu verlangsamen. |
| Sie sind sicher, dass Sie Kubernetes benötigen (siehe Abschnitt 4, bevor Sie dies annehmen) | Azure Kubernetes-Dienst | Verwaltete Kontrollebene. Passt Teams an, die bereits über Kubernetes-Erfahrung oder spezifische Plattformanforderungen verfügen. | Im Abschnitt „Container“ finden Sie die AKS-Entscheidungskriterien. |
Tipp
Beginnen Sie mit App Service für Ihre erste benutzerorientierte Web-App und Azure Functions für alles ereignisgesteuert. Sie können zu Azure Container Apps oder zu einem späteren Zeitpunkt Azure Kubernetes Service wechseln, ohne den Anwendungscode zu ändern, wenn Sie die Anwendungszustandslosigkeit beibehalten und die Konfiguration in Umgebungsvariablen schreiben.
Auswählen zwischen Container-Apps und App-Dienst
Container-Apps und App Service überschneiden sich. Der ehrliche Tiebreaker: Wenn Ihre Anwendung bereits als Container-Image läuft und Sie eine dienstspezifische Skalierung möchten (unterschiedliche Replikazahlen für die Webschicht und den Worker), gewinnt Container Apps. Wenn Ihre Anwendung ein einzelner Webprozess ist und Sie keine Dockerfile-Datei verwalten möchten, gewinnt App Service.
Vorsicht
Berücksichtigen Sie Azure Kubernetes Service, wenn Sie klare Anforderungen haben, die nicht durch einfachere Optionen erfüllt sind. Es bietet zwar eine starke Flexibilität und Kontrolle, führt aber auch zusätzliche betriebliche Überlegungen ein (z. B. Upgrades, Größe des Knotenpools, Eingangskonfiguration und Zertifikatverwaltung). Wenn sie zu früh eingeführt werden, finden Teams häufig mehr Zeit für das Plattformmanagement als das Erstellen von Produktfeatures.
Netzwerk: Was am ersten Tag eingerichtet werden soll
Die meisten frühen Azure Workloads benötigen am ersten Tag kein virtuelles Netzwerk. App Service, Funktionen, Container-Apps und die meisten verwalteten Datenbanken bieten Ihnen öffentliche Endpunkte mit TLS, die sicher verfügbar sind, solange Sie die Authentifizierung ordnungsgemäß festgelegt haben. Das Hinzufügen von Netzwerkkomplexität, bevor Sie einen Grund haben, ist die häufigste vorzeitige Optimierung auf Azure.
| Ihre Situation | Standardansatz | Warum? | Erneut prüfen, wenn |
|---|---|---|---|
| Brandneue App, öffentlicher Webdatenverkehr, noch keine Complianceanforderungen | Verwenden Sie den öffentlichen Endpunkt mit TLS. Kein virtuelles Netzwerk. | Niedrigster Betriebsaufwand. App Service, Container-Apps und verwaltete Datenbanken verarbeiten TLS für Sie. Verwenden Sie Microsoft Entra ID für die Authentifizierung. | Ihr erster Enterprise-Kunde fragt nach privater Konnektivität. |
| Sie benötigen eine private Verbindung zwischen Ihrer App und einer verwalteten Datenbank. | Virtuelle Netzwerkintegration auf der Computeseite, privater Endpunkt auf der Datenbankseite | Der Datenverkehr bleibt auf dem Backbone Microsoft. Keine öffentliche Gefährdung für die Datenbank. Derselbe verwaltete Dienst, keine Anwendungsänderung. | Vom ersten Tag an, wenn Sie mit geschützten Daten arbeiten; andernfalls, wenn ein Audit oder ein Kunde danach fragt. |
| Sie benötigen einen einzelnen öffentlichen Einstiegspunkt, der mehrere Back-Ends mit Routing, TLS-Beendigung und einer Webanwendungsfirewall vorgibt. | Azure Front Door (global) oder Azure Application Gateway (regional) | Front Door fügt ein globales Content Delivery Network und Edge Caching hinzu. Das Anwendungsgateway ist die regionale, systemeigene Option für virtuelle Netzwerke. | Die integrierten TLS- und Routingfunktionen von App Service reichen für Ihre Anforderungen nicht mehr aus. |
| Sie benötigen ausgehende statische IP-Adressen (z. B. eine Zulassungsliste für Zahlungsauftragsverarbeiter) | Mit Ihrem virtuellen Netzwerk verbundenes NAT-Gateway | Vorhersagbare ausgehende IP-Adresse. Erforderlich für viele ApIs von Drittanbietern. | Für einen Anbieter ist dies erforderlich. Fügen Sie sie nicht spekulativ hinzu. |
| Topologie mit mehreren Regionen oder Konten | Virtual Network Peering oder Azure Virtual WAN | Die reale Netzwerkarchitektur beginnt hier. Für die meisten Teams in der Explore-Phase nicht relevant. | Multi-Region ist eine echte Anforderung, keine bloße Wunschvorstellung. |
Important
Sichern Sie Microsoft Entra ID und die Rollenzuweisungen Ihres Abonnements ab, bevor Sie sich um die Netzwerkisolation kümmern. Die meisten Azure-Sicherheitsvorfälle bei kleinen Unternehmen gehen auf eine Identität mit zu weitreichenden Berechtigungen zurück, nicht auf eine Netzwerkfreigabe. Verwenden Sie Microsoft Entra ID-Gruppen für den Zugriff durch die Technikteams, und weisen Sie auf Abonnementebene nicht die Rolle „Besitzer“ zu.
Speicher: Blobs, Dateien und Datenträger
Azure Storage ist ein einzelner Ressourcentyp (das Speicherkonto), der vier Datendienste verfügbar macht: Blobs, Dateien, Warteschlangen und Tabellen. Bei Anwendungsspeicherentscheidungen wählen Sie fast immer zwischen Blobs (Objektspeicher), Dateien (verwaltete Dateifreigaben) und verwalteten Datenträgern (an einen virtuellen Computer angefügten Speicher blockieren) aus.
| Was Sie speichern | Standarddienst Azure | Warum? | Erneut prüfen, wenn |
|---|---|---|---|
| Vom Benutzer hochgeladene Dateien, generierte Berichte, Protokolle, Modellartefakte, Sicherungen | Azure Blob Storage (Hot-Tier) | Objektspeicher. Billig, langlebig, skaliert auf Petabyte. Verwenden Sie später die Cool- oder Archivebene für Daten, die Sie selten lesen. | Sie benötigen POSIX-Dateisemantik oder zufälligen Lese-/Schreibzugriff in eine einzelne Datei von mehreren Computern. |
| Ein freigegebenes Dateisystem, das von mehreren virtuellen Computern oder Containern bereitgestellt wird | Azure Files (Standard) oder Azure NetApp Files (hoher Durchsatz) | Freigegebene VOLUMES (Server Message Block, SMB) oder Network File System (NFS). Vermeiden Sie dies für Inhalte, die dem BLOB-Modell entsprechen. | Sie beginnen mit der Verwendung einer Dateifreigabe als Warteschlange oder Datenbank. Zur rechten Primitive wechseln. |
| Datenträger für einen virtuellen Computer | Premium SSD v2 verwaltete Datenträger | Anpassbare Leistung, gutes Preis-Leistungs-Verhältnis für Anwendungsfestplatten. Premium SSD v2 kann nicht als Betriebssystemdatenträger verwendet werden; koppeln Sie es mit Premium SSD (v1) oder Standard SSD für das Betriebssystem. Standard-SSD ist für Workloads mit geringem Durchsatz akzeptabel. | Sie benötigen gemeinsam genutzten Blockspeicher auf virtuellen Computern (verwenden Sie Azure Elastic SAN oder Azure NetApp Files). |
| Statische Websiteobjekte (Einzelseitenanwendungsbundle, Marketingwebsite, Dokumentation) | Azure Storage statische Websitehosting + Azure Front Door | Static Web Apps ist die moderne Standardeinstellung: integrierte benutzerdefinierte Domänen, kostenlose verwaltete TLS, globale Verteilung, GitHub Actions CI/CD und integrierte Authentifizierung. Statische Speicherwebsite + Front Door funktioniert weiterhin für sehr kostengünstige Setups, unterstützt jedoch keine benutzerdefinierten Header oder Authentifizierungen. | Sie fügen vom Server gerenderte Seiten hinzu. Wechseln Sie zu App Service oder Container Apps. |
Note
Speicherkonten haben eine weiche Obergrenze von 250 pro Region und Abonnement (kann auf Anfrage auf 500 erhöht werden). Das ist mehr als genug für Early-Stage-Teams. Der Fehler, den es zu vermeiden gilt, ist, für jeden Mikroservice ein eigenes Speicherkonto zu erstellen; gruppieren Sie stattdessen nach Umgebung (Produktion, Staging, Entwicklung) und nach Zugriffsmuster (heiß, kalt, Archiv).
Eine Notiz zu Sicherungen
Azure Backup und Speicherkontoredundanzoptionen (lokal redundanter Speicher, Zonenredundanter Speicher, georedundanter Speicher) sind pro Konto und pro Datenträger tunbar. Lokal redundanter Speicher (LRS) eignet sich gut für die Entwicklung und Staging. Verwenden Sie zonenredundanten Speicher (ZRS) für Produktionsdaten. Geo Redundant Storage fügt Kosten hinzu und ist kein Ersatz für die Notfallwiederherstellung auf Anwendungsebene.
Container und Azure Kubernetes Service
Azure verfügt über drei Möglichkeiten zum Ausführen von Containern in der Produktion: Azure Container Apps, Azure Container Instances und Azure Kubernetes Service. Sie entsprechen unterschiedlichen Teamgrößen und operativen Präferenzen.
| Ihre Situation | Standarddienst Azure | Warum? | Wenn es anfängt weh zu tun |
|---|---|---|---|
| Sie verfügen über Container-Images und möchten eine verwaltete Laufzeitumgebung mit HTTPS-Eingang, Skalierung auf null und Revisionen | Azure Container Apps | Serverlose Plattform auf Kubernetes mit automatischer KEDA-Skalierung, aber Sie sehen oder verwalten den Cluster nicht. Zahlen Sie nur für das, was läuft. Gut geeignet, bis Sie die Anforderungen auf Clusterebene erreicht haben. Dapr ist als Opt-In-Integration verfügbar. | Sie benötigen benutzerdefinierte Scheduler, erweiterte Netzwerke (mehrere Netzwerkschnittstellenkarten, benutzerdefinierte Plug-Ins für Containernetzwerkschnittstellen) oder bestimmte Kubernetes-Operatoren. |
| Sie möchten einen einzelnen Container als einmaligen Auftrag oder als kurzer Batch ausführen. | Azure Container Instances | Schnellster Weg vom Image zum laufenden Container. Keine Orchestrierung. Pro Sekunde der Laufzeit in Rechnung gestellt. | Sie benötigen alles, was einem Dienstgitter oder einer automatischen Skalierung über einen einzelnen Container hinaus ähnelt. |
| Sie betreiben Kubernetes bereits an anderer Stelle, oder Ihre Anwendungsarchitektur erfordert sie wirklich. | Azure Kubernetes-Dienst | Verwaltete Kontrollebene. Verwenden Sie Ihre eigenen Knotenpools, Netzwerk-Plugins, Ingress-Controller und Observability-Stacks. | Tag 1. Planen Sie laufende Upgrades (mit einer Minor-Version alle 4 Monate), die Optimierung des Node-Pools und die Zertifikatsverwaltung. |
| Sie wissen nicht, ob Sie Kubernetes benötigen | Container-Apps für jetzt | Bei Bedarf können Sie Azure Kubernetes Service später neu erstellen. Die Migration einer zustandslosen containerbasierten Anwendung dauert Tage, nicht Wochen. | Sie benötigen einen konkreten Bedarf (Operatorökosystem, Richtlinie auf Clusterebene), den Sie benennen können. "Zukunftssicherung" ist kein konkreter Bedarf. |
Zeitpunkt für den Abschluss an AKS
Wechseln Sie zu Azure Kubernetes Service (AKS), wenn mindestens zwei dieser Elemente zutreffen:
- Sie führen mehr als zehn Dienste mit gemeinsamem Lebenszyklus und gemeinsamen Netzwerkanforderungen aus.
- Sie benötigen benutzerdefinierte Controller, Sidecars oder benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRDs), die Container Apps nicht bereitstellt.
- Sie benötigen eine umfassende Integration des virtuellen Netzwerks mit strikter Richtlinienerzwingung.
- Sie standardisieren auf einem Kubernetes-basierten Open Source Ökosystem (Argo, Istio, KEDA usw.).
Wenn Sie AKS übernehmen, folgen Sie der AKS Baseline-Architektur. Das Microsoft Azure Well-Architected Framework und die AKS-Basisreferenz decken zusammen die gewünschten Standardvorgaben für Sicherheit, Skalierung und Upgrades ab.
AKS-Standardwerte für ein kleines Team
| Setting | Vorgabe | Warum? |
|---|---|---|
| Knotengröße | Standard_D4s_v5 Systempool, Standard_D8s_v5 Benutzerpool | Vorhersehbare Preis-zu-Leistung für allgemeine Workloads |
| Cluster-Autoskalierer | Aktiviert | Vermeiden Sie, für ungenutzte Knoten zu zahlen |
| Workloadidentität | Aktiviert | Ersetzt die Pod-Identität, integriert sich in Microsoft Entra ID |
| Azure Policy-Add-On | Aktiviert | Kostenlose Leitplanken (keine privilegierten Container, erforderliche Labels) |
| Container Insights | Aktiviert | Erstklassige Metriken und Protokolle in Azure Monitor |
| Privater Cluster | Für die Produktion aktiviert | Steuerebene nur über das VNet erreichbar |
Azure Container Registry (Registrierungsdienst für Container von Azure)
Unabhängig davon, welche Computeplattform Sie auswählen, speichern Sie Ihre Bilder in Azure Container Registry. Der Basic-Tarif ist für Teams in der Anfangsphase ausreichend. Verwenden Sie eine separate Registrierung pro Umgebung (Produktion, Staging), wenn Sie eine feste Isolation wünschen, oder eine einzelne Registrierung mit separaten Repositorys und rollenbasierter Zugriffssteuerung, wenn Sie Einfachheit wünschen.
Datenplattform: relational, dokumentenbasiert, Vektor, Analytik
Datenplattformentscheidungen sind die am ehesten dauerhaft. Das Schema, das Sie im ersten Monat ausliefern, prägt jede Funktion der nächsten zwei Jahre. Wählen Sie einen Standard aus, der flexibel genug ist, um mit dem Produkt zu wachsen, und widerstehen Sie der Versuchung, eine spezielle Datenbank für ein Feature, das Sie noch nicht erstellt haben, vorab zu wählen.
| Ihre Arbeitsauslastung | Standarddienst Azure | Warum? | Erneut prüfen, wenn |
|---|---|---|---|
| Transaktionsanwendungsdaten (Benutzer, Bestellungen, Inhalte) mit einem bekannten relationalen Schema | Azure Database for PostgreSQL (Flexible Server) | Reifes, weit verstandenes, starkes Erweiterungsökosystem (einschließlich pgvector für Einbettungen). Platzbare Stufe ist billig genug für Entwicklung und Staging. | Regionenübergreifende Schreib- oder Hyper-Scale-Lesemuster. Erwägen Sie Azure Cosmos DB für PostgreSQL. |
| Schemaflexible Betriebsdaten, globale Verteilung, vorhersagbare Lesevorgänge im einstelligen Millisekundenbereich | Azure Cosmos DB (NoSQL-API) | Mehrere Regionen standardmäßig. Die Serverless-Stufe ist billig genug, um zu beginnen. Partitionsdesign ist wichtig; lesen Sie die Partitionsschlüsselleitfaden vor dem Versand. | Sie erzwingen relationale Verknüpfungen in der Anwendungsschicht. PostgreSQL ist wahrscheinlich die richtige Antwort. |
| Suche in strukturierten und unstrukturierten Inhalten, einschließlich abrufgestützter Generierung | Azure KI-Suche | Hybride Schlüsselwort- und Vektorsuche. Integriert in Azure OpenAI Service und Cosmos DB. Es gibt eine kostenlose Stufe zum Prototyping. | Sie überschreiten die Indexgrenzwerte pro Ebene (Standard 1 ist ein häufiger Upgradepunkt). |
| Vektorembeddings für eine Retrieval-Augmented-Generation-Funktion | Beginnen Sie mit pgvector in PostgreSQL oder Azure KI-Suche | Vermeiden Sie eine separate Vektordatenbank für die erste Version eines Abruffeatures. Sie erfahren, was Sie tatsächlich benötigen (Filtern, Hybridsuche, Skalierung) aus der tatsächlichen Nutzung. | Sie haben Ihre Lesezugriffsmuster charakterisiert, und die gegebenen Einschränkungen rechtfertigen eine spezialisierte Engine. |
| Analyse-, Berichterstellungs- und Ad-hoc-Abfragen über Produktionsdaten | Azure Database for PostgreSQL Lesereplikat (Explore), Microsoft Fabric (Erweitern und Extrahieren) | Für die meisten Analysen in der Explore-Phase reicht ein Lesereplikat aus. Microsoft Fabric ist die moderne Analyseplattform, wenn Sie daraus herauswachsen. | Ihre Lesereplikate können nicht Schritt halten, oder die Fachbereiche benötigen eine Self-Service-Analyseoberfläche. |
| Zwischenspeicherungsebene vor einer Datenbank | Azure Cache for Redis (Standardebene) | Standardzwischenspeicherungsgrundtyp. Billig, um später hinzuzufügen; fügen Sie nicht spekulativ hinzu. | Sie sehen ein klares Muster häufiger Lesezugriffe, das die Datenbank überlastet. Messen Sie vor dem Hinzufügen. |
Important
Wählen Sie eine Standarddatenbank aus, und bleiben Sie so lange darauf, wie möglich. Ein Team mit fünfzehn Ingenieurinnen und Ingenieuren, das PostgreSQL, Cosmos DB, Redis, AI Search, ein Queue-System und eine Graphdatenbank betreibt, hat sich versehentlich Arbeit im Umfang eines ganzen Plattformteams eingehandelt.
Wo Azure OpenAI Service passt
Azure OpenAI Service ist keine Datenplattform, sondern teilt den gleichen Entscheidungsrhythmus. Die meisten Startups, die ein generatives KI-Feature erstellen, beginnen mit einer Modellbereitstellung (ein aktuelles Chat-Abschlussmodell) in einer einzelnen Region sowie AI Search oder pgvector für den Abruf. Sie benötigen weder eine dedizierte Pipeline für die Feinabstimmung noch ein Modellgateway oder mehrere Bereitstellungen, bis die Nutzung zeigt, dass Sie sie benötigen.
Was dieser Artikel behandelt (und was nicht)
| Thema | In diesem Artikel | Wann sie hinzugefügt werden soll |
|---|---|---|
| Identitäts- und Zugriffsverwaltung über die Grundlagen hinaus | No | Erster Tag für die Einrichtung von Microsoft Entra ID. Bedingter Zugriff und Privileged Identity Management, wenn Sie über eine Überprüfung der Informationssicherheit verfügen. |
| Infrastruktur als Code (Bicep, Terraform) | No | Wenn manuelle Portaländerungen beginnen, zwischen Umgebungen zu driften. Normalerweise etwa zu dem Zeitpunkt, an dem Sie Staging hinzufügen. |
| Kontinuierliche Integration und kontinuierliche Bereitstellungspipelinen | No | Tag 1. GitHub Actions oder Azure DevOps Pipelines sind beide in Ordnung. |
| Observability (Protokolle, Metriken, Ablaufverfolgungen) | No | Application Insights vom ersten Tag an. Azure Monitor-Arbeitsmappen bei Warnungsmüdigkeit. |
| Kostenmanagement | No | Legen Sie ein Budget auf Abonnementebene am ersten Tag fest. Markieren Sie Ressourcen von Anfang an mit Umgebung und Besitzer. |
| Compliance (SOC 2, ISO 27001, HIPAA) | No | Wenn ein Kunde fragt. Microsoft Defender for Cloud verfügt über ein Compliance-Dashboard, das Steuerelemente Azure Ressourcen zuordnet. |
| Notfallwiederherstellung und mehrere Regionen | No | Wenn die Kosten für eine Stunde Ausfallzeiten die Technischen Kosten der zweiten Region überschreiten. |
Wenn die Standardeinstellungen der Plattform nicht mehr ausreichen
Diese Anzeichen für Wachstum zeigen Ihnen, dass eine bestimmte Voreinstellung durch eine bewusstere Alternative ersetzt werden sollte:
- Sie haben mehr als fünf eigenständige Dienste in App Service oder Container Apps bereitgestellt, und die Skalierung einzelner Dienste wird zu einer täglichen Herausforderung. Sehen Sie sich Azure Kubernetes Service an.
- Ihre monatliche Azure Rechnung wächst schneller als Ihr monatlicher Umsatz für zwei Monate in Folge. Zeit für eine Überprüfung des Kostenmanagements und eine Analyse von Reservierter Instanz oder Savings Plan.
- Ihr virtuelles Netzwerk umfasst jetzt mehrere Abonnements oder Regionen. Sehen Sie sich Azure Virtual WAN und eine Hub-and-Spoke-Topologie an.
- Eine einzelne PostgreSQL-Instanz kann Ihren Arbeitssatz nicht im Arbeitsspeicher enthalten, und Lesereplikate schließen die Lücke nicht. Betrachten Sie Cosmos DB für PostgreSQL oder eine shardierte Architektur.
- Analyseabfragen in der Produktionsdatenbank wirken sich spürbar auf die Anwendungslatenz aus. Verschieben sie Analysen in Microsoft Fabric.
- Sie führen mehr als zwei Speicherkonten pro Umgebung für dasselbe Zugriffsmuster aus. Konsolidieren.
- Sie haben ein Drittland mit zahlenden Kunden hinzugefügt. Zeit für die Auswertung einer zweiten Region, eines georedundanten Speichers und einer Front Door-Routingstrategie.
Note
Widerstehen Sie der Versuchung, die Tools der Unternehmensplattform frühzeitig zu übernehmen. Die meisten der vorherigen Muster (Dienstgitter, aktiv-aktiv-multi-region, Finanzoperationstools, benutzerdefinierte Kubernetes-Operatoren) fügen operative Oberflächenfläche hinzu, die sich nur im Großen auszahlt. Fügen Sie sie erst hinzu, wenn Sie das Team haben, um sie zu pflegen, nicht vorher.
Referenz-Checkliste
Führen Sie dies einmal im Monat für die ersten sechs Monate am Azure durch. Es fängt die häufigste Abweichung.
- Ein Abonnement pro Umgebung (Produktion, Staging, Entwicklung) oder ein Abonnement mit strengen Ressourcengruppen pro Umgebung. Nicht mischen.
- Jede Ressource wird mit Tags für die Umgebung, den Besitzer und die Kostenstelle versehen (selbst wenn die Kostenstelle heute für alle denselben Wert hat).
- Ein Budget auf Abonnementebene mit Warnungen bei 50 %, 80 % und 100 % des monatlichen Zielwerts im Kostenmanagement.
- Microsoft Entra ID-Gruppen, nicht Einzelpersonen, verfügen über Rollenzuweisungen für Ressourcengruppen. Kein dauerhafter Besitzer auf Abonnementebene.
- Application Insights oder Azure Monitor ist für jede Produktionsberechnungsressource aktiviert.
- Produktionsdatenbanksicherungen werden durch einen dokumentierten Wiederherstellungstest (mindestens einmal) überprüft.
- Geheime Schlüssel befinden sich in Azure Key Vault, nicht in der Anwendungskonfiguration. Verwenden Sie verwaltete Identitäten für den Compute-zu-Key-Vault Pfad.
- Container-Images werden gescannt (mit Microsoft Defender für Container oder dem integrierten Scanner Ihrer Registry).