Der Prozess der Software beginnt normalerweise mit einer Reihe von Anforderungen; Als Ingenieure sind wir darin geschult, den effizientesten Weg zur Lösung dieser Anforderungen zu finden. Anschließend überlegen wir, wie wir die Software entsprechend den Nutzungs- und Zuverlässigkeitsanforderungen der Benutzer anpassen und skalieren können.

Dieser Prozess ist zyklisch, ja sogar sisyphusartig. Wenn die Software verwendet wird und das Unternehmen wächst, muss das Produkt verbessert werden, um neuen Bedürfnissen oder Anforderungen gerecht zu werden. Daher müssen Ingenieure den Code „umgestalten“, ihn dann testen und erneut bereitstellen.

Unter Refactoring versteht man im Zusammenhang mit der Erstellung von Software den Prozess, bei dem kleine und sichere Änderungen am Code vorgenommen werden, um dessen Leistung, Wartbarkeit oder andere Aspekte zu verbessern, ohne sein Gesamtverhalten zu ändern. Es ist wie das Polieren und Optimieren der vorhandenen Codebasis. Das Prime Video-Engineering-Teamstand beispielsweise vor der herausfordernden Aufgabe, seine serverlose Architektur umzugestalten, um lang laufende, containerisierte Dienste zu verwenden, was eine Änderung der Art und Weise erforderte, wie die Software strukturiert und verwaltet wurde.

Martin Fowler, der berühmte Software , brachte es auf den Punkt: „Das Wesentliche von [Refactoring] ist die Anwendung einer Reihe kleiner verhaltenserhaltender Transformationen, von denen jede „zu klein ist, als dass sie sich lohnen würde.“ Der kumulative Effekt all dieser Transformationen ist jedoch recht erheblich. Indem Sie sie in kleinen Schritten durchführen, verringern Sie das Risiko von Fehlern. Sie vermeiden außerdem, dass das System während der Umstrukturierung kaputt geht – was Ihnen ermöglicht, ein System über einen längeren Zeitraum schrittweise umzugestalten.“

Ich habe kürzlich einige spannende Geschichten über Veränderungen in der Art und Weise gehört, wie Software erstellt und verwaltet wird, die das Potenzial haben, diesen Kreislauf zu durchbrechen. Einige Unternehmen wandeln verteilte Cloud-Dienste in monolithische Anwendungen um oder wechseln sogar von der Cloud zu einer Rechenzentrumsumgebung. Viele Organisationen, die sich im Prozess der digitalen Transformation befinden, sind am zyklischen Übergang nach dem Ausstieg aus der monolithischen Architektur interessiert, auch wenn einige Hindernisse bestehen bleiben.

Dank einer Technik namens „Infrastruktur als Code“, bei der Ingenieure die Computerinfrastruktur durch Code und Automatisierung statt durch manuelle Prozesse verwalten und bereitstellen, ist dieser Weg der Umgestaltung der Infrastrukturebene eine mögliche beschreibende Aufgabe. Es ist jedoch wichtig zu beachten, dass dieser Refactoring-Prozess immer noch viel Zeit und Mühe erfordert, um die Änderungen sicher zu entwerfen, zu implementieren, zu testen und bereitzustellen, sodass sie keine Probleme mit dem System verursachen.

Im Fall des Prime Video-Engineering-Teams bestand das Ziel darin, den Benutzern weiterhin hervorragende Videoinhalte und Anwendungsverhalten bereitzustellen und gleichzeitig erhebliche Änderungen an der Einrichtung der Infrastruktur vorzunehmen. Sie haben die Infrastruktur manuell portiert oder „neu kompiliert“, indem sie die Art und Weise geändert haben, wie sie im Code definiert wurde, und von der Verwendung kurzlebiger Lambda-Funktionen zur Verwendung langlebigerer ECS-Dienste (Elastic Container Service) übergegangen sind.

Überlegungen zu Architekturänderungen

Der Wechsel zu einer anderen Architektur, wie es das Prime Video-Team getan hat, bringt eine Reihe von Dingen mit sich, die es zu beachten gilt:

• Produktivität
  • Unterschiedliche Rechenschnittstellen erfordern unterschiedliche Maß an Aufwand und Wartung. Serverlose Setups erfordern beispielsweise weniger Wartung, während Server mit langer Laufzeit mehr Aufmerksamkeit erfordern.
  • Bei einigen Architekturen ist für den Start mehr Code erforderlich, was sich darauf auswirken kann, wie schnell die Entwicklungsteams die Software zum Laufen bringen können.
  • Die Vereinfachung eines komplexen Systems kleiner Dienste (ein Microservice-Spaghetti) kann die Arbeit erleichtern, ohne sich zu sehr auf die Cloud verlassen zu müssen. 
• Zuverlässigkeit
  • Die Vereinfachung eines Microservice-Spaghetti kann das Testen und Beobachten erleichtern, was die Zuverlässigkeit der Software verbessert.
• Cloud-Sicherheit
  • Wenn Sie die Architektur ändern, müssen Sie möglicherweise die Art und Weise anpassen, wie das System sich gegen Angriffe verteidigt, da sich die Angriffsfläche ändert.
  • Rollen und Berechtigungen (IAM-Rollen) sowie Netzwerkeinstellungen müssen möglicherweise ebenfalls aktualisiert werden, und manchmal kann sogar Code auf Anwendungsebene betroffen sein.
• Kosten
  • Jeder Cloud-Dienst hat seine eigene Preisstruktur, die bei Architekturänderungen berücksichtigt werden muss.

Da ich selbst Software Entwickler bin, bin ich im Laufe der Jahre auf verschiedene Best Practices für die Neuarchitektur von Systemen gestoßen – und ich habe einige dieser Bemühungen sogar selbst geleitet. Allerdings empfand ich die Aufgabe oft als repetitiv, erforderte umfangreiche Dokumentation und war auf zu viele Programmier-Frameworks und Paradigmen verteilt. Meine größte Sorge war, dass solche Veränderungen Zeit brauchen und immer mit der Gefahr verbunden sind, dass etwas kaputt geht. Deshalb habe ich mich oft gefragt, ob es der richtige Weg ist, technische Ressourcen zuzuweisen.

Die Änderung von Architekturen ist ein komplexer Prozess, der selbst bei einfachen Änderungen eine teamübergreifende Zusammenarbeit und Kommunikation zwischen Anwendungs- und Infrastrukturteams erfordert. Eine Lösung, die diese Anwendungs- und Infrastrukturanforderungen konsolidieren würde, gab es bis heute nicht.

Betreten Sie Wing Cloud*

Wing * wurde im April 2022 von Elad Ben Israel, dem Schöpfer von AWS CDK, und Shai Ber, ehemaliger VP R&D beiEquityBee* mit tiefen Wurzeln in der Skalierung von Cloud-Infrastrukturen und der Entwicklung weit verbreiteter Entwicklertools, gegründet und ist ein neues Programmier-Framework für die Cloud.

Zu den Vorteilen von Wing gehören meiner Meinung nach:

• Erhöhte Produktivität: Vereinheitlicht Anwendungs- und Infrastrukturcode, Infrastruktur wird von einem Compiler generiert und Entwickler müssen weniger Code pflegen.
• Cloud-Sicherheit: Der Compiler kann die Angriffsfläche reduzieren und die am wenigsten privilegierten IAM-Berechtigungen und Netzwerktopologien durch Anwendungscode generieren.
• Kostenreduzierung: Ein Ingenieur kann die Cloud-Workloads beobachten und die Architektur anhand der Metriken der beobachteten Workload von einer Rechenressource zur anderen neu kompilieren.
• Schnellere Entwicklungsiteration: Wing kann eine Cloud-Umgebung lokal simulieren und eine schnellere Feedbackschleife ermöglichen.
• Cloud-Portabilität: Behält App-Code bei und die Infrastruktur kann auf ein neues Cloud-Ziel neu kompiliert werden.
• Service-Portabilität: Der App-Code bleibt erhalten und die Infrastruktur kann für ein neues Service-Ziel neu kompiliert werden (Beispiel: In-Memory-Warteschlange, Kafka-Warteschlange, AWS SQS).
• Verteilte Programme: Senkt die Hürde bei der Nutzung einer Cloud-verteilten Infrastruktur, indem Anforderungen aus der Anwendungslogik abgeleitet werden.

Seit seiner Gründung hat Wing ein Team von über 10 Ingenieuren in den USA, Israel und Europa zusammengestellt und meiner Meinung nach den Grundstein gelegt, um eine sinnvolle Open Source im Bereich der Cloud-Infrastruktur zu schaffen.

Bei Battery freue ich mich, wenn Gründer und Unternehmer komplexe Probleme mit prinzipiellem Denken, Einfachheit und Klarheit angehen. Elad, Shai und der Rest des Wing-Teams bringen eine Fülle von Kenntnissen aus ihrer Zeit bei Amazon, Microsoft und Equitybee* mit und verstehen es meiner Meinung nach, wie man Klarheit in die komplexesten Probleme des Cloud Engineering bringt. Ich freue mich darauf zu sehen, wie sie weiterhin Innovationen hervorbringen.