Geschichte der Software-Entwicklung: Wie ist Cloud Native entstanden?
6 schnelle Fragen an unseren Cloud-Experten zur Geschichte der Software-Entwicklung
Simon: „Hey Patrick, was ist eigentlich Cloud Native?“
Patrick: „Es gibt keine absolute Definition, aber es gibt ein paar Building-Blocks, die insgesamt betrachtet dann das Konzept Cloud Native ergeben. Es handelt sich weder um ein rein technisches noch ein rein organisatorisches Konstrukt. Vielmehr erstreckt es sich in alle Bereiche des Software-Lifecycles: von der Entwicklung (Coding und Management) bis in den Betrieb der Plattform. Der Begriff an sich kommt aus der Software-Entwicklung."
Simon: „Und wie ist Cloud Native entstanden?“
Patrick: „Anfang der 2000er Jahre kam in der Software-Entwicklung das Agile Manifest auf, das wiederum Parallelen zu den Ideen des Lean Manufacturing aufweist, ohne diese jedoch explizit aufzuführen.
Beiden Ideen ist gemein, dass es darum geht, mehr Traktion mit weniger Verschwendung zu erzeugen. Weniger Gerede über Nebensächlichkeiten, mehr Produktivität und vor allem: kürzere Produktionszyklen und Vorlaufzeiten.
Auch finden sich hier Konzepte und Erkenntnisse wieder, die von Fred Brooks bereits 1975 in seinem Buch The Mythical Man-Month festgehalten wurden. Die stark verkürzte Erkenntnis hieraus ist bekannt als Brooks’s Law:
‚Adding more manpower to an already late software project will delay it even more.‘
Simon: „Wie gings dann weiter?“
Patrick: „Mitte/Ende des Jahrzehnts kamen dann die Hyperscaler (AWS 2006, Google Cloud 2008, Azure 2010) auf, die plötzlich einen gänzlich neuen Umgang mit den klassischen Infrastruktur-Ressourcen (Compute, Storage, Network) ermöglichten. Statt Rechenleistung per Investition in Hardware zu beschaffen, konnte diese bei Bedarf und auf die Schnelle für kurze Zeiträume abgerufen werden.
Das und andere Faktoren (z.B.: Apple iPhone 2007) gingen Hand in Hand: Diese Entwicklungen machten es nötig, Software neu zu denken. Start-ups, die mit einer Time-to-Market von wenigen Wochen den großen Playern am Markt das Leben schwer machten, gaben hier die Richtung vor."
Simon: „Was bedeutete das für die Anwendungen?“
Patrick: „In einer klassischen Welt des Anwendungsbetriebs ist eine Anwendung etwas, dass dem Endbenutzer bereitgestellt wird, indem im Hintergrund Server, Speichersysteme und ein Netzwerk arbeiten. Früher war hier oft eine 1:1-Korrelation gegeben: Man hatte dedizierte Server, die nichts anderes gemacht haben, als diese Anwendung bereitzustellen. Der IT-Betrieb hat sich darum gekümmert, dass diese Server laufen, so dass es keine Ausfälle gibt und die notwendigen Wartungsarbeiten im Hintergrund geschehen. Darauf läuft dann eine Anwendung, die entweder durch die entsprechenden Spezialisten in der IT bereitgestellt wird oder durch eine Fachabteilung selbst, die über das notwendige Wissen verfügt.
Das Problem: Zwischen Entwicklung und Betrieb kann es zu gegenläufigen Zielsetzungen kommen: Die Aufgabe der Entwicklung ist es, neue Features zu erstellen. Neu heißt aber auch, dass die bestehende Belastbarkeit herausgefordert wird. Die Aufgabe des IT-Betriebs ist es, für maximale Stabilität zu sorgen. Grundsätzlich besteht also kein Interesse daran, neue Features zu implementieren. Schließlich gefährdet jede Anpassung den Status quo.
Durch die vereinfachte Bereitstellung von Ressourcen auf der Basis von “Cloud” verschiebt sich das Gefüge an dieser Stelle deutlich. Es muss auch nicht zwingend nur AWS, Azure, Google und vergleichbare Anbieter umfassen, sondern kann auch sehr allgemein gesehen werden: als eine flexible und schnelle Bereitstellung von standardisierten Infrastrukturresourcen on Demand. Somit kann auch eine intern betriebene Virtualisierungsplattform als eine “Cloud” betrachtet werden.
Die Verschiebung, die sich daraus ergibt, ist, dass die Plattform von einer Manufaktur-Leistung zu einem Massenprodukt wird. Standardisierung ersetzt die individuelle Bereitstellung und im Gegenzug erfolgt eine weitgehende Entkopplung von Plattform und Applikation."
Simon: „Apropos Plattform: Was ist das eigentlich?“
Patrick: „Der Begriff entstand aus der Notwendigkeit heraus, zwischen der Anwendungsentwicklung und der Infrastruktur eine Art Übergabeebene einzuziehen. In der Entwicklung sind die tatsächlichen, physikalischen Ressourcen eher weit weg. Eine Installation der Anwendung auf einem Server ist ein Thema, das Ressourcen bindet, aber keinen echten Mehrwert bietet. Daher macht es Sinn, diese Ebene so weit wie möglich zu streamlinen und zu standardisieren. Ziel ist es, dass der eigentliche Rollout der Software komplett automatisiert stattfinden kann und keine Interaktion erfordert. Die einzigen erlaubten Interaktionen an dieser Stelle sind manuelle Freigaben, die sich aber auf ein Go bzw. No-Go beschränken."
Simon: „Und was passierte dann?“
Patrick: „In diese Entwicklung platzten Docker (2013) und Kubernetes (2015) hinein. Docker stellte hierbei eine universelle Möglichkeit dar, Software zu paketieren und auszurollen. Kubernetes übernahm die komplette Orchestrierung des Rollouts und der Laufzeit.
Die typische Aufteilung, die sich hieraus ergibt, ist, dass sich der Plattformbetrieb auf die Bereitstellung von Kubernetes fokussiert (inkl. Monitoring, Observability, Zertifikatsmanagement, Service Mesh etc.) und die Anwendungsentwicklung ihre Artefakte in Eigenregie auf dieser Plattform betreibt.
Diese Entkopplung zwischen dem Betrieb der Plattform und dem der Anwendung ist in erster Linie als eine Aufteilen auf der technischen Ebene zu sehen. In der Organisation ist die Anwendungsentwicklung natürlich der Endnutzer bzw. Kunde der Plattform und muss als Stakeholder in die Entwicklung einbezogen werden.“
