Neustrukturierung für kontinuierliche Innovation

Zahlreiche Unternehmen erstellen ihre eigenen Softwaredienste auf der Grundlage monolithischer Architekturen.

Diese Strategie hat Vorteile: Das Entwerfen und Bereitstellen monolithischer Systeme ist anfangs im Allgemeinen unkompliziert. Wenn Anwendungen jedoch immer komplexer werden, kann es schwierig werden, die Produktivität der Entwickler und die Bereitstellungsgeschwindigkeit aufrechtzuerhalten, was zu Systemen führt, deren Bereitstellung kostspielig, zeitaufwändig und gefährlich ist. In diesem Dokument wird gezeigt, wie Sie Ihre Apps auf ein Cloud-natives Paradigma umstellen, mit dem Sie die Bereitstellung neuer Funktionen beschleunigen können, selbst wenn Ihre Teams wachsen. Gleichzeitig verbessern Sie die Softwarequalität und erreichen ein höheres Maß an Zuverlässigkeit und Verfügbarkeit.

Mit der Erweiterung von Diensten und der dafür verantwortlichen Teams werden sie tendenziell schwieriger anzupassen und zu verwalten und werden komplizierter. Es wird schwieriger, Tests und Bereitstellungen durchzuführen, neue Funktionen hinzuzufügen und Stabilität und Verfügbarkeit aufrechtzuerhalten.

Laut einer Studie des Google DORA-Teams ist es für Unternehmen jeder Größe und in allen Branchen möglich, einen hohen Durchsatz bei der Softwarebereitstellung, Servicestabilität und Serviceverfügbarkeit zu erreichen. Leistungsstarke Teams können mehrere Male am Tag bereitstellen, Änderungen in weniger als einem Tag in die Produktion bringen, den Service in weniger als einer Stunde wiederherstellen und Änderungsfehlerraten zwischen 0 und 15 % erreichen.

Darüber hinaus sind Leistungsträger in der Lage, die Entwicklerproduktivität (gemessen an der Anzahl der Bereitstellungen pro Entwickler und Tag) zu steigern, selbst wenn sie ihre Teams erweitern.

Was ist eine native Cloud-Architektur?

Das Erstellen, Testen und Bereitstellen monolithischer Anwendungen muss als eine Einheit erfolgen. Häufig werden das Betriebssystem, die Middleware und der Sprachstapel für eine Anwendung geändert oder individuell konfiguriert. Skripte und Verfahren für die Anwendungsentwicklung, das Testen und die Bereitstellung sind häufig für jede Anwendung einzigartig. Dies ist bei Greenfield-Anwendungen unkompliziert und effektiv, aber wenn diese Systeme erweitert werden, wird es schwieriger, sie zu ändern, zu testen, bereitzustellen und auszuführen.

Darüber hinaus wächst mit der Systemerweiterung auch die Anzahl und Komplexität der Teams, die für die Entwicklung, das Testen, die Bereitstellung und den Betrieb des Dienstes verantwortlich sind. Es ist zwar beliebt, aber falsch, Teams nach Funktion aufzuteilen, was zu Übergaben zwischen Teams führt, die Vorlaufzeiten und Batchgrößen verlängern und erhebliche Nacharbeit erfordern. Untersuchungen von DORA zeigen, dass leistungsstarke Teams doppelt so häufig Software erstellen und bereitstellen wie ein einzelnes, funktionsübergreifendes Team.

Zu den Symptomen dieser Erkrankung gehören:

• Lange, häufig unterbrochene Build-Prozesse
• Seltene Integrations- und Testzyklen
• Erhöhter Aufwand zur Unterstützung der Build- und Testprozesse
• Verringerte Entwicklerproduktivität
• Aufwändige Bereitstellungsprozesse, die außerhalb der Geschäftszeiten durchgeführt werden müssen und geplante Ausfallzeiten erforderlich machen
• Erheblicher Aufwand bei der Verwaltung der Konfiguration von Test- und Produktionsumgebungen

Übergang zum Cloud-Native

Zahlreiche Unternehmen haben für die Migration ihrer Dienste in die Cloud eine „Lift-and-Shift“-Methode implementiert.

Bei dieser Methode sind keine kleinen Systemänderungen erforderlich und die Cloud wird im Wesentlichen wie ein herkömmliches Rechenzentrum behandelt, bietet jedoch weitaus bessere APIs, Dienste und Verwaltungstools als herkömmliche Rechenzentren.

Allerdings bietet Lift-and-Shift allein keinen der Vorteile des oben diskutierten Cloud-native-Modells.

Aufgrund der Kosten und Schwierigkeiten bei der Umstellung ihrer Anwendungen auf eine Cloud-native Architektur, die eine Neugestaltung von allem vom Anwendungsdesign über die Produktionsabläufe bis hin zum gesamten Softwarebereitstellungszyklus erfordert, bleiben viele Unternehmen in der Lift-and-Shift-Phase stehen. Diese Befürchtung ist berechtigt: Mehrere große Unternehmen haben mehrjährige „Big Bang“-Re-Platforming-Initiativen erfolglos durchgeführt.

Die Antwort besteht darin, einen progressiven, iterativen und evolutionären Ansatz zur Umstrukturierung Ihrer Systeme in die Cloud zu verfolgen, bei dem die Teams lernen, wie sie in diesem neuen Paradigma erfolgreich arbeiten können, während sie gleichzeitig weiterhin neue Funktionen entwickeln: Dies ist eine „Move-and-Improve“-Strategie.

Die Anwendung der Würgefeige ist ein wichtiges Motiv in der evolutionären Architektur. Anstatt Systeme von Grund auf neu zu erstellen, entwickeln Sie neue Funktionen auf zeitgemäße, Cloud-native Weise, lassen Sie sie jedoch mit dem alten monolithischen Programm für vorhandene Funktionen kommunizieren. Verschieben Sie die aktuelle Funktionalität im Laufe der Zeit schrittweise, wie es für die konzeptionelle Integrität der neuen Dienste erforderlich ist.

Laden Sie das Whitepaper von Google Cloud herunter, um mehr über die Neustrukturierung für kontinuierliche Innovation nur bei Whitepapers Online zu erfahren.