Cloud Migrationsstrategien

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und ich habe mir einen lieben Kollegen eingeladen und zwar Kofi Jedamzik. Hallo Kofi.

Kofi Jedamzik: Hi.

Anja Kammer: Hallo. Wir werden sprechen über Cloud Migration, vor allem über Cloud Migrationsstrategien, ähm also die 6R Strategien und auch so ein bisschen über unsere Erfahrungen in der Praxis sprechen. Ja, warum reden wir eigentlich über dieses Thema? Kofi, erzähl doch mal, was hast du denn für Erfahrungen bei dem Thema?

Kofi Jedamzik: Ähm ja, also auch erstmal von mir ein Hallo. Ich bin Kofi Jedamzik, Senior Consultant bei INNOQ, ähm inzwischen seit 12 Jahren. Und ich beschäftige mich hauptsächlich mit dem Betrieb von Software. Genau, also wir äh ja, helfen halt Kunden dabei, ihre Workload in die Cloud zu transferieren. Und äh ja, unter anderem äh machen wir auch Workshops dazu. Genau. Ähm.

Anja Kammer: Ja. Also, genau, wir machen Workshops dazu, z.B. den ISAQB Cloud Infra Workshop bzw. auch das Training vom ISAQB. Also Cloud Infra bedeutet im Grunde Cloud Infrastruktur und Container. Da besprechen wir mit den Teilnehmenden nicht nur Cloud Migrationsstrategien, sondern auch generell die Technik hinter den ähm hinter den Cloud Provider Services und wie man sie verwendet, ähm und welche Architekturmuster es so gibt, die man nutzen kann.

Kofi Jedamzik: Genau.

Anja Kammer: Genau. Und ansonsten ähm führe ich auch ähm strategische Cloud Workshops durch, auch in Unternehmen, die sozusagen gerne eine Cloud Strategie erarbeiten möchten oder eine haben, aber trotzdem noch nicht so ganz wissen, wie sie dann da jetzt damit anfangen sollen. Und daran merkt man halt auch, was die typischen Probleme sind, ähm in Unternehmen, die in die Cloud wollen, ne? Also die fangen dann äh an zu überlegen, okay, wir wollen in die Cloud aus bestimmten Gründen und ähm wissen dann trotzdem nicht weiter. Und dafür sind eben diese Cloud Migrationsstrategien da. Also, was sind so die die typischen, was sind so die typischen Gründe, weshalb Unternehmen in die Cloud wollen? Zum Beispiel ähm den letzten Kunden, den ich beraten habe in der Hinsicht, der wollte sozusagen in die Internationalisierung. Das heißt, der wollte internationale Märkte erschließen und sie haben ein eigenes Rechenzentrum gehabt, ne, also On-Premise und dachten sich, na ja gut, aber in China oder in Australien kann ich nicht auch noch mal irgendwie ein Rechenzentrum aufbauen, ähm das wäre viel zu viel, also wie zu viel zu viel Aufwand. Man müsste ähm das Rechenzentrum mieten, Dienstleister innen ähm beauftragen und das war ein wenig zu kompliziert im Ausland und deswegen hat man sich dafür entschieden, okay, nehmen wir dann einfach die Cloud nur für sozusagen diese internationalen Märkte, bleiben in Deutschland bzw. in Europa On-Premise. Und ja, damit können sie eben die ihre Latenz gering halten, dadurch, dass sie sozusagen genau in der Region dann ihren ihre Software betreiben und äh haben da die Möglichkeit trotzdem ihre Software eben zu betreiben, obwohl sie dort äh kein Betriebspersonal haben.

Kofi Jedamzik: Genau, gerade Latenz ist halt ähm ja, ein wichtiger Punkt. Das ist etwas, was man häufig optimieren möchte. Ähm da gibt’s ja diverse Untersuchungen zu, dass die Conversion sinkt, je länger die Kunden eben warten müssen. Und ähm ja, besonders wo du sagst China, das äh da gibt’s eben auch noch eine große Firewall, die zur Latenz beiträgt, äh da möchte man auf jeden Fall äh auf dem Festland äh ja, seine Workload betreiben.

Anja Kammer: Genau, da hast du ja ähm Praxiserfahrung damit, ne? Du musstest auf einmal eine Internationalisierung durchführen, auch mit China.

Kofi Jedamzik: Genau, da hat ein Kunde ähm sein Produkt nach China gebracht und ja, die sollen da eben auch äh ja, möglichst schnelle Verbindungs ähm möglichst schnelle Verbindung haben und da war das eben auch gefragt, genau.

Anja Kammer: Genau, was gibt’s für andere Gründe in die Cloud zu wollen? Ähm z.B. dass es in der Cloud oftmals neueste Technologien zur Verfügung stehen, die ähm Entwicklungsteams halt gerne nutzen wollen und vielleicht auch sehr sehr viele unterschiedliche Technologien nutzen wollen, wo so ein Betriebsteam, welches beispielsweise On-Premise ist, das alles selbst aufbauen muss, sehr schnell überfordert ist, ne? Je nachdem, wie groß das Betriebsteam ist, aber es ist meistens so, dass das Betriebsteam weniger People Power hat, als man braucht. Und deswegen ist es halt auch oftmals das Problem, hey, wir wir schaffen diese Anforderungen der Entwicklungsteams nicht mehr zu schaffen, also wir schaffen das nicht mehr, lasst uns doch einfach in die Cloud gehen, damit irgendwie die neuesten Technologien in der Cloud eben innerhalb von Minuten installiert werden können, statt eben, also statt, dass sie mehrere Wochen bis Monate brauchen. Und das ist tatsächlich so, ne? Also, wenn eine neue bestimmte Datenbank, äh die sozusagen bisher noch nie betrieben wurde, ähm angefordert wird, dann dauert das mehrere Monate und dann äh dauert es aber wieder mehrere Wochen, diese dann auch noch zu updaten, äh neueste neueste Versionen und Patches einzuspielen, mal von dem Betrieb abgesehen.

Kofi Jedamzik: Genau, auch ähm Stichwort Self-Service äh bzw. ähm ja, wir bauen dort komplette Plattformen, so dass die Teams sich ihre Infrastruktur selbst ähm ja, konfigurieren, provisionieren können, ohne dass sie eben äh da Ticket Pingpong mit dem eigenen Betrieb spielen müssen. Das geht oftmals eben viel schneller.

Anja Kammer: Mhm.

Kofi Jedamzik: Mhm.

Anja Kammer: Und noch ein Grund in die Cloud zu gehen, vor allem für Startups ist es einfach, weil es eine sehr schnelle Art und Weise ist, ähm ihre Produkte zu launchen oder wenn man sozusagen ein oder ja, genau, also oder wenn man ein Produkt schon in einem größeren Unternehmen sozusagen launchen möchte, was aber eher so eher ein Experiment ist, dann kann man auch erstmal in die Cloud gehen, um um schnell sozusagen Feedback einzuholen, anstatt in dem Unternehmen erst einmal Betriebsressourcen zu beantragen, wo man noch gar nicht weiß, ob man da wirklich irgendwie langfristig das Ganze die ganzen Ressourcen braucht oder betreiben möchte. So kann man in der Cloud schneller ja, schneller Experimente verifizieren.

Kofi Jedamzik: Genau, also häufig ähm gerade wenn auch irgendwas mit Fernsehwerbung involviert ist, äh stellen Startups halt fest, dass die Ressourcen da gar nicht für ausreichen und dann kann man eben, wenn man in der Cloud äh unterwegs ist, da sehr schnell ähm ja, sehr viele Ressourcen bereitstellen und die eben auch sehr schnell wieder dekommissionieren, ohne dass man da ähm ja, langfristig große äh Kosten äh produziert.

Anja Kammer: Mhm. Mir fällt mir fallen auch die kostenfreien Quotas ein. Also es gibt so bestimmte bestimmte Ressourcen, die kostenfrei sind äh bei Cloud Providern. Man zahlt halt meistens nur für den Traffic oder das sind die höchsten Kosten und die Betriebskosten sind normalerweise sehr gering, wenn man auch nur geringe geringe Anforderungen hat wirklich. Äh da kann sich wirklich sehr kostengünstig, kann man dort sozusagen die Experimente auch laufen lassen, also bis zu

Kofi Jedamzik: Ich nenne das äh Lockangebote, genau.

Anja Kammer: Lockangebote, ja. Aber die sind wirklich sehr gut, muss man sagen. Wir nutzen wir auch für für interne Anwendungen, die wirklich nur kurze Zeit laufen müssen, auch sehr gerne.

Kofi Jedamzik: Mhm.

Anja Kammer: Genau. Ähm welche Probleme haben denn Unternehmen während der Cloud Migration? Äh da haben wir uns schon Gedanken drüber gemacht. Also oftmals ist es, dass der Zeitplan gesprengt wird, äh oder die Kosten oder sogar beides, ne? Das hat verschiedene Gründe. Beispielsweise es geht ewig nicht los. Unternehmen planen immer, ja, wir wollen in die Cloud, aber sie kommen nicht wirklich über die Planungsphase hinaus, vielleicht weil weil dort Angst existiert, ne? Das ist meistens genau die Phase, in der ähm in der ich und Kofi dann gerufen werden, hey, helft uns mal, wir wissen nicht, wie wir jetzt anfangen sollen. Und dann kommen wir beispielsweise eben mit diesen Art von Migrationsstrategien, über die wir ja jetzt heute sprechen wollen und fangen dann an, ähm zu analysieren, okay, wo fangen wir denn überhaupt an, ähm mit welchen Applikationen, äh machen wir schon mal eine Pilotphase und so weiter. Und dann hat man einen Schritt für Schritt Migrationsplan und oftmals fehlt das in Unternehmen, ne? Dass sie es nicht schaffen, irgendwie diesen diesen Migrationsplan, diesen diesen Schrittweisen Plan aufzustellen, um ihn dann zu gehen. Manchmal passiert es.

Kofi Jedamzik: Genau. Ja. Also ähm häufig wird eben äh mehr oder weniger alles auf einmal äh migriert oder die Ziele werden ein bisschen zu hoch gesteckt, dass man, obwohl es da diverse Legacy Anwendungen gibt, die sollen dann halt direkt auch äh containerisiert werden und quasi direkt auf den neuesten Stand der Technik gebracht werden und das ist ähm ja, oft nicht die sinnvollste Reihenfolge.

Anja Kammer: Ich sag mal so, Containerisieren an sich ähm halte ich gar nicht mal für so schlimm, also grundsätzlich ähm ist sind Container halt genau die ist genau die also das Artefakt, was sozusagen in jeder Cloud immer läuft und was irgendwie ein gutes Austauschformat ist und so weiter. Wo ich mich daran störe ist, wenn man gleich sozusagen alle Applikationen Cloud Native machen möchte, man möchte gleich in Microservices zerteilen und in Lambdas und man fängt sofort mit allen Applikationen an. Das da wird man nicht fertig. Natürlich wird da der Zeit und Kostenrahmen komplett gesprengt. Man man will viel zu perfekt sein für etwas, wofür man bestimmt auch Rahmenbedingungen hat. Also es ist selten so, dass man unendlich Zeit und unendlich Geld zur Verfügung hat, aber wenn man glaubt, man hätte so, ne, also wenn man glaubt, man hätte unendlich Zeit und unendlich Geld, dann kann man natürlich diese diese Route gehen und sehr perfektionistisch anfangen, alles erstmal zu verkleinern und Cloud Native zu machen. Und man sagt zwar, Ja, in der Cloud sollten Cloud Native Applikationen laufen, aber sollten heißt nicht müssen. Es funktioniert auch mit Legacy Applikationen, die gerade mal in den Container gepresst wurden. Es funktioniert, ist nur teurer.

Kofi Jedamzik: Genau, das meinte ich eben, diese Legacy Applikationen, die vielleicht noch irgendwelche Host basierten Technologien voraussetzen. Ähm natürlich kann ich da jetzt super viel Aufwand reinstecken, die zu containerisieren und wir wollen ja auch in einem Container immer nur einen Prozess haben. Das sind meistens Konzepte, da äh gibt’s ähm ja, wie soll ich sagen, Konflikte oder ist nicht so ganz so einfach zu erreichen und ja, da kann man äh vielleicht auch einfach eine VM daneben stellen und erstmal damit leben, dass äh diese App dann eben noch nicht ähm perfekt Cloud Native ist.

Anja Kammer: Mhm. Okay.

Kofi Jedamzik: Mhm.

Anja Kammer: Dann lass uns doch mal reinstarten in die Migrationsstrategien und es gibt so eine kleine Historie in der Migrationsstrategien, äh die wir besprechen wollen, die 6R Migrationsstrategien. Es gibt auch die 5R, es gibt auch die 7R. Ähm fangen wir mal mit den mit den 5R an und zwar äh gibt es die tatsächlich schon seit 2010 und wir aber wir wissen seit 2010 hat ja erst diese ganze Cloud Geschichte angefangen, ne? Also, wann hat AWS angefangen äh AWS Cloud Services ähm zu veröffentlichen? Das war doch auch 2010, oder?

Kofi Jedamzik: Äh ich weiß nicht ganz genau, ich kannte die auch erst äh also ich kenne die noch nicht so lange, ähm diese 6 5 6 7 R Strategien, genau, erst seitdem wir das auch in unseren Schulungen äh drin haben. Wir haben das vorher schon gemacht, äh aber ähm seit dieser seit diesen äh XRs, sage ich mal, äh hat es alles einen Namen bekommen und ist so ein bisschen formalisiert und hilft so ein bisschen äh ja, darüber zu sprechen über die unterschiedlichen Ansätze, genau.

Anja Kammer: Ja, also 2010 hat es schon angefangen, wo halt die Cloud sich erst sozusagen etabliert hat oder erst sozusagen neu dazu gekommen ist ins Game ähm durch AWS Cloud Services und zwar gibt es diese oder haben diese 5Rs aufgestellt Leute bei Gartner. Und zwar 5Rs bedeutet im Grunde fünf Worte, die alle mit R beginnen und das sind alles Migrationsstrategien. Ähm Rehost, Refactor, Revise, Rebuild und Replace. Das sind also Strategien, um in die Cloud zu gehen und man muss für jede Applikation, für jede Komponente entscheiden, sozusagen, welche Strategie man gerne fahren möchte oder welche sinnvoll ist zu fahren, denn das Gesamtsystem hat nicht nur eine komplette Strategie, sondern jede Komponente muss einzeln betrachtet werden, ähm äh welche Strategie dort funktioniert. Also, welche Komponenten sollten refactored werden, welche sollten neu gebaut werden, welche sollten ähm komplett ähm durch andere Produkte ersetzt werden.

Kofi Jedamzik: In den Ruhestand geschickt werden, genau.

Anja Kammer: Genau, die Sache mit dem Ruhestand kam tatsächlich erst später durch AWS, die haben sich diese 5R Strategien von Gartner angeguckt und haben gesagt, da fehlt uns das in den Ruhestand versetzen, denn wenn man so eine Legacy Applikation oder System hat, dann gibt es Komponenten, die braucht man in der Cloud gar nicht. Und die kann man dann gleich abschalten, ne? Was sind das für Sachen, sowas wie selbstgebaute Service Discovery, selbstgebaute Monitoring Systeme z.B.. Ähm das braucht man in der Cloud nicht, weil das sozusagen schon von der Plattform übernommen wird. Ja.

Kofi Jedamzik: Ja. Oder das sind einfach Services, die brauchte man mal, aber man stellt eben jetzt im Rahmen dieser Migration fest, oh, der wird eigentlich gar nicht mehr benötigt.

Anja Kammer: Äh schon seit drei Jahren nicht mehr benötigt.

Kofi Jedamzik: Ja, das äh auch das passiert, genau.

Anja Kammer: Mhm, genau. Äh das passiert vor allem, weil man ja erstmal analysieren muss, okay, wie sieht das System aus, welche Services gibt es und dann fällt halt mal auf, okay, da gibt’s Services, die werden gar nicht mehr verwendet, die können auch gleich abschalten. Ist auch eigentlich ganz gut. Ähm mal so ein Check-up zu machen regelmäßig. Gut, ich bin eigentlich mit den 6R schon zufrieden, ähm wir haben sozusagen Retire dazu bekommen, Dinge, die abgeschalten werden sollten und dann hat sich AWS aber überlegt 2021, hey, wir haben da so ein neues Produkt und das wollen wir bewerben, machen wir doch einfach ein weiteres R dran. Weil die ähm die 6R Migrationsstrategien ja so gut ankommen und zwar ist es Relocate und da geht es im Grunde einfach um eine Migration einer Plattform von On Premise in in die Cloud, ohne aber wirklich die Plattform zu verändern. Das ist einfach eine von einer On Premise Version auf eine Cloud Version, beispielsweise Kubernetes On Premise hatte man vorher genutzt und Relocate ist im Grunde der Shift in Kubernetes in die Cloud.

Kofi Jedamzik: Genau.

Anja Kammer: Hört sich jetzt erstmal valide an, aber ähm der Grund war, dass sie ein bestimmtes Produkt verkaufen wollten und zwar ähm VMware den VMware Hypervisor für die Cloud.

Kofi Jedamzik: Genau, also die konnten das, glaube ich, schon äh länger, ne, dass man dann quasi im laufenden Betrieb eine VM von einem Host auf den anderen verschiebt und jetzt haben sie halt als Target die Cloud da hinzugefügt, ähm genau, ein bisschen Marketing Schnickschnack. Ähm ja, vielleicht wieder relevant, wenn wir über Kubernetes sprechen, weil das im Grunde genommen das gleiche ist, äh wenn ich dann meine Workload erstmal auf Kubernetes migriert habe, dann ist es relativ einfach, die eben auf dem anderes Kubernetes zu bringen. Ähm genau.

Anja Kammer: Mhm. Ja, gut, dann lass uns doch mal über diese 6R Strategien sprechen. Wir ignorieren jetzt mal die 7, obwohl wir können wir können noch mal kurz über die 7 sprechen, aber der Fokus ist, denke ich, die 6R. Ähm fangen wir doch mal mit Retain an, ne? Also die erste Strategie, die man für eine Komponente eines Systems fahren könnte. Retain bedeutet einfach Teile des Systems oder Komponenten bleiben einfach On Premise.

Kofi Jedamzik: Genau. Ähm nicht selten findet man dann solche Dinge wie äh der Dienst, wo die wo der Login stattfindet und Userdaten dran sind, das wird halt bei vielen irgendwie noch so ein bisschen ähm ja, als wichtiger angesehen und das kann dann vielleicht bei einem äh lokalen Dienst bleiben, äh weil man glaubt, der wird dann vielleicht lokal ähm oder im eigenen äh auf dem eigenen Blech etwas besser geschützt, z.B.. Ähm genau, das kann man eben auch mischen.

Anja Kammer: Ja. Genau, ich habe das bisher auch nur für Applikationen gesehen, die sozusagen äh hohe Datenschutzanforderungen haben, wie du gerade gesagt hast, oder Dinge, die einfach zu teuer wären in die Cloud zu migrieren, ne? Also, wo der Aufwand und die Kosten viel zu hoch wären und der Nutzen viel zu gering in die Cloud zu gehen. Ähm also, wenn ich keinen Nutzen habe, um ein System in die Cloud zu packen, dann würde ich es auch nicht tun, ne? Also, wenn ich jetzt keine äh keine keine Latenz Anforderung da habe oder wenn die Latenz jetzt nicht so schlimm ist, ich würde immer ein System, welches schon sehr gut läuft, da lassen, wo es ist, anstatt es in die Cloud zu heben, nur weil man das so tut. Ich würde niemals Dinge tun, nur weil man es so tut, sondern nur zu einem bestimmten Vorteil. Wir müssen also wirklich analysieren, zu welchem Vorteil migriere ich etwas? Gibt es einen Vorteil? Lohnt sich das? Ob es jetzt nun

Kofi Jedamzik: Genau.

Anja Kammer: Ja, was für Vorteile können das sein? Ähm die Einfachheit es zu benutzen, die Einfachheit es zu maintainen oder auch Kostenersparnis, obwohl Kostenersparnis in der Cloud oftmals kein Faktor ist.

Kofi Jedamzik: Mhm. Naja, vielleicht hat man noch andere Pläne für diesen Dienst und äh die können noch nicht umgesetzt werden und dann entscheidet man sich eben, den erstmal da zu lassen, wo er ist.

Anja Kammer: Genau, das bedeutet, ähm wenn ich diese Strategie des Retain fahre, heißt das nicht, dass ich das für immer On Premise lasse, sondern ich kann immer wieder neu evaluieren. Haben sich jetzt die Rahmenbedingungen geändert, äh lohnt es sich jetzt sozusagen eine andere Strategie zu fahren? Ja. Ist z.B. eine Lizenz abgelaufen und es lohnt sich jetzt sozusagen zu migrieren. Ähm genau. Haben wir noch andere Beispiele, sonst gehe ich zum nächsten Thema, zum nächsten R über. Retain. Ich glaube, das war’s, oder?

Kofi Jedamzik: Ja, ich glaube schon.

Anja Kammer: Gut, Retire. Retire hatten wir schon erwähnt, ähm das machte die 5R zu zu den 6R. AWS hatte sozusagen Retire hinzugefügt und das hatten wir schon besprochen, ne? Also Dinge, die schon in der Cloud vorhanden sind, muss ich nicht umziehen oder Dinge, die mir aufgefallen sind, die eh nicht verwendet werden, muss ich nicht umziehen. Mhm.

Kofi Jedamzik: Genau. Also gute Beispiele dafür sind äh hattest du, glaube ich, schon erwähnt, ne, so ein Monitoring Dienst, den ich irgendwie lokal oder oder irgendwie selbst betreibe. Die meisten Cloud Anbieter kommen eben bereits mit einer eigenen Lösung einher. Ähm ja, das muss man dann nicht noch mal das Rad neu erfinden.

Anja Kammer: Ja, das sind vor allem aus der Praxis sehe ich das, das sind auch vor allem Applikationen, die ähm für diese On Premise Plattform notwendig waren. Deployment ähm Systeme oder Monitoring Systeme, die aber in der Cloud total obsolet sind, weil äh das eine komplett andere Plattform ist, was halt überhaupt nicht übersetzt werden kann, ne? Also, das.

Kofi Jedamzik: Mhm.

Anja Kammer: Genau, weil die sozusagen selbst schon mit ihren Deployment Mechanismen kommen, die komplett anders sind oder ähm du musst dann nicht jeden Host selbst überwachen, wenn du dann eigentlich eher Serverless Applikation bzw. Serverless Plattform nutzt, dann dann dann bringt dir das Monitoring System nicht, mal davon abgesehen, dass du es nicht selber schreiben solltest zum Monitoring System.

Kofi Jedamzik: Mhm.

Anja Kammer: Das nächste R ist Rehost und das kennen, glaube ich, viele auch bekannt unter dem Namen Lift and Shift. Hat aber einen schlechten Ruf, finde ich gar nicht so gut.

Kofi Jedamzik: Genau, also das klassische Lift and Shift ist, ähm wir ändern sehr wenig oder gar nichts äh. eigentlich an dem an dem Prozess und verschieben das einfach, also üblicherweise einfache VMs. Äh die wir dann äh ja, einfach rüberschieben.

Anja Kammer: Mhm. Genau, warum finde ich das nicht so gut, dass es einen schlechten Ruf hat, weil das eine sehr schnelle Art und Weise ist in die Cloud zu gehen, wenn man wenn man ähm wenn die Constraints so gebaut sind, dass man sehr wenig Zeit hat für die Migration, ist das die beste Alternative schnell sozusagen schon mal Meter zu machen und wenn man dann erst sozusagen in der Cloud ist, dann kann man sich dann nach und nach Zeit nehmen für jede Komponente, für jede Applikation noch mal grundsätzlich zu entscheiden, vielleicht sich noch mal umzuentscheiden, ähm wollen wir das jetzt refactoren, was machen wir jetzt mit dieser Komponente, bleibt die bleibt die sozusagen virtualisiert oder nicht, denn man muss auch dazu sagen, dass wenn man einfach eine wie wenn man einfach eine VM umzieht, dann ist es so, dass der Betrieb on Premises viel viel günstiger ist, als in der Cloud eine VM zu betreiben. Das wird mit der Zeit sehr sehr viel teurer, ne? Also das macht man eigentlich nur, um sozusagen schnell in die Cloud zu kommen und dann sozusagen langsam zu entscheiden, okay, was machen wir jetzt, aber man sollte sich nicht zu viel Zeit lassen, weil das wirklich teuer ist. Die Cloud ist teurer als der On Premise Betrieb. Das war schon immer so. Ist aber wie gesagt, Rehost ist trotzdem eine sehr valide Alternative, um eben schnell zu sein. Man muss sich aber auch man muss sich aber auch bewusst sein, dass man dann viele Vorteile der Cloud gar nicht hat. So eine Sachen wie ähm Resilienzmechanismen.

Kofi Jedamzik: Dynamische Skalierung ist alles so ein bisschen schwieriger dann.

Anja Kammer: Genau, ja.

Kofi Jedamzik: Ähm genau, aber ja, man darf auch nicht vergessen, man muss sich ja auch ähm je nachdem, wer das macht, man muss sich erstmal mit dem Tooling auseinandersetzen. Ähm das sind alles so Dinge, die einen auch erstmal aufhalten und ähm genau, wie du sagst, man kann da erstmal schon eine Menge bewegen und dann nach und nach verbessern. Ähm ja, Firewall Regeln und all dieser Kram, das muss auch alles eingestellt werden und ja, wenn ich das erstmal einfach rüberschiebe, dann ähm genau, kann ich mich da später mit auseinandersetzen. Das ist je nachdem abhängig, was quasi gerade der Treiber ist, ne? Vielleicht habe ich äh da schon eine Deadline und mit Lift and Shift komme ich äh da gut vorwärts.

Anja Kammer: Mhm. Ja, das heißt nicht, dass man jetzt keine Firewall Einstellungen machen sollte, wenn man so Lift and Shift macht, das heißt nur, dass man sozusagen jetzt nicht sagt, okay, man man zerteilt diese Komponente noch mal in Microservices und hat dann sozusagen noch mal ein Wust von Konfiguration in einer sehr ungewohnten Umgebung, sondern ähm auch in in der Cloud Umgebung ist es so, wenn man VMs in die Cloud verschiebt, dann hat man auch noch eine eine recht ähm ähnliche Art und Weise diese VMs zu verwalten, wie man es on Premise gewohnt ist.

Kofi Jedamzik: Genau, es gibt halt viele neue Konzepte dabei, die muss man erstmal lernen, ähm also wie gesagt, je nachdem, wer das macht und wenn das neu ist, ähm und wenn wir erstmal bei diesem VM Konzept bleiben und das Host basiert ist, ähm ja, dann.

Anja Kammer: Ja, bleiben viele Konzepte eben nicht, ja.

Kofi Jedamzik: Ja, kann man sich dem erstmal nähern, ja.

Anja Kammer: Mhm. Das bedeutet auch, wenn ich keinen Vorteil darin sehe, auch hier, ne, wenn ich keinen Vorteil darin sehe, so eine VM zu verschieben, würde ich es auch nicht lassen, denn eine VM in der Cloud ist immer schlechter als eine VM on Premise meiner Meinung nach. Du hast sozusagen, du hast die Inflexibilität von diesem Legacy System oder dieser Legacy ähm Betriebsumgebung mit der Komplexität des Cloud Anbieters. Also es ist nie, es ist glaube ich also Rehost finde ich ist jetzt nie eine sehr gute Lösung, um jetzt in die Cloud zu gehen, es sei denn man hat so Anforderungen wie, das muss jetzt aber irgendwie in ein anderes Land und da hast du keine Rechenzentrum. Das ist irgendwie ein valider Punkt, aber ansonsten würde ich das nicht tun.

Kofi Jedamzik: Man muss es halt immer als man muss es mal das gesamte System im Auge behalten und vielleicht äh ist das eben nur eine Komponente davon und ich habe vielleicht noch äh Kubernetes Cluster daneben.

Anja Kammer: Na ja, und ich muss die Latenz minimieren.

Kofi Jedamzik: Das sieht auch schon genau, und das sieht auch schon eine Menge ähm Ressourcen, dann ja, ist für Umsysteme ein Lift and Shift manchmal eine gute Option.

Anja Kammer: Okay, ja.

Kofi Jedamzik: Ja.

Anja Kammer: Okay.

Kofi Jedamzik: Genau.

Anja Kammer: Dann kommen wir zum nächsten R, Replatform und zwar geht es darum, eine bestehende Anwendung leicht anzupassen, also es nennt man auch Lift Tinker and Shift, also dieses Tinker bedeutet, die Architektur im Grunde des Codes und der Applikation lasse ich erstmal so wie es ist, aber alles drumherum, also die Art zu deployen, das Deployment Artefakt, ähm das wird sozusagen an die Plattform angepasst, damit diese Applikation an der auf der neuen Plattform betriebsfähig ist, ne? Und wir reden jetzt nicht eben von von von dem VM Hypervisor, sondern wir reden hier schon beispielsweise über solche Plattformen ähm wie Kubernetes z.B. oder andere Container Manager.

Kofi Jedamzik: Genau, wird auch Lift and Reshape genannt.

Anja Kammer: Oder Reshape, ja.

Kofi Jedamzik: Ja, das ist einer der prädestinierten Änderungen in dem Bereich, also in der Cloud ist ja dieser Object Store oder S3 kompatible Storage ähm eigentlich äh ja, sehr verbreitet und das z.B. umzurüsten, äh dass wir Dinge jetzt statt auf einen FTP Server oder SCP, dass wir das auf einen S3 schieben, das ist so eine Änderung, die man sich da vorstellen kann oder dass wir eben ähm Container statt Warfiles äh deployen, ähm genau, also ohne jetzt riesen Änderungen herbeizuführen, schon äh Teile von diesem ähm von der Cloud Flexibilität äh nutzen können. Genau.

Anja Kammer: Genau, das heißt aber auch, dass ich mir Gedanken, also ja genau, dass ich mir trotzdem Gedanken machen muss, wie okay, wie logge ich denn auf dieser Plattform, ne? Habe ich vorher in in Dateien geloggt, dann muss ich jetzt auf Standard Out loggen. Ähm wie konfiguriere ich die Applikation? Also das sind schon Dinge, die eine Zeit brauchen, ist nicht so einfach wie ein Rehosting, das braucht schon Zeit und vor allem Know-how für die neue Plattform. Das ist also es kommt natürlich drauf an, aber das kann eine steile Lernkurve erst einmal sein, deswegen ist es gut, einfach mal einen Piloten herauszusuchen, ähm der es einem besonders einfach macht oder eben besonders schwer, um herauszufinden, wie schwer es sein kann, um eine Applikation sozusagen auf diese Plattform zu heben von Legacy on Premise auf genau diese Plattform. Das kann halt auch eine steile Lernkurve sein, vielleicht macht man das auch wieder schrittweise, ne? Zuerst ein Rehosting, dann ähm versucht man sozusagen dann ein Replatforming währenddessen dann durchzuführen, bis man es geschafft hat und die Applikation stabil auf der neuen Plattform läuft.

Kofi Jedamzik: Mhm.

Anja Kammer: Und dann kann man auch schon ähm sozusagen bessere Skalierungsmechanismen nutzen, als sie sozusagen für VMs in der Plattform äh als sie als für VMs in der Cloud Plattform möglich sind mit Containern. Ähm ja, man kann viel mehr ähm drumherum nutzen, beispielsweise sowas wie Service Meshes oder ähnliches. Sobald meine Applikation in Containern läuft und und sozusagen dort auch stabil läuft, kann ich sozusagen all diese Services, die die Cloud mir bietet, sozusagen daran flanschen, was vorher vielleicht beim VM Betrieb eher schwieriger zu integrieren war.

Kofi Jedamzik: Genau, da gibt’s eben so einige Querschnittliche ähm ja, Querschnittliche äh oder wir sagen so nicht funktionale Anforderungen, die ich dann eben komplett auf die Plattform auslagern kann und Service Meshes finde ich ist ein sehr gutes Beispiel, weil jeder, der schon mal MTLS von Hand ähm bereitgestellt hat, ne, mit diesen ganzen Zertifikaten, die erstmal generiert werden wollen und regelmäßig getauscht werden, das macht alles so ein bisschen fehleranfällig und ja, mit so einem Service Mesh kann ich das komplett automatisieren. Ähm genau, da gibt’s einige Vorteile, Logging z.B. auch, dass das ähm dass ich eben alle Container nur noch äh auf Standard Out loggen und ich habe Plattform drumherum, die das entsprechend abgreift und zentral äh irgendwo indexiert. Ja.

Anja Kammer: Mhm.

Kofi Jedamzik: Verschiedene Skalierungsmöglichkeiten, ne? Ich meine, mit mit VMs habe ich diese Autoscaling Groups, aber ähm ja, wenn wir an Kubernetes denken, das kann ich eben noch viel flexibler steuern. Ich kann z.B. einfach fachliche Metriken anziehen, um zu entscheiden, ob ich jetzt mehr oder weniger Instanzen eines Pots ähm bereitstellen möchte im Vergleich zu nur CPU Auslastung. Ja.

Anja Kammer: Und da merkt man auch schon, dass man manchmal vielleicht sogar ein bisschen tiefer reingehen muss noch in die Architektur, den Code, ne, um um beispielsweise die Applikation aus Stateless zu machen, um damit wir eben die Skalierungsmöglichkeiten haben, wobei ich bei der VM, auch wenn ich diese Autoscaling Groups habe, ähm habe ich die Möglichkeit, das auch einfach nicht zu tun, die Skalierung nicht zu tun, weil eben meine Applikation noch nicht bereit ist dafür auf Prozessebene sozusagen skaliert zu werden, statt auf Thread Ebene.

Kofi Jedamzik: Mhm.

Anja Kammer: Genau, also man sieht auch beim Replatforming kann es sein, dass man halt auch in den Code noch mal rein muss, um die Integration zu machen mit der Cloud, mit den Technologien der Cloud. Worüber wir noch nicht geredet haben, sind Datenbanken, das heißt auch, wenn ich jetzt eine ähm lokal betriebene Datenbank on Premises habe, dann wäre das ein Replatforming, wenn ich ein Äquivalent mir einkaufe, so eine Managed Datenbank bei einem Cloud Provider, nicht wahr?

Kofi Jedamzik: Mhm.

Anja Kammer: Ist das der Grund, warum es die Oracle Cloud gibt?

Kofi Jedamzik: Ähm ich weiß es nicht, weil ich glaube, man kann auch bei anderen Cloud Providern einfach in deren Shop äh Oracle basierte Ähm Datenbanken bereitstellen. Genau.

Anja Kammer: Hast du Erfahrung mit der Oracle Cloud?

Kofi Jedamzik: Äh nein.

Anja Kammer: Mhm.

Kofi Jedamzik: Also, das werde ich auch regelmäßig gefragt, ne, weil Kunden halt auch Business Logik da viel drin äh äh erstellt haben. Genau, also ich weiß, dass man das äh bei den verschiedenen Anbietern auch bekommen kann. Ich glaube, das sind dann aber häufig ähm ja, lizenztechnische Hürden äh mehr als technische.

Anja Kammer: Mhm.

Kofi Jedamzik: Genau, weil teuer.

Anja Kammer: Ja. Und teuer heißt aber auch, dass generell Datenbanken in der Cloud auch teuer sind. Oftmals ähm führt das auch dazu, dass man sozusagen nur eine fette gemanagte Datenbank sich bei einem Cloud Provider sozusagen einrichtet und dort dann mehrere Applikationen auf diese eine Datenbankinstanz dann ihre eigene Schemata nutzen. Kann man so machen, ich habe auch das Gegenteil gesehen, dass sozusagen äh sehr viele Demo Applikationen ihre eigene gemanagte Datenbank bekommen, was halt auch sehr teuer sein kann. Also, das sind wieder so Dinge, bei denen man finanziell drauf achten sollte, hey, wie hoch sind die Kosten für die gemanagten Datenbanken, lohnt es sich dort vielleicht so ein bisschen drauf zu achten, dass ähm dass Applikationen vielleicht äh dass nicht jede Applikation eine gemanagte eigene Datenbankinstanz bekommt oder eben doch.

Kofi Jedamzik: Ja, genau, also bei teuer muss man sich halt auch immer fragen, was ist die Alternative und ist das dann günstiger und auch langfristig? Ähm also äh schwierig ist natürlich, wenn ähm also eine einzelne Instanz so unglaublich teuer ist, dass man dazu neigt, alles auf einer ähm eben zu betreiben, aber das hat erzeugt natürlich andere Kosten, ne? Langfristig habe ich jetzt da so ein äh dickes klebriges Dingen geschaffen, wo alle von abhängig sind und wenn ich das Teil updaten will, muss ich jetzt äh zwanzig verschiedene Teams fragen, das erzeugt natürlich auch äh Verzögerungen und und riesige Kosten. Genau. Bei den gemanagten Datenbanken, also da hat man teilweise auch Vorteile, äh die es so bei den, wenn ich die jetzt selbst betreiben würde, nicht habe. Also, ich denke z.B. an ähm äh Replikations Traffic, den ich je nachdem, für welches Produkt ich mich entscheide, nicht bezahlen muss, weil es da proprietäre Technologien für gibt, die äh Replicas über Storage quasi ähm bereitstellen, statt äh Replikations Traffic bezahlen zu müssen. Genau, die gibt’s, da gibt’s verschiedene Pläne auch für ähm da lohnt es sich dann z.B., dass äh man ähnliche äh Produktfamilien verwendet. Ähm genau, dass man äh ja, die nennen das Reserved Instances. Das heißt, ich kann quasi mich vorher committen, eine bestimmte Summe in Datenbanken zu investieren und dann kann ich das eben mit verschiedenen kleinen Datenbanken einer bestimmten Familie auch nutzen. Genau, da gibt’s also einiges, was man in Sachen Kosten optimieren kann.

Anja Kammer: Ja.

Kofi Jedamzik: Was hinzu Serverless Datenbanken, wenn man jetzt sehr sehr wenig Traffic hat und das auch selten aufgerufen wird, dass man da eben ähm ja, runter skalieren kann.

Anja Kammer: Genau, also auf Null sozusagen sogar skalieren kann, ne? Also einfach nichts dafür bezahlt, wenn wirklich keine Daten abgerufen oder geschrieben werden, ja. Ja, ich würde sagen, lass uns vielleicht doch noch mal über Relocate sprechen. Wir hatten schon gesagt, Relocate ist irgendwie das siebte R.

Kofi Jedamzik: Mhm.

Anja Kammer: Da geht es um das Verschieben von bestehenden Anwendungen einfach nur von beispielsweise On-Premise in die Cloud oder von einer Cloud in die andere, ist eigentlich egal, weil die Plattform ändert sich eigentlich nicht, die bleibt unverändert, ne? Wir hatten als Beispiel ähm ähm beispielsweise Kubernetes genannt oder auch VMware Cloud on AWS beispielsweise, dieses Produkt, welches dazu geführt hat, dass wir jetzt diese diese diese Relocate Strategie haben.

Kofi Jedamzik: Mhm.

Anja Kammer: Genau, dazu, also gibt es dazu etwas zu sagen, weil es ändert sich ja im Grunde nichts, außer dass es wahrscheinlich, also ich weiß nicht, ob es teurer ist. Hast du Erfahrungen, ob dieses VMware on Cloud teurer ist, als würde ich VMware on Premise betreiben?

Kofi Jedamzik: Ähm also ich weiß nur, dass einige Kunden dort Probleme haben oder Risiken sehen, weil das ja auch äh inzwischen von Broadcom gekauft wurde und die Lizenzmodell geändert haben und äh genau, dieser eigene Betrieb da, soweit ich das äh weiß, gar nicht mehr vorgesehen ist in deren Lizenzmodell. Aber ähm genau, da weiß ich keine Details.

Anja Kammer: Ja.

Kofi Jedamzik: Was ähm Kubernetes angeht, das ist natürlich ähm eine Möglichkeit, um diesen gefürchteten Vendor Lock-in äh aus dem Weg zu gehen, ne, weil wenn ich erstmal meine Workload auf Kubernetes habe, dann ähm ja, kann ich sehr wahrscheinlich ohne größeren Aufwand das auf ein anderes Kubernetes migrieren, wenn ich z.B. das in meinem eigenen Rechenzentrum betrieben hatte und äh genau, z.B. das jetzt in einem gemanagten Cloud Kubernetes verschieben. Es kommt so ein bisschen drauf an, was man genau da jetzt benutzt hat, vielleicht verschiedene Storage äh Plugins oder Networking, das bedarf noch mal einen äh besonderen Blick, aber genau, das ist ähm erstmal eine Möglichkeit, dass ich da ziemlich unabhängig werde.

Anja Kammer: Mhm. Okay, das nächste R ist Repurchase und da geht es um das Ersetzen von Komponenten des Systems durch ähm Software as a Service Lösung, also SaaS Lösung oder auch Open Source äh Lösung, die man dann selbst betreibt. Und damit ähm ja, vermeide ich die Migration von bestehender, also von bestehenden Komponenten und entscheide mich dafür sozusagen mit Dingen, die ich einkaufe. Äh wir hatten ja schon über Migration äh ja, nochmal, wir hatten ja nochmal, wir hatten über ähm nicht Migration, wir hatten über Monitoring Systeme gesprochen. Wenn es jetzt ein Monitoring System gibt, ein Application Monitoring System, was ich vorher betrieben hatte, das war das war sozusagen spezial speziell für On-Premise und ich brauche aber auch ein Monitoring System in der Cloud, dann wäre das für mich ein Repurchase, ne? Also ich verändere das Produkt äh und ich nutze es jetzt in der Cloud, hat aber ähm dieselbe Funktionalität, ne? Ich habe mir dann aber dadurch erspart, das alte Produkt weiter zu maintainen oder zu bezahlen, indem ich entweder irgendwie, wie gesagt, beispielsweise auch auf eine Open Source Lösung wechsle.

Kofi Jedamzik: Mhm. Genau, was ja also ja, Repurchase wird halt auch häufig Drop and Shop genannt, das finde ich ein bisschen witziger. Ähm genau, die also was wir halt häufig sehen ist so so Ticket Systeme oder so Wiki-artige äh äh Softwarelösungen, die dann eben.

Anja Kammer: Oder so CRM.

Kofi Jedamzik: Genau, sowas wird gerne mal in der Cloud einfach eingekauft, auch durchaus Monitoring Lösung, wie du schon sagst, egal ob ähm ja, also es gibt halt äh man muss sagen, die also die meisten On-Prem-artigen Monitoring Lösungen, die ich so kenne, neigen dazu sehr Host-basiert zu sein und kriegen Probleme, wenn ich jetzt z.B. meine Lambdas irgendwie überwachen möchte und da ähm genau, bietet sich das manchmal an. Äh beziehungsweise man kann dann auch einfach, wenn ich halt eh zu einem bestimmten Cloud Anbieter gehe, deren ähm Monitoring System gleich mitnutzen. Ja.

Anja Kammer: Mhm.

Kofi Jedamzik: Das sind für mich so Drop and Shop Beispiele.

Anja Kammer: Ja, man kann sich, glaube ich, auch daran daran langhangeln, dass es halt vor allem Dinge sind, die so eher so Supporting oder Generic Domain sind, ne? Also, wenn wir so an DDD denken, an diese DDD Core Domain Charts, äh dann kann man sehen, Dinge, die sich dazu lohnen gekauft zu werden, statt sozusagen selbst zu entwickeln, sind Dinge, die nicht wirklich ähm das Kerngeschäft ausmachen, ne? Also äh ja, was wäre das z.B. wenn ich z.B. einen Onlineshop betreiben würde, dann äh ist es sozusagen, das kann schon sein, dass das Kerngeschäft dann so dann sozusagen ein Onlineshop ist und ich dementsprechend den Onlineshop selbst auch schreibe und maintaine und ähm vielleicht sogar das Customer Relation Management Tool oder den Einkaufs, also das Einkaufstool für andere äh für andere Unternehmen wie Versicherungen beispielsweise braucht man das dann wahrscheinlich nicht. Dann kaufe ich mir sowas beispielsweise ein, ne, um jetzt auch mal äh solche fachlichen Applikationen damit reinzunehmen.

Kofi Jedamzik: Ja.

Anja Kammer: Was hatte ich aus der Praxis, aus der Praxis hatte ich neulich eine Datenanalyse Plattform, die sozusagen dann neu gekauft wurde und ähm dann ist auch die Entscheidung für einen Cloud Provider schon sehr sehr kritisch, ne? Also, wenn die Datenanalyse Plattform äh sehr wichtig ist in deinem Unternehmen, dann machst du dir die Entscheidung für einen Cloud Provider schon sehr schwer, wenn du eben diese proprietäre ähm Cloud Software nutzen möchtest, weil unsere Cloud Provider oder unsere Cloud Provider, Cloud Provider generell haben sehr gute Big Data und Datenanalyse Tools, die aber alle oder viele davon proprietär sind. Und das kann auch ein also ein schwieriger Punkt sein, da die Entscheidung überhaupt zu machen, okay, wir haben da diese Datenanalyse Plattform, bevor wir uns überhaupt für einen Cloud Provider entscheiden, müssen wir erstmal überlegen, welche Software für diese Datenanalyse wollen wir haben, oder man sagt gleich, okay, wir wollen es davon nicht abhängig machen, wir gehen eine Multi Cloud Lösung. Diese Datenanalyse ist nicht abhängig von unserer Applikation zur Laufzeit, da können wir einen anderen Cloud Provider benutzen.

Kofi Jedamzik: Genau, also bisweilen war es so, ne, dass die sich ähm was so bestimmte äh AI Funktionen oder auch, wie du schon sagst, Data Pipelines und so, da haben die sich schon so ein bisschen unterschieden und da hatte mal der ein oder andere die Nase vorn. Ähm genau, das kann man sich dann entsprechend zusammenkaufen, wo man ja sich den größten Vorteil von erhofft.

Anja Kammer: Mhm. Das letzte R ist Refactor. Und das ist auch das größte, was sozusagen sehr invasiv ist in das System oder in die Komponente, die man da refactorn möchte. Also ist sozusagen die vollständige Migration von der Anwendung in einer Cloud Native Architektur. Ob das jetzt bedeutet, dass man daraus Microservices macht aus einer Komponente oder Lambdas oder es einfach nur mal sozusagen neu schreibt. Aber es ist wirklich das Ziel, diese Applikation besonders gut lauffähig, also Cloud Native für die Plattform zu machen, die man dann benutzt. Also mindestens auf jeden Fall Containerisierung und es kommt drauf an, wie die Applikation, die man da umbauen möchte, bereits beschaffen ist. Es also man macht so ein Refactoring aus einem bestimmten Grund, beispielsweise, dass ähm das Rehosting irgendwie zu viel Kosten produzieren würde, das Replatforming zu instabil wäre oder ähnliches und dann sagt man, okay, dann dann geht man auf jeden Fall sofort die Richtung des Refactorings, weil wir kriegen diese Applikation, die besonders groß, die besonders instabil wäre auf der Cloud halt sonst nicht anders betrieben.

Kofi Jedamzik: Genau. Refactor oder auch Rearchetecting, das ist eigentlich so ein bisschen zurück ans Reißbrett. Ähm da denke ich auf jeden Fall an umfangreichere Änderungen, wo wir wirklich äh diesen Gedanken, dass ein Prozess in einem Container nur läuft, dass wir das zu Ende äh denken, dass wir wirklich äh alle einzelnen Bestandteile getrennt voneinander skalieren können, so dass wir auch immer nur das verbraucht, was wirklich gerade notwendig ist. Ähm das äh ja, genau, wir an den verschiedenen Stellen genau die Resilienz äh einbauen, die wir ähm benötigen. Ähm genau. Ja, also ich würde sagen, das hat halt auch dann das das größte Potenzial, ne, so langfristig auch meine Betriebskosten runterzukriegen. Das System ähm verhält sich da sehr dynamisch, je nachdem ähm wo Traffic entsteht, wird skaliert, äh da wo das nicht passiert, ähm ne, äh verschwende ich dann auch nicht zusätzliche Ressourcen. Das ist eigentlich das, wo ich immer drauf hinarbeite, dass da ähm ich genauso viele Ressourcen binde, wie im Moment wirklich gerade notwendig ist. Ähm wir sehen halt häufig so große, meist äh Java-artig, monolithische Apps, wo ähm zum einen der Webservice drin läuft, wo verschiedene Cron Jobs drin laufen und ich muss diesem Ding dann natürlich entsprechend viele äh Ressourcen zuweisen, damit alle diese Dinge potenziell gleichzeitig auch laufen können. Und ähm ja, wenn ich die Möglichkeit habe, hier noch mal ähm einen Schritt zurückzugehen, dann können wir das eben rauslösen und äh diese einzelnen Cron Jobs auch in einzelne Jobs packen, die dann immer nur dann, wenn sie auch wirklich laufen, Ressourcen binden und ähm genau. So ähm ja, kann ich die einfach getrennt skalieren und ja, langfristig auch äh Kosten sparen.

Anja Kammer: Mhm.

Kofi Jedamzik: Und auf Resilienz und so weiter zu verzichten.

Anja Kammer: Ja, du hast da gute Punkte gebracht, genau dann würde ich auch ein Refactoring machen. Was ich aber in den vielen Workshops bei den Unternehmen oftmals sehe, ist, dass ähm vor allem die Entwicklungsteams, die es betrifft, die diese Applikation, die refactored werden soll, sozusagen also bzw. dass das Entwicklungsteams immer glauben, dass ihre Applikation refactored werden sollen, weil die besonders wichtig sind, weil die besonders die Vorteile der Cloud brauchen. Und oftmals ist dahinter, glaube ich, eher so dieser Perfektionsgedanke. Ähm wir wollen Microservices, wir wollen den neuesten heißen Scheiß, wir wollen das richtig machen und wir wollen nicht irgendwie unsere alte Legacy Applikation in der Cloud betreiben und dann funktioniert die nicht ganz so gut. Also, wenn wir schon in die Cloud gehen, dann wollen wir es richtig machen und das führt dazu, dass man bei solchen Workshops immer wieder dagegen argumentieren muss, warum das eine schlechte Idee ist, mit Refactoring anzufangen, weil das nämlich sehr sehr viel Vorabkosten, sehr sehr viel Aufwand vorher ähm bedeutet und dass das gesamte Projekt sozusagen dadurch vielleicht sogar ähm nach hinten verschoben werden muss, weil so ein Refactoring einfach mal Arbeit ist. Ähm vielleicht auch niemals beendet wird, weil man merkt, wir haben uns total verzettelt, wir müssen noch mal von vorne anfangen. Das ist nicht selten, dass man bei einem Neuschreiben, bei einem Refactoring einfach noch mal von vorne anfangen muss, weil man es falsch gemacht hat am Anfang.

Kofi Jedamzik: Ja, genau, das meinte ich mit diesen Ziele zu hoch stecken. Ähm es ist halt wichtig, sich am Anfang mal Gedanken zu machen und zu gucken, wo verschwenden wir denn jetzt hier gerade am meisten Ressourcen, zum Beispiel. Ähm und genau, da fängt man dann vielleicht an oder vielleicht sind die Ressourcen gar nicht das Problem und äh ne, ich möchte irgendwie ein bisschen mehr Unabhängigkeit haben oder äh ich möchte Koordinationsaufwand äh reduzieren. Genau, man muss halt gucken, wo wo drückt der Schuh, dass man wirklich diesen Schmerz ähm an diesem Schmerz arbeitet und nicht äh ja, enthusiastisch äh auf die grüne Wiese rennt und da äh denkt, alles muss jetzt direkt Cloud Native äh genau, in Perfektion sein.

Anja Kammer: Ja. Ähm und in solchen ja, in solchen Situationen hilft es zu sagen, hey, ihr habt die Option mit einem Rehosting oder Replatforming schon mal in die Cloud zu gehen. Und während ihr auf der Cloud ähm eure Software beispielsweise über Replatforming schon beispielsweise in Kubernetes betreibt, seht ihr dann, okay, wo können wir, also welche Teile können wir aus dieser Applikation rausziehen, die besser in einer Lambda passen, die besser Cron Jobs sind oder die besser in einen eigenen Container platziert werden sollten, ne? Und dann können sie während des Betriebs diese Dinge rauslösen, dann Cloud Native Magic drüber streuseln und das können sie dann nach und nach über die Jahre machen, bis sie dann ihre Perfektion erreicht haben und die sind dann schon in der Cloud und ähm ja. Man macht das dann halt nebenbei, dauert natürlich länger, aber ähm du scheiterst nicht währenddessen. Du kannst halt immer wieder zurück, weil du weil du läufst ja schon in der Cloud. Also Perfektion ist super teuer, geht erstmal in die Cloud und schaut dann, was können wir verbessern, was lohnt sich überhaupt zu verbessern, wie du gesagt hast, ne? Also welche welche Komponenten, welche Codeteile brauchen wirklich eine höhere Skalierung, welche brauchen andere Resilienzmechanismen und ja, etc.

Kofi Jedamzik: Mhm.

Anja Kammer: Genau. Ich finde es gut, dass wir das besprochen haben, das ist ja wichtig. Ich möchte nicht, dass äh alle Leute glauben, okay, wenn man in die Cloud geht, muss man immer gleich Cloud Native sein, muss man nicht, das geht auch schneller.

Kofi Jedamzik: Ja. Genau, manchmal sind die Leute auch in unseren Schulungen total verwundert, äh wenn ich sag, äh macht das lieber nicht, wenn sie halt fragen, wie man irgendwie so eine Legacy Technologie containerisiert. Dann stellt halt einfach eine VM daneben und äh genau, baut die neuen Apps schön in Container und äh ja, macht das äh nach und nach. Also häufig gibt’s ja halt auch äh diese Abhängigkeiten dazwischen und bevor ich eben viel den den Zeitraum, wann ich ähm meine alte Plattform abschalten kann, bevor ich das unendlich in die Länge ziehe, packe ich das vielleicht lieber erstmal so wie es ist in die Cloud, kann dann schon mal das alte System äh dekommissionieren und äh ja, in dem neuen, in der neuen Umgebung dann nach und nach verbessern bzw. dort einzelne Dienste in in äh SCS oder Microservices äh neu schreiben. Genau, da müssen alle anderen da drum herum nicht auf diesen einen Dienst warten und ich äh spare mir auch dieses diesen hybriden Ansatz, wo ich vielleicht erstmal noch äh aufwendig VPNs und solche Dinge bauen muss. Genau.

Anja Kammer: Okay, das war’s. Wir haben jetzt die 7R Strategien besprochen. Und ähm etwas, was ich noch erwähnen möchte, ist, dass ähm bevor wir uns für passende Migrationsstrategien für eine Komponente entscheiden oder für alle Komponenten eines Systems entscheiden, gibt es noch so Dinge, die ich ganz davor machen muss. Ich muss erst einmal das Gesamtsystem ähm ja, also ich muss das Gesamtsystem erst einmal analysieren. Welche Kritikalität haben diese Systeme, welche Daten verarbeiten diese Systeme, wo sind die Abhängigkeiten? Welche Systeme haben Skalierungsanforderungen, welche nicht? Und das ist die größte Arbeit. Wichtig sind natürlich auch die Rahmenbedingungen zu äh zu ähm zu beleuchten. Welche Rahmenbedingungen habe ich? Wie schnell muss ich migrieren, auf welche Plattform muss ich, also muss ich migrieren, habe ich vielleicht die Möglichkeit mich zu entscheiden, auf welche Plattform ich migrieren muss? Manche Unternehmen ähm wissen noch gar nicht in welche Cloud oder ob sie überhaupt in Cloud wollen. Das sind alles Dinge, die ganz am Anfang gemacht werden müssen, die total unsexy sind, weil sie nichts mit Technik zu tun haben. Erst einmal zu überlegen, was ist denn die Strategie? Ähm und wo und wo ja und ja, welche welche Rahmenbedingungen habe ich, welches Constraints habe ich, habe ich irgendwie zu wenig Leute, die mit mir diese Migration machen können in die Cloud, habe ich zu wenig Zeit für die Migration oder habe ich wenig Zeit für die Migration? Das kann alles beeinflussen, für welche Strategien wir uns am Ende der ganzen Komponenten entscheiden. Wir können uns dafür entscheiden, wenn wir zu wenig Zeit haben, dass alle erstmal auf Rehosting gehen. Das kann total passieren, oder wir entscheiden uns dafür, dass diese eine Applikation, die die die viel zu groß ist, die in der Cloud absolut nicht lauffähig wäre, aber die unser Kerngeschäft sind, dass wir die erstmal refactorn und damit erstmal Zeit verbringen. Das sind alles Dinge, die ich sozusagen vorher erstmal in der Architektur auch beleuchten muss, ne? Also was sind unsere was sind die Applikationen? Wie kritisch sind sie, welche technische Schulden haben die? Also wie viel Arbeit ist dann noch dran zu machen, bevor es überhaupt sozusagen auf eine andere Plattform gehen kann?

Kofi Jedamzik: Ja. Genau, das sind ja diese bei Amazon sind das diese drei Schritte davor, ne, mit Discovery, Assess Prioritize und Determine Migration Pass. Super wichtig, weil man halt ähm äh halt häufig vergisst, dass ähm ich dass ich eine natürliche Reihenfolge dieser Migration alleine schon aus auf Grund der Abhängigkeiten ergeben, ne? Und man sollte halt gucken, dass äh ja, ich das, was von den meisten Apps ähm am dringendsten gebraucht wird, dass ich mich um solche Dinge zuerst kümmere. Ähm ja, und man also ich stelle immer wieder fest, dass das mitunter ganz schön schwierig ist herauszufinden, was genau haben wir denn hier alles am Laufen und wer kann denn jetzt eine Aussage darüber treffen, ähm ob das mit dem neuen Application Server laufen würde, ne? Lässt sich das überhaupt containerisieren, wie viel Aufwand bedeutet das? Das ist ähm ein immenser Aufwand, ähm genau. Da.

Anja Kammer: Aber bei der Priorisierung kann ich dann trotzdem, also ich bin nicht immer, also bei der Priorisierung habe ich trotzdem die Möglichkeiten danach zu steuern, ne? Ich kann natürlich danach steuern, was ist irgendwie mein mein Hauptkerngeschäft oder oder die größte Applikation, die irgendwie erstmal aufgebrochen werden muss, damit könnte ich mich sozusagen zuerst befassen, um sie zu priorisieren, um sie priorisiert in die Cloud zu schieben. Aber ich könnte auch sagen, okay, ich fange erstmal mit den leichten Dingen an, um erstmal reinzubekommen und um erstmal ein Gefühl zu bekommen, um erstmal sozusagen die ersten Erfolge zu feiern. Das ist z.B. eine Strategie, die oftmals in sehr politischen Organisationen gewählt wird, um erstmal zu zeigen, hey, wir schaffen das. Ich meine die ersten sehr einfachen Applikationen zu migrieren, die vielleicht sogar eh schon irgendwie Open Source Software sind, die man gar nicht so richtig selbst geschrieben hat, die man einfach nur in die Cloud heben muss oder Dinge, die einfach sehr einfach sind, Frontends beispielsweise zuerst migrieren, sehr viel einfacher und hat man sofort einen Impact. Man hat vielleicht sogar eine schnellere Auslieferung der der Webseiten und alles. Das kann alles sozusagen schon mal was hermachen, dass höhere ähm ja, das das höhere Rollen sozusagen sagen, okay, dann bekommt ihr irgendwie mehr Geld dafür, scheint ja gut zu laufen oder ihr bekommt Prestige, ihr habt es ja schon sehr schön und sehr schnell gemacht. Das kann sozusagen alles beeinflussen, welche Applikation ich zuerst priorisiere, um sie in die Cloud zu schieben. Bei Unternehmen, die weniger politisch getrieben sind, die fangen meistens mit den, also mit ihrer mit ihrer Kernaufgabe an, die am meisten Potenzial hat, sozusagen äh von von Skalierung zu profitieren, ne? Die fangen dann eben mit dieser großen Kern Applikation oftmals an.

Kofi Jedamzik: Genau, was ich gerade gesagt habe, bezog sich jetzt halt auf die rein technische Sicht, was hängt von was ab und dann hänge ich ähm genau, fange ich nicht mit dem letzten Glied zuerst an. Ähm aber genau, es gibt halt unterschiedlichste Gründe. Ich hatte ja vorhin schon mal gesagt, man kann sich dann erstmal mit dem Tooling auseinandersetzen. Ähm die meisten Cloud Anbieter bieten eben dieses sogenannte Well Architected Framework, wo es bestimmte Best Practices, Tooling, ähm ja, äh ja so Rahmenwerk, sage ich mal, gibt, ne? Wie in welche unterschiedlichen Sub Accounts teile ich das auf, wie richtig für alle ähm Audit Logging ein und solche Dinge. Ähm genau, oft ähm oder nicht selten entscheidet sich der Kunde ein eigenes Rechenzentrum loszuwerden und dann sind natürlich sehr viele Menschen da involviert, die vielleicht jetzt glauben, dass sie ihren Job verlieren, weil bald alles irgendwie automatisiert in der Cloud passiert. Wir brauchen natürlich äh weiterhin die Leute, die jetzt die YAML Dateien schreiben und die können sich vielleicht dann schon mal, wie gesagt, mit dem Tooling und den neuen Technologien auseinandersetzen. Ähm genau, das sind auch wichtige Dinge, die diesen Migrationspfad beeinflussen.

Anja Kammer: Genau, du hast einen sehr guten Punkt. Wir haben jetzt sehr von der Technikseite uns die Cloud Migration angeschaut und Architekturseite, aber weniger die menschliche Seite, ne? Also so eine Cloud Migration ist so ein krasser Um Umbruch in einer Organisation und ich habe auch gesehen, dass Menschen kündigen, weil sie glauben, dass sie ähm dass sie sozusagen obsolet werden, dass sie den Anforderungen nicht gerecht werden in der in der also mit den neuen Technologien zu arbeiten oder ähnliches. Das habe ich sehr oft gesehen und daran kann natürlich eine Organisation dann auch scheitern in die Cloud zu gehen, wenn Leute gehen, die sehr viel Erfahrung haben und eigentlich gebraucht werden für die Migration, dass genau die Leute dann gehen, weil sie mit der neuen Betriebsumgebung nichts anfangen wollen oder können.

Kofi Jedamzik: Genau, oder andersrum, dass äh sie für die äh neuen Cloud Dinge irgendwie externe Menschen engagieren und das das bestehende Personal soll jetzt sich um den Legacy Kram kümmern.

Anja Kammer: Ja, das stimmt.

Kofi Jedamzik: Die Leute wollen wir halt auch alle mitnehmen. Ähm genau, das kann man unterschiedlich äh gestalten, damit die Leute halt an Bord sind, ja.

Anja Kammer: Ja. Gut, ich glaube, ähm wir sind damit durch. Wir haben jetzt zwar noch ein schönes Thema aufgemacht, aber das ist vielleicht ein Thema für einen anderen Podcast, ne, die die menschliche Seite bei so einer Cloud Migration. Ich bedanke mich sehr, dass ich mit dir reden durfte, Kofi, vielen Dank.

Kofi Jedamzik: Ja, danke dir.

Anja Kammer: Ciao.

Kofi Jedamzik: Tschüssi.