Verbessern der Ermittlung und Beseitigung von Abfällen durch Inventare und Beziehungsnachverfolgung

Mit der organization wächst auch die Menge an Inhalten, die Sie nachverfolgen müssen. Möglicherweise müssen Sie Code, APIs, Container, virtuelle Computer (VMs), Messagingthemen, Teammitgliedschaft, Projektbesitz und vieles mehr nachverfolgen. Bei der Skalierung ist es nicht ungewöhnlich, dass duplizierte Anstrengungen häufig auftreten, weil ein Team das andere nicht kennt. Wenn Personen zwischen Teams wechseln, neue Personen dem Unternehmen beitreten und andere verlassen, können Projekte verwaist werden. Wenn dies nicht verwaltet wird, kann dies zu technischer Zersiedelung und Abfall führen, einfach weil Sie nicht so einfach entdecken können, was bereits vorhanden ist. Dies ist eine häufige Herausforderung. Betrachten Sie beispielsweise dieses Zitat:

Wir verfügen über eine Menge von Containern oder [VM]-Instanzen, die ausgeführt werden. Können wir unsere alten VMs löschen? Niemand weiß es. Wir müssen uns eine Möglichkeit ausfindig machen, alte Dinge zu sauber und richtige Tags zu verwenden, damit wir wissen, wer der Besitzer oder das Team ist, der uns darüber informieren kann, was wir tun können und was der Lebenszyklus ist.... Wir wissen nicht, ob wir eine bestimmte VM herunterfahren können, da wir nicht sicher sind, was passieren wird. - Martin, DevOps Engineer, Großes Logistikunternehmen

Verbesserung der Nachverfolgung, Sicherheit und Wiederverwendung durch maßgeschneiderte Inventare

Ein Teil des Benötigten ist ein Inventar, das Ihnen hilft, alle "Dinge", die Sie in Ihrem Ökosystem erstellt oder erstellt haben, nachzuverfolgen, die interne Kunden auf verständliche Weise visualisieren können.

Ein Bestand kann die Sicherheit verbessern, die Wiederverwendung fördern und die Ermittlung im Allgemeinen vereinfachen. Beispielsweise beschreiben und verfolgen Azure-Bereitstellungsumgebungen komplexe Infrastruktur, die über Infrastructure-as-Code (IaC) erstellt wurde, als eine abstrakte Umgebung , die sich auf einer Ebene befindet, die sowohl für die Entwicklung als auch für den Betrieb verständlich ist. Ebenso bietet Azure API Center Entwicklern eine Möglichkeit, APIs zu ermitteln und zu nutzen. Paketregistrierungen wie GitHub-Pakete oder Azure Artifacts (oder andere Inventare genehmigter Pakete und SDKs) verbessern die Sicherheit der Lieferkette. Jedes dieser Tools bietet einen Bestand, der Ihnen hilft, Verschwendung zu verwalten, nachzuverfolgen und sauber.

Bei der Bewertung, wie Sie diese Inventare erstellen oder anwenden, ist eine wichtige Entscheidung, zu bestimmen, wie breit ihre Inhalte sichtbar sein sollten. Denken Sie daran, dass es hier keine richtige oder falsche Antwort gibt. Einige Unternehmen verfolgen einen offenen Küchenansatz, bei dem "jeder sehen kann, dass das Essen zubereitet wird, aber nur wenige Leute können es kochen". Mit einer offenen Küche haben Entwickler einen vollständigen Einblick in die Softwareressourcen, können aber nur die Ressourcen ändern, für die sie verantwortlich sind. Umgekehrt können regulierte Unternehmen strengere Regeln haben, bei denen selbst die Sichtbarkeit von Projektnamen als sensibel angesehen wird.

Verbessern der Ermittlung und Nachverfolgung durch Beziehungen

Ein oder mehrere Inventursysteme, die Ihnen helfen, das zu verfolgen, was Sie haben, ist wichtig für plattformtechnische Verfahren und zur Vermeidung von technischen Zersprühungen. Zunächst reicht es möglicherweise aus, eine Reihe von flachen Bestandslisten zu haben. Obwohl sie nicht gestartet werden müssen, können Sie auch die Auffindbarkeit verbessern, indem Sie Beziehungen zwischen verschiedenen Ressourcen über mehrere Lagerbestände hinweg hinzufügen. Unabhängig von der erforderlichen Sichtbarkeit können Teams mit einem zentralisierten Aggregationspunkt alle verfügbaren Ressourcen schnell durchsuchen und ermitteln. Dies fördert die Wiederverwendung, reduziert redundanz und etabliert einen konsistenten Governanceansatz.

Betrachten Sie die Beziehung zwischen einer API-Definition und dem bereitgestellten Anwendungscode, der die Schnittstelle implementiert. Dieser Code wird in einem Repository gespeichert und von einem Team verwaltet und stellt Dokumentation zu seiner Verwendung bereit. Entwicklungs-, Test-, Prod- und sogar temporäre Sandboxumgebungen werden erstellt. In cloudnativen Szenarien können die Umgebungen in einem freigegebenen Kubernetes-Cluster bereitgestellt werden. Das Entwicklungsteam, das die API erstellt, und alle internen Consumer der API müssen in der Lage sein, Informationen zu jedem dieser Dinge zu erhalten, aber die Beziehung zwischen den Ressourcen ist nicht offensichtlich.

Zu Beginn können Sie etwas so einfaches wie eine Wiki-Seite verwenden, um nachzuverfolgen, wie die einzelnen Dinge miteinander in Beziehung stehen. Aber die Dokumentation altert schnell und kann schwierig sein, sowohl zu finden als auch zu analysieren. Im Idealfall verfügen Sie über ein System mit einem Beziehungsdiagramm , mit dem Benutzeroberflächen diese Beziehungen in Ihrem Bestand durchlaufen können. Um die Auffindbarkeit wirklich zu verbessern, müssen Sie in der Lage sein, dinge, die in mehreren Arten von Inventaren oder Graphen gespeichert sind, zusammenzubinden. Möglicherweise müssen Sie Inventare nicht direkt nutzen, aber Sie möchten sie wahrscheinlich Informationen in einem API-Katalogsystem zuordnen.

Um die Analogie des digitalen Speichers zu verwenden, kann es auch hilfreich sein, die Elemente (Vorlagen) in Ihrem Katalog den resultierenden Inventarinhalten zuzuordnen. Wenn Sie beispielsweise feststellen, dass eine Ihrer Vorlagen eine unsichere Konfiguration erstellt, müssen Sie schnell alle Ressourcen finden, die die Vorlage erstellt haben, um sie zu beheben. Selbst start right application templates sind im Wesentlichen Starter Kit-Bundles in diesem Katalog, die an andere Arten von Katalogelementen (z. B. IaC-Vorlagen) gebunden sind. Wenn Sie diese Zuordnungen nachverfolgen, können Sie jede Anwendung proaktiv finden, die auf eine ungültige IaC-Vorlage verweist, auch wenn noch keine Infrastruktur bereitgestellt wurde.

Eine vereinfachte Variante dieses konzeptionellen, allgemeinen Entwicklerplattformdiagramms ist heute in einigen Toolkits und Produkten zu finden, obwohl der Begriff variiert. Beispielsweise bezeichnet das Open-Source-Portal-Toolkit Backstage.io dies als Softwarekatalog, während andere Produkte andere Begriffe verwenden. Die meisten dieser Produkte und Toolkits gehen jedoch davon aus, dass Sie ihren umfassenderen Featuresatz verwenden und dass die Inhalte Ihrer Inventare darin dupliziert werden müssen. Diese Duplizierung bedeutet, dass der Inhalt der Katalogdatenbank nicht benutzerspezifisch ist, veraltet werden kann und nicht durch die Benutzerautorisierungsmechanismen des tatsächlichen Quellsystems gesteuert wird. Dies kann jedoch für Ihre organization gut funktionieren, wenn Sie einen offenen Küchenansatz verfolgen.

Erfahren Sie mehr über Konzepte, die Ihnen helfen können.

Beginnen Sie Ihre Plattformentwicklungsreise