Verfeinern Der Anwendungsplattform für optimierte Anwendungsentwicklung und Infrastrukturverwaltung

  • Artikel

Ein großer Teil der Verbesserung der Plattform-Engineering-Praktiken Ihrer Organisation besteht darin, Ihre Anwendungsplattform auszuwerten. Eine Anwendungsplattform umfasst alle Tools und Dienste, die zur Unterstützung von Entwicklung, Bereitstellung und Anwendungsverwaltung in Ihrer Organisation verwendet werden.

Vereinfachen und Standardisieren

Infrastruktur als Code (IaC) und Automatisierungstools können mit Vorlagen kombiniert werden, um Infrastruktur und Anwendungsbereitstellung zu standardisieren. Um die Belastung von Plattformspezifischen für den Endbenutzer zu verringern, abstrakte Plattformdetails, indem Sie Auswahlmöglichkeiten in verlässige Benennungskonventionen aufteilen, z. B.:

  • Ressourcentypkategorien (high compute, high memory)
  • Ressourcengrößenkategorien (T-Shirt-Größe, klein mittel und groß)

Vorlagen sollten allgemeine Anforderungen darstellen, die mit voreingestellten Konfigurationen getestet wurden, sodass Entwicklerteams sofort mit der Bereitstellung minimaler Parameter und ohne Überprüfungsoptionen beginnen können. Es gibt jedoch Situationen, in denen Teams mehr Optionen für veröffentlichte Vorlagen ändern müssen, als verfügbar oder wünschenswert sind. Beispielsweise benötigt ein genehmigtes Design möglicherweise eine bestimmte Konfiguration, die sich außerhalb der unterstützten Vorlagenstandardwerte befindet. In dieser Instanz können 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 cloudeigene IaC-Tools (Beispiele, Cluster-API, Crossplane, Azure Service Operator v2). Außerhalb der IaC-Toolabweichungserkennung gibt es Cloudkonfigurationstools, die Ressourcenkonfigurationen abfragen können, z . B. Azure Resource Graph. Diese können als zwei Vorteile dienen; Sie überwachen Änderungen außerhalb des Infrastrukturcodes und überprüfen auf geänderte voreingestellte Konfigurationen. Um zu starr zu sein, können Sie auch Toleranzen in Bereitstellungen mit vordefinierten Grenzwerten implementieren. Sie können beispielsweise Azure-Richtlinie verwenden, um die Anzahl der Kubernetes-Knoten einzuschränken, die eine Bereitstellung haben 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 aber mit ihren App-Modellen präskriptiv. Letztendlich gibt es einen Kompromiss zwischen benutzerfreundlicher Bedienung und Kontrolle, die Sie auswerten müssen.

Bewerten und priorisieren Sie während des Plattformdesigns die Dienstanforderungen Ihrer Organisation. Ob Sie z. B. Apps direkt auf Azure Kubernetes Service (AKS) oder über Azure Container Apps (ACA) erstellen, hängt von Ihren Anforderungen für den Dienst und Ihren internen Kapazitäts- und Qualifikationssatz ab. Das gleiche gilt für Funktionen wie Azure Functions oder Azure-App Service. ACA, Azure Functions und App Service reduzieren die Komplexität, 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, sind jedoch in der Regel in früheren Phasen der Reife als Clouddienste mit vollständiger Unterstützung und anwesenheit in etablierten IaC-Formaten.

Die Probleme, die Sie bei der Planung erkannt haben, sollten Ihnen helfen, zu bewerten, welches Ende dieser Skala für Sie geeignet ist. Achten Sie darauf, Ihre eigenen internen vorhandenen Fähigkeiten zu berücksichtigen, während Sie eine Entscheidung treffen.

Freigegebene und dedizierte Ressourcen

Innerhalb Ihrer Organisation gibt es Ressourcen, die von mehreren Anwendungen gemeinsam genutzt werden können, um die Auslastung und Kosteneffizienz zu erhöhen. Jede gemeinsame Besourse hat einen eigenen Satz von Überlegungen. Dies sind z. B. Überlegungen zum Freigeben von K8s-Clustern, einige gelten jedoch für andere Ressourcentypen:

  • Organisation: Das Freigeben von Ressourcen wie Clustern innerhalb und nicht über Organisationsgrenzen hinweg kann die Ausrichtung auf die Organisationsrichtung, Anforderungen und Priorität verbessern.
  • Anwendungs-Mandant: Anwendungen können unterschiedliche Anforderungen an die Mandantenisolation haben. Sie müssen die sicherheit und die Einhaltung gesetzlicher Vorschriften überprüfen, wenn sie mit anderen Anwendungen koexistieren kann. Beispielsweise können Anwendungen in Kubernetes die Namespaceisolation verwenden. Sie sollten jedoch auch die Anwendungs-Mandantschaft für verschiedene Umgebungstypen berücksichtigen. Es empfiehlt sich beispielsweise häufig, Testanwendungen mit Produktionsanwendungen auf denselben Clustern zu mischen, um unerwartete Auswirkungen aufgrund von Fehlkonfigurationen oder Sicherheitsproblemen zu vermeiden. Oder Sie können sich entscheiden, zuerst kubernetes-Cluster zu testen und zu optimieren, um diese Probleme vor der Bereitstellung auf einem freigegebenen Cluster nachzuverfolgen. Unabhängig davon ist Konsistenz in Ihrem Ansatz der Schlüssel, um Verwirrung und Fehler zu vermeiden.
  • Ressourcenverbrauch: Verstehen Sie jede Anwendungsressourcennutzung, ihre Kapazitätsressource und führen Sie eine Projektion aus, um zu ermitteln, ob die Freigabe lebensfähig ist. Außerdem sollten Sie die Grenzwerte der verbrauchten Ressourcen (Rechenzentrumskapazität oder Abonnementbeschränkungen) kennen. Ziel ist es, das Verschieben Ihrer Anwendung und Abhängigkeiten aufgrund von Ressourceneinschränkungen in einer freigegebenen Umgebung zu vermeiden oder Live-Site-Vorfälle zu haben, wenn die Kapazität abgelaufen ist. Verwenden Sie Ressourcengrenzwerte, repräsentative Tests, Überwachen von Warnungen und Berichte, um den Ressourcenverbrauch zu identifizieren und vor Anwendungen zu schützen, die zu viele Ressourcen verbrauchen.
  • Optimieren freigegebener Konfigurationen: Freigegebene Ressourcen wie freigegebene Cluster erfordern zusätzliche Überlegungen und Konfigurationen. Diese Überlegungen umfassen cross charging, resource allocation, permissions management, workload ownership, data sharing, upgrade coordination, workload placement, establishing, managing, and iterating a baseline configuration, capacity management, and workload placement. Gemeinsam genutzte Ressourcen haben Vorteile, aber wenn die Standardkonfigurationen zu restriktiv sind und sich nicht weiterentwickeln, werden sie veraltet.

Implementieren von Governancestrategien

Governance ist ein wichtiger Bestandteil der Self-Service-Aktivierung mit Schutzläufen, aber das Anwenden von Complianceregeln auf eine Weise, die sich nicht auf den Geschäftlichen Wert für Anwendungen auswirkt, ist eine häufige Herausforderung. Es gibt zwei Teile der Governance:

  • Anfängliche Bereitstellungscompliance (Start right): Dies kann mit standardisierten IaC-Vorlagen erreicht werden, die über Kataloge verfügbar gemacht werden, mit Berechtigungsverwaltung und Richtlinien, um sicherzustellen, dass nur zulässige Ressourcen und Konfigurationen bereitgestellt werden können.
  • Beibehalten der Compliance (bleiben Sie richtig): Richtlinienbasierte Tools können Sie verhindern oder benachrichtigen, wenn Ressourcenänderungen vorhanden sind. Berücksichtigen Sie darüber hinaus Tools, die die Compliance in Ressourcen wie K8s zusammen mit OSs unterstützen, die in Ihren Containern oder virtuellen Computern verwendet werden. Sie können beispielsweise eine gesperrte Betriebssystemkonfiguration erzwingen oder Sicherheitssoftwaretools wie Windows-Gruppenrichtlinie, SELinux, AppArmor, Azure-Richtlinie oder Kyverno installieren. Wenn Entwickler nur Zugriff auf IaC-Repositorys haben, können Sie Genehmigungsworkflows hinzufügen, um vorgeschlagene Änderungen zu überprüfen und direkten Zugriff auf Ressourcensteuerungsebenen zu verhindern (z. B. Azure).

Die Aufrechterhaltung der Compliance erfordert Tools, um auf Probleme zuzugreifen, zu melden und zu reagieren. Azure-Richtlinie kann beispielsweise mit vielen Azure-Diensten für Überwachung, Berichterstellung und Wartung verwendet werden. Es verfügt außerdem über verschiedene Modi wie Audit, Deny und DeployIfNotExists, je nach Ihren Anforderungen.

Richtlinien können zwar complianceerzwingen, aber auch Anwendungen unerwartet unterbrechen. Erwägen Sie daher die Entwicklung einer Richtlinie als Code (PaC)-Praxis, wenn sie im Maßstab ausgeführt wird. Als wichtiger Bestandteil Ihres Start- und Aufenthaltsrechts bietet PaC:

  • Zentral verwaltete Standards
  • Versionssteuerung für Ihre Richtlinien
  • Automatisierte Tests und Validierung
  • Reduzierte Zeit für das Rollout
  • Continuous Deployment

PaC kann dazu beitragen, den Strahlradius einer potenziell schlechten Richtlinie mit Funktionen wie:

  • Richtliniendefinitionen, die als Code in einem Repository gespeichert sind, das überprüft und genehmigt wird.
  • Automatisierung zur Bereitstellung von Tests und Validierung.
  • Ringbasierte schrittweise Einführung von Richtlinien und Korrekturen für vorhandene Ressourcen helfen, den Strahlradius einer potenziell schlechten Richtlinie zu minimieren.
  • Der Wartungsvorgang verfügt über integrierte Sicherheit, mit Steuerelementen wie dem Beenden des Wartungsvorgangs, wenn mehr als 90 Prozent der Bereitstellungen fehlschlagen.

Implementieren von rollenspezifischer Observability und Protokollierung

Um Ihre Anwendungen und Infrastruktur zu unterstützen, benötigen Sie observability and logging across your entire stack.

Abbildung eines Grafana-Dashboards mit Observability und Protokollierung.

Die Anforderungen unterscheiden sich je nach Rolle. Beispielsweise benötigen das Plattform-Engineering- 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 für Problembehandlung und angepasste Dashboards, die den Anwendungs- und Infrastrukturstatus anzeigen. Ein Problem dieser Rollen könnte auftreten, ist kognitive Überlastung von zu vielen Informationen oder Wissenslücken aufgrund eines Mangels an nützlichen Informationen.

Beachten Sie Folgendes, um diese Herausforderungen zu lösen:

  • Standards: Wenden Sie Protokollierungsstandards an, um das Erstellen und Wiederverwenden standardisierter Dashboards zu vereinfachen und die Aufnahmeverarbeitung durch etwas wie das OpenTelemetry-Observability-Framework zu vereinfachen.
  • Berechtigungen: Stellen Sie Dashboards auf Team- oder Anwendungsebene bereit, z . B. Grafana , um Rollupdaten für interessierte Personen bereitzustellen, zusammen mit einer Einrichtung für vertrauenswürdige Mitglieder von Anwendungsteams, um bei Bedarf sicheren Zugriff auf Protokolle zu erhalten.
  • Aufbewahrung: Das Aufbewahren von Protokollen und Metriken kann teuer sein und unbeabsichtigte Risiken oder Complianceverletzungen erstellen. Richten Sie Aufbewahrungsstandardwerte ein, und veröffentlichen Sie sie als Teil Ihrer richtigen Anleitungen für den Start.
  • Überwachen von Ressourcengrenzwerten: Operationsteams sollten in der Lage sein, Einschränkungen für einen bestimmten Ressourcentyp zu identifizieren und nachzuverfolgen. Diese Einschränkungen sollten in IaC-Vorlagen oder Richtlinien mithilfe von Tools wie Azure-Richtlinie berücksichtigt werden. Vorgänge sollten dann proaktiv die Verwendung von Dashboards in etwa Grafana überwachen und freigegebene Ressourcen erweitern, bei denen 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 Benachrichtigen des Betriebssystems und freigegebener Ressourcen (Beispiele: CPU, Arbeitsspeicher, Speicher) für den Hunger mit Metrikensammlung mithilfe von Prometheus oder Azure Container Insights. Sie können Sockets/Ports überwachen, die Netzwerkbandbreitennutzung von chatty-Apps und die Anzahl der zustandsbehafteten Anwendungen, die auf dem Cluster gehostet werden.

Erstellen sie sicherheit mit dem Prinzip der geringsten Berechtigungen, der einheitlichen Sicherheitsverwaltung und der Bedrohungserkennung

Sicherheit ist auf jeder Ebene von Code, Container, Cluster und Cloud/Infrastruktur erforderlich. Dies sind die mindest empfohlenen Sicherheitsschritte:

  • Befolgen Sie das Prinzip der geringsten Privilegien.
  • Vereinheitlichen Sie Ihre DevOps-Sicherheitsverwaltung über mehrere Pipelines hinweg.
  • Stellen Sie sicher, dass kontextbezogene Erkenntnisse sichtbar sind, um Ihr kritischstes Risiko zu identifizieren und zu beheben.
  • Aktivieren Sie die Erkennung und Reaktion auf moderne Bedrohungen in Ihren Cloud-Workloads 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 in cloud- und hybriden Umgebungen (z . B. Microsoft Defender für Cloud) funktionieren. Bewerten Sie über die Anwendungssicherheit hinaus:

Berechtigungsanforderungen können sich je nach Umgebung unterscheiden. In einigen Organisationen dürfen einzelne Teams beispielsweise nicht auf Produktionsressourcen zugreifen, und neue Anwendungen können erst dann automatisch bereitgestellt werden, wenn Rezensionen abgeschlossen sind. Die automatisierte Ressourcen- und App-Bereitstellung und der Zugriff auf Cluster zur Problembehandlung können jedoch in Entwicklungs- und Testumgebungen zulässig sein.

Das Verwalten des Identitätszugriffs auf Dienste, Anwendungen, Infrastruktur im großen Maßstab kann eine Herausforderung darstellen. Identitätsanbieter zum Erstellen, Verwalten und Verwalten von Identitätsinformationen. Ihr Plan sollte Authentifizierungsdienste für Anwendungen und Dienste enthalten, die in rollenbasierte Zugriffssteuerungsautorisierungssysteme (RBAC) integriert werden können. Sie können beispielsweise Microsoft Entra-ID verwenden, um Authentifizierung und Autorisierung im großen Maßstab 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 cloudeigene Apps beispielsweise eine Workloadidentität verwenden, die mit Microsoft Entra-ID verbunden ist, um die Authentifizierung von containerisierten Workloads zu ermöglichen. Dieser Ansatz ermöglicht Anwendungen den Zugriff auf Cloudressourcen ohne geheimen Austausch innerhalb des Anwendungscodes.

Reduzieren der Kosten durch Identifizieren von Workloadbesitzern und Nachverfolgen von Ressourcen

Das Verwalten von Kosten ist ein weiterer Bestandteil des Plattform engineering. Um Ihre Anwendungsplattform ordnungsgemäß zu verwalten, benötigen Sie eine Möglichkeit, Workloadbesitzer zu identifizieren. Sie möchten eine Möglichkeit zum Abrufen eines Inventars von Ressourcen, die Besitzern für einen bestimmten Satz von Metadaten zugeordnet sind. In Azure können Sie beispielsweise 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-Richtlinie) enthalten, wenn Arbeitslasten und Ressourcen bereitgestellt werden. Dies hilft bei der Kostenzuordnung, der Lösungsressourcenzuordnung und den Besitzern. Erwägen Sie, regelmäßige Berichte auszuführen, um verwaiste Ressourcen nachzuverfolgen.

Über die Nachverfolgung hinaus müssen Sie möglicherweise einzelnen Anwendungsteams Kosten für die Ressourcennutzung zuweisen, indem Sie dieselben Metadaten mit Kostenverwaltungssystemen wie Microsoft Cost Management verwenden. Diese Methode verfolgt zwar ressourcen, die von den Anwendungsteams bereitgestellt werden, deckt jedoch nicht die Kosten gemeinsam genutzter Ressourcen wie Identitätsanbieter, Protokollierung und Metrikspeicher sowie Netzwerkbandbreitenverbrauch ab. Bei gemeinsam genutzten Ressourcen können Sie die Betriebskosten gleichmäßig durch die einzelnen Teams unterteilen oder dedizierte Systeme (z. B. Protokollierungsspeicher) bereitstellen, bei denen ein nichtuniformer Verbrauch besteht. 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, mit denen Sie die aktuellen Ausgaben überprüfen können. Beispielsweise gibt es in Azure-Portal Warnungen zu Kosten und Budgets Warnungen, die den Verbrauch von Ressourcen in einer Gruppe nachverfolgen und Benachrichtigungen senden können, wenn Sie voreingestellte Schwellenwerte erreicht haben.

Entscheiden, wann und wo investiert werden soll

Wenn Sie über mehrere Anwendungsplattformen verfügen, kann es schwierig sein zu entscheiden, wann und wo Sie in Verbesserungen investieren, die Probleme wie hohe Kosten oder schlechte Observierbarkeit lösen. Wenn Sie neu beginnen, verfügt das Azure Architecture Center über mehrere potenzielle Muster, die Sie auswerten können. Darüber hinaus sind hier einige Fragen, die Sie berücksichtigen sollten, wenn Sie mit der Planung beginnen, was Sie tun möchten:

Frage Tipps
Möchten Sie Ihre vorhandene Anwendungsplattform anpassen, neu starten oder eine Kombination dieser Ansätze verwenden? Auch wenn Sie mit dem zufrieden sind, was Sie jetzt haben oder neu beginnen, möchten Sie überlegen, wie Sie sich im Laufe der Zeit anpassen können. Sofortige Änderungen funktionieren selten. Ihre Anwendungsplattformen sind ein verschiebendes Ziel. Ihr ideales System ändert sich, wenn die Zeit vergeht. Sie möchten dieses Denken und alle zugehörigen Migrationspläne in Ihren Zukünftigen Entwurf integrieren.
Wenn Sie das, was Sie heute tun, ändern möchten, mit welchen Produkten, Dienstleistungen oder Investitionen sind Sie zufrieden? Wie die Aussage sagt: "Wenn es nicht beschädigt ist, beheben Sie es nicht." Ändern Sie die Dinge nicht, ohne dass Sie dies tun müssen. Wenn Sie jedoch über hausgemachte Lösungen verfügen, überlegen Sie, ob es an der Zeit ist, zu einem vorhandenen Produkt zu wechseln, um langfristigen Wartungsaufwand zu sparen. Wenn Sie beispielsweise Ihre eigene Überwachungslösung betreiben, möchten Sie diese Belastung von Ihrem Ops-Team entfernen und zu einem neuen verwalteten Produkt migrieren?
Wo werden die meisten Änderungen im Laufe der Zeit angezeigt? Gibt es solche Bereiche, die allen (oder den meisten) App-Typen Ihrer Organisation gemeinsam sind? Bereiche, mit denen Sie oder Ihre internen Kunden nicht zufrieden sind und sich wahrscheinlich nicht häufig ändern, sind großartige Ausgangspunkte. Diese haben langfristig die größte Rendite für Investitionen. Dadurch können Sie auch herausfinden, wie Sie die Migration zu einer neuen Lösung erleichtern würden. Beispielsweise sind App-Modelle tendenziell flüssig, aber Protokollanalysetools weisen tendenziell eine längere Haltbarkeit auf. Sie können sich auch auf neue Projekte /Anwendungen konzentrieren, um zu beginnen, während Sie bestätigen, dass die Richtungsänderung die gewünschten Rückgaben hat.
Investieren Sie in benutzerdefinierte Lösungen in Bereiche mit dem höchsten Mehrwert? Fühlen Sie sich stark, dass eine einzigartige App-Infrastrukturplattform-Funktion Teil Ihres Wettbewerbsvorteils ist? Wenn Sie Lücken identifiziert haben, sollten Sie vor dem Ausführen einer benutzerdefinierten Aktion überlegen, in welche Bereiche Anbieter am wahrscheinlichsten investieren und ihr benutzerdefiniertes Denken an anderer Stelle konzentrieren. Denken Sie zunächst an sich selbst als Integrator und nicht als benutzerdefinierter App-Infrastruktur- oder App-Modellanbieter. Alles, was Sie bauen, muss beibehalten werden, welche Zwerge langfristig kosten. Wenn Sie die dringende Notwendigkeit haben, eine Lösung in einem Bereich zu erstellen, von dem Sie vermuten, dass sie von Anbietern langfristig abgedeckt werden, planen Sie eine Sonnenuntergang oder langfristige Unterstützung. Ihre internen Kunden werden in der Regel so glücklich (wenn nicht mehr) mit einem Off-the-Shelf-Produkt als benutzerdefiniertes Produkt sein.

Die Anpassung Ihrer vorhandenen Anwendungsplattforminvestitionen kann eine gute Möglichkeit sein, loslegen zu können. Wenn Sie Updates vornehmen, sollten Sie mit neuen Anwendungen beginnen, um Pilotideen vor jeder Art von Rollout zu vereinfachen. Berücksichtigen Sie diese Änderung durch IaC und Anwendungsvorlagen. Investieren Sie in benutzerdefinierte Lösungen für Ihre einzigartigen Anforderungen in bereiche mit hohem Nutzen. Versuchen Sie andernfalls, eine Standardlösung zu verwenden. Konzentrieren Sie sich wie bei Engineeringsystemen auf die Automatisierung von Bereitstellung, Nachverfolgung und Bereitstellung, anstatt einen starren Weg zu übernehmen, um Änderungen im Laufe der Zeit zu verwalten.

Zugehöriger Inhalt

Entwerfen einer Self-Service-Foundation für Entwickler