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.
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.
- Timo Brueggemann, Canonical
„Wer glaubt, es genügt, sich ein Cloud-natives Produkt zu besorgen und es auf die eigene Infrastruktur aufzuspielen, um dann loszulegen, der irrt sich gewaltig. An erster Stelle geht es darum, zentrale Fragen zu beantworten: Wie ist mein Stack, und welche Use-Cases habe ich? Wie sind meine Infrastruktur und meine unternehmensinterne Organisation aufgebaut, und in welchen Bereichen ergibt Cloud-native am ehesten Sinn? Wenn das geklärt ist, beginnt man mit ausgewählten Themen und holt sich externes Wissen für Trainings dazu. Anhand dieser Leuchtturmprojekte lässt sich dann gut zeigen, wie es laufen muss. Man stellt ja nicht von heute auf morgen alles und alle Anwendungen gleichzeitig um.“ - Christian Dörrer, Objektkultur
„Um alle Vorteile von Cloud-native effektiv nutzen zu können, muss das gesamte Change- Management im Unternehmen berücksichtigt werden. Neben der Transformation der Organisation, der Prozesse und der Querschnittsfunktionen ist auch die Qualifizierung der Mitarbeiter entscheidend. Zudem erwarten neue hoch qualifizierte Mitarbeiter, dass der Arbeitgeber in Cloud-native-Technologien investiert. Nur so kann die komplette Innovationskraft eines Unternehmens ausgeschöpft werden.“ - Thorsten Fischer, Open Text Software
„Unternehmen haben unterschiedliche Cloud-Strategien. Die einen bevorzugen Standardisierung Richtung SaaS und Cloud-native, andere erhalten sich eine stärkere Individualität bei maximaler betrieblicher Effizienz. Für Unternehmen und Softwarehersteller ist es wichtig, die richtige Balance zu finden: Wie kann ich vorhandene Software zum Beispiel mittels Containerisierung besser in die Cloud bringen und gleichzeitig einen Cloud-native Stack hochziehen? Für Anwender und Anbieter spielt dabei neben der Technik die Organisationsstruktur eine entscheidende Rolle, es reicht nicht mehr, nur in Produkten zu denken. Die Gesamtbetrachtung muss im Mittelpunkt stehen.“ - Andreas Knols, QSC
„Viele gehen das Thema Cloud-native mit den Technologieabteilungen oder auch nur mit den Fachabteilungen an, aber neben dem Mindset Richtung DevOps oder Continuous Deployment gehören noch viele weitere Dinge dazu. Es ist hauptsächlich ein People- und Prozess-Business und weniger ein Technik-Business. Ich kann nur empfehlen, sich einen erfahrenen Berater zu holen, der die Visibilität für all die Themen schafft, die ebenfalls davon betroffen sind, wie zum Beispiel die Rechnungsfreigabe. Wenn Sie die Public-Cloud-Rechnung nicht rechtzeitig bezahlen, dann wird der Service einfach abgeschaltet. Auch darauf muss man den Kunden hinweisen.“ - Stephan Nies, Deloitte
„Die Entwicklungskosten und die Cost of Opportunity werden gerne unter den Tisch gekehrt. Wenn ich es wegen meiner selbst gehosteten Lösung nicht schaffe, die Projekte in einem halben Jahr umzusetzen, und statt dessen zwei Jahre brauche, dann haben die Wettbewerber in einem halben Jahr schon gehandelt. Von daher kann es durchaus wirtschaftlich sinnvoll sein, ein bisschen mehr Geld für die Cloud auszugeben. Zumal man bedenken muss, dass manche deutschen Unternehmen ohnehin schon im Hintertreffen gegenüber chinesischen und amerikanischen Konkurrenten sind. Da ist dann die Frage, wie viel Selber-Hosten man sich noch leisten kann.“
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ß.