Full Transcript for (DE) Cloud readiness in deutschen Unternehmen

haben. Und da hast du Leute, die beschäftigen sich seit zwei, drei Jahren mit Azure, die sind natürlich ganz anders drauf. 00:05:32.120 --> 00:06:21.079 Da musst du erst mal im Raum so eine Einheitlichkeit schaffen. Und dann ist eben genau die Frage, ja wann sind wir eigentlich Cloud-Ready? Und ich finde tatsächlich, Ready ist so ein schwieriger Begriff, weil die Cloud sich ja permanent weiterentwickelt. Also wenn du dich heute ready fühlst, guck mal in drei Monaten, was in Azure los ist, da bist du schon wieder nicht mehr ready, weil es hat sich alles geändert. Deswegen reden wir heute auch viel von Cloud-Maturity. Also wie hast du dich daran angepasst, auch so zu denken und zu arbeiten wie die Cloud. Und da gehört ein bisschen mehr dazu, als zu verstehen, was kann ich im Azure-Portal klicken, was ganz oft tatsächlich das ist, was immer noch die Hersteller auch empfehlen. Machen Sie mal das Portal auf, gucken Sie mal, können Sie klicken, klicken, klicken. Da habe ich mal irgendwann über die Konferenzen entweckt, diesen Begriff, klick, klick, Cloud geprägt, weil das tatsächlich viel das ist. Dann gucken Sie, jetzt haben Sie eine VM in Azure, jetzt sind Sie in der Cloud. Super cool. Was habe ich gekonnt? 00:06:21.079 --> 00:07:20.639 Gar nichts. Ich habe noch nichts über Security, nichts über Connectivity. Ich habe noch keine Ahnung, wie ich das Manager und so weiter und so fort. Und das ist für mich tatsächlich ein großer Punkt dieser Readiness oder Maturity, dass ich eben diesen Umfang von so einer Cloud-Migration. Das ist eben nicht nur ein Server in Azure haben, sondern gehört viel, viel, viel mehr dazu. Ja, das geht mir ganz genau so. Also ich komme auch in die Unternehmen rein und höre das dann. Also ich fange meistens in dem Drossar an, wo wir dann erst mal Begriffe in dem schreiben und versuchen, sich zu leveln, dass wir dann über ein oder selbe sprechen können. Das ist ganz cool. Ganz oft ist es ja auch so, dass IT eigentlich gar nicht gesagt hat, dass sie in Cloud will, sondern dass das von ganz woanders her kommt. Da soll ich erst mal wie dein Erfahrung bellen. Ja, tatsächlich. Es hat übrigens auch ein ganz witziges Beispiel aus, also noch mal in einer früheren Historie, in einem Mittelstandsunternehmen, da hat der Geschäftsführer mit Microsoft sich auf irgendeine Messe getroffen und hat einfach mal vereinbart, wir nehmen mal 200.000 Euro Azure, so auf Handscharg und dann hatten sie einen Monetary Commitment von 200.000 Euro und die Frage war, was machen wir damit? 00:07:20.639 --> 00:07:47.680 Und dann haben sie mal irgendwann ein Proof of Concept gemacht für eine Woche und dann war das wieder gut und dann bekamen sie sieben Monate später die E-Mail, ihr Commitment ist aufgebrau, aber fast aufgebrau. Und dann waren sie so, hey, wir machen aber gar nichts in Azure und haben sie vergessen, das mit dem Proof of Concept abzuschalten, dann liefen wir wie drei Cosmos DBs mit Commitment und keine Ahnung was. Erfolge. Super gut, also die 200.000 waren auch benutzt, das war super, aber leider nicht produktiv. Also mit voll Filmen? Genau, das haben sie gut geschafft. 00:07:47.680 --> 00:23:26.759 Aber tatsächlich, also gerade in den größeren Unternehmen ist das ja ganz oft eine Management Entscheidung, die also wirklich sagen, ja, wir wollen digitales Unternehmen werden, ganz vielen CEOs gehört, wir sind Cloud First. Entschuldigung, kein No Offense to any CEO out there, aber für die viele ist es wirklich, diese keine Ahnung, wo von sie reden. Also sie sagen halt Cloud First, weil das ist gerade so Mode und dann wollen wir das jetzt auch sein. Und dann steht die IT plötzlich da und sagt, oh, wir haben aber gerade vor einem halben Jahr in unser Rechenzentrum investiert, das ist irgendwie eine dumme Idee. Also das ist eine, tatsächlich so managementmäßig, irgendwie die C Level sagen, wir müssen ja wie die anderen sein, wir müssen das jetzt auch machen, oder aus dem Business tatsächlich. Also auch das habe ich schon ganz oft erlebt, dass dann wirklich ich mit dem Kunden zusammensaße, der Kunde mir inbrünstig erklärt hat, ich mache keine Cloud, ich will keine Cloud und jetzt einmal erlebt, da kam während wir zusammensaßen eine Mail von Box, also nicht das Box Drive Ding, aber hey, sie haben 2000 Accounts unter ihrer E-Mail-Adresse Domain, wollen sie nicht mal über Box for Business nachdenken. Ich bin fast drückwärts umgefallen vor Lachen, weil wir wollen keine Cloud, aber ihr nutzt über 2000 Leute bei euch nutzenden Cloud Drive. Das passiert da ganz viel und HR-Abteilungen, die sich irgendwo ein Hiring Portal in die Cloud setzen lassen, Marketing-Teams, die sich Landing-Pages irgendwo hinpacken und plötzlich bist du in der Cloud und du kannst auch nicht sagen, das wollen wir jetzt alles zurück, weil dann bist du plötzlich der Business-Vorhinderer und gerade aus der Rolle wollen wir als IT eigentlich raus, wir wollen der Business-Enabler und Unterstützer sein und ja, von daher kommst du um Cloud dann irgendwann nicht mehr drum herum. Ich komme mehr aus der Entwickler-Schiene, das ist ja also meistens hoch und was ich dann auch erlebe, ist ja nicht nur, dass die Anforderung übersteht, sondern kommt dann die IT-Witter mit über die Hand und hat dann auf einmal ein Problem. Also meistens ist es nicht nur so, dass sie gerade in einen Rechenzentrum investiert haben, sondern es fehlt meistens auch noch Wissen und neben diesen Wissen auf die Möglichkeit und die Chance sich dahin zu transformieren als IT, dass man auch den Infrastructure auf einem richtigen Weg startet. Also gerade, weil du das Thema Wissen ansprichst, was mich da echt ein bisschen schockiert, weil wie du das kannst ja gleich mal sagen, ob du das auch schon so erlebt hast, aber ich habe es tatsächlich in letzter Zeit häufiger gehabt, dass ich zu Kunden komme, erster Termin und der Kunde sagt mir, aber wir brauchen überhaupt nicht bei der Basis anfangen, ich hatte vor kurzem den einwöchigen Azure Workshop. Ich habe eine Schule

gemacht, ich bin total ready mit Azure und ich fange irgendwie an zu erklären, was der Unterschied zwischen der Edge-Zeit und der Production-Zeit ist und der Kunde guckt mich mit großem AUSA, was? Und dann machen wir irgendwie so vier Stunden Azure Basic und der Kunde sagt, wow, jetzt habe ich mehr gelernt als in den fünf Tagen Schule. Und das finde ich ganz schwer. Also es ist gut für mich, weil das zeigt ja scheinbar, dass ich irgendwie Wissen vermitteln kann besser oder mehr oder wie auch immer, aber es ist eigentlich ganz traurig für die Unternehmen da draußen, die sich für fünf Tage und das sind ja meistens tausende Euro eine Schulung gönnen und die Leute kommen nach raus und haben aber irgendwie die Grundlagen noch nicht mitbekommen. Also das schockiert mich zur Zeit, deswegen kann ich jedem irgendwie nur raten, wenn es um Schulung geht, schaut tatsächlich, dass jemanden kennt, der es schon mal gemacht hat und wie der den Gefühl danach war, weil es scheint da draußen schwarze Schafe zu geben, ich bin da immer wieder schockiert, aber weiß ich, was du das auch schon erlebt? Ja, mir geht es ganz, ganz genauso. Tatsächlich biete ich meinen Kunden an, wenn ich feststelle, okay, wir haben hier einen Knowledge-Gab, dass ich dann anfange, also da gebe ich ein Training und hab das aber customized, das ist komplett von mir selber entwickelt, wo ich anfange mit, was ist die Cloud? Und was sind deine Bührungspunkte, so wie das du eben mit dem Boxstripe beschrieben hast, fangt meistens an mit der iCloud oder so, fast jeder hat entweder einen Google Mail Account oder hat ein iCloud oder irgendwas anderes in der Richtung und nutzt schon mal die Happy Castle Cloud und ist sich darüber aber gar nicht klar und so bewege ich dann so langsamer sicher den Fokus Richtung, was ist denn Unternehmenscloud und wie könnte das aussehen, was sind da für Services drin? Du kennst bestimmt das coole, diese coole Pizza, EarthShark, wo man dann ablesen kann, was ist denn überhaupt ein Paar, was ist SARS, was ist IAS, diese ganzen Themen und bis das da mal durchdrucken ist und auch diese vielen Abhängigkeiten, die es dazu gibt, eine Monetäre, Abhängigkeiten, was ist, was bedeutet global, was sind Regions und ich meine, da müssen wir ja über ganz viele Themen sprechen, wo sich die IT nie darüber Gedanken gemacht hat, die haben ein Rechenzentrum, zwei Rechenzentren, vielleicht noch eine große Co-Location irgendwo in Frankfurt stehen oder sowas und unterhalten sich über Pfeiler, die irgendwelche Daten in der Nacht schaufeln müssen und bandbreiten und jetzt kommt auf einmal eine ganz andere Nummer dazu, wo sie sich über sowas keine Gedanken machen müssen, aber schon darüber Gedanken machen müssen, wie das ganze Thema dann dann ausschaut, also ja, ich erliebt genau das gleiche. Und die kommen dann auch und sagen, ja, ich habe die irgendwas 900 gemacht und die Basics können wir uns schenken und dann, ja, ich habe sogar die Prüfung bestanden. Ja, okay, erst den Blick wünsche ich, ich freue mich und dann kommen wir eben wieder auf das Gloss Harz zurück und dann merkst du ganz genau, wo sind die Schwarze? Genau, also das kenne ich ganz genau. Ja, das ist definitiv ein Thema. Andere Story ist dann, was ein Unternehmen, wenn ein Unternehmen kommt und sagt, ja, wir sind schon Klaufe, also dieses Ding so, wir haben eine Subscription, ein Credit Park Subscription, wo das Thema 590 noch hier gehört wurde und weiß ich nicht, wie das da bei dir ausschaut, ob die dann schon immer gleich mit dem Enterprise Agreement um die Ecke kommen oder ob da irgendwas. Ja, also tatsächlich in den Enterprise Unternehmen, wo ich jetzt unterwegs bin, die haben alle ja Enterprise Agreement, weil das Microsoft einfach dafür sorgt. Und viele haben das tatsächlich auch am Anfang mal irgendwo abgeschlossen, weil dann gab es Rabatte auf den gesamten Enterprise-Vertrag, so ähnlich, wie siehst du es ja, wo sind die Lizenzierung abschreifen, weil ich sehe, auf dem Moment viele Kunden, die haben irgendwie 100 GitHub Lizenzen in ihren Enterprise-Verträgen, benutzen überhaupt keinen GitHub, aber das ist halt irgendwie, wenn du das mitkaufst, dann kriegst du halt x% Rabatt auf dein Office. So, und so ähnlich haben viele ja mit Azure angefangen, irgendwie klein und dann wurde es immer ein bisschen größer und so weiter. Und was wir tatsächlich im Moment haben, ist, dass ganz viele Kunden wirklich groß nach Azure Committed haben, also wirklich im 2-3-stelligen Millionen-Bemalt und jetzt tatsächlich so ein bisschen den Druck haben, okay, jetzt müssen wir da Workload reinbringen und zwar business-relevanten Workload, weil du willst ja nicht 100 Millionen verbrennen, einfach nur, damit du deinen Commitment benutzt, das. Und von daher, die haben schon die richtigen Azure Subscriptions über den Enterprise Agreement, einfach weil es vertraglich sich so entwickelt hat, heißt aber noch lange nicht, dass man auch weiß, wie man damit umgeht. Und gerade dieses Thema, ich habe eine Subscription, wir haben auch schon Kunden, die hatten 600 Subscriptions, aber haben alles händisch verwaltet, wo man dann dastehen sagt, okay, nutzt Cloud, aber Cloud Ready würde ich jetzt nicht bezeichnen. Nee, auf gar keinen Fall, weil, also ich meine, also die Transformierung einer IT in Richtung einer DevOps ist ja, ist ja die größte Herausforderung, also der IT, um nicht das Gefühl zu geben, du bist jetzt obsolet, weil wir keine Hardware mehr umschubsen und installieren und oder irgendwelche IIS konfigurieren müssen, sondern wir müssen dich jetzt in eine ganz andere Richtung bewegen und dann kommt es ja, also Infrastructure as Code, also ganz wichtiges Thema, wenn man, also damit fange ich dann auf an, sie dann gleich in diese Schiene zu bewegen, dass sie verstehen, dass Automatisierung eigentlich der Next Level ist, oder? Ja, auf jeden Fall, also das ganze Thema, DevOps, People, Processes, Tools, wenn man jetzt ja mittlerweile so ein Bass wird geworden, aber ja, im Ende ist es tatsächlich das,

ich hab tatsächlich auf Arbeit gerade an einem Artikel, das nennt sich DevOps ist tot, lang lebe DevOps, weil genau das ist das Ding, also DevOps ist erstmal sowieso so ein Schwein, das Dorf getrieben wurden, jeder hat irgendwie DevOps ist geil, das muss man machen und dann haben sich alle irgendeinen Tool gekauft und haben gesagt, so jetzt haben wir DevOps, aber wenn du nicht da nacharbeitest, wenn du dich da nicht anpasst, wenn ich keine Infrastructure Code nehme, dann ist halt ganz toll, dass ich irgendwie mehr Azure DevOps oder GitHub oder was weiß ich, in Jenkins hingestellt habe, wenn aber keine Pipelines drin laufen, die mir irgendwie helfen, dann forward und das ist tatsächlich, dass die große Herausforderung, weil du natürlich eine IT hast, die ja im Bestand auch noch zu verwalten hat, es ist, in dem seltenen Fällen kommen wir irgendwo hin und dann ist Grünewiese, hier hast du zehn Leute, mach aus denen mal ein Cloud Team, sondern die können sich neben einem VMWR, die müssen noch das Sahnen verwalten, die haben irgendwelche Netzwerkoutages und dann kommst du und sagst, wo, Grünewiese Azure, so und das ist natürlich schwierig zu adaptieren und eine lustige Geschichte, ich zitiere jetzt mal den Kunden ohne irgendwelche Namen zu nennen, aber der sagte zu mir auf dem Weg zum Parkplatz, Herr Berg, wissen Sie was, ich habe zwei Mitarbeiter, die reparieren Telefone, wir haben aber seit zwei Jahren keine Telefone mehr am Standort und das war für mich so dieses, okay, ja du musst halt auch die Leute mitnehmen und du musst auch Leute haben, die das auch wollen natürlich und das ist, glaube ich, eine der größten Herausforderungen, also mittlerweile würde man sehr fast 100 Change Management fassen, aber wirklich so diese alten Silos aufbrechen, Leuten diesen Freiraum zu ermöglichen, dass sie neben ihren Day-to-Day-Tas auch wirklich Zeit haben, sich mit Azure auseinanderzusetzen und wie wir es ja vorhin schon gesagt haben, das ist halt nicht ein, ich lerne das jetzt mal fünf Tage und dann kann ich Azure, sondern das ist ein kontinuierlicher Lern, wir saßen jetzt hier in der Woche zusammen mit den Product Groups und haben irgendwie den neuesten Scheiß von Azure gehört, ja, das machen wir in drei Monaten nochmal gefühlt, weil dann ist schon wieder alles. Ja, das ist ein Riesenthema, es ist halt eine Transformation, ich mein Gott sei Dank gibt es eigentlich eine sehr gute Dokumentation dafür, das Cloud Adoption Framework eignet sich ja schon um sich zu orientieren, wie man es machen muss, aber wenn ich meine Kunden wenn ich also schon mal versucht, Kunden schnell zu helfen, habe ich um den Link auf das Adoption Framework gegeben und aber das Ergebnis war dann halt sehr enttäuschend, weil sie weil sie es einfach nicht verstehen, also Dokumentation auf der einen Seite, die die man benutzen kann um so was aufzubauen, finde ich gut, aber man braucht immer noch diese Begleitung dabei, der jemanden dann diesen diesen Transferschaft in die alte Welt, also da wo wir herkommen, also genauso wie du, habe ich viel Infrastructure gemacht früher im Automotes Umfeld und da auch viel Virtualisierung, also diesen man muss diese Transferleistung schaffen, um dann die, das muss man eben nicht nur für das IT Team machen, sondern das muss man unternehmensweit machen, also der Change, der muss unternehmensweit gemacht werden, damit also nicht nur das IT Team, sondern eben auch alles, das da drüber hängt und daneben hängt diesen Change mitmacht und auch damit umgehen kann, wenn es ist ja eins, das zum anderen zu automatisieren, ganz oft finde ich, wenn die IT das so langsam aber sicher versteht, was da abgeht und diese Transformation begonnen hat, die freuen sich über eine Sache riesig und das ist nicht die Automatisierung, es ist die kontinuierliche Dokumentation der Changes und sie können genau nachvollziehen, wann, was wer gemacht hat und dann manchmal dieses Frühstücksbüro rufen, wer hat denn das dann abendwas konfiguriert? Genau, guckst altes Repo und siehst es und oder hast ja das dokumentiert ja selbstverständlich und dann liegt es auf seinem Laptop, der dann gerade in dem Bach gefallen ist, weil er über die Brücke gegangen ist, also all diese Themen sind dann nicht mehr da, also das finde ich ziemlich gut, was mir aber bei diesem Thema Change und Unternehmen und Cloud auch immer wieder in den Sinn kommen, das ist so dieses Bashing von Vendor Locking, Vendor Locking, Multicloud und oder diese Fanboys, die ist dann in diese Nager, die dann entstehen teilweise in den Unternehmen. Hast du da Erfahrungen, Ernebnisse? Kann ich glaube ich Bücher drüber schreiben, also ja, Vendor Locking, das ist auch so ein Begriff, der mittlerweile auch wir wollen das nicht, wo ich immer sage, okay, was habt er für Clients, Windows Clients, was mit Vendor Locking, also das Spiel spielen wir schon eine ganze Weile, wir haben Firmen, die haben vollständig auf iPhones umgestellt, das ist auch ein Vendor Locking, wir haben, wenn nicht dort, wann, genau, wir haben, wir haben Windows Clients, wir nutzen seit zig Jahren Exchange, da gehst du auch nicht morgen mal hin und tauscht mal den Exchange gegen was anderes, macht kein Mensch, da haben wir uns darauf eingelassen und wir wissen das, dass es bewusst, eine bewusste Entscheidung, da hinzugehen, um eine gewisse Stabilität zu bekommen. Der Vendor Locking in der Cloud ist natürlich immer grundsätzlich schon ein Thema, ich muss mir überlegen, wie weit gehe ich in diese Cloud-Plattform rein und wie kann ich mich da auch wieder herausziehen, gerade wenn du jetzt wirklich anfängst, irgendwas neu zu entwickeln oder zu Refactor oder so und du verstehst vielleicht irgendwann fest, wie eigentlich erfüllt der Cloud Service gar nicht meine Anforderungen, wie komme ich da wieder raus und das ist tatsächlich was, was ich viel sehe, dass dann Kunden sagen, na ja, machen wir VMs. VMs ist super, weil die können wir ja einfach in der Cloud, genau, die kommen wieder nach unten ziehen, die kommen wieder

hoch, kostet halt schweine Geld, nicht so eine gute Idee, da hast du viel, die sagen, na ja, Container, Container ist ja der One Fit All Lösung für irgendwie alles, ich hätte es nicht gleich gesagt, aber auch da siehst du ja am Ende, na ja, dann fangen sie halt an, dann haben sie ja einen Container, nutzen einen Backend, aber eine Cosmos DB, dann haben sie ihren Container, dann fängt die Diskussion an, nutzen wir jetzt Post-Create als Container oder nutzen wir Post-Create in Asher, weil in Asher ist das eigentlich ein Komfortabel mit dem insigrierten Backup und Monitoring und Staling und so und na ja und am Ende tausche ich Flexibilität gegen Komfort ein, das ist so ein bisschen das, das was ich haben muss und die Frage ist einfach, wie viel Vendor Lock in oder wie riskant es tatsächlich ein Vendor Lock in, weil meine Frage ist immer okay, wovor habt ihr denn Angst beim Vendor Lock in? Und die zwei Hauptpunkte, die du hörst, ja was ist, wenn Microsoft man nicht mehr ist, wo ich sage, wenn das passiert, haben wir ein ganz anderes Problem, ein großes Fotschlag, wo ich dann auch keine, hast du die geahnt? Nein, aber da bin ich ganz ehrlich, also wenn Microsoft morgen Pleite geht, da haben wir ein ganz anderes Problem in der Welt, weil wir eine deutsche Regierung an, wir arbeiten vollständig mit Office-Produkten, angenommen Microsoft soll morgen alle Office-Produkte deaktivieren müssen aus welchem Grund auch immer, das sind wir alle am Arsch, um das mal so hart zu sagen, also da hätten wir ganz andere Probleme mit Vendor Lock in, als dass wir gerade in Azure sind. Und der zweite Punkt ist das Thema Pricing, das kann ich zum Teil natürlich nachvollziehen, wenn ich auf der Plattform bin und Microsoft geht morgen hin und sagt, das ist jetzt einfach mal 200 Prozent so teuer, dann bin ich halt da, dann muss ich halt kämpfen. Aber ich glaube auch da, es gibt ja eine riesen Masse an Kunden und man merkt es ja jedes Mal, wenn Microsoft irgendwas ändert an den Preisen, gibt es einen Feedback Loop, was so ein vögelich das formuliert. Genau. Und dann werden bestimmte Dinge gemacht. Und aber auch da, auch das hat man früher schon, wenn Microsoft damals die Windows Server-Lizenzierung geändert hat, dann war das halt so. Dann sagst du halt, mach ich weiter oder nehm ich jetzt die Millionen, die anderem alles auf Linux umzustellen. Hat's jemand gemacht? 00:23:26.759 --> 00:26:57.319 Auch bloß nicht. Ja, das ist auch meine Meinung dazu. Aber was ganz spannend ist, weil du vorhin das Thema Cloud Adoption Frame mal kurz angesprochen hast. Eine meiner Haas-Fragen beim Thema Cloud Readiness ist dieses, wie machen es denn andere Kunden? Es macht mich einfach nur fertig, aber ich dann immer frage, ja, sind sie denn wie andere Kunden? Sind sie als Bauunternehmen denn wie eine Bank? Ja. Sind sie als Bank denn wie ein Logistikunternehmen? Kann ich ein deutsches Logistikunternehmen mit einem schwedischen Fintech vergleichen? Nein, in der Regel nicht. So und das ist für mich persönlich auch so ein bisschen die Krux am Cloud Adoption Framework und an vielen dieser Standards, dass viele im Glauben sind, na ja, dann nehme ich das Cloud Adoption Framework und dann hab ich ja alles. Und das stimmt nicht. Das sehen nicht wie ITIL. Auch ganz viele, die so ITIL BAM, dann sind wir in der Super-Service-Organisation. Nein, das ist ein Framework. Deswegen heißt das Ding ja auch Cloud Adoption Framework. Nicht Cloud Adoption Rule Set oder Cloud Adoption Out-of-the-Box-Solution. Genau, es ist ein Framework und es gibt halt Vorgaben und es gibt ja ganz viel, auch mittlerweile Inter-Form und in Beise, Brunt, was weiß ich, und dass ich mir ziehen kann und dann muss ich es aber anpassen auf Licht und meine Prozesse. Und wenn ich halt, wie gesagt, ich habe ein Projekt in der Bank-Orderung. Genau, die Prozesse, sondern auch auf die Antwortung. Genau, ich habe ein Projekt in der Bank gemacht und dann hast du halt riesige Anforderungen in Richtung Compliance, da kommt die Barfinde, da kannst du nicht das Standard Cloud Adoption Framework nehmen, weil bist du tot. Und das ist, glaube ich, so das Fingerspitzengefühl, was es halt braucht zu sagen. Ja, es gibt da einen Standard, den nehme ich mir, um einfach so dieses Gesamte zu verstehen und jetzt pass ich das aber so an, dass es auf mich passt, auf meine Anforderungen, auf meine Prozesse, vielleicht auch auf meine Tools. Vielleicht macht es keinen Sinn für mich, Azure DevOps zu benutzen an der Stelle, weil ich habe schon eine ganz andere Toolchain implementiert. Warum das Rad neu erfinden an der Stelle? Ja, ich finde es auch schwierig, diese Best Practices Frage immer zu beantworten. Ja, und also bei ITs kommt es ja ganz schnell, wenn du in die Richtung Policies gehst und Policy Management, dann ja, was kann ich denn alles? Und dann, ja, naja, du kannst alles, quasi alles absperren und den Flügel wegschmeißen oder du kannst dir sinnvolle und den Antworten um entsprechende Entscheidungen treffen und ein gesundes Maß an Policies nehmen. Also wenn man dem Cloud Adoption Framework glaubt, dann sind da schon manchmal Sachen dabei, wo man sagt, ja, würde ich jetzt schlecht nicht so. Ja, genau, finde ich, finde ich gut, dass du sagst, dass man das auf jeden Fall auf den Kunden, auf die Anforderungen, auf die Bedürfnisse unterbricht und das dann sinnvoll übersetzt ist, machen wir genauso. Also ich glaube, in unserer Community würde keiner was anderes tun. Ich hoffe das. Ich hoffe das auch mehr. Ich hoffe, das ist ganz stark. Ja, Wendorlogin ist genau das, was du sagst auch. Also wenn ich mich mit dem Begriff auseinandersetzen, mit dem Kunden zusammen, dann frage ich Ihnen auch, was denn das bedeutet? Und am Ende des Tages ist, versuche ich ihm das ja halt so aufzuerklären, dass es ein Wendorlogin ist, der Moment, wenn der Schmerz und der Preis für einen Wechsel so groß ist, dass du ihn nicht mehr tust. Und diesen Wendorlogin gehen viele Firmen ja schon in ganz andere Richtungen. Einen hast du jetzt

zwar sehr simple Beispiele gebracht, aber wenn wir mal an SAP denken, once in, never out, ganz einfache Geschichte, von daher finde ich das sinnvoll. 00:26:57.319 --> 00:28:27.680 Aber Hybridcloud ist trotzdem ein Thema, ein interessantes, oder? Also ich mein, besides 5.1, ja, das ist ganz interessant, aber es ist total unterschiedlich, wie Unternehmen das spielen. Also so hast Kunden, die gehen strategisch in mehrere Clouds und sagen einfach, wir wollen das, weil wir wollen die Flexibilität haben und best of breed und was auch immer. Ist eine strategische Entscheidung, was viele dann halt feststellen, naja, ich implementiere halt alles zweimal. Ich mache zweimal ein Netzwerk, ich mache zweimal Policy, ich mache zweimal Security, weil man das ja dann auch trennen will. Und witzig sind dann die Kunden, die dann sagen, wir machen zwei Clouds, damit wir unabhängig sind, aber wir nutzen dann Azure DevOps, um auch in die andere Clouds zu deployen und wir nutzen das Azure Security Center, um auch da Security zu machen. Was ja sinnvoll ist, weil dann habe ich dieses Single pane of glass, aber das Argument ist halt weg. Also das ist so ein bisschen so, was man auch viel sieht, ist tatsächlich, ich habe eine Primary Cloud, wir schieben 80, 90 Prozent der Workloads nach älter und dann nehmen wir aus Google den Service, weil den gibt es halt nur da und in Amazon, Oslo, dies und das, weil die anderen Regionen, die die anderen nicht haben. Also so solche Geschichten sieht man tatsächlich relativ häufig mittlerweile und ja, dass jemand bei einer Cloud bleibt und nichts anderes aufpoppt, das ist quasi unmöglich heutzutage, aber die Frage ist halt immer, wie weit ist das eine strategische Entscheidung, inwieweit passiert das einfach, weil eben Leute irgendwo was aktivieren, weil sie glauben, dass das gerade zu müssen. 00:28:27.680 --> 00:30:31.559 Ja, das geht mir auch so. Ja, also oft ist es auch eine, also in dem Projekt, wo ich jetzt dann so tätig war, es ist ganz oft auf eine Sache von Ausfallsicherheit, weil also das ein oder andere Mal haben wir ja schon gesehen, dass man sich nicht mehr bei Teams anmelden konnte, ausgründen und davon ist ja also nicht nur Teams betroffen dann in dem Moment, aber und dann ist es einfach gut, wenn man, na gut, wenn man auf den Auto sitzt, wenn man auf den Auto weiter gesetzt hat, dann darf man trotzdem falten am Marsch, aber wenn man. Du kannst ja auch wirklich transparent bauen. Wir haben zum Beispiel eine Industrielösung bei das CGI, die macht quasi Bank Payment Transfers, wir schieben quasi Geld quer über den Planeten zwischen Banken hin und her und da ist halt einfach das strategische Anforderung, das muss laufen, immer. Wenn eine Region ausfällt, wenn ein Provider ausfällt, dann muss, die haben wir tatsächlich aufgebaut auf Azure und AWS und das Ding macht einen transparenten Failover zwischen den zwei Clouds. Das heißt, wenn Azure Region weg ist, läuft es einfach in AWS weiter und umgekehrt, weil, stell dir vor, wir würden quasi morgen das Payment System der Welt kaputt machen. Mein Motto ist immer, ich will morgen nicht auf der Schlagzeit der Bild stehen. Bei Bild postet nie was Positives auf der Titelseite, von daher möchte ich nicht. Da macht das natürlich absolut Sinn. Das ist auch einfach nur, kann ja auch nur jedem empfehlen, wenn ich wirklich was Business-Kritisches habe. Das kann ich aber auch innerhalb Azure ja schon machen, wenn wir viele Kunden die sagen, da gehen wir auch alles in West-Europe und attacke und feuerfreie, wo ich auch immer sage, aber was ist, wenn West-Europe mal ein Problem hat? Es gibt ja nicht umsonst diese Partnerregion North-Europe, wo man wählen es mal irgendwie so einen Failover noch hinpacken kann oder mindestens mal eine Datenkopie. Man ist ja nicht vor allem gefeiert und man sieht davon, Amsterdam ist unter Meeresspiegel. Weiß ich, ob das so eine gute Idee ist. Es gibt so ein paar Challenges dabei. Wenn man sagt, keine Panikmache oder Angstmache sein, aber man muss sich immer überlegen, wie kritisch ist das. 00:30:31.559 --> 00:31:10.559 Muss ich jetzt meinen Print-Server in zwei Klauts legen? Nein. Außer ich bin vielleicht eine Großdruckerei. Aber was sind wirklich meine kritischen Dienste und was dabei vielleicht tatsächlich ganz Interessant ist, was mittlerweile gerade im mittelgrößeren Mittelstand viel sehe, ist wirklich der Weg in Richtung Saas. Also dass viele Kunden da sich einfach sagen, ich gebe alles, was nicht meine Kernkompetenz ist, in Saas. Wir können gar nicht so kümmern, es ist überhaupt nicht meine Aufgabe, irgendeinen E-Mail-Server zu streicheln oder irgendeinen HR Recruiting-System zu streicheln. Damit verdiene ich ja kein Geld. Ich bin ein Logistiker, ich fahre Schiffe um die Welt, ich fliege Flugzeuge um die Welt und da drin Pakete und Container. 00:31:10.559 --> 00:31:24.599 Das ist meine Kernkompetenz. Da habe ich unique Sellingpoints, da habe ich irgendwie IP, DiOS, die selbst und den Restbezieh von außen. Genau, also da kommen ja auch die Themen dann wieder ins Spiel, wo man dann ins Juristische abdriftet, wo man sich erstellen muss. Das genießt es. 00:31:25.599 --> 00:32:28.839 Na, Governance gewährleistet ist und das will man dann vielleicht nicht von da haben, möchte man dann lieber im Profi an der Seite haben. Da sehe ich ganz genau so. Da kommen wir dann noch langsam so sicher, langsam aber auch sicher in die Ecke, wo wir dann über Security Also in Security ist ja auch etwas, also es gibt Kunden, die sagen, ist ja alles public und automatisch gefährdet und auf der anderen Seite gibt es die Kunden, die sagen, ah nee, ist okay, ich baue mir jetzt dann noch mein Wiener drin herum und dann glaube ich, ist das relativ safe. Wir beide wissen die Wahrheit, ich bin irgendwo in der Mitte und da hängt immer von den Anforderungen ab, aber alleine die Tatsache, was die Cloud an Abwehrmechanismen hat, wenn du für Standard gehst, ist ja schon irre, also. Ja, also das ist auf jeden Fall, ich stelle gerne

die Frage, wie sieht es denn im aktuellen Rechenzentrum aus? Also was sind denn eure heutigen Sicherheitsmechanismen? Was macht ihr denn mit Delos Schutz? Was macht ihr denn mit? 00:32:29.960 --> 00:34:29.719 Und dann wird es ja relativ dünn bei dem einen oder anderen. Ich habe tatsächlich auch schon Kunden erlebt, wo ich dann dachte, okay, Respekt, habe mir gut gemacht, Congrats. Cloud ist vielleicht auch gar nicht so viel zu viel, das ist ja da, aber das ist tatsächlich recht zählt. Bei mir natürlich auch aus einer ganz anderen Welt kommt und ja, die Diskussion über Public oder nicht Public, das Spannende an der Stelle finde ich ja tatsächlich, das wird immer noch viel über Infrastruktur reden. Also wir bringen Server in die Cloud, wir bringen VMware und Azure. SAP hast du vorhin genannt, ist halt immer noch in den Server-Workloads und selbst die SAP Cloud ist am Ende ja nichts anderes als Bunch of Servers, die du halt nur nicht mehr siehst. Das finde ich ganz spannend, weil ich tatsächlich ganz am Anfang, wo diese ganze Cloud Journey so aufkam, hat Microsoft ja viel gepredigt, macht Innovation, Refactored und so weiter und so fort und mittlerweile sehe ich aber, dass wir so viele Dienstenerger einführen, die es den Kunden leicht machen, sich nicht verändern zu müssen. Ja, ich sage mir jetzt SFTP Support für ein Storage Account oder so ein Quad, wo ich mal dachte, oh, bitte nicht, lasst doch die Kunden davon endlich weg. Oh, wir brauchen jetzt NFS, oh, wir brauchen jetzt, jetzt kriegen wir ja LSD VirtualSan, ja, Azure, wo ich so dachte so, also ja, ich verstehe es natürlich, damit kriege ich jetzt auch den letzten Kunden, der gesagt hat, ich brauche aber einen Sahen, sonst kann ich nicht migrieren, den kriege ich jetzt auch noch nach Azure. Aber die werden ja die nächsten 20 Jahre so weitermachen und eben nicht wegkommen. Und wie viele Kunden sehe ich heute immer noch, die ein Mainframe dastehen haben und sagen, ui, was machen wir jetzt mit den 700 Quadratmeter, die durch unser Mainframe belegt sind? Wie kriegen wir die dann in die Cloud? Naja, fass es halt an, aber dann ist es halt ein riesiger Aufwand, das um zu ändern. So, und da im Prinzip so ein bisschen diese Security-Diskussion reinzubringen, naja, eine Infrastruktur ist halt so sicher wie eine Infrastruktur ist. Und ich kann das Internet abtreten, dann ist halt auch sicher, also voraus sind. 00:34:29.719 --> 00:35:12.039 Innen habe ich natürlich immer noch Angriffsrektoren und irgendwo gibt es weißes trotzdem mit Internet Gateway, also von daher, mhm. Und deswegen siehst du ja viele im Prinzip die Konzepte, die im Rechenzentrum passieren, in der Cloud einfach wiederholen, naja, wir hatten lokale Palo Alto, also packen wir uns nach Azure Palo Alto und dann ist das ja sicher, dass sie dann an jede vor allem eine Public IP dran hängen und diese Public IP komplett an der Palo Alto vorbei redet. Ups, das wussten wir nicht, ja, also auch das schon erlebt. Da ist wieder so wieder beim Thema Learning und Wissen und so weiter, da geht ein bisschen mehr dazu, aber tatsächlich diese klassischen Infrastruktur-Netzwerkkonzepte, das gute innere und das böse Äußere, was immer noch der Gedanke von vielen Firewalls ist, ist schon irgendwie immer noch der Standard. 00:35:12.039 --> 00:35:57.960 Ich denke, ich sehe, man sieht das sogar auf manche einer Blueprint noch, naja, ich meine, Hubs Hope-Prinzip ist ja im Prinzip genau das. Mein Vorteil ist man immerhin, denkt man drüber über Segmentierung nach, was ja an vielen Rechenzentren ja heute auch nicht der Fall ist, ja, das ja alles wäscht, ein Netzwerk von Fire. Also, mein Mann entwickelt sich natürlich schon weiter, aber schon immer noch in dieser sehr Infrastruktur lastigen und lernt doch so dieses net das gute innere, böse Äußere. Das bleibt halt irgendwie erhalten und ich Challenge-Kunden dann schon gerne mal zu sagen, naja, aber was ist denn die Zukunft, ne? Eine Identity-Based Security und Zero Trust und wie kommen wir da hin? Das ist natürlich heute nicht geht, sofort ad hoc, weil ich bin mal eben auf Server und laufe, das ist ja klar, aber ich sollte wenigstens irgendwie eine Roadmap dafür haben und mich da hin entwickeln. 00:35:57.960 --> 00:36:21.639 Das ist ja mittlerweile auch, wenn du dir die klassischen Firewall-Hersteller anguckst, gehen ja auch den Weg, Identity-Based Firewalling und Co. Also so langsam gehen wir ja in die richtige Richtung, aber es gibt halt auch aus meiner Sicht einfach ganz viele Dienste, wo ich immer sage, wozu hast du eine IP? Also intern jetzt? Ja, wofür? Das ist irgendeine Webschnittsstelle, da hast du ein Katalog, wo deine Kunden von dir Katalogdaten runterladen. 00:36:22.440 --> 00:37:48.599 Warum musstest du das Ding in der internen IP haben? Das ist ja Quatsch, hast du eine API, da kannst du deinen Katalog hochladen und deine Kunden können die runterladen. Fertig! So und das Ding musst du ja eh publizieren. So und warum solltest du jetzt dieses Sicherheitsrisiko aufmachen, das in dein Netzwerk zu integrieren und dann mit Firewalls schützen und Routing regeln und also du machst ja eigentlich mehr Aufwand dadurch, dass du halt den alten Schuh fährst, wenn das Ding einfach ins Internet stellt, du sagst, das Schlimmste, was passieren kann, ist, dass einer den Katalog runterlädt, der ist nicht darf. Ja. Aber der kommt nicht weiter, weil der kommt eben nur an den Katalog dran. Das ist ein Stand-alone-Webservice, fertig. Dieses Umding, das macht für mich persönlich tatsächlich auch ganz viel an der Cloud Readiness aus, dass ich mich als wirklich auf diese neuen Konzepte tatsächlich einlasse. Ja, ganz spannend finde ich, die Deep Gründung mit den Kunden sagt, ich muss jetzt dabei da meine virtuelle Maschine hochziehen, damit ich meinen IRS doch hochziehen kann, damit ich meine Webfab und dann beschaut man da ein bisschen genauer hin und kann dann sagen, ja, okay, wir können jetzt auf ein App Service nehmen oder wir können den in den Container backen und das

Container reißen, dann laufen lassen. Wir würden die Kosten ungefähr viertfiel. Oh, du kannst dir das überlegen, ob du das jetzt so und so machen möchtest und da kommt dann halt wieder dieses wissenden Spiel. Ich, den IRS, den kenne ich hin und auswendig und auf der anderen Seite habe ich ein App Service oder ein Container und erst mich damit erst auseinandersetzen, lernen, wie das funktioniert. Ich verlasse meinen Gewohntester. Es ist natürlich auch eine Challenge, also heute weiß ich, ich logge mich in den Windows Server ein, da gehe ich in den Event Viewer und dann sehe ich, was passiert. Genau. 00:37:48.599 --> 00:38:21.239 Und jetzt sagt der einer und der andere, da musst du dann in Application Insights gucken und musst dann eine KQL Query schreiben und du stehst natürlich erst mal da, also brauchst du einen Server mit einem Event Viewer, ist eigentlich ganz nett. Aber ja, langfristig gesehen, ich glaube auch damals die ersten Lochkarten bedient, haben gesagt, durch meine Lochkarten ist ja eigentlich ganz nett, aber die haben sich irgendwie doch nicht durchgesetzt. Von daher, ich war ein langes Spiel. Ich habe noch mit Lochkarten gearbeitet, das war zwar bei der Bundeswehr noch, aber es waren Lochkarten, wenn lieber schon die. Also noch Streifen hängt, aufwand. Tatsächlich ja. 00:38:21.239 --> 00:38:36.360 Aber es ist auch eine andere spannende Entwicklung da, also du erinnerst dich bestimmt noch an die Phase, wo die Tin Clients das topen Notchbahn. Oh ja. Ja, bloß kein Computer auf dem Schreibt zu stehen haben, aber Monitor und Tastatur und Maus mit extrem schlechter Performance. 00:38:37.000 --> 00:40:35.719 Und wo kommen wir jetzt wieder hin? Also wenn wir uns das anschauen mit dem Virtual Desktop in der Decknote. Wir haben Boten in einem Virtual Desktop. Ganz genau. Das ist ja so ein ganz gewünschtes Feature von vielen Grunds. Ja, ich habe Virtual Desktop, das ist ja schon cool, aber kann man da nicht jeder reinboten? Warte mal, der Dring ist so well, das hat man doch schon mal. Warte mal, das ist ja ohnehin das. Also das geht ja immer in Wellen. Wir hatten ja mal alles im Mainframe, dann haben wir es an den Endbenutzer rausgegeben, dann haben wir es wieder mit der Virtualisierung zurückgeholt, dann haben wir wieder ein bisschen mehr an die Clients verlagert, weil wir plötzlich mobile Clients hatten. Jetzt holen wir es gerade wieder zurück ins Rechenzentrum und machen es alles als Web App. Ich bin mal gespannt, welches Sauwärter das ist durch das Doktorreiben, aber mein Gott, das ist IT. Also es verändert sich halt. Also ich bin Fan von diesen Themen, wo wir gucken, wie Codespaces oder so, wo ich gefühlt keine Maschine dazwischen. Natürlich gibt es eine Witsel. Soberness. Soberness. Also Serverless, muss man auch mal durchdringen. Also Kubernetes Serverless zu bezeichnen, finde ich wahnsinnig. Das ist witzig, oder? Und wenn man dann das erste Mal in Kubernetes deployen möchte in Azure, lernt man, dass man eine virtuelle Maschine und eine

virtuelle Cluster anlegen muss. Also wirklich Serverless. All right. Aber ich finde tatsächlich die Virtualisierung von Dienst. Und das ist das, was wir jetzt dann schlussendlich unter Saas verstehen. Als Angebot, als Offering, wo ich mich wenig kümmern muss, finde ich mega gut. Also CardDevBox, wenn auch ich gleich nicht der besondere Fan bin von diesem Thema, weil auch hier an der Stelle, wenn man sich die Dokumentationen zu genüge führt, dann ist das Kriegibundi. Und dann lernst du aber ganz schnell, dass du dahinter noch ein Intune konfigurieren musst. Das ist ein Active Directory Primo, man muss dann so weiter sofort. Also es ist noch vornehin ein Job-Abaustellen. Genau. Und mir ist es bis jetzt noch nicht gelungen. Also ich war in der Preview unterwegs, ein Devbots richtig aufzubauen, so dass es funktioniert hat. 00:40:36.679 --> 00:40:47.000 Weil das ist ja sehr ähnlich beim Windows 365, was ganz oft ja gezeigt wird als für Einzelbenutzer. Ja, das ist super easy. Das ist halt ein Desktop, so kannst du benutzen. 00:40:47.320 --> 00:40:59.400 Wenn du aber das Windows 365 für Enterprise nimmst und dann mal guckst, was dahinter, wo du dann eine Express-Route brauchst und Routing-Regel und vielleicht wieder eine Firewall und einen Domain-Controller, dann wird es dann plötzlich nämlich auch wieder deutlich komplexer. 00:40:59.400 --> 00:41:17.960 Aber gut, auf der anderen Seite, das ist ja das, wo wir herkommen. Ja, genau. Also darf man auch nicht vergessen, wir sind eben nicht im Greenfield, sondern gibt halt eine bestehende Enterprise-Infrastruktur und dann muss ich irgendwie rein. Und das ist ja für mich persönlich, dass ich ein Microsoft Fanboy bin, das weiß man. Ich trage gerade eine Microsoft-Jacke, aber das finde ich jetzt nicht. 00:41:19.559 --> 00:41:35.880 Kann ich jetzt nicht leugnen. Aber das ist ja das, was eine Microsoft eben ausmacht. Die ganzen anderen, der Amazon hatte keine Bestandskunden. Die sind reingekommen und haben gesagt, oh, fancy, fancy, wir machen Web Services für Start-ups. So, weil die mussten niemanden bedienen. 00:41:36.519 --> 00:41:44.199 Eine Google kam, oh, wir sind ein Data-Unternehmen, wir können total toll Cloud machen. Also die kamen sehr spät, weil sie es ein bisschen verpennt haben, aber sie kamen irgendwann. 00:41:45.000 --> 00:43:01.079 So eine Microsoft kam ja schon immer von dem Punkt, damn, wir haben da draußen Windows Server, SQL Server, Bistock Server, Dynamics, Navig, all diese Schrutz. Und das wollen die Kunden ja weiter benutzen. Also war eine der Kernpunkte Integration. Ja, und das machen sie heute aus meiner Sicht immer noch viel, viel, viel besser als die anderen, weil sie eben ja Kernfokus ist. Ich muss den Bestand, die Windows Clients, das Office und so weiter, das muss zusammenpasst, muss konvenient sein. Und deswegen ist tatsächlich mittlerweile dieses ganze Hybrid-Thema auch ein großes Thema, weil es gibt Workloads, die gehören nicht in die Cloud. Auch das ist was, was man Kunden übrigens als Cloud Platinum immer wieder mal beibringen muss. 100 Prozent Cloud ist Blödsinn. Wenn du irgendwie deine OT in die Cloud verlagerst, wo du, was ist ich, deine, bei meinem Glaswerk, da werden die Flaschen ja gescanned auf dem letzten Meter, dass da nicht irgendwelche Einschlüsse und so sind. Man, dieses Scansystem packst du doch nicht in die Cloud. Das wäre ja dumm. Ja, also du kannst die Daten, die Langzeitdaten und wo kannst du in die Cloud packen. Aber die Processing Unit, die will ich daran gerät haben. So, und solche Geschichten haben wir aber tatsächlich erlebt. Wo Kunden da meinen, dann schmeißen wir mal alles, was OT ist in Richtung Cloud. Ich sage, don't do it. PD unter uns, die nie wissen, was OT ist. 00:43:01.639 --> 00:44:30.760 Ja, tschuldigung, also wir haben angefangen mit IoT, Internet of Things und jetzt spricht man ja IT, ist Informationstechnologie. Also das ist alles das, was irgendwie so dieses klasse, kleinen Server-Infrastruktur angeht und OT, die Operational IT quasi, also alles, was ich für den Betrieb meines Produktionsprozesses quasi. Ja, genau, ganz oft in den frühen Anlagen. Genau, genau. Nee, und solche Workloads, wenn ich natürlich On-Fam haben, also an der Edge, ja, das passen wir da noch drin. Ich möchte nicht die Daten erst nach in die Cloud schieben, selbst mit einer Express-Route sind wir beide uns einig, dass die Latentsen so groß sind, um Echtzeitentscheidung, die diese Kundenbeweis irgendwie zu arbeiten. Ja, genau. Auf die lange Zeit bin ich natürlich diese Daten haben und dann habe ich einen... Ich wollte sagen, das macht ja da durchaus Sinn, zu sagen, also ich mache das Processing an der Maschine und dann schiebe ich die Langzeitdaten in die Cloud, um dort Analysen zu machen, Machine Learning Modelle zu trainieren, damit ich Predictive Maintenance machen kann, weil das Analysiere ich natürlich an der Maschine vor Ort nicht, ob jetzt der Durchsatz pro Sekunde singt über die Zeit, weil sich was für sich das Laufband abnutzt. Ja. Weil das kann ich über eine Time Series viel, viel besser in der Cloud machen, weil dort dann auch die Speicherkosten geringer sind und so weiter und so fort, weil muss auch die Hardware in der OT selbst auch nicht die billigste, je nachdem, wo du auch unterwegs bist. Ja, ja. In der Klinik IT zum Beispiel ist das ein Riesenthema mit... Das ist verrückt. Ja, also was die an Sterilisers, der Sterilisers ist für uns das falsche Wort an der Stelle, dass sie steril sein müssen und keinen Staub aufwirbeln und was weiß ich, was alles. 00:44:30.760 --> 00:46:07.000 Aber die wird nicht... Viele Geräte dürfen keine Luft da haben? Ja. Oder brauchen wir einen extremen Filtervorbau davor? Also das willst du halt nicht für ein Datenspeicher, dann hax du halt in die Cloud. Aber das ist... Also ich glaube da so ein bisschen so das Mittelmaß zu finden und zu sagen, okay, was ist einfach logisch lokal zu halten, was ist aber absolut logisch in die Cloud zu packen, weil es lokal überhaupt

keine Abhängigkeit gibt. Und deswegen ist eine der wichtigen Fragen in diesem ganzen Kontext immer, wie wird's denn genutzt? Ja. Also wenn ich sage, ich habe irgendwie eine Mobile Workforce, wie man das ja heute so schön nennt, also ich hab halt, was ist ich, Außendienstler, die an der Baumaschine draußen auf der Baustelle irgendwas konfigurieren. Wozu soll ich das per VPN im Rechenzentrum... Ist ja Quatsch, mal die greifen übers Internet zu. Ist ja egal wohin. Ja. Und dann nehme ich da lieber einen skalierfähigen Service, der an der Lage ist, wenn die Leute arbeiten an der Maschine, auch zu skalieren. Und wenn sie nicht dran arbeiten, runter zu skalieren. Also plötzlich habe ich ein Cloud Case, plötzlich funktioniert das. Wenn ich aber sage, ich habe, weil ich nicht 300 Leute, die sitzen in einem Büro Gebäude, die arbeiten miteinander am gleichen Dokument. Und diese Dokumente sind aber, weil es ein Architekturbüro ist, zig Gigabytes groß. Ja, dann macht es durchaus auch mal Sinn, die Daten noch in der Lokation zu belassen. Ja, ja. Und nicht, oder Videoschnitt, das ist auch so ein großes Thema. Videoschnitt über die Cloud geht mittlerweile auch. Da gibt es ja auch ganz fancy Technologien dafür, aber wir haben es zum gewissen Grad, da gibt es auch Sinn. Genau, Card Engineering ist auch ein Thema. Also bestimmte Workloads einfach nahe am Benutzer zu lassen, macht halt immer noch Sinn. 00:46:07.000 --> 00:46:19.800 Oder die Entscheidung zu treffen, alles da, weil also in die Cloud, weil so eine Mischbetrieb zwischen Cloud und Lokal ist, an der Stelle, ihr kannst machen, aber es ist dann ein Scheiß. 00:46:19.800 --> 00:46:28.039 Ja, genau. Also mir fällt jetzt nichts, irgendwie hast du noch mal so ein Turnover, was so richtig so. 00:46:28.039 --> 00:47:01.960 Turnover. Ich glaube, das Anfangsthema nochmal aufzukreifen, also Cloud Readiness, oder wie sage ich, wird es fast, wie ich sage nochmal, mit diesem Thema Cloud Maturity, weil Ready eben sauschwer ist, aber das kann ich einfach jedem nur mitgeben. Es gibt ein sogenanntes Cloud Maturity Framework von der Open Cloud Foundation Native Something. Einfach mal danach suchen. Und da gibt es so ein paar Messkriterien, die dann wirklich sagen, also wie weit bin ich in meiner Cloud Journey. Auch wieder, das ist ein Framework, bitte nicht zu wörtlich nehmen, aber sich mal damit beschäftigen. 00:47:01.960 --> 00:47:07.639 Im Zweifel einen guten Konsultant anrufen, ich kenne da einen, der kann ihn da auch beraten. 00:47:07.639 --> 00:48:56.679 Also einfach wirklich mal sich damit beschäftigen und zu sagen, okay, habe ich vielleicht irgendetwas ausgelassen, weil das ist eigentlich die große Hürde. Also wenn wir machen irgendwie ganz, ganz viel und bauen die richtigen Tools und vielleicht stellen wir so ein Prozesse um und so weiter und so fort, dann vergessen wir aber, dass wir die Leute auch irgendwie trainieren und schulen müssen. Vielleicht nochmal so ein typisches Beispiel, was mir wirklich immer wieder begegnet. Oder genau End-User mitnehmen. Also so Key-User oder Stakeholder einbeziehen, vergisst man einfach und dann plötzlich hast du irgendwo den Blocker im Raum stehen. Also das kann ich einfach nur jedem empfehlen, in diesem Gesamtkontext, egal wie gut oder schlecht ihr euch gerade fühlt mit eurer Cloud-Transformation oder hat vielleicht auch noch gar nicht angefangen oder ihr glaubt ihr habt sie schon hinter euch, einfach mal zu betrachten, okay, mit so einem Standard-Framework, wo stehe ich eigentlich? Mach mal die Checklist. Wo will ich eigentlich hin? Das öffnet einem ganz oft die Augen und dann denkt man sich so, oh guck, jetzt machen wir drüber nachdenken können. Also wenn man das so zusammenfassen will, dann ist es ja eigentlich, dass wir sagen können, sind unsere Unternehmen Cloud-Ready. In der Readiness werden wir nicht finden. Es gibt die Cloud-Maturity und Cloud-Maturity ist aber immer noch in vielen Unternehmen ein Ding, wo man sich hinarbeiten kann aus dem Fall. Und damit möchte ich mich ganz, ganz herzlich bei dir bedanken, dass du Gast warst in meinem Podcast und allen Links über Themen, die vielleicht interessant sind, die werdet ihr in der Beschreibung finden von dem Podcast und freue mich schon auf die nächste Folge mit dir. Vielleicht mal in den Gekehrt und wir gehen in deinen Podcast rein. Sehr gern. What's up everyone? Auf jeden Fall haben wir jetzt an der Stelle hoffentlich bald einen Uber, mit dem wir zum Flug haben. Genau, guten Flug und wir sehen uns bald. Das wünsche ich dir auch. Vielen Dank. Ciao ciao. Ciao ciao.