Der Run wird kommen

Cloud-native begibt sich auf die große Reise

12.12.2019
Von 
Iris Lindner ist freiberufliche Journalistin für Elektronik und Automatisierung.
Mit weniger Aufwand schneller ans Ziel: Das verspricht Cloud-native zumindest für die Softwareentwicklung. Da die eigentliche Arbeit dafür aber im Change-Management steckt, gewinnt die Methodik nur zögerlich an Fahrt.

Wenn von Flexibilität und Effizienz in der Softwareentwicklung die Rede ist, fällt neben Geschwindigkeit, Agilität und Skalierbarkeit immer häufiger der Begriff Cloud-native. Dahinter verbirgt sich eine Projekt- oder Softwarelösung zum Entwickeln und Betreiben von Anwendungen, die nur in der Cloud verfügbar ist. Die vorkonfigurierte Lösung kann sehr einfach und in einem gewissen Rahmen individualisiert genutzt werden. Ein bekanntes Beispiel dafür sind Software-as-a-Service-Modelle. Cloud-native umfasst somit auch den Einsatz von diversen Cloud-Technologien, wie sie die entsprechenden Hyperscaler bereitstellen, sowie Container-Techniken. Weil Cloud-native nicht auf einer monolithischen Architektur basiert, sondern auf lose gekoppelten Microservices, lassen sich kontinuierliche Updates der Anwendung ohne lange Zyklen einspielen. Und das funktioniert sowohl in der Public- als auch in der Private Cloud.

Cloud-native verbindet viele Themen wie DevOps, Agile oder As-a-Service-Modelle aber auch kulturelle Aspekte im Unternehmen miteinander. Wie diese zusammenspielen können und sollten, diskutierten die Experten beim COMPUTERWOCHE-Roundtable.
Cloud-native verbindet viele Themen wie DevOps, Agile oder As-a-Service-Modelle aber auch kulturelle Aspekte im Unternehmen miteinander. Wie diese zusammenspielen können und sollten, diskutierten die Experten beim COMPUTERWOCHE-Roundtable.
Foto: Michaela Handrek-Rehle

Ohne Organisation keine Technik

Was die Cloud-native-Entwicklung zusätzlich auszeichnet, ist die Infrastrukturbeschreibung, welche die Applikation unterstützt und auch braucht. Infrastructure as Code als Teil des Ziel-Artefaktes bringt es mit sich, dass Cloud-native nicht nur technisch, sondern auch organisatorisch betrachtet werden muss - ein Grund, der den vielversprechenden Cloud-native-Ansatz aktuell noch ein wenig ausbremst. Zum einen müssen das Infrastruktur- und das Entwicklungsteam für eine gemeinsame Cloud-native-Denkweise im Unternehmen zusammengebracht werden. Diese organisatorische Umstellung muss vom Management getrieben sein, doch in vielen IT-Management-Segmenten mangelt es derzeit an der erforderlichen Methodenkompetenz.

Informationen zu den Partner-Paketen der Cloud-native Studie

Zum anderen müssen sich die Firmen daran gewöhnen, dass sie viel höherwertiges Personal brauchen, um den Betrieb sicherzustellen. IT-Dienstleistungen wie bisher über einen harten Einkauf zu sourcen führt sicher nicht dazu, qualifizierte Mitarbeiter mit einem breit gestreuten Wissen über alle Bereiche der IT zu akquirieren. Denn diejenigen, die die Technologien bereits beherrschen, arbeiten lieber in einer digitalen Factory als beim Kunden, da sie sich dort wieder in einer organisatorischen Struktur befinden, in der sie vor lauter Barrieren nicht vorwärtskommen.

Und das ist der springende Punkt: Gerade die großen Enterprise-Kunden haben Bestandsapplikationen und eine Bestands-IT. Diese einfach in die Cloud zu heben wäre ein Lift-and-Shift-Projekt ohne Gewinn. Es fehlt der Sinn dahinter, um mit Cloud-native ein Ziel tatsächlich auch erreichen zu können.

Der Zweck heiligt die Methode

Geschwindigkeit und Agilität sind ebenso die Treiber für Cloud-native wie der Druck vom Wettbewerb oder Start-ups. Wer also den Schritt in Richtung Cloud-native gehen möchte, der sollte dies keinesfalls voreilig und unbedacht tun, sondern sich genau überlegen: Ergeben sich dadurch neue Geschäftsmodelle? Was bin ich als Organisation bereit zu ändern oder aufzugeben? Komme ich mit regulären Updates klar? Muss ich dazu Personal schulen? Auch wenn die ersten Gehversuche nur dazu dienen, Erfahrungen zu sammeln, den Zweck muss man in der Belegschaft auf jeden Fall transparent machen. Schließlich können in der Organisation mehr Aufwand und Reibungsverluste entstehen als auf der technischen Seite.

Und nicht zuletzt müssen die Kosten in die Überlegung miteinbezogen werden, denn eines ist klar: Services aus der Cloud bieten nur in einigen Fällen einen Kostenvorteil. Für Digitalausgründungen, die sich aus einer festgefahrenen Konzernstruktur lösen wollen, oder Start-ups sind die Anfangskosten in der Cloud geringer, als wenn sie ihre eigene IT aufbauen würden, zumal dies auch mit immensem Zeitaufwand verbunden wäre.

Für einen Greenfield-Approach sprechen auch die Probleme, die eine Brownfield-Strategie mit sich bringt. Eines davon ist die Anpassung der Software an die Kundenapplikation, für die wiederum mehr in die Inhouse-Softwareentwicklung investiert werden muss. Auch bei der Entscheidung Private- oder Public Cloud müssen die Entwicklungskosten den Cost of Opportunity gegenübergestellt werden. Liegt das Hauptziel darin, mit einem digitalen Produkt so schnell wie möglich vorwärtszukommen, und das mit einem digitalen Ökosystem dahinter, dann kann nur die Public Cloud die Lösung sein. Je größer allerdings die Systeme werden, desto mehr spricht für die Private Cloud. Ab einer bestimmten Serveranzahl können die Kosten für das Inhouse Hosting sogar um bis das Vierfache niedriger sein. Von daher ist es auch eine gute Option, die Kernlast im eigenen Haus zu lassen und nur die Spitzen in die Cloud zu packen.

Unsicherheit und Sorgen, aber keine Security

Cloud-native steht definitiv am Anfang, weshalb man sich bei einer Cloud-native-Adoption zurzeit noch für eine Richtung bezüglich Technologie und Hyperscaler entscheiden muss. Vieles lässt sich in Container packen, aber eben nicht alles. Deshalb ist es wichtig, auch die Storage- und Datenbanktechnologien der jeweiligen Hyperscaler zu betrachten. Selbst wenn sich für den Kunden dadurch eine spezifische Lösung ergibt, von der er sich nicht ohne Weiteres so schnell wieder lösen kann: Die Datenbanksysteme der Hyperscaler, die ohne Zweifel deren großer Benefit sind, nicht zu nutzen wäre ein Fehler. Auch hier gilt es, Nutzen und Kosten durch eine mögliche Preiserhöhung gegeneinander abzuwägen.

Informationen zu den Partner-Paketen der Cloud-native Studie

Derzeit verlassen sich die Entscheider aufgrund mangelnder Erfahrung und Wissen auf ihr Bauchgefühl - auch was die Security angeht, denn die steht noch nicht im Vordergrund, weder beim Kunden noch beim Entwickler. Im Gegensatz zu einer Applikation in der Legacy-Welt - in sich geschlossen mit eigenen Nutzern und Anmeldeoptionen - braucht eine skalierbare Servicearchitektur Security-Services, die ebenfalls skalierbar und verfügbar sein müssen. Dadurch herrscht momentan noch große Unsicherheit, wenn es darum geht, Cloud und On-prem-Systeme zu verbinden. Auf die Angst, weil die On-prem-Systeme noch nicht so weit sind, folgen die Sorgen, die den Datenschutz betreffen. Vernünftig wäre es, hier ein Backoffice zu schaffen aus Unternehmensjuristen, Datenschützern und Security-Experten, die zusammen als eine Art Projektbüro direkt neben dem Entwicklungsteam sitzen. Ansonsten führen fehlende Freigaben und langwierige interne Prozesse schnell wieder zu einem Deadlock.

Gekocht wird in der Cloud, gegessen in der eigenen Hardware

Auch wenn es den monolithischen Kern in Zukunft noch geben wird, so geht der Trend hin zur Public Cloud. Das ist nicht ganz ohne Risiko, denn ein Security Incident in der Cloud wäre ein Reputationsschaden, der die Kunden zum sofortigen Incourcing veranlassen würde. Doch je mehr die Public Cloud nutzen, desto größer wird die Angriffsfläche. Einige Branchen, wie zum Beispiel die Energieversorger, unterliegen hier deshalb strengen Vorgaben: Cloud-Technologien nutzen? Ja, aber nur in der eigenen Hardware. Dennoch zählt die Energiebranche aktuell zu denen, die bisher den größten Schritt in Richtung Cloud-native gegangen sind, ebenso wie der Telekommunikationssektor. Fast alle bauen ihre Applikationen Cloud-native um und haben dafür sehr hohe Investitionen getätigt. Sie wissen genau, dass sie zum einen auf die Kosten achten, zum anderen mit der Bereitstellung ihrer Services vorne dran sein müssen.

Auch Online-Retailer sind schon relativ weit, weil ein Scale-out bei Webshops oder Homepages mit großer Reichweite absolut sinnvoll ist. Etwas zögerlicher sind derzeit noch die Banken. Aber auch sie werden nach und nach aus Kostengründen auf App-getriebene Workflows übergehen müssen. Vielleicht hilft ihnen - und auch den übrigen Branchen - dabei das Entgegenkommen der Hyperscaler. Diese fangen gerade damit an, ihre internen Konzepte zurück in die Kundendatencenter, den normalen IT-Betrieb, zu geben. Die Entscheidung zwischen Hyperscaler oder Private Cloud ist zwar dann immer noch zu treffen, technologisch ist aber der Unterschied nicht mehr so groß.