Close

Software-Sprawl eindämmen

Drei Anzeichen für Software-Sprawl und was du dagegen tun kannst

Portrait von Andrew Boyagi
Andrew Boyagi

Senior Evangelist


Monolithische Strukturen verschwinden zusehends. Unzählige Unternehmen auf der ganzen Welt nutzen inzwischen eine lose gekoppelte Architektur für die Softwareentwicklung. Verteilte, autonome Teams zerlegen monolithische Anwendungen in Komponentensammlungen wie Microservices.

Warum? Eine lose gekoppelte Architektur erleichtert die Skalierung der Softwareleistung und -ausfallsicherheit und reduziert gleichzeitig das Risiko und die Vorlaufzeit für die Bereitstellung neuer Anwendungsfunktionen. Die Vorteile sind auch nicht nur auf Software beschränkt. Eine lose gekoppelte Architektur ermöglicht es Teams, unabhängig voneinander zu handeln und häufig Änderungen zu veröffentlichen, von denen die Benutzer profitieren. Autonome Teams, die Software in einer lose gekoppelten Architektur entwickeln, sind zufriedener, engagierter und produktiver.

Neue Arbeitsweisen bringen jedoch auch neue Herausforderungen mit sich. Dynamische und skalierbare Umgebungen, in der einzelne Komponenten unabhängig voneinander erstellt werden, sind komplexer, was eine neue Art von Herausforderung mit sich bringt: Software-Sprawl.

Abbildung: Block

Was ist Software-Sprawl?


Software-Sprawl liegt vor, wenn die Anzahl der Anwendungen oder Softwarekomponenten in einer Umgebung schnell wächst und sich verändert. Dadurch steigt die Komplexität erheblich und herkömmliche Methoden zur Softwareverwaltung scheitern. Dieses Szenario tritt häufig auf, wenn die Geschwindigkeit in einer verteilten Softwarearchitektur steigt.

Selbst die Modernisierung einer einzigen monolithischen Anwendung führt wahrscheinlich zu Hunderten von Microservices, die von mehreren Teams verwaltet werden. Diese Teams veröffentlichen unabhängig voneinander und regelmäßig neue Funktionen für die Produktion. Wenn man dies auf ein Anwendungsportfolio überträgt, kann es möglicherweise die Einführung von Tausenden Microservices in mehreren Entwicklerteams bedeuten. Es ist keine Überraschung, dass herkömmliche Methoden zur Verwaltung selbst eines kleinen Anwendungsportfolios wahrscheinlich nicht zu langfristigem Erfolg führen werden. Während Atlassian die Umstellung auf die Tausenden Microservices vornahm, die unseren Produkten heute zugrunde liegen, haben wir festgestellt, dass in der Eindämmung von Software-Sprawl die Lösung liegt, um das Potenzial einer lose gekoppelten Architektur und autonomer Teams zu nutzen.

Symbol: Codespeicher
Zugehöriges Material

Microservices und monolithische Architektur im Vergleich

Symbol: drei Ringe
Lösung anzeigen

Verwalte deine Komponenten mit Compass

Die Symptome von Software-Wildwuchs sind anfangs oft nur schwer zu erkennen. Anfangs ist es nur ein kleines Ärgernis, das zugunsten wichtigerer Dinge ignoriert wird. Doch wenn nichts dagegen unternommen wird, kann Software-Wildwuchs die Entwicklungsteams mit einer höheren kognitiven Belastung lähmen, die Teammotivation verringern und die Vorteile einer lose gekoppelten Architektur zunichte machen. Wie das Sprichwort: "Der beste Zeitpunkt, einen Baum zu pflanzen, war vor 20 Jahren. Der zweitbeste Zeitpunkt ist jetzt". Wer in Zukunft erfolgreich sein will, muss dem Software-Wildwuchs Einhalt gebieten, bevor er zu einem Problem wird.

Im Folgenden findest du drei Anzeichen für Software-Sprawl und was du tun kannst, um das Chaos zu bewältigen und gleichzeitig eine innovative und dynamische Umgebung zu schaffen, die das Potenzial aller Teams ausschöpft.

Identifizierung von Upstream-Änderungen als Hauptursache in Überprüfungen nach Vorfällen


Ein frühes Anzeichen von Software-Sprawl ist es, wenn mehrere Überprüfungen nach Vorfällen (Post-Incident-Reviews, PIRs) Upstream-Änderungen als Hauptursache für einen Vorfall angeben. Eine wachsende Anzahl von Microservices und ein erhöhtes Änderungsvolumen innerhalb einer Umgebung können die bestehenden Normen in Bezug auf die Zusammenarbeit von Entwicklern und die Koordination von Änderungen auf die Probe stellen. Selbst eine kleine Erhöhung der Änderungshäufigkeit von monatlich auf wöchentlich für eine modernisierte Anwendung kann zu einer 100-fachen Erhöhung der Releases pro Monat führen. Es ist keine Überraschung, dass Entwickler ihre Art der Zusammenarbeit anpassen müssen. Vorfälle treten in der Produktion eher auf, wenn die Normen für die Zusammenarbeit von Entwicklern in einer schnelllebigen Umgebung nicht skalierbar sind.

Die Schaffung einer unauffälligen Methode für Entwickler, Upstream- und Downstream-Änderungen zu berücksichtigen, ist eine großartige Möglichkeit, die Auswirkungen von Software-Sprawl einzudämmen. Wir bei Atlassian verwenden Compass – ein Entwicklerportal, das Teams dabei hilft, sich in verteilten Architekturen zurechtzufinden –, um Entwicklerteams In-App-Benachrichtigungen über aktuelle Änderungen an Upstream- und Downstream-Services zu senden. Das Bestätigen dieser Benachrichtigung signalisiert dem Initiator der Änderung, dass die Teams, die für abhängige Services verantwortlich sind, die Änderung zur Kenntnis genommen haben. Dies bietet die Möglichkeit, gemeinsam an der Änderung zu arbeiten, falls es zu Problemen kommt. So kann die Wahrscheinlichkeit unbeabsichtigter Auswirkungen auf die Produktion verringert werden. Da Vorfälle in einer dynamischen Umgebung unvermeidlich sind, ist die Zusammenarbeit der Entwickler während eines Vorfalls von entscheidender Bedeutung, um Services schnell wiederherzustellen.

Bei Überprüfungen nach Vorfällen, in denen Upstream-Änderungen die Hauptursache sind, ist es üblich, dass die Zeit für die Wiederherstellung von Services von der Zeit beeinflusst wird, die benötigt wird, um die problematische Upstream-Änderung zusammen mit dem Team oder der Person zu identifizieren, das oder die für den Service zuständig ist. Logischerweise reduziert die Verringerung der Zeit, die benötigt wird, um die fehlerhafte Upstream-Änderung zu identifizieren, langfristig die mittlere Wiederherstellungszeit (Mean Time to Restore, MTTR). Dies gestaltet sich in einer lose gekoppelten Architektur, in der Services in einer umfangreichen Abhängigkeitshierarchie gegliedert sind und die Hauptursache eines Vorfalls an einer beliebigen Stelle des Stacks liegen kann, schwieriger. Traditionell durchsuchen Vorfallsverantwortliche Protokolle oder Änderungsdatensätze, um eine Änderung zu identifizieren, die zu einem Vorfall geführt haben könnte. In einer dynamischen Umgebung gleicht dies der sprichwörtlichen Suche nach der Nadel im Heuhaufen.

Wir bei Atlassian verwenden den Aktivitäten-Feed in Compass, um die MTTR zu verkürzen. Der Aktivitäten-Feed zeigt alle Ereignisse für Upstream-Systeme zusammen mit den Details des Teams, das dafür zuständig ist. Das reduziert die Selektierungszeit erheblich, indem die Zusammenarbeit der Entwickler während eines Vorfalls unterstützt wird. Vorfälle passieren, aber die rechtzeitige Identifizierung einer Upstream-Änderung als Hauptursache eines Vorfalls ist entscheidend, um sicherzustellen, dass die Auswirkungen minimiert werden und die Services schnell wiederhergestellt werden.

Software-Sprawl

Der Aktivitäten-Feed in Compass zeigt alle Ereignisse für Upstream-Systeme, wodurch die Selektierungszeit während eines Vorfalls reduziert wird.

Die Teamleistung ist hoch, aber nichts wird erledigt


Die Umstellung auf eine lose gekoppelte Architektur ist einer der wichtigsten Bestandteile für Teamproduktivität und Zufriedenheit – die Möglichkeit, unabhängig und mit einem hohen Maß an Autonomie zu handeln. Wenn nichts dagegen unternommen wird, kann Software-Sprawl einige dieser Vorteile ins Gegenteil umkehren, was zwar zu einem beschäftigten, aber unproduktiven und unglücklichen Team führt. Eine häufige Beschwerde der Entwicklerteams lautet: "Alles funktioniert gut, bis wir mit einem anderen Team zusammenarbeiten müssen." Dies gilt umso mehr, wenn Software-Sprawl zu einem Problem wird. Eine schnell wachsende und sich verändernde Umgebung verringert die Fähigkeit der Entwickler, den Überblick darüber zu behalten, wen sie für Upstream- oder Downstream-Abhängigkeiten beauftragen müssen. Dies führt letztendlich zu einer Verlangsamung und zu Frustration in Teams, die versuchen, schnell zu liefern.

Hypothetisches Szenario: Alpha-Squad und Beta-Squad haben dieselbe Anzahl von Vorgängen und Story Points, die in Jira jede Woche nach "Erledigt" verschoben werden. Der Alpha-Squad investiert 90 Prozent seiner Zeit darauf, neue Funktionen in die Produktion einzubringen, während der Beta-Squad 30 Prozent für neue Funktionen und 70 Prozent für die Interaktion mit den vielen Upstream-Services aufwendet, von denen sie abhängig sind. Beide Squads haben das gleiche Leistungsniveau, aber nur Alpha wird wahrscheinlich als produktiv angesehen. Software-Sprawl erhöht die Notwendigkeit der Zusammenarbeit zwischen Teams. Die Identifizierung intelligenter Methoden für autonome Teams zum Reagieren auf Abruf ist der Schlüssel, um das Potenzial einer lose gekoppelten Umgebung auszuschöpfen.

In einer schnell wachsenden und dynamischen Umgebung ist die Fähigkeit, Informationen selbst zu nutzen, wichtig für die Produktivität und Zufriedenheit des Teams. Eine Möglichkeit, dies zu erreichen, ist die Implementierung eines zentralen Softwarekomponentenkatalogs mit dezentraler Verwaltung. Hierbei handelt es sich um einen zentralen Katalog, bei dem jedes Team für die Erstellung und Aktualisierung der Services, für die es zuständig ist, verantwortlich ist. Herkömmliche Umgebungen haben in der Regel einen zentralen Katalog, der von einem bestimmten Team oder einer bestimmten Funktion verwaltet wird. Dies kann jedoch nicht mit der Geschwindigkeit des Wandels in einer verteilten Umgebung Schritt halten, was dazu führt, dass Teams Schatten-Wikis darüber erstellen, wer und wie eingebunden werden soll. Wir bei Atlassian haben festgestellt, dass ein dezentraler Ansatz den nicht sichtbaren und vergeudeten Aufwand teamübergreifend reduziert, die Self-Service-Funktionen verbessert und eine Umgebung für Einbindung auf Abruf schafft. Die Eindämmung von Software-Sprawl durch selbst genutzte Informationen zu Upstream- und Downstream-Abhängigkeiten ist eine großartige Möglichkeit, die Teamproduktivität mit zusätzlichen Auswirkungen auf die Zufriedenheit und die Einbindung des Teams zu verbessern.

Screenshot: Compass-Benutzerservice

Compass bietet einen zentralen Ort für entwicklerspezifische Informationen zu den Softwarekomponenten, für die sie zuständig und von denen sie abhängig sind.

Änderungsmanagement wird zum Engpass


Ein weiteres wichtiges Anzeichen für Software-Sprawl ist es, wenn Governance-Funktionen wie Änderungsmanagement und Cybersicherheit zunehmend zu einem Engpass werden, sobald Änderungen an den Produktionssystemen vorgenommen werden sollen. Diese Funktionen spielen eine zentrale Rolle bei der Sicherstellung, dass die unternehmerischen Standards und Erwartungen erfüllt werden, bevor Änderungen in der Produktion umgesetzt werden. Sie verlieren jedoch an Effizienz, wenn Software-Sprawl ins Spiel kommt. In einer Umgebung mit Software-Sprawl werden Governance-Funktionen mit zunehmenden Änderungen allmählich überlastet, wodurch ein Backlog an Änderungen und Anfragen entsteht, die überprüft werden müssen. Dies verzögert Deployments in der Produktion. Der State of DevOps-Bericht 2022 (Bericht zur Verbreitung von DevOps) ergab, dass 56 Prozent der Umfrageteilnehmer der Meinung waren, dass die Softwaresicherheitsprozesse ihres Unternehmens den Entwicklungsprozess verlangsamen.

Idealerweise sind Sicherheitsverfahren in die Entwicklungsprozesse integriert, aber in der Realität lassen viele Unternehmen die Änderungen vor dem Deployment in der Produktion von Mitarbeitern überprüfen. Das ist in dem Umfang, der in einer verteilten Umgebung erforderlich ist, nicht effektiv. Es verlangsamt nicht nur die Fähigkeit des Unternehmens, Änderungen herbeizuführen, sondern kann auch zu Spannungen zwischen den Entwicklerteams und denjenigen führen, die dafür verantwortlich sind, dass die Unternehmensstandards eingehalten werden.

In einer Umgebung mit Software-Sprawl ist es wichtig, hohe Geschwindigkeiten zu ermöglichen und gleichzeitig die gewünschten Unternehmensstandards in großem Maßstab zu erreichen. Automatisierte – oder halbautomatisierte Scorecards – eignen sich hervorragend, um Unternehmensstandards zu kommunizieren und bieten eine unauffällige Möglichkeit, die Compliance in der gesamten Umgebung zu überprüfen. Wir bei Atlassian verwenden Compass, um Qualitätsstandards und Erwartungen in Unternehmen festzulegen. Eine Scorecard für jede Softwarekomponente bietet dem Unternehmen Transparenz in Bezug auf die Compliance. Teams und Engineering-Führungskräfte können produktspezifische Standards zu den Scorecards hinzufügen, wodurch alle im Unternehmen einen vollständigen Überblick über die unternehmerischen Qualitätserwartungen und Status erhalten. Dies ist ein bedeutender Wandel von Governance- und Compliance-Checks am Ende eines Lieferzyklus hin zur frühzeitigen Festlegung von Erwartungen und der Möglichkeit, dass diese von den Teams während des gesamten Entwicklungsprozesses erfüllt werden. Governance-Teams können in einer dynamischen Umgebung Erwartungen festlegen, während die Delivery-Teams die Möglichkeit haben, die Anforderungen während des Lieferzyklus zu verstehen und zu erfüllen. Da die Auswirkungen von Software-Sprawl sowohl für die Softwareauslieferungs- als auch für die Governance-Teams nachteilig sein können, bieten Scorecards eine Möglichkeit, Software kontrolliert einzusetzen.

Bild zur Datensicherheit

Die Compass-Scorecard wird verwendet, um den Zustand von Softwarekomponenten anhand einer Reihe definierter Erwartungen zu verstehen.

Fazit


Es gibt kein Patentrezept, um Software-Sprawl einzudämmen. Langfristiger Erfolg setzt jedoch voraus, dass die Auswirkungen von Software-Sprawl frühzeitig erkannt und angegangen werden. Zu den Frühindikatoren von Software-Sprawl gehören mehrere Vorfälle, die durch Upstream- oder Downstream-Änderungen verursacht wurden, vielbeschäftigte Teams, die ihre Ziele nicht erreichen, sowie Governance-Engpässe. Der beste Weg, um Software-Sprawl zu erkennen, besteht darin, mit deinen Entwicklern zu sprechen und die Herausforderungen zu verstehen, mit denen sie konfrontiert sind.

Atlassian hat Compass entwickelt, um Unternehmen bei der Eindämmung von Software-Sprawl zu unterstützen, indem sie die Komplexität verteilter Architekturen während der Skalierung verwalten können. Die Lösung ist eine erweiterbare Developer-Experience-Plattform, die unzusammenhängende Informationen über die gesamten Entwicklungsergebnisse und die Teamzusammenarbeit an einem zentralen, durchsuchbaren Ort zusammenführt.

Weitere Informationen zu Compass

Andrew Boyagi
Andrew Boyagi

Andrew ist Senior Evangelist im Agile- und DevOps-Team von Atlassian. Mit seiner langjährigen Erfahrung in der Softwareentwicklung und im Operations-Bereich von Unternehmen weiß Andrew aus praktischer Sicht, wie Teams und Organisationen die Vorteile von Agile und DevOps maximal für sich nutzen können. Andrew hat bei der Commonwealth Bank of Australia, einem der größten australischen Finanzinstitute, eine Platform-Engineering-Funktion aufgebaut und weiterentwickelt, die 7.000 Ingenieure unterstützt. Andrew ist viel daran gelegen, dass Softwareentwicklungsteams ihre Potenziale voll entfalten können und glaubt, dass Platform Engineering der Schlüssel zum Erfolg in modernen Technologieumgebungen ist.

In seiner Freizeit hat Andrew das Ziel, alle 10 der 10 besten Motorradstrecken der Welt zu fahren. Er lebt mit seiner Frau und zwei Kindern in Sydney, Australien.


Diesen Artikel teilen
Nächstes Thema

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Abbildung: DevOps

Compass-Community

Illustration: Überwindung von Hindernissen

Tutorial: Erstellen einer Komponente

Abbildung: Karte

Erste Schritte mit Compass (kostenlos)

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up