Welche Technologie kann meinen Geschäftsprozessen auf die Sprünge helfen? Ist generative KI schon reif für den Unternehmenseinsatz? Wie kommt meine Applikation in die Cloud und was habe ich davon? Diese und weitere Fragen am Schnittpunkt von Business und Tech beantworten wir im Podcast. Digitale Wissenswissen. Wir erleben so oft eine leicht naive Vorstellung davon, was es bedeutet, in die Cloud zu gehen oder in die Cloud zu migrieren. Dass es sinnvoll ist, mal über ein paar grundlegende Begriffe zu reden, die wirklich jeder kennen sollte. Im Rahmen von Cloud Migration und im Rahmen von Cloud Deployment. Gerade aus der Businesssicht ist die Cloud ja immer ein zweischneidiges Schwert, weil einerseits Kosteneinsparungen möglich sind, kosten Skalierungseffekte, die zum Teil ganz wunderbar sind und mit nichts zu vergleichen, was man lokal hinkriegt. Auf der anderen Seite hat es aber auch finanzielle Konsequenzen, wenn man eine Cloud Migration zu naiv angeht und zu sehr versucht, das ganze Projekt einfach zu halten auf der technischen Ebene. Und diese. Diesen Widerspruch wollen wir heute ein bisschen beleuchten und uns anschauen, was da für Einflussfaktoren mitspielen und wie wie die gegeneinander spielen. Auch in einer gewissen Weise, wie man diesen Widerspruch auflösen kann, um idealerweise die Vorteile zu ernten oder die Nachteile auch mit auf sich zu nehmen, sollten zuerst mal über eine Cloud Migrations Strategie der sehr oft begegnen, die sehr oft gerade vom so leicht technologisch versierten Management gepusht wird, die aber leider sehr, sehr viele Nachteile hat, dass sie die Strategie des sogenannten Left Shift, was damit gemeint ist. Wir nehmen eine alte Applikation, die eigentlich auf einem Server Cluster läuft, auf irgendwelchen Rechnern unter meinem Schreibtisch oder in einem Datenzentrum. Vielleicht ist es schon ein bisschen virtualisiert, vielleicht aber auch nicht und schieben die quasi fast ohne Veränderung in die Cloud. Das bedeutet unterm Strich tauschen wir physikalische Server, die aktuell vielleicht per Capek sogar gekauft sind, gegen monatliche Gebühren für virtuelle Server in der Cloud. An der Application müssen wir nichts ändern, die schieben wir einfach eins zu eins rüber und können anschließend sagen Hey, unsere Applikation, unser Service, unsere Dienstleistung findet in der Cloud statt. Mit den Vorteilen, die das hat, was auch immer das in dem konkreten Fall sein magister. Das klingt erst mal wahnsinnig attraktiv und kommt mir aber vielen Beteiligten auch wahnsinnig attraktiv vor, hat aber ein paar entscheidende Nachteile, die sehr, sehr oft zum Scheitern von solchen Projekten führen. Wenn man darüber nachdenkt, was normalerweise Rechenressourcen kosten, was man normalerweise verrechnen, Ressourcen bezahlt, dann gibt es eine recht scharfe Preissteigerung zwischen einem Rechner, die ich unterm Schreibtisch stehen habe oder in meinem eigenen Datenzentrum betreibe, zu einem Rechner, den ich miete, den also jemand anders für mich betreibt, zu einem entsprechenden virtuellen Rechner in der Cloud. Und dieses, diese Kostensteigerung, da reden wir von Sprüngen um Größenordnungen. Ein Server, den ich gekauft habe, also per Invest per Capex mir geholt habe und der unter meinem Schreibtisch steht oder in meinem Datenzentrum und den ich, sagen wir mal fünf Jahre betreibe. Der kostet mich im Monat vielleicht umgerechnet 50 €. So ein mittleres Ding, auf dem ich irgendwelche Application Services betreiben kann. Wenn ich den ein sehr ähnlichen Server mir bei Overhead zum Beispiel was ein relativ preiswerter Anbieter wäre Miete kostet nämlich 200 €. Und ob man es glaubt oder nicht, wenn ich mir genau die gleichen Ressourcen, die dieses Server zur Verfügung stellt, also die gleichen Festplatten, Kapazitäten, gleiche Hauptspeicher, gleiche CPU in einem Cloud Anbieter Environment zusammen konfiguriere als zum Beispiel Perikatur auf Amazon Apps oder oder entsprechend auf. Also die Preise sind da gar nicht so unterschiedlich. Dann bin ich sehr schnell bei 1.000 € im Monat. Das ist natürlich dann ein harter Anstieg. Das heißt, selbst wenn ich jetzt es schaffe, meine Applikationen ohne große Änderungen von meinen lokalen Servern auf Cloud Server zu schieben, muss ich diesen Anstieg irgendwie kompensieren oder an meine Endnutzer weitergeben. Beides geht natürlich oft nicht. Nehme mal eine Stelle ein ein Dienst für irgendwelche Kunden von mir zur Verfügung, den ich jetzt aktuell mit 500 € Monat bepreise. Dann kann ich tatsächlich nach dem letzten Shift nicht mal die Hardware, also nicht mal Hardware ist es in dem Sinne ja nicht nicht mehr die Ressourcen für diesen Service mehr bezahlen. Von dem, was ich vorher mit Marge eingenommen habe. So eine Cloudmigration scheitert dann oft zu Recht am Controlling oder am Finance Bereich, der direkt vom Anfang an sagt okay, mit diesen Kosten, die hier projiziert sind, brauchen wir gar nicht anfangen, eine Migration zu machen. Da zeigt sich dann auch gleich immer schön, dass es eigentlich in diesen Cloud Migrationsprojekten oft ein Dreieck aus Interessen gibt, das einmal den IT Betrieb im weitesten Sinne. Also die Leute, die dafür sorgen müssen, dass eine Applikation läuft bzw die Hardware läuft, dass der Applikationen bereitgestellt werden. Die hätten schon gerne eine Cloud Migration, denen wir auch vielleicht egal ob es ein Lift in Shift ist, weil die hoffen primär darauf, dass ihr Job ein bisschen einfacher wird und ein bisschen effizienter durch die Cloud Migration Cloud Services selbst nach Lift und lassen sich einfacher bekappen, lassen sich einfacher wiederherstellen, lassen sich einfacher monitoren. Einige Security Aspekte, also IT Sicherheits Aspekte sind etwas einfacher zu handhaben, wenn das nicht mehr in einem auf einem Server unter dem Schreibtisch läuft. Und insgesamt ist einfach das Handling von der Applikation in der Cloud sehr, sehr stark durch Werkzeuge vereinfacht, das heißt IT betriebsseitig werden einem selten große Steine in Weg gelegt. Es gibt natürlich Bedenken zum Thema DSGVO, was es mit Datenschutz, was es mit Daten, Privacy Die sollten mittlerweile eigentlich nach so viel Jahren Erfahrung mit DSGVO und mit Cloud Anbietern nicht mehr so ins Gewicht fallen. Wenns nicht gerade um Gesundheitsdaten geht, findet man eigentlich gute Lösungen dafür. Auf der anderen Seite haben wir wie gesagt Finance, die dieses Ding rein aus der Kostensicht betrachten und anschauen. Was bedeutet das jetzt für die Operation und XP Managers? Was läuft mich an dauernden Kosten auf? Durch diese Cloud Migration und die Perspektive dort ist natürlich Auf und Shift eher eine negative, weil es immer mehr kostet als der lokale Betrieb. Also der lokale Betrieb ist wirklich saudumm aufgezogen. Muss man da auch in aller Deutlichkeit sagen. Und dann haben wir den dritten, den dritten Bereich, die dritten Interessenlage. Das ist quasi das Developmentteam bzw die Leute, die Applikationen bereitstellen, seien es nun eigenentwickelte oder eine zugekaufte. Die wollen eigentlich schon immer gerne modernisieren. Die sehen natürlich tendenziell auch den Vorteil, den man in der Zukunft mit einer Cloud Migration heben kann, indem man Wartungs Aufwände für Software Komponenten reduziert oder Skalierbarkeit schafft. Weil nach dem letzten Shift ist ja normalerweise immer angedacht, dass ich anschließend meine Applikationen so umstrukturiert, dass sie immer nativer wird, also immer mehr Cloud Services auch verwendet, statt nur dumpf vorhandene Software in die Cloud zu heben. Meistens passiert das nicht, also bei dem letzten Shift oder lange nicht. Aber im Projektplan steht das sagen wir mal so meistens schon drin, dass man sagt Lift, den Shift und anschließend wird das Ganze dann so umstrukturiert, dass wir tatsächlich skalieren können und und von den Cloud Services profitieren diese drei Interessen. Wenn man ein reines Den Chef Projekt anschaut, widersprechen sich. Wie gesagt, IT Betrieb kann vielleicht an Bord sein. Mit dem letzten Shift vielen sicher nicht dev normalerweise auch nicht Entwicklungsteam Normalerweise, wenn man schon die Cloud geht, auch tatsächlich die Vorteile davon verwenden. Und ein gutes DevTeam zeichnet sich dadurch aus, der sich darauf freut, Code loszuwerden, was tatsächlich durch eine ordentliche Cloud Migration immer möglich ist. Man kann normalerweise für vieles, was man einen eigenen Code geschrieben hat, in der Cloud einfach externe Services nehmen und so allen Code loswerden, der nicht direkt am Business Kern hängt und die eigene Businesslogik realisiert. Das ist eigentlich eine gute Sache. So was muss man also mindestens machen, um diese drei Interessenlagen unter einen Hut zu bringen. Aus meiner Sicht ist die Mindestanforderung ein sogenanntes Free plattforming. Darunter verstehen verschiedene Leute verschiedene Dinge. Man nennt es auch Lift Tinker Shift und das bedeutet, ich nehme meine Applikation und ich ändere sie zumindest mal ein bisschen. Ich nehme meine Applikation und versuche zumindest die offensichtlichen Komponenten, die überflüssig wären, in der Cloud durch Cloud Native Implementierung zu ersetzen. Was meine ich damit? Es gibt ein paar offensichtliche Sollbruchstellen, wo man ansetzen könnte für so ein Lifting enthält die offensichtlichste Sollbruchstelle die gefürchtete Datenbank. Viele Applikationen sind immer noch sehr datenbanklastig, arbeiten immer noch mit einer zentralen Datenbank, magister man davon das halten, was was man will. Diese Datenbank tendiert dazu, groß zu werden und wichtig zu sein im Gesamtkonstrukt und damit aber auch ressourcenhungrig und damit aber auch im Rahmen von einem Na left und Shift eine der teuersten Komponenten im Betrieb. In der Cloud. Das heißt, diese Datenbank durch einen Datenbankservice ein Cloud nativen zu ersetzen, verspricht die höchsten sowohl Performanz, Skalierung seffekte als auch die höchsten Einsparpotenziale gegenüber einer reinen Differenz Shift Migration. Das heißt, wenn man mit irgendwas Tinkert im Rahmen von Lifting ein Schiff, dann bitte auf jeden Fall mit den Datenbanken Twingstrukturen, Service, Basis. Solche Dinge sind das sind auch gute Kandidaten Software in die Cloud zu heben. Meistens passiert das nicht bei einem Geschäft oder lange nicht. Aber im Projektplan steht das sagen wir mal so meistens schon drin, dass man sagt Lift, den Shift und anschließend wird das Ganze dann so umstrukturiert, dass wir tatsächlich das skalieren können und und von den Cloud Services profitieren diese drei Interessen, wenn man ein reines Den Chef Projekt anschaut, widersprechen sich. Wie gesagt, IT Betrieb kann vielleicht an Bord sein mit dem Lift Geschäft Ihnen sicher nicht dev normalerweise auch nicht Entwicklungsteam bilden Normalerweise, wenn man schon die Cloud geht auch tatsächlich die Vorteile davon verwenden, und ein gutes devTeam zeichnet sich auch dadurch aus, dass sie sich darauf freut, Code los zu werden, was tatsächlich durch eine ordentliche Cloud Migration immer möglich ist. Man kann normalerweise für vieles, was man einen eigenen Code geschrieben hat, in der Cloud einfach externe Services nehmen und so allen Code loswerden, der nicht direkt am Business Kern hängt und die eigene Businesslogik realisiert. Das ist eigentlich eine gute Sache. So was muss man also mindestens machen, um diese drei Interessenlagen unter einen Hut zu bringen. Aus meiner Sicht ist die Mindestanforderung ein sogenanntes Free plattforming. Darunter verstehen verschiedene Leute verschiedene Dinge. Man nennt es auch Lift Tinker Shift und das bedeutet, Ich nehme meine Applikation und ich ändere sie zumindest mal ein bisschen. Ich nehme meine Applikation und versuche zumindest die offensichtlichen Komponenten, die überflüssig wären, in der Cloud durch Cloud Native Implementierungen zu ersetzen. Was meine ich damit? Es gibt ein paar offensichtlich Sollbruchstellen, wo man ansetzen könnte für so ein Lifting. Kein Shift. Die offensichtlichste Sollbruchstelle ist die gefürchtete Datenbank File Applikation on sind immer noch sehr datenbanklastig, arbeiten immer noch mit einer zentralen Datenbank, magister man davon das halten, was was man will. Diese Datenbank tendiert dazu, groß zu werden und wichtig zu sein im Gesamtkonstrukt und damit aber auch ressourcenhungrig und damit aber auch im Rahmen von einem na eben Lift und Shift. Eine der teuersten Komponenten im Betrieb in der Cloud. Das heißt, diese Datenbank durch einen Datenbankservice ein Cloud nativen zu ersetzen, verspricht die höchsten sowohl Performanz, Skalierungsseffekte als auch die höchsten Einsparpotenziale gegenüber einer reinen Lift Shift Migration. Das heißt, wenn man mit irgendwas zwinkert im Rahmen von Lifting ein Schiff, dann bitte auf jeden Fall mit den Datenbanken Housing Strukturen, Service, Basis. Solche Dinge sind sind auch gute Kandidaten. Die sind normalerweise, wenn eine Applikation sinnvoll strukturiert ist, nicht so eng mit dem Business Kern, mit der Geschäftslogik verwoben, dass es ein Riesenprojekt wird, die rauszuziehen. Manchmal ist das so, dass dann aber auch gleich ein guter Grund, über eine fundamentale Remigration nachzudenken, weil die Applikation ist dann einfach von der Architektur her schlecht, auch wichtig anzuschauen. Im Rahmen von Lifting kann Chef, da will ich jetzt nicht zu sehr ins Detail gehen, ist das ganze Thema Ressourcenhandling. Also was braucht die Applikation für lokalen Plattenspeicher oder braucht sie zum Beispiel zu bestimmten uhrzeiten besonders viel Hauptspeicher? Das sind so Dinge, die sollte man auch nicht einfach blind in der Cloud nachbauen und an jeden Service, riesige virtuelle Plattenhängen oder oder wahnsinnig viel Hauptspeicher zur Verfügung stellen, die man meistens gar nicht braucht. Das kostet und ist auch in der Zukunft dann quasi ein Pulverfass für zukünftige Architektur. Optimierung in Richtung Skalierbarkeit in Richtung auch dieser Art Recovery usw verteilte Datenhaltung. Gerade für diese Art Recovery ist das immer ein problematisches Thema. Gut, warum soll ich mir diesen ganzen Stress antun? Warum sollte ich das Lifting trotzdem machen, statt einfach den Server unter dem Schreibtisch zu behalten, nachdem ich ihn einmal bezahlt habe und er schon lange abgeschrieben ist? Das eine Thema ist tatsächlich Sicherheit. Also um Patchstände und Firewalls und solche Dinge muss ich mir schon in der Cloud deutlich weniger Gedanken machen. Ich muss mir nicht keine Gedanken machen. So ist es leider auch nicht. Aber es gibt mehr Mechanismen, die mich warnen, wenn meine Software tatsächlich veraltete Komponenten verwendet. Es gibt mehr Mechanismen, die mich auch beschützen vor bestimmten Formen von Angriffen. Es gibt zusätzlich Komponenten, die ich verwenden kann und und quasi in die Applikation reinbringen, die zusätzliche Sicherheitslevels zur Verfügung stellen. Authentisierung ist oft integriert und einfacher in der Cloud. Das sind alles Dinge, die man mitnehmen kann und die einem ermöglichen Software wegzuschmeißen. Wie gesagt, Software wegschmeißen ist eigentlich ein absolut gutes Vorgehen, weil Software kostet Software bringt auch Wert, aber sie kostet auch. Das heißt, je weniger Software ich habe vor den gleichen fährt, desto besser. Und dabei meine ich ganz banal Zeilen Code. Je kleiner das ist, was ich wirklich warten muss mit meinem eigenen Team, desto besser ist das. Das heißt, die wir mehr ich mich aus der reichhaltigen Bibliothek von Cloud Funktionen und Cloud Services bedienen kann, desto besser ist es im Normalfall für mich. Außer natürlich, diese Cloud Services sind ungeeignet, aber das ist das Problem von den Architekten. Was ich auch kriege, ist Skalierbarkeit, zumindest theoretisch. Wenn die Applikation das nicht hergibt, kann ich nicht skalieren, also automatisch skalieren, nur weil irgendwas in der Cloud läuft, ist natürlich auch nicht drin. Aber wenn ich die Applikationen dann richtig umstrukturieren, habe ich grundsätzlich die Möglichkeit, sowohl auf unendlich zu skalieren. Also beliebige Benutzer Ansturm wirklich abzufangen, als auch in Warmance zu haben, die auf Null skalieren, das heißt die weggehen in einem physischen Deployment zahlt man zum Beispiel für einen Test in Moment einfach die ganze Zeit, selbst wenn gar nichts getestet wird, selbst wenn diese Applikation vielleicht gerade gar nicht weiterentwickelt wird. Man lässt es stehen, weil es sehr aufwendig ist und testet. Wir haben dann wieder hinzustellen, ich muss die Server wieder besorgen usw und wahrscheinlich habe es ja gekauft. In der Cloud funktioniert das ganz anders. Wenn ich mein Deployment automatisiert habe, kann ich Befehl beliebig viele in warmen Stadtplan testen, weil man statt Dingen mal meine kundenspezifischen, weil Monkey und sie dann auch alle wieder abbauen und wegschmeißen und damit auch Aufwand für sie zu bezahlen. Minutengenau, unter Umständen. Von einer Minute auf die andere fällt dann auch dieser Kostenblock weg. Und das ist natürlich auch eine sehr, sehr schöne Sache. Ein weiteres Geld zu Zero Thema ist, dass manches Services in jeder Applikation nicht die ganze Zeit laufen müssen oder zumindest nicht die ganze Zeit Ressourcen konsumieren. Und in jeder Cloud Implementierung sei das Google Cloud, sei es Apps, sei es. Aber gibt es Mechanismen, um dieses Geld zu sehr abzubilden, sodass so ein Service dann auch nichts kostet, wenn er keine Anfragen kriegt? Das geht für manche Services sicher nicht für alles. Alle. Es geht definitiv für alle Batch Jobs, also Jobs, die einfach nur mal nachts laufen, um irgendwelche Daten Maintenance zu machen. Und es kann unter Umständen je nach Applikation enorm viel Geld auch einsparen. Natürlich wird im IT Umfeld genauso viel Greenwashing betrieben wie überall sonst auch, aber es ist eigentlich auch intuitiv logisch das als weiteren Vorteil man anführen kann, wenn nicht jeder seine eigenen Server betreibt, sondern wenn wir alle quasi diesen Pool aus Cloud Ressourcen schären, braucht man natürlich insgesamt weniger Server. Leider ein bisschen ad absurdum geführt mit Erfindungen, die wahnsinnig Ressourcen hungrig sind wie Blockchain oder oder Language Modus. Aber grundsätzlich ist es natürlich schon so, wenn ich in die Cloud mich wehre, spare ich nicht nur Kosten, sondern ich spare schon auch real Ressourcen, die nicht zur Verfügung gestellt werden müssen, weil ich mehr Ressourcen mit anderen Kunden des Cloud Providers teile. So scary sehe ich das vielleicht in punkto Datenschutz anhören magister. Im Normalfall ist es eine gute Sache, weil es Kosten spart und eben auch die Umwelt schont. Auch ein Aspekt, der nicht vielleicht nicht ganz außen vorgelassen werden sollte, wenn man in die Cloud migriert, wenn man eine alte Applikation in die Cloud heben will. Lasst euch nicht auf den Shift ein. Zumindest im Normalfall nicht. Glaubt niemanden, der euch verspricht, das Lüften Chef der einfachste Weg ist und kosteneffizient macht. Keine naive Migration. So macht eine möglichst native Migration, weil nur so kann man tatsächlich die ganzen Cloudvorteile nutzen. Ansonsten holt man sich einfach nur die Nachteile an Bord zu enorm gesteigerten Kosten. Und das ist in dieser Allgemeinheit, in dieser Plattheit tatsächlich trotzdem fast immer wahr. Bis zum nächsten Mal. Das war digitale Wissenswissen. Bleibt dran, um mehr über Trends und Technologien und deren praktischen Nutzen für dein Unternehmen zu erfahren. Danke fürs Zuhören und bis zur nächsten Episode.