Share via

Verfeinern Ihrer Anwendungsplattform

  • Artikel

Nachdem Sie die Probleme verstanden haben, die Sie zuerst auf Ihrer Plattformentwicklungsreise angehen möchten, stellen Sie möglicherweise fest, dass Sie einige Herausforderungen mit Ihrer Anwendungsplattform bewältigen müssen. Dieser Artikel enthält einige Tipps, wie Sie genau das tun können. Sie erfahren mehr über die oft verpassten oder vergessenen Aspekte der Erstellung einer gut entworfenen Anwendungsplattform. Insbesondere Infrastrukturverwaltung, Sicherheit, Kostenverwaltung, Governance und Beobachtbarkeit.

Entscheiden, wann und wo investiert werden soll

Wenn Sie heute über eine oder mehrere Anwendungsplattformen verfügen, kann es schwierig sein, zu entscheiden, wann und wo Sie in Verbesserungen investieren, die die von Ihnen identifizierten Probleme lösen. Wenn Sie neu beginnen, verfügt das Azure Architecture Center über mehrere potenzielle Muster, die Sie auswerten können. Aber darüber hinaus sind einige Fragen, die Sie berücksichtigen sollten, wenn Sie beginnen, zu planen, was Sie tun möchten:

Frage Tipps
Möchten Sie Ihre vorhandene Anwendungsplattform anpassen, neu beginnen oder eine Kombination dieser Ansätze verwenden? Auch wenn Sie mit dem zufrieden sind, was Sie jetzt haben oder neu anfangen, sollten Sie darüber nachdenken, wie Sie sich im Laufe der Zeit an Veränderungen anpassen können. Blitzschneiden funktioniert selten. Unabhängig davon sind Ihre Anwendungsplattformen ähnlich wie technische Systeme ein bewegliches Ziel. Was Sie heute landen, wird sich mit der Zeit ändern. Sie sollten dieses Denken und alle zugehörigen Migrationspläne in Ihren Go-Forward-Entwurf einbeziehen. Weitere Informationen zu bereits behandelten Infrastructure-as-Code (IaC) und Vorlagenansätzen finden Sie unter Anwenden von Softwareentwicklungssystemen , damit Sie einige dieser Varianten für neue Anwendungen verwalten können.
Wenn Sie das, was Sie heute tun, ändern möchten, mit welchen Produkten, Dienstleistungen oder Investitionen sind Sie zufrieden? Wie das Sprichwort sagt: "Wenn es nicht beschädigt ist, beheben Sie es nicht." Ändern Sie dinge nicht ohne einen Grund. Wenn Sie jedoch über selbst entwickelte Lösungen verfügen, überlegen Sie, ob es an der Zeit ist, zu einem vorhandenen Produkt zu wechseln, um bei der langfristigen Wartung zu sparen. Wenn Sie beispielsweise eine eigene Überwachungslösung betreiben, möchten Sie diese Belastung für Ihr Ops-Team beseitigen und zu einem neuen verwalteten Produkt migrieren?
Wo sehen Sie die meisten Veränderungen im Laufe der Zeit? Befinden sich diese in Bereichen, die für alle (oder die meisten) App-Typen Ihrer organization gemeinsam sind? Bereiche, mit denen Sie oder Ihre internen Kunden nicht zufrieden sind und die sich wahrscheinlich nicht häufig ändern, sind gute Ausgangspunkte. Diese haben langfristig die größte Rendite. Dies kann Ihnen auch helfen, die Migration zu einer neuen Lösung zu vereinfachen. App-Modelle sind beispielsweise in der Regel flüssig, aber Protokollanalysetools haben in der Regel eine längere Haltbarkeit. Sie können sich auch auf neue Projekte/Anwendungen konzentrieren, die gestartet werden sollen, während Sie bestätigen, dass die Richtungsänderung die gewünschten Rückgaben aufweist.
Investieren Sie in maßgeschneiderte Lösungen in Bereichen mit dem höchsten Mehrwert? Sind Sie der Meinung, dass eine einzigartige Plattformfunktion für die App-Infrastruktur Teil Ihres Wettbewerbsvorteils ist? Wenn Sie Lücken identifiziert haben, sollten Sie vor der Durchführung eines benutzerdefinierten Vorgangs überlegen, in welche Bereiche Anbieter am wahrscheinlichsten investieren, und konzentrieren Sie sich auf Ihre benutzerdefinierten Überlegungen an anderer Stelle. Betrachten Sie sich zunächst als Integrator und nicht als benutzerdefinierter App-Infrastruktur- oder App-Modellanbieter. Alles, was Sie bauen, muss beibehalten werden, was langfristig die Vorlaufzeiten in den Schatten stellt. Wenn Sie die dringende Notwendigkeit haben, eine benutzerdefinierte Lösung in einem Bereich zu erstellen, von dem Sie vermuten, dass sie langfristig von Anbietern abgedeckt wird, planen Sie eine Einstellung oder einen langfristigen Support ein. Ihre internen Kunden sind in der Regel genauso zufrieden (wenn nicht mehr) mit einem Standardprodukt wie einem kundenspezifischen Produkt.

Die Anpassung Ihrer vorhandenen Investitionen für Die Anwendungsplattform kann eine gute Möglichkeit sein, loszuwerden. Wenn Sie Updates vornehmen, sollten Sie erwägen, mit neuen Anwendungen zu beginnen, um Pilotideen vor jeder Art von Rollout zu vereinfachen. Berücksichtigen Sie diese Änderung durch IaC und Anwendungsvorlagen. Investieren Sie in maßgeschneiderte Lösungen für Ihre einzigartigen Anforderungen in bereichen mit hoher Wirkung und hohem Wert. Versuchen Sie andernfalls, eine Standardlösung zu verwenden. Wie bei Entwicklungssystemen sollten Sie sich auf die Automatisierung von Bereitstellung, Nachverfolgung und Bereitstellung konzentrieren, anstatt einen starren Pfad anzunehmen, der Ihnen bei der Verwaltung von Änderungen im Laufe der Zeit hilft.

Überlegungen zu Entwurf und Architektur

Es gibt zwar mehrere potenzielle Anwendungsplattformmuster, die Sie verwenden können, aber hier sind einige allgemeine Bereiche aufgeführt, die kritisch sind, aber beim Entwurf häufig übersehen werden.

Infrastrukturverwaltung

Wie unter Anwenden von Softwareentwicklungssystemen erwähnt, können IaC- und Automatisierungstools mit Vorlagen kombiniert werden, um die Infrastruktur- und Anwendungsbereitstellung zu standardisieren. Um die Belastung durch Plattformspezifik für den Endbenutzer zu verringern, sollten Sie Plattformdetails abstrahieren, indem Sie Auswahlmöglichkeiten in nachvollziehbare Namenskonventionen unterteilen, z. B.:

  • Ressourcentypkategorien (hohe Computekapazität, hoher Arbeitsspeicher)
  • Ressourcengrößenkategorien (T-Shirt-Größe, klein mittel und groß)

Das Ziel sollte darin bestehen, Vorlagen zu haben, die allgemeine Anforderungen darstellen, die mit voreingestellten Konfigurationen getestet wurden, damit Entwicklerteams sofort mit der Bereitstellung minimaler Parameter beginnen können, ohne Optionen überprüfen zu müssen. Es gibt jedoch Fälle, in denen Teams mehr Optionen für veröffentlichte Vorlagen ändern müssen, als verfügbar oder wünschenswert sind. Beispielsweise kann ein genehmigter Entwurf eine bestimmte Konfiguration benötigen, die außerhalb der unterstützten Vorlagenstandardeinstellungen liegt. In diesem instance Betriebs- oder Plattformentwicklungsteams eine einmalige Konfiguration erstellen und dann entscheiden, ob die Vorlage diese Änderungen als Standard integrieren muss.

Sie können Änderungen mithilfe von IaC-Tools mit Drifterkennungsfeatures nachverfolgen, die die Drift automatisch beheben können (GitOps). Beispiele für diese Tools sind Terraform und cloudnative IaC-Tools (Beispiele, Cluster-API, Crossplane, Azure Service Operator v2). Außerhalb der IaC-Toolabweichung gibt es Cloudkonfigurationstools, die Ressourcenkonfigurationen abfragen können, z. B. Azure Resource Graph. Diese können zwei Vorteile haben; Sie überwachen änderungen außerhalb des Infrastrukturcodes und überprüfen auf geänderte voreingestellte Konfigurationen. Um zu starr zu sein, können Sie Toleranzen auch in Bereitstellungen mit vordefinierten Grenzwerten implementieren. Sie können beispielsweise Azure Policy verwenden, um die Anzahl der Kubernetes-Knoten zu begrenzen, die eine Bereitstellung aufweisen kann.

Selbstverwaltet oder verwaltet?

In öffentlichen Clouds haben Sie die Wahl, SaaS, PaaS oder IaaS zu nutzen. Weitere Informationen zu SaaS, PaaS und IaaS finden Sie im Schulungsmodul Beschreiben von Cloudkonzepten. PaaS-Dienste bieten optimierte Entwicklungserfahrungen, sind jedoch mit ihren App-Modellen präskriptiver. Letztendlich gibt es einen Kompromiss zwischen Benutzerfreundlichkeit und Kontrolle, den Sie bewerten müssen.

Bewerten und priorisieren Sie während des Plattformentwurfs die Dienste, die Sie anbieten oder verschieben möchten. Ob Sie Apps beispielsweise direkt auf Azure Kubernetes Service (AKS) oder über Azure Container Apps (ACA) erstellen, hängt von Ihren Anforderungen für den Dienst sowie von Ihrer internen Kapazität und Qualifikation ab. Gleiches gilt für Dienste im Funktionsstil wie Azure Functions oder Azure App Service. ACA, Azure Functions und App Service die Komplexität reduzieren, während AKS mehr Flexibilität und Kontrolle bietet. Experimentellere App-Modelle wie das OSS Radius-Inkubationsprojekt versuchen, ein Gleichgewicht zwischen den beiden zu schaffen, befinden sich jedoch in der Regel in früheren Reifephasen als Clouddienste mit vollständiger Unterstützung und einer Präsenz in etablierten IaC-Formaten.

Die Probleme, die Sie bei der Planung identifiziert haben, sollten Ihnen helfen, zu bewerten, welches Ende dieser Skala für Sie geeignet ist. Achten Sie darauf, ihre eigenen internen vorhandenen Skills zu berücksichtigen, wenn Sie eine Entscheidung treffen.

Freigegebene und dedizierte Ressourcen

In Ihrem Bestand gibt es viele Ressourcen, die von mehreren Anwendungen gemeinsam genutzt werden können, um die Auslastung und Kosteneffizienz zu erhöhen. Jede der Ressourcen, die freigegeben werden können, hat einen eigenen Satz von Überlegungen. Dies sind z. B. Überlegungen zum Freigeben von K8s-Clustern, aber einige gelten für andere Ressourcentypen:

  • Organisation: Die Gemeinsame Nutzung von Ressourcen wie Clustern innerhalb und nicht über Organisationsgrenzen hinweg kann die Ausrichtung der Ressourcen an der Organisationsrichtung, den Anforderungen, der Priorität usw. verbessern.
  • Mandantenfähigkeit der Anwendung: Anwendungen können unterschiedliche Anforderungen an die Mandantenisolation haben. Sie müssen die Sicherheit einzelner Anwendungen und die Einhaltung gesetzlicher Bestimmungen überprüfen, wenn sie mit anderen Anwendungen koexistieren können. In Kubernetes können Anwendungen beispielsweise namespaceisoliert werden. Sie sollten jedoch auch die Anwendungsmandantenfähigkeit für verschiedene Umgebungstypen in Betracht ziehen. Beispielsweise ist es häufig am besten, testanwendungen mit Produktionsanwendungen in denselben Clustern zu mischen, um unerwartete Auswirkungen aufgrund von Fehlkonfigurationen oder Sicherheitsproblemen zu vermeiden. Oder Sie können sich entscheiden, zuerst dedizierte Kubernetes-Cluster zu testen und zu optimieren, um diese Probleme vor der Bereitstellung in einem freigegebenen Cluster aufzuspüren. Unabhängig davon ist Konsistenz in Ihrem Ansatz der Schlüssel, um Verwirrung und Fehler zu vermeiden.
  • Ressourcenverbrauch: Machen Sie sich mit der Nutzung der einzelnen Anwendungsressourcen und der freien Kapazität vertraut, und erstellen Sie eine Projektion, um zu schätzen, ob die Freigabe praktikabel ist. Sie sollten auch die Grenzwerte der verbrauchten Ressourcen (Rechenzentrumskapazität oder Abonnementgrenzwerte) beachten. Das Ziel besteht darin, das Verschieben Ihrer Anwendung und Abhängigkeiten aufgrund von Ressourceneinschränkungen in einer freigegebenen Umgebung oder Live-Site-Incidents aufgrund von Kapazitätsauslastung zu vermeiden. Die Verwendung von Ressourcengrenzwerten, repräsentativen Tests, Überwachung von Warnungen und Berichterstellung kann dazu beitragen, den Ressourcenverbrauch zu identifizieren und vor Anwendungen zu schützen, die zu viele Ressourcen verbrauchen, die sich auf andere Anwendungen auswirken können.
  • Optimieren freigegebener Konfigurationen: Freigegebene Ressourcen wie freigegebene Cluster erfordern zusätzliche Überlegungen und Konfigurationen. Zu diesen Überlegungen gehören Kreuzgebühren, Ressourcenzuordnung, Berechtigungsverwaltung, Workloadbesitz, Datenfreigabe, Upgradekoordination, Workloadplatzierung, Einrichten, Verwalten und Durchlaufen einer Baselinekonfiguration, Kapazitätsverwaltung und Workloadplatzierung. Freigegebene Ressourcen haben Vorteile, aber wenn die Standardkonfigurationen zu restriktiv sind und sich nicht weiterentwickeln, werden sie veraltet.

Einige dieser Probleme werden durch PaaS-Lösungen vereinfacht, aber viele dieser Punkte gelten auch für die Freigabe einer Datenbank. Die Freigabe hat sowohl Ups-Seiten als auch Abwärtsseiten, daher sollten Sie die Kompromisse sorgfältig berücksichtigen.

Weitere Informationen zum Kubernetes-Clusteraspekt in diesem Artikel finden Sie in der mehrinstanzenfähigen Dokumentation Azure Kubernetes Service (AKS).

Governance

Governance ist ein wichtiger Bestandteil der Aktivierung von Self-Service mit Leitplanken, aber die Anwendung von Complianceregeln in einer Weise, die sich nicht auf den Zeit-bis-Geschäftswert für Anwendungen auswirkt, ist eine häufige Herausforderung. Governance ist ein allgemeines Thema, aber wenn dies ein Problem ist, das Sie haben, beachten Sie beide Aspekte dieses Bereichs:

  • Compliance für die anfängliche Bereitstellung (start right): Dies kann mit standardisierten IaC-Vorlagen erreicht werden, die über Kataloge zur Verfügung gestellt werden, mit Berechtigungsverwaltung und Richtlinien, um sicherzustellen, dass nur zulässige Ressourcen und Konfigurationen bereitgestellt werden können.
  • Aufrechterhaltung der Compliance (bleiben Sie richtig): Richtlinienbasierte Tools können Sie verhindern oder warnen, wenn Ressourcenänderungen vorliegen. Erwägen Sie neben Ihrer Kerninfrastruktur auch Tools, die Compliance innerhalb von Ressourcen wie K8s zusammen mit in Ihren Containern oder VMs verwendeten Betriebssysteme unterstützen. Beispielsweise können Sie eine gesperrte Betriebssystemkonfiguration erzwingen oder Sicherheitssoftwaretools wie Windows Gruppenrichtlinie, SELinux, AppArmor, Azure Policy oder Kyverno installieren. Wenn Entwickler nur Zugriff auf IaC-Repositorys haben, können Sie Genehmigungsworkflows hinzufügen, um vorgeschlagene Änderungen zu überprüfen und den direkten Zugriff auf Ressourcensteuerungsebenen (z. B. Azure) zu verhindern.

Für die Aufrechterhaltung der Compliance sind Tools erforderlich, um auf Probleme zuzugreifen, sie zu melden und zu reagieren. Beispielsweise können Azure Policy mit vielen Azure-Diensten für Überwachung, Berichterstellung und Wartung verwendet werden. Es verfügt auch über verschiedene Modi wie Audit, Deny und DeployIfNotExists, je nach Ihren Anforderungen.

Richtlinien können zwar Compliance erzwingen, aber auch Anwendungen unerwartet unterbrechen. Erwägen Sie daher die Weiterentwicklung zu einer PaC-Praxis (Policy as Code), wenn Sie im großen Stil arbeiten. PaC ist ein wichtiger Bestandteil Ihres richtigen Start- und Verbleibsansatzes :

  • Zentral verwaltete Standards
  • Versionskontrolle für Ihre Richtlinien
  • Automatisiertes Testen & Validierung
  • Verkürzte Rolloutzeit
  • Kontinuierliche Bereitstellung

PaC kann dazu beitragen, den Explosionsradius einer potenziell fehlerhaften Richtlinie mit Funktionen wie folgenden zu minimieren:

  • Richtliniendefinitionen, die als Code in einem Repository gespeichert werden, das überprüft und genehmigt wird.
  • Automatisierung zum Bereitstellen von Tests und Validierungen.
  • Das ringbasierte schrittweise Rollout von Richtlinien & Abhilfemaßnahmen für vorhandene Ressourcen trägt dazu bei, den Explosionsradius einer potenziell fehlerhaften Richtlinie zu minimieren.
  • Der Wartungstask verfügt über integrierte Sicherheit mit Steuerelementen wie dem Beenden des Wartungstasks, wenn mehr als 90 Prozent der Bereitstellungen fehlschlagen.

Beobachtbarkeit

Um Ihre Anwendungen und Infrastruktur zu unterstützen, benötigen Sie Beobachtbarkeit und Protokollierung über den gesamten Stapel, die Ihre Plattformentwicklungs-, Betriebs- und Entwicklerteams verwenden können, um zu sehen, was geschieht.

Abbildung einer Grafana-Dashboard.

Die Anforderungen unterscheiden sich jedoch je nach Rolle. Beispielsweise erfordert das Plattformentwicklungs- und Betriebsteam Dashboards, um die Integrität und Kapazität der Infrastruktur mit geeigneten Warnungen zu überprüfen. Entwickler benötigen Anwendungsmetriken, Protokolle und Ablaufverfolgungen zur Problembehandlung und angepasste Dashboards, die die Anwendungs- und Infrastrukturintegrität anzeigen. Ein Problem dieser Rollen ist möglicherweise die kognitive Überlastung durch zu viele Informationen oder Wissenslücken aufgrund eines Mangels an nützlichen Informationen.

Um diese Herausforderungen zu lösen, berücksichtigen Sie Folgendes:

  • Standards: Wenden Sie Protokollierungsstandards an, um das Erstellen und Wiederverwenden standardisierter Dashboards zu vereinfachen und die Erfassungsverarbeitung durch etwa das OpenTelemetry-Beobachtbarkeitsframework zu vereinfachen.
  • Berechtigungen: Erwägen Sie, Dashboards auf Team- oder Anwendungsebene bereitzustellen, die etwa Grafana verwenden, um roll up-Daten für alle Interessierten bereitzustellen, sowie eine Möglichkeit für vertrauenswürdige Mitglieder von Anwendungsteams, um bei Bedarf sicheren Zugriff auf Protokolle zu erhalten.
  • Speicherung: Das Aufbewahren von Protokollen und Metriken kann teuer sein und unbeabsichtigte Risiken oder Complianceverletzungen verursachen. Richten Sie Aufbewahrungsstandards ein, und veröffentlichen Sie sie als Teil Ihrer richtigen Startanleitung.
  • Überwachen von Ressourcengrenzwerten: Betriebsteams sollten in der Lage sein, alle Einschränkungen für einen bestimmten Ressourcentyp zu identifizieren und nachzuverfolgen. Wenn möglich, sollten diese Einschränkungen mithilfe von Tools wie Azure Policy in IaC-Vorlagen oder -Richtlinien berücksichtigt werden. Vorgänge sollten dann proaktiv mithilfe von Dashboards in etwa Grafana überwachen und freigegebene Ressourcen erweitern, wenn die automatisierte Skalierung nicht möglich oder aktiviert ist. Überwachen Sie beispielsweise die Anzahl der K8s-Clusterknoten auf Kapazität, da Apps im Laufe der Zeit integriert und geändert werden. Warnungen sind erforderlich, und diese Definitionen sollten als Code gespeichert werden, damit sie programmgesteuert Ressourcen hinzugefügt werden können.
  • Identifizieren sie wichtige Kapazitäts- und Integritätsmetriken: Überwachen und Warnen von Betriebssystemen und freigegebenen Ressourcen (Beispiele: CPU, Arbeitsspeicher, Speicher) auf Aushungern mit Metriksammlung mithilfe von z. B. Prometheus oder Azure Container Insights. Sie können die verwendeten Sockets/Ports, die Nutzung der Netzwerkbandbreite von chatten Apps und die Anzahl zustandsbehafteter Anwendungen überwachen, die im Cluster gehostet werden.

Sicherheit

Sicherheit ist auf jeder Ebene erforderlich, von Code, Containern, Clustern bis hin zu Cloud/Infrastruktur. Jede organization hat ihre eigenen Sicherheitsanforderungen, aber auf hoher Ebene sind dies einige Punkte, die Sie für Ihre Plattform berücksichtigen sollten:

  • Befolgen Sie das Prinzip der geringsten Rechte.
  • Vereinheitlichen Sie Ihre DevOps-Sicherheitsverwaltung über mehrere Pipelines hinweg.
  • Stellen Sie sicher, dass kontextbezogene Erkenntnisse zum Identifizieren und Beheben Ihres kritischsten Risikos sichtbar sind.
  • Aktivieren Sie die Erkennung und Reaktion auf moderne Bedrohungen in Ihren Cloudworkloads zur Laufzeit.

Um Probleme in diesem Bereich zu beheben, benötigen Sie Tools zum Auswerten von Tools, die in Ihren Engineering- und Anwendungssystemen, Ressourcen und Diensten cloud- und hybrid funktionieren (z. B. Microsoft Defender für Cloud). Über die Anwendungssicherheit hinaus sollten Sie Folgendes auswerten:

Die Berechtigungsanforderungen können sich je nach Umgebung unterscheiden. In einigen Organisationen können einzelne Teams beispielsweise nicht auf Produktionsressourcen zugreifen, und neue Anwendungen können erst dann automatisch bereitgestellt werden, wenn die Überprüfungen abgeschlossen sind. In Entwicklungs- und Testumgebungen ist jedoch möglicherweise die automatisierte Bereitstellung von Ressourcen und Apps sowie der Zugriff auf Cluster zur Problembehandlung zulässig.

Die Verwaltung des Identitätszugriffs auf Dienste, Anwendungen und Infrastruktur im großen Stil kann eine Herausforderung sein. Sie sollten Identitätsanbieter zum Erstellen, Verwalten und Verwalten von Identitätsinformationen verwenden und gleichzeitig Authentifizierungsdienste für Anwendungen und Dienste bereitstellen und die in rollenbasierte Zugriffssteuerungsautorisierungssysteme für die Authentifizierung und Autorisierungsverwaltung (RBAC) in großem Umfang integrieren können. Beispielsweise können Sie Azure RBAC und Microsoft Entra ID verwenden, um Authentifizierung und Autorisierung im großen Stil für Azure-Dienste wie Azure Kubernetes Service bereitzustellen, ohne Berechtigungen direkt für jeden einzelnen Cluster einrichten zu müssen.

Anwendungen benötigen möglicherweise Zugriff auf eine Identität, um auf Cloudressourcen wie Speicher zuzugreifen. Sie müssen die Anforderungen überprüfen und bewerten, wie Ihr Identitätsanbieter dies auf möglichst sichere Weise unterstützen kann. In AKS können cloudnative Apps beispielsweise eine Workloadidentität verwenden, die mit Microsoft Entra ID verbunden ist, um containerisierten Workloads die Authentifizierung zu ermöglichen. Dieser Ansatz ermöglicht Anwendungen den Zugriff auf Cloudressourcen ohne Geheimaustausch innerhalb des Anwendungscodes.

Kostenverwaltung für Metadaten &

Die Kosten sind ein weiteres Problem, das für Ihre Plattformentwicklungsbemühungen nach oben sprudeln kann. Um Ihre Anwendungsplattform ordnungsgemäß zu verwalten, benötigen Sie eine Möglichkeit, Workloadbesitzer zu identifizieren. Sie möchten eine Möglichkeit zum Abrufen eines Ressourcenbestands, der Besitzern für einen bestimmten Satz von Metadaten zugeordnet ist. Beispielsweise können Sie in Azure AKS-Bezeichnungen, Azure Resource Manager-Tags sowie Konzepte wie Projekte in Azure-Bereitstellungsumgebungen verwenden, um Ihre Ressourcen auf verschiedenen Ebenen zu gruppieren. Damit dies funktioniert, müssen die ausgewählten Metadaten obligatorische Eigenschaften (z. B. Azure Policy) bei der Bereitstellung von Workloads und Ressourcen enthalten. Dies hilft bei der Kostenverteilung, der Zuordnung von Lösungsressourcen, besitzern usw. Erwägen Sie, regelmäßige Berichte auszuführen, um verwaiste Ressourcen nachzuverfolgen.

Neben der Nachverfolgung müssen Sie möglicherweise einzelnen Anwendungsteams Kosten für ihre Ressourcennutzung zuweisen, indem Sie dieselben Metadaten mit Kostenmanagementsystemen wie Microsoft Cost Management verwenden. Diese Methode verfolgt zwar die von den Anwendungsteams bereitgestellten Ressourcen nach, deckt jedoch nicht die Kosten für freigegebene Ressourcen wie Ihren Identitätsanbieter, die Protokollierung & Metrikspeicher und die Netzwerkbandbreitennutzung. Bei gemeinsam genutzten Ressourcen können Sie die Betriebskosten gleichermaßen nach den einzelnen Teams aufteilen oder dedizierte Systeme (z. B. Protokollierungsspeicher) bereitstellen, bei denen eine nicht einheitliche Nutzung vorliegt. Einige freigegebene Ressourcentypen können möglicherweise Einblicke in den Ressourcenverbrauch liefern, z. B. Kubernetes verfügt über Tools wie OpenCost oder Kubecost und kann ihnen helfen.

Sie sollten auch nach Kostenanalysetools suchen, in denen Sie die aktuellen Ausgaben überprüfen können. In Azure-Portal gibt es beispielsweise Kostenwarnungen und Budgetwarnungen, die den Ressourcenverbrauch in einer Gruppe nachverfolgen und Benachrichtigungen senden können, wenn Sie voreingestellte Schwellenwerte erreichen.

Entwerfen einer Self-Service-Basis für Entwickler