Softwareentwicklung im Zeitalter der unbegrenzten Rechenkapazität

„The Sky is the limit!“ Dieses geflügelte Zitat trifft für moderne Applikationen fast im wörtlichen Sinne zu. Dank der Cloud sind Rechenleistungen heute per Knopfdruck bereitgestellt. Den Überblick über das Wolkenmeer zu behalten, ist die Herausforderungen einer modernen Architektur. Müssen wir die Bestellung von Kapazitäten regeln?

Ausprobieren und lernen

Am Anfang eines Projektes stand für on-premise Server oftmals die Analyse der benötigten Ressourcen. Danach folgten Bestellungen mit komplexen Freigaberegelungen. Heute wurde dieser Schritt durch agile Projektabläufe und Continous-Deployment fast vollständig verdrängt. Cloudanbieter reagieren innerhalb von Sekunden auf gestiegene Anforderungen und ermöglichen sofortige „Proof of Concept“-Versuche mit dedizierten Instanzen, die schnell bereitstehen.

Dies ist eines der Argumente auf der positiven Seite für die Hyperscaler und wurde sogar innerhalb des NIST definiert. Ausprobieren ist ausdrücklich erwünscht und stösst damit ins gleiche Horn wie agile Ansätze der Produktentwicklung. Schnellere Produktentwicklungen und kleinere Lieferobjekte sind dabei das Ziel.

Ressourcen, für die sich niemand mehr verantwortlich fühlt und die ausser Kosten nichts erzeugen, können ein negativer Effekt dieser Beschleunigung sein. Mit einer cleveren Architektur und mit der Vermeidung von sogenannten „Zombies“[1] können Kostenüberraschungen vermieden werden.

Dediziert liegt nahe – besonders in der Cloud

Jeder Entwickler, der eine neue Technologie einsetzten möchte, macht sich als erstes Gedanken über eine Instanziierung auf der berühmten „grünen Wiese“. Hier werden die zu erwartenden Schwierigkeiten bei einer Entwicklung und bei einem Einsatz in der Breite angeschaut und allenfalls adressiert. Für bestehende Systeme steht dabei zumeist eine Working-Directory, ein Testserver oder ein Developmentserver zur Verfügung. Der Inhalt dieser Umgebungen wird über eine Kopie oder über Branching erzeugt und stellt damit ein Abbild der produktiven Umgebung dar.

Für eine neu entwickelte Applikation wurde in alten on-premise Lösungen zuerst eine neue Partition geschaffen, die auf den Stand des zukünftigen Ökosystems gebracht wurde. Entwickler konnten dann innerhalb ihrer eigenen „Sandbox“ erste Entwicklungen verwirklichen.

Der Unterschied zu heute war einerseits die Geschwindigkeit, in der diese Sandboxen zur Verfügung standen und die Governance, die bei der Beschaffung neuer Server berücksichtigt wurde. Die Verantwortung über die effektive Nutzung der Instanzen liegt damit heute bei den Entwicklerteams und muss klar kommuniziert werden. Nicht genutzte Instanzen können 20-30%[2] der OPex Kosten für Cloud-infrastruktur ausmachen. Teams zu befähigen, neue Ressourcen zu bestellen, heisst auch ihnen beizubringen, wie nachträglich aufgeräumt werden sollte.

Verantwortung verteilen

Moderne Dev-Ops Teams haben eine grosse Verantwortung. Sie produzieren nicht nur Entwicklungen, sondern betreuen sie auch. Ihnen dabei die Verantwortung über die Infrastruktur zu entziehen, ist eine Massnahme, die dem Ansatz von Dev-Ops[3] widerspricht. Die Verantwortung deutlich zu machen und Transparenz zu schaffen, kann hingegen helfen, die Kosten für Cloud-Services zu senken.

Eine Architektur übernimmt in Unternehmen die Aufgabe des Zeichners vom „Big Picture“ und sollte eine klare Strategie haben, wie neue Technologien einzusetzen sind und wie Services gestaltet werden sollten, um Redundanzen zu vermeiden. Die Verteilung von Workload auf freie Kapazitäten ist eine Disziplin, die in den vergangenen Jahren mit der Cloud eine neue Dimension erreicht hat.

Architekturvisionen, die Technologien wie Docker vorgeben und dabei den Fokus auf Wiederverwendbarkeit und Verteilbarkeit legen, machen dedizierte Instanzen überflüssig. Wirklich elastische Unternehmen können VMs nach Bedarf zuschalten oder abschalten und müssen dabei keine dedizierten Entwicklungen beachten, die auf den Instanzen laufen. Die Verteilung kann automatisch geschehen.

Für eine echte Cloud Strategie braucht es einen Wechsel in der Herangehensweise an Projekte. Projektverantwortlich sollten die Verantwortung über die benötigten technischen Ressourcen den Teams übergeben und Architekten sollten verteilte Technologien zum goldenen Standard neuer Applikationen machen. Damit gelingen Systemen, die wirklich von unbegrenzten Ressourcen profitieren, ohne dabei unbegrenzte Budgets vorauszusetzen. Eine Vision über die gewünschte Nutzung von Ressourcen hilft mehr als eine Beschränkung der Befugnisse oder der Budgets innerhalb der Teams. Die Flexibilität von Hyperscalern kann wie eingangs beschrieben durchaus ein Katalysator für den laufenden Wandel zur schnelleren Produktentwicklung sein. Mit zu viel Governance für die Bestellung dieser Ressourcen entsteht wiederum ein Effekt, der diese Entwicklung bremst.

Quellen

[1] Michael Liebow , Oct 4, 2016,linkedin.com, Zugriff 09.11.19

[2] Martin Heller, CIO Magazin, SEP 26, 2017, 6 cloud cost management tips, Zugriff 08.11.19

[3] The 5 Foundational DevOps Practices, Splunk, 2019, eBook

Weiterführende Links