Warum „Cloud-Native“?

Warum „Cloud-Native“? (Teil 4)

von Gastautorin/Gastautor 20. Dezember 2018

Wie veränderte Treiber zu neuen Paradigmen führen

Ein Gastbeitrag von Uwe Friedrichsen

(Dieser Artikel ist zuerst erschienen in Softwerker. Mehr Infos unter https://info.codecentric.de/softwerker-cloud-native)

Cloud-Native-Anwendungen

Nun, das klingt ja alles sehr schön, aber was ist mit der tiefen Fachlogik, mögen Sie sich jetzt fragen. Wohin kommt die? Oder stöpseln wir jetzt nur noch Managed Services per FaaS zusammen?

Differenzierende Fachlogik als Managed Container

Nein, natürlich nicht. Jedes Unternehmen hat eine gewisse Menge an differenzierender Fachlogik, die das Unternehmen von anderen Unternehmen unterscheidet. Das ist aber so gut wie immer sehr viel weniger, als die jeweiligen IT-Abteilungen derzeit glauben und dafür Unmengen an Geld ausgeben. Hier kann man mit Managed Services viel Aufwand, Risiko und Geld sparen, indem man die nicht differenzierenden Teile damit adressiert, was häufig 80-90 % der gesamten IT darstellt. Trotzdem bleibt ein Kern an Fachlogik übrig, den man nicht einfach kaufen kann, sondern den man selber implementieren muss.

Bei komplexerer Fachlogik stoßen die heutigen FaaS-Ansätze aber schnell an ihre Grenzen bzgl. Verständlichkeit, Wartbarkeit und Betreibbarkeit. Dann empfiehlt es sich weiterhin, auf Microservices oder kleine Monolithen (aber mit klaren, wohldefinierten Schnittstellen) zu setzen. Diese Services werden auch weiterhin in Form von Containern bereitgestellt.

Beim Betrieb dieser Container zeichnet sich aber ein Paradigmenwechsel ab: Anstatt diese (z. B. unter Nutzung von Kubernetes) selber zu betreiben, wird man sie perspektivisch als Managed Container betreiben. AWS Fargate (ein Managed Container Scheduler von AWS) zeigt die Richtung dafür auf: Man sagt nur noch, wann ein bestimmter Service/Container benötigt wird, sprich, auf welche Events er reagiert, und der Scheduler kümmert sich ähnlich wie bei FaaS um den Rest. Das reduziert die Fertigungstiefe für die Nutzung von Containern massiv, weil die gesamte Komplexität von Konfiguration und Betrieb der Container weitestgehend hinter einer sehr einfach nutzbaren Fassade abstrahiert wird.

Radikale Reduktion der Fertigungstiefe

Betrachtet man das gesamte Bild, das sich hier bietet und vergleicht es mit der zuvor skizzierten typischen IT-Lösung von heute, so sieht man, dass Cloud-Native das Potential bietet, die eigene Fertigungstiefe im Backend-Bereich radikal zu reduzieren. Um Bereitstellung, Härtung, Wartung und Betrieb der Laufzeitinfrastruktur muss man sich gar nicht mehr kümmern und alle nicht differenzierenden Anwendungsteile werden ebenfalls als Managed Services zugekauft und integriert. Damit muss man sich neben der Integration nur noch um den differenzierenden Teil der Anwendungslogik kümmern, deren Betrieb man perspektivisch via Managed Container auch komplett an einen Cloud-Provider abgeben kann.

Wenn wir jetzt zurück zum Anfang dieses Artikels gehen und der Notwendigkeit, die Durchlaufzeiten in der IT radikal zu reduzieren, ohne die Qualität zu kompromittieren, dann unterstützt einen Cloud-Native hier durch eine drastische Reduktion der Fertigungstiefe sehr gut.

Ja, aber…

Damit sind Potentiale und Nutzen von Cloud-Native hoffentlich klar geworden, und wenn Sie das jetzt interessant und einleuchtend finden, dann freut mich das. Häufig bleiben aber auch trotz grundsätzlicher Überzeugung einige Fragen offen. Ich versuche einmal kurz, auf die Fragen einzugehen, die ich am häufigsten höre:

  • Muss ich auch Cloud-Native machen, wenn ich gar nicht das Problem habe, dass ich die Durchlaufzeiten durch die IT-Wertschöpfungskette minimieren muss?
    Nun, ein Muss ist es sowieso nicht, sondern eine Option, die wie alle Optionen Vor- und Nachteile hat. Wenn Sie sich tatsächlich in der komfortablen Situation befinden sollten, dass Sie die Durchlaufzeiten durch Ihre IT-Wertschöpfungskette nicht beschleunigen müssen (z. B. weil Sie in einem sehr geregelten Markt oder abseits des Consumer-Segments tätig sind), dann werden viele der aktuell populären IT-Themen wie z. B. Agilität, DevOps, Microservices, Continuous Delivery und vieles mehr für Sie optional und Sie sollten sich genau überlegen, ob und was sie davon nutzen wollen.

  • Ist es nicht viel teurer, wenn ich alles in die Cloud verschiebe?
    Das ist eine berechtigte, aber auch nicht-triviale Fragestellung, die leider gerne von Cloud-Gegnern genutzt wird, um Unsicherheit bei den Entscheidern zu schüren.

Grundsätzlich gilt, dass ein naives „Lift-and-Shift“, d. h. Verschieben bestehender Anwendungen auf Cloud-VMs ohne weitere Anpassungen in der Regel teurer als der Betrieb im eigenen Rechenzentrum (RZ) ist. Jenseits davon ist die Antwort nicht so einfach.
    

Der springende Punkt ist die Ungewissheit: Ich habe keine Ahnung, ob das, was ich erstelle, Wert am Markt hat. Ich weiß, dass eine Menge meiner Ideen am Markt keine Resonanz finden werden. Trotzdem muss ich kontinuierlich und zeitnah neue Ideen am Markt testen, um die Ideen zu finden, die von meinen Kunden angenommen werden. Wenn ich für jede dieser Ideen eigene Infrastruktur bereitstellen und betreiben muss, dann ist das (sofern das eigene RZ die Ressourcen überhaupt zeitnah bereitstellen kann) in der Regel deutlich teurer und aufwändiger als die Nutzung einer Cloud-Native-Serverless-Lösung.
    Im eigenen RZ muss man die Ressourcen in der Regel für eine erwartete Spitzenlast bereitstellen, die – wenn sie überhaupt eintritt – nur ganz selten erreicht wird, während die durchschnittliche Ressourcenauslastung meist im einstelligen Prozentbereich liegt. Selbst wenn man Ressourcen dynamisch aufstocken kann, so hat das im normalen RZ-Betrieb doch immer so langen Vorlauf, dass man bei unerwarteten Lastspitzen, sprich einem erfolgreichen Angebot, die Nutzer entweder nicht bedienen kann (was aus Geschäftssicht sehr riskant ist) oder man doch deutlich mehr Ressourcen bereitstellt, als man normalerweise benötigt.
    Bei einem Cloud-Native-Serverless-Ansatz ist das anders: Hier zahlt man in der Regel sehr feingranular nur für die tatsächlich genutzten Ressourcen, sprich, meine Kosten steigen und fallen linear mit der Nutzung meines Angebots. Da die durchschnittliche Nutzung eines Angebots häufig nur wenige Prozent der Spitzenlast ausmacht, kann man gerade im Serverless-Szenario sehr viel Geld gegenüber einer traditionellen Bereitstellung der Ressourcen im eigenen RZ sparen. Und sollte die Last einmal hochschnellen, weil man den Nerv der Kunden getroffen hat, dann zahlt man zwar mehr, aber dann verdient man auch mehr.
    Hat man dagegen ein stabiles Geschäftsmodell, z. B. bei einem reifen Produkt mit klar verteilten Marktanteilen (Stichwort: „Cash Cow“), das eine gut prognostizierbare und relativ konstante Systemlast erzeugt, dann kann der Betrieb in einem eigenen RZ sinnvoll sein, um die Anwendung kosteneffizienter zu betreiben. Dann weiß man aber genau, was man wie und wo braucht. Dann sind die kurzen Durchlaufzeiten nicht mehr so wichtig und man bewegt sich wieder im Bereich der (relativen) Gewissheit.
    Sind diese Voraussetzungen aber nicht gegeben und man ist der Ungewissheit eines dynamischen Marktes ausgesetzt, sind Cloud-Native-Anwendungen fast immer günstiger als der Betrieb im eigenen RZ.
  • Werde ich als Entwickler jetzt nur noch Managed Services zusammenstöpseln?
    Nein, nicht wirklich. Natürlich wird man als Entwickler in einem solchen Cloud-Native-Umfeld eine Reihe von Funktionen nicht mehr selber implementieren und stattdessen Managed Services via FaaS integrieren und orchestrieren. Aber das ist ja nur ein Teil der Aktivitäten. Zum einen bleibt die differenzierende Geschäftslogik, die weiterhin selber entwickelt werden muss – und bereits damit kann man als Entwickler gut ausgelastet sein, wenn es darum geht, die Durchlaufzeiten zu minimieren und viele Ideen auszuprobieren.
    Weiterhin ist das strikte Serverless-Szenario eher eine „Endausbaustufe“ von Cloud Native. Die meisten Unternehmen in Deutschland nähern sich erst mit unsicheren Schritten an die Nutzung der Cloud an und der Übergang vom exzessiven DIY der Vergangenheit zur radikalen Reduktion der Fertigungstiefe unter strikter Nutzung von Serverless-Angeboten ist ein langsamer und schrittweiser Übergang. Hier bleibt noch viel Zeit, das Thema schrittweise aufzugreifen.
    Dann ist die gesamte Frontend-Entwicklung von dem Thema nicht betroffen. Ganz im Gegenteil wird dieser Bereich immer wichtiger, denn der Kampf um den Kunden wird heute im Frontend gewonnen. Wenn man sich jetzt noch überlegt, welche neuen Möglichkeiten und Herausforderungen etwa Sprache oder zukünftig Gestik usw. sowie Contextual Computing (die Geräte passen sich an die Fähigkeiten ihrer Umgebung an bzw. eine smarte Umgebung passt sich an die anwesenden Personen an) bieten, dann wird es für Entwickler an der Stelle alles andere als langweilig werden.
    Und letztlich gibt es ja auch noch Bereiche wie z. B. (Smart) Data, AI, IoT oder InfoSec, die Entwicklern in den nächsten Jahren sehr viele spannende Betätigungsfelder bieten werden. Es wird aus meiner Sicht also auf keinen Fall langweilig für Entwickler – ganz im Gegenteil!
  • Werde ich als Operations-Mitarbeiter überflüssig?
    Aus meiner Sicht nein. Natürlich sind die Zeiten vorbei, in denen man Rechner oder Datenbanken noch von Hand aufsetzt (bzw. sollten vorbei sein, auch wenn man das in manchem Unternehmen noch antrifft). Und auch das Betreiben, Verwalten und Patchen von Infrastrukturbausteinen neigt sich mit Cloud-Native dem Ende entgegen. Das Wissen aber, wie man eine zuverlässige Anwendungslandschaft aufsetzt, absichert und überwacht, wird in solchen Szenarien fast noch dringender benötigt als zuvor.
    Wie setze ich ein SDN (Software-Defined Network) richtig auf? Welche SDN brauche ich, um meine Systemlandschaft zuverlässig und sicher betreiben zu können? Wie überwache ich die ganze Landschaft gut? Wo brauche ich ggf. ein VPN oder eine VPC und wie setze ich das richtig auf? Wie konfiguriere ich die ganzen Sicherheitseinstellungen des Cloud Providers richtig? Und viele Fragen mehr, die ein profundes Operations-Wissen voraussetzen.
    Damit ändert sich das Profil eines Operations-Mitarbeiters zwar ein Stück weit, aber überflüssig wird er auf gar keinen Fall. Und letztlich werden die Aufgaben aus meiner Sicht sogar interessanter und abwechslungsreicher.

Fazit

Wir sind von veränderten Marktbedingungen und einer veränderten Rolle der IT über typische IT-Lösungen heute und die Notwendigkeit zur Reduktion der Fertigungstiefe zu Cloud-Native gekommen. Natürlich ist Cloud Native nur ein Baustein, wenn man es mit der radikalen Beschleunigung der IT-Wertschöpfungskette ernst meint, aber es ist ein sehr wichtiger Baustein.

Nun werden Sie deswegen natürlich nicht alle laufenden Projekte stoppen und von heute auf morgen alles auf Cloud-Native umstellen (und das würde ich Ihnen auch nicht empfehlen). Auch ist Cloud-Native ein relativ breiter Begriff. Ich habe hier eher die „Endausbaustufe“ skizziert, um die Potentiale deutlich herauszuarbeiten. In der derzeitigen Praxis werden Sie aber ein weites Spektrum von ein paar einzelnen Services über die von mir skizzierte IT-Lösung heute bis hin zur vollen Adoption von Serverless antreffen.
Mein Ziel war es auch nicht, die perfekte Definition von Cloud-Native zu liefern (die es m. E. Ohnehin nicht gibt), sondern Ihnen zu helfen, das Thema besser zu verorten und zu verstehen, warum es sinnvoll ist, sich damit zu beschäftigen. Und wenn mir das gelungen sein und der Artikel Ihnen ein paar Denkanstöße geliefert haben sollte, dann würde mich das sehr freuen.

In dem Sinne wünsche ich Ihnen viel Spaß bei der Lektüre der anderen Artikel, die tiefer auf einzelne Aspekte von Cloud Native eingehen – in der ganzen Bandbreite des Begriffs. Und sollten Sie mehr zu dem Thema wissen wollen: Fragen Sie uns einfach. Wir helfen Ihnen gerne.

Referenzen

[1] U. Friedrichsen, „DevOps is not enough“, siehe https://www.slideshare.net/ufried/devops-is-not-enough-embedding-devops-in-a-broader-context, Vortragsaufzeichnung siehe https://www.youtube.com/watch?v=PZCNw_i12Us
[2] Nicholas G. Carr, „IT doesn’t matter“, siehe https://hbr.org/2003/05/it-doesnt-matter

Teil 1: Warum „Cloud-Native“? – Wie veränderte Treiber zu neuen Paradigmen führen.

Teil 2: Warum „Cloud-Native“? – Schnellere Durchlaufzeiten als Ziel.

Teil 3: Warum „Cloud-Native“? – Langsamer und schlechter

Unser Gastautor

Uwe Friedrichsen Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als Fellow und CTO der codecentric AG ist erstets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit, Resilience und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und natürlich gerne auch im direkten Gespräch.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Ähnliche Beiträge