136 - No mile left behind: Die Punktlandung von Miles & More in der Cloud
33m 56s
In der Podcast-Folge diskutieren Igor, Dominik von Meißen Mor und Chris von der LPS die erfolgreiche Migration des Kernsystems "Sammbar", eines europäischen Vielfliegerprogramms, von einer On-Premise-Umgebung in die AWS-Cloud. Hauptauslöser waren die notwendige technische Modernisierung einer über 15 Jahre gewachsenen Anwendung und die drohende Abschaltung des alten Rechenzentrums. Das Projekt stand unter enormem Zeitdruck, da das System zum Stichtag voll funktionsfähig sein musste. Statt eines einfachen "Lift-and-Shift" entschied man sich für eine grundlegende Architekturüberarbeitung hin zu cloud-nativen Technologien, um Skalierbarkeit und Kosteneffizienz zu nutzen. Die Zusammenarbeit wurde agil gestaltet, um auf unbekannte Herausforderungen reagieren zu können. Kritische Erfolgsfaktoren waren die frühe Einrichtung einer produktionsnahen Testumgebung, die konzentrierte Arbeit in fokussierten Workshops (wie AWS EBA) und die ständige Erarbeitung von Fallback-Plänen. Besondere Sorgfalt galt der Datenmigration und dem Cutover, da es sich um ein transaktionales System handelt, in dem Buchungen nicht einfach rückgängig gemacht werden können. Die vertrauensvolle Partnerschaft und der effektive Wissensaustausch zwischen den Teams waren für die Bewältigung dieses komplexen Vorhabens entscheidend.
Es macht am meisten Spaß, wenn man auch Mut hat und wenn man gemeinsam Mut hat, da vorne zu gehen und solche Dinge einfach mal zu machen. Hallo an alle Entgeräte daraus und willkommen zu einer neuen Folge von Klaus Horizonte, im AVS-Broadcast auf Deutsch. Mein Name ist Igor, ich bin Enterprise Account Manager und heute in Begleitung von gleich zwei Gästen, die gemeinsam meine Systemtransformation durchgeführt haben, die es echt in sich hatte. Von Zeitdruck über technischen Herausforderungen bis hin zu den besten Learnings werden wir heute mit Dominik Sommer von Meißen Mor und Christdemel von der LPS sicherlich einiges mitnehmen können. In diesem Sinne, grüßt euch ihr beiden, schön dass ihr da seid. Hi Igor, grüßt euch. Hi da uns. Hallo zusammen. Hi Chris. Hi Igor. Lass uns am besten einmal uns kurz vorstellen, dass wirklich alle zuhörere Wissen mit, mit dem sie es zu tun haben. Chris, magst du anfangen? Ja genau, ich bin der Chris. Ich bin Solutions Architect bei der LPS in München. Aber ich habe schon über zehn Jahre dort und die meiste Zeit auch für meinen Lieblingskunden die Meißen Mor. So eine gute Übergang direkt zu Dominik. Was soll ich dazu jetzt auch sagen, Chris? Ja, ich habe gar nicht. Gerglindert hat, genau. Ja Dominik, ich bin seit zehn Jahren jetzt knapp bei der meißen Mor. Da hat auch als Architekt angefangen, Kenning Chris auch aus der Zeit. Und eine lange Gemeinsamhe historie deswegen. Ich glaube, ich bin sehr vertraut miteinander. Ich habe dann das IT-Plattform-Team aufgebaut bei der Meißen Mor. Und bin jetzt seit knapp fünf Jahren verantwortlich für den Bereich IT- und Produktentwicklung und der Eigenschaft. Und dann auch quasi als Sponenzor, wenn man so möchte von unserem gemeinsamen Projekt unterwegs. Ich glaube, es fühlen da draußen einen Begriff. Wir sind da ein Europas-Kurstesviel-Flegerprogramm oder Travel-Vol-Typ-Programm, wie wir auch immer das genau definieren möchte mit über 30 Millionen Teilnehmenden. Und das, was wir gemeinsam getan haben, ist unser Kernsystem, das heißt, sammbar, zu migrieren von einer on-premise Hosting-Umgebung in eine Cloud-Umgebung bei der RWS. Super, danke dir Dominik. Chris, kannst du auch uns etwas dazu sagen? Ich durfte bei der Umsetzung helfen. Wir hatten da einige Vorgaben innerhalb der LBS, wie wir das tun. Und denke, wir haben es jetzt am Ende ja sehr auf Vorgrenn hinbekommen. Aber wir genau erfahren wir da weiter im Podcast hier. Was mich jetzt vor allem interessieren würde, typischerweise hört man ja von Kunden "Never Change a Running System" und Dominik Du hast ja gesagt, dass eure Samba-Initiative eigentlich bereits lief. Wie kam es denn überhaupt gänden, gefragt an Chris und Dominik, zu der Entscheidung das Ganze in die Cloud zu migrieren? Es gab verschiedene Auslöser dafür, vielleicht da auch noch mal ein bisschen Hintergrund. Wir sind seit knapp umgekehr 15 Jahren mit dem System am Sammbar unterwegs, was im Basiert auf einem Landart-Produkt von der LBS. Wir haben es Leute, die Management-Systeme. Und wir haben das in laufe der letzten 15 Jahre natürlich massiv an unsere Bedürfnisse angepasst, weil wir in der Situation im Ausruf der Gruppe oder viel Fliegerprogramme einer großen Erleihengruppe durchaus auch Anforderungen haben, die man am Markt jetzt vielleicht nicht unbedingt so ein Standardprodukt rein bauen würde. Und insofern ist das wie mit allen Software-Entwicklungen, die über eine längere Zeit laufen, da sammelt sich im Laufe der Jahre dann schon so ein bisschen was an. Und von daher war eine der Zielsetzungen zu sagen, wir müssen eh eine technische Modernisierung starten. Also lassen es doch auch an der Stelle nochmal auf das Hosting die Betriebsumgebung schauen. Und ganz akut hatten wir dann da noch einen kleinen zeitlichen Verstärkader drin, nämlich die Tatsache, dass das Rechentzentrum in dem wir die Infrastruktur stehen hatten, geplantermaßen abgehörschaltet werden sollte. Also das heißt wirklich Strom aus, alles selber raus und dann das Gebäude anderweitig genutzt. Und von daher hatten wir da Änderändigkeit über nachzudenken und hätten natürlich dann die Option gehabt zu sagen, wir machen das weiter wie bisher in einem anderen Rechentzentrum. Aber da wir eben auf der anderen Seite auch mit den Modernisierungssaktivitäten in Unterwechswern, haben wir gesagt, dann machen wir auch gleich in richtigen Schritt und machen die Modernisierung an der Stelle so, dass wir mehr Cloud Native-Komponenten einsetzen oder auch mehr auf Nativ, auf die Cloud Technologien setzen, damit wir da eben nicht den klassischen Liftschiff, das klassische Liftschiffproblem haben, dass wir eigentlich mal das gleiche, was sie vorher am Präm hatten und einfach in der Cloud haben, ohne die Vorteile zu haben, die meine Cloud sind, so zu hat uns, was so um Elasticität angeht, im Skalierungsoptionen und solche Dinge mehr. Die wollten wir in dem Zugetleich mit nutzen und von daher haben wir eben gesagt, wir gehen direkt in die Cloud. Ja, so gleich mehrere Herausforderungen, die ich da gehört habe, sowohl vom Liftschiff dann, Salz als auch von den Deadlines, fangen wir mal bei dem Liftschiff-T-Part an, bauen wir ab, die durch den Gegend einfach nur einen wegschiefen von und Präm hin zu Cloud entschieden, sondern direkt auf die Integration mit der LPS Produktplattform. Die LTS-Plattform ist die Grundlage von der von Sambarseit je her, also von daher war es tatsächlich die Frage, wo betreiben wir das, wenn das Rechentzentrum zumert. Und wie gesagt, die Hoffnung, die wir da reingesetzt haben zu sagen, wenn wir von der Legacy-Appletation zur Struktur von einer sehr starker auch on-Prem-Datenbank getriebenen Infrastruktur oder Architektur hingehen und sagen, wollen das Ganze in der Cloud betreiben, dann wäre das, das haben wir auch noch durchgerechnet, Christoph nicht mich recht, erinnere relativ teuer geworden, einfach zu sagen, dass wir das aus einer on-Prem-obtimierten Software-Architektur einfach umheben in eine Cloud-Umgebung hätte uns mehr Geld gekostet und wir hätten eben die Vorteile, die nicht laut mit sich bringt, nicht nutzen können. Und von daher haben wir gesagt, die Vorteile, die wir uns an der Cloud sehen, also auch spezifisch, was so ganz banale Dinge wie wir brauchen, wir schnell eine Test- oder eine Entwicklung umgebung, das kann ich halt in der Cloud mal eben hochfahren, um wir auch noch für eine Stunde. Aber eben auch solche Dinge wie Performance, wenn ich eben Peaks habe in der Last, dann kann ich schnell oskanieren. Ich kann ohnehin die Pläume machen, ohne Autages. Also diverse Vorteile, die ich einfach habe in der Abgebung, war einfach und die Mahn da mehr Computervikbar ist. Man schaue die Dinge auf, die wir auch um Zukunftsfähig zu sein, da vornehin stark setzen wollten. Vielleicht da wird doch noch ein Stück tiefer in die Technik rein springen. Wir haben eben die alte Plattform, wo ganz stark ordnet getrieben. Und das sind natürlich gewisse Lizenzkosten, die uns Prämis schon auf einen zukommt. Und das wäre in der Cloud wahrscheinlich noch deutlich schlimmer geworden. Und das war auch ein Grund darum, warum wir diese die Teile ausgebaut haben. Und wenn man eh schon leicht gewichtiger wird in Sinne Dattenbank und Applikationsserver, die Idee war damals eigentlich auf Spring Boot zu gehen, dann liegt das auf der Hand auch die Möglichkeiten von modernen Plastauengebungen wie Kubernetes und in Containern umzuswitschen. Und dann war das eigentlich relativ klar, dass wir das auf einmal tun werden. Bei einer oder anderen hat vielleicht schon mal so ein einiges Projekt gemacht. Ja, wenn man einen Hub macht und entsprechend investiert und dann so einen Punkt kommt, wo ja alles eigentlich funktioniert, dann ist es immer sehr schwer, einen zweiten Hub hinzubekommen. Das war zumindest also meiner Sicht auch noch einen Grund, warum wir gesagt haben, wir machen das in einem. Jetzt hast du vorhin auch die harten Deadlines angesprochen? Dominik, ich kann mir vorstellen, dass das gerade bei einem Projekt dieser Größe herausfordernd ist. Wie hat denn dieser Zeitdruck die Projektplanung beeinflusst? Ich glaube der größte Einfluss war natürlich, dass wir einen sehr hartes Entdatum hatten, wo von Anfang an allen klar war, bis zu dem Termin, wo das Rechentrum da geht, der Strom abgeschaltet wird. Also wirklich physisch, man müsste fertig sein. Ansonsten sind wir jetzt am Beaufleihen und wie gesagt, das ist die, das ist sozusagen unser Kernbanksystem, wo alle unsere Kunden Daten mit ihren Meilen konnten und allen Transaktionen rüberlaufen. Wenn das nicht da ist, dann funktioniert ab dem Tag De facto nichts mehr, was mit mal zu Mäuigen wie zu tun hat. Also von daher war das sicherlich der Klargrundstrainer von Anfang an da war. Die Schwierigkeit, die wir hatten, merk ich ja, war, dadurch hat es eben kurz angerissen, dadurch das System über die Jahre gewachsen ist. Das hat sich mal an keine von Anfang an eine vollständige Transparenz darüber hat. Die Groß ist eigentlich das, was man da tun muss. Das heißt, dass die Anzahl der anderen, anderen, anderen uns, relativ groß am Anfang. Und von daher haben wir gesagt, wir haben ja zum einen das hingehen und zum anderen, also wohl der Christ, glaube ich, ein bisschen erzleitet, hart sind, haben wir gesagt, wir machen das so in einem agilen Projekt Ansatz und versuchen uns eben iterativ dahin zu entwickeln, dass wir jeweils zum jeweiligen Zeitpunkt klar haben, was die nächste richtige und wichtigen Dinge zu tun sind. Und die Freiheit zu haben, dass das sozusagen bei Design so ist, dass wenn wir etwas Neues, ein Neues annauen, zu einem Nohn machen, also etwas Neues entdecken, dann bei Design reagieren zu können und zu sagen, wir machen jetzt das nächste, was jetzt gerade sich als richtig erweist. Und ohne dass wir da, ich sag mal, in der klassischen Projektstruktur anfangen müssen, eine Egligenzrequest zu vereinbaren, übrigens auch in der vertraglichen Situation zwischen unseren beiden Unternehmen. Deswegen haben wir gesagt, wir setzen das vorhin nach einer Agilauf, wir spielen das gemeinsam, treffen die Entscheidung, was jeweils Priorität ist gemeinsam und bauen dann darauf, dass die Zeit, die wir bis zum Cutover haben, reicht. Das haben wir natürlich vorhin schon ein bisschen angeschaut, also es ist jetzt nicht so, ansatz zu sagen, so genau, wissen wir, dass unterwegs nicht werden, damit wir eine Menge Dinge unterwegs lernen, da müssen wir darauf reagieren. Und das haben wir versucht, eben in diesem Agil-Nansatz zu berücksichtigen. Und der Christanns, vielleicht noch wissen, ergänzen, was wir sozusagen an Safety-Netz eingebaut haben. Diese Agile-Ansatz war meiner Ansicht nach das wichtigste oder das einzige, was wir in dem Moment tun konnten, weil die Enge des Zeitrahmens hätte eine lange klassische Wasserfall, eine lüse Phase, was es denn jetzt alles genau zu tun, bis zum Ende einfach nicht ermöglicht. Wir mussten einfach sofort anfangen. Es gab genügend Dinge, wo wir, von denen wir wussten, die mussten getan werden. An die sind wir sofort gegangen, während wir die implementiert haben. Wir haben wir unsere weitere Dinge überlegt, das waren so die None-Annaun-S, die wir gelernt haben und während wir die None-Annaun-S gelernt haben, haben wir auch die Andonen-Annaun-S gelernt. Gleichzeitig haben wir uns immer wieder Malensteine gesetzt, wo wir den Fortschütz auf gewisse Weise trecken können und auch so ein Sicherheitsnetz an einziehen konnten, indem wir gesagt haben, "OK, zu diesem Zeitpunkt muss eigentlich das und das funktionieren. Zu dem und dem Zeitpunkt müssen wir das und das wissen." Und dann eben, und es ist ja in der ergehen Welt mit einem harten Anschlag, die einzige Möglichkeit, wie man steuern kann, indem man den Scope immer wieder überprüft und "OK, was muss ich denn jetzt wirklich haben und was nicht?" Und ich glaube, das ist das, was es am Endeffekt reakt technisch zum Erfolg geführt hat. Kriss, jetzt hat es ja der Dominika Zeltes, ihr euch bereits schon aus vergangenheit, gut kennt und die Zusammenarbeit aus der vorherigen Erfahrung da ist. Hat denn alles so wie es euch vorhin ein Überlegt habt, auch geklappt? Oder muss es dir doch Kompromisse eingehen, gerade bei dieser wirklich harten, harten Netline? Ja, mussten wir leider, ich hat es ganz kurz vorher angedeutet, eigentlich wäre die Zielarchitiktur gewesen, die alle JE-Technologien komplett aus dem Steck zu werfen und auf Spring Boot zu wechseln. Da haben wir relativ schnell gemerkt, dass die Abhängigkeiten so groß sind, dass es einfach ist, so ein Interim-Scenario zu nutzen. Also anstatt, das wäre Logix einfach einen deutlich leichtgewichtigeren Applikations Server zu nutzen. Und es war eigentlich eine Entscheidung, die haben wir schon noch zwei Monaten oder sowas gefällt, dass wir das tun mussten. Und da das resultierte auch, dass wir zum Beispiel das Badsch-Frame-Work, mit dem wir alle uns alle da dahein importieren und exportieren, nicht ersetzen durch neues, sondern auch auf dem alten bleiben. es waren unsere deine die wütterm pilden die wir relativ wік verschlupen mussten范 welcher das heute auch im engl dimmbarème den des chat
art nochwich hiel aspect mal anne von st reine und safe denn jetzt optionart的是 ein der gekrist apprenticeship beergatan disorders mit zdemestimmt النostalt ist des betting der funktion alt South where den mellan stürmer er daweise nicht halten können was dann dazu geführt hat das wir gesagt haben ja okay dann müssen wir jetzt tatsächlich in sein kathau war termin nochmal verschieben und wir müssen auch aber plan b nachdenken oder plan c also jeden fall die bizigerenden aktionen sozusagen starten und das waren sicherlich auch Dinge die uns eben mit der vorgehend zwar sind mindestens haben und die war deswegen eben genauso aufgesetzt haben das für diese möglichkeiten haben das auch zu navigieren unter der wechsel sagen sind für entrag also unseren berndauernd schatzen wir da auf dem richtigen fahrt kommen wir daraus wo wir raus kommen müssen und wenn nicht dann eben aber auch tatsächlich zu reagieren oder zu agieren absolut war war notwendig immer einen plan b zu haben lange war der plan b der das wir vielleicht den vertragen mit dem und prämisdienstleister doch noch etwas verlängern könnten irgendwann ist der teil dann weggebrochen und dann was glaube ohne dem plan b auf diese agilieart und weise vorzufahren wird das management nicht dauerhaft abnicken weswegen wir dann ja eigentlich in der heißen fase dann noch mal an einem zusätzlichen plan b gearbeitet haben ich glaube das war auch gut weil man sich vielleicht vorstellen kann wie viel da an so den großen system dran hängt und was passieren würde wenn es nicht wenn es einfach nicht mehr da wäre werden glaube ich gut und wir wussten auch was wir tun wenn das tatsächlich schief geht spannend ist ja auch mal für die für die zuhörer daraus dass ich habe es eben so ein bisschen erwähnt ist ein kontroführungssystem also dann deswegen verwend ich mal so ein bisschen gegen den bekriffkern banksystem das heißt da werden transaktionen verbucht also in unserem verleben keine euro transaktionen sondern malen transaktionen und da kann ich halt wenn ich einmal eine karteau war gemacht habe auch nur begrenzt zurückrollen das heißt im dem moment wo ich die daken mit red ab und dann anfange transaktion auf der neununggebung und in der neun datenbank zu verarbeiten kann ich halt nicht einfach so sagen dass ich das mal einfach zurückrolle wenn jemand seine malen ausgegeben hat und da findet ein premium für gebucht hat oder eine koffer im welthaft gekauft hat da kann ich nicht einfach sagen ich roll diese transaktionen weil er hege dann tatsächlich auch dafür abgeliege transaktionen dran das waren weiterer konstruint immer zu berücksichtigen hatten deshalb uns sicher genug sein mussten zu sagen zu dem zahltpunkt wo wir es dann wagen den karteau war zu machen gibt es kein zurück also da ist wäre zumindest sehr sehr schwierig gewesen deswegen haben wir von vor an der reingesaktiv fokussieren uns darauf möglichst viel konfüttens zu erzeugen darin zu den zack zu den zacken das karteau war es genau zu wissen was passiert dann wenn wir das jetzt tun und da wirklich auch sehr sehr hohen sicherheitsgrad zu haben aber das alles vorher schon vorbereitet haben getestet haben in der live umgebung um da einfach zu wissen wenn wir den hebel umlegen dann wird sicherlich an der anderen schülle noch ein bisschen rumwählen aber das ist ein grundsätzlich hält das grundsätzlich das tut was es soll das wird da keine offensichtlichen fehler mehr drin haben das haben wir alles vorher eben entsprechend mit getestet absolut ich meine das ist natürlich ein mamutsprojekt das ihr auf die beine gestellt habt und es muss absolut sichergestellt sein das gerade bei so einer harten deadline die vorangegangene schritte funktionieren wohl wissen dass es eben die ihr gesagt habt non unknowns gibt was mich nur interessieren würde um das zu bewältigen ihr wartet es ja nicht nur zu zweit sondern er hat sicherlich ein entsprechen des team gehabt wie hat sich gerade dieses dreier gespannt euch steht aus mindestens drei unternehmen in der zusammenarbeit ausgewirbt bzw. wie habt ihr wirklich diese unterschiedlichen expletiesen wie eingesetzt ja da sprich so einen wichtigen punkt an egoa aber ich würde gerne noch ganz kurz auf auf dominik zurückkehren diese qualität haben wir eigentlich dadurch erreicht dass wir schon schnell versucht hatten eine proaktive umgebung an start zu bekommen ja das heißt das war eigentlich ein anderer von von einem sehr geschützten abskollegen den materias padstag der gesagt hat ja macht das doch mal so baut erst mal die produktionslinie auf versucht möglichst schnell den treffig auf der echten auf der neuen produktion zu haben um zu sehen ob das funktioniert und ob es net funktioniert welche latensies es gibt welche welche wie es funktional funktuer ist usw und das hat uns sehr gut kräufen sehr aktiv früh ein sehr gutes gefühl zu haben das ist zumindest technisch von der älimesinne von performance und stabilität kein problem geben wird haben so und zweitens war es natürlich so dass wir in der zeit sehr viel lernen mussten ja ich wir als lps mit der arbeite und dort haben uns eigentlich zwei dinge kräufen zum einen experten einkaufen zum beispiel von der firma sordwärks oder auch von aws professionels services und zweitens diese diese experten auch ganz fokussiert zusammen zu bekommen und dort sind wir auch auf andraten von aws auf so ein eba wirkschaft gegangen was für mich sage ich mal leise heißt spär die besten leute die der hast ganz fokussiert zu speziellen themen für eine woche in einen raum ein reiter ist so gut es geht vor damit die leute in dieser woche so so so flu und wie möglich miteinander arbeiten können und das war als als mechanik einfach ein ein ein learning ein learning für uns deswegen jetzt nicht nur in dem ibs also wir haben in diesem ibs auch unfassbare portschritte gemacht da nicht nur im sindel von der umsetzungshand auch im sindel von lernen aber wir haben das auch immer wieder innerhalb der lps gemacht solche solche kurzen sprints sozusagen einzuführen in dem wir uns eine große fläche gebucht haben zusammen zusammen gerottet haben uns dediziert vorbereitet haben was passiert in dieser woche und das dann gemeinsam durchzuziehen und das ist schon für mich eine eine faszinierende erforderung gewesen welchen spiet man dort dann dann hinbekommen der wie so so ein bisschen wie so eine raketen einsatzzentrale ja da geht was vorwärts der wird sich der kollege pazer sicherlich freuen das zu hören aber nur zu ein ordnung was das experience based acceleration workshop also kurz eba am betrifft das klang jetzt natürlich recht strakronisch die leute einzusparen aber erfahrungsgemäß kann ich wirklich nur bestätigen dass diese konzentrierte und fokussierte arbeit im sprint wirklich wunder bewirbt wenn man sich nicht in anführungszeichen ablenken lässt und über eine längere zeit sich wirklich nur eine sacher fokussiert aber dank auf jeden fall für die blumenhanderstelle um vielleicht nochmal mit zahlen das ganze zu untermauen gesprechen hier von milionen kunden daten die wie kreiert migriert werden mussten wie habt ihr das denn geschafft wir haben eigentlich auf wie schon gesagt eben dieser dieser schon bereits hergestellten productions umgebung genutzt um dort auch schon die daten lange vorab mit a wstms also mit diesen daten migration service zu migrieren heißt wir hatten schon monatte vor dem go live einen kompletten abzug der daten über einen initial load gezogen und einen ständig laufen den delta load der echten daten des aus dem alten system des neue system das heißt im kartt aber selber musste nur noch umgeschalten werden und ja genau hat was mal ganz spannend war bei dem vg natürlich auch dadurch dass wir diese migrations umeignetig laufen als delta load haben laufen lassen aber wir haben auch irgendwie zwei drei mal verprobt eben wie ist denn das eigentlich wenn bs die gesamten daten einmal durch migrieren und samt eiben gemerkt wenn wir da jetzt eine karteau war machen wollen denn nicht irgendwie ich glaube die erste schätzung war drei vier tagetown time oder sowas krasse was ganz ganz genau da ging es darum dass das zwar die daten migrieren sind aber konstrains foreign keys etc. nachgebaut werden mussten und die macht das macht man dann nur einmal und da war natürlich war es so dass das mehrere stunden gedauert hätte wenn man das ohne flege macht hätte genau und da haben wir durch dieses vorgehemen mit der produktion umgebung vorher aufbauende so da echt daten migration mehrfach vorher testen die delta loads zu schauen auch zu gucken wann wann ich glaube trinkweiternd dass wir eben diese in die die live in die zierung quasi beim import ausgescheitet haben und dann quasi gesagt haben erste migrations durchlaufen lassen danach die die in die zerser aufbauen hat uns dann natürlich auch noch mal ein bisschen mehr cycle time sozusagen gespart und natürlich dann am ende des tagest dazu beigetragen dass für den karteau war dann das hätte ich auch sehr schnell organisiert durchlaufen lassen können ja genau da war dann noch der tweg mit um dann von diesen zuerst geplanten so sechs sieben stunden noch mal auf eine echte downtime von der stunde oder sogar darunter zu kommen hatten wir dann das alte system als readout diversion während des kuppletten cut hours live also mit ausnahm er von diesen 60 minuten von den freie gesprungen haben als heißt die Kunden die nur lesend auf das system zugegriffen haben sprich man meldet sich an man schaust ist ein profile an man schaut ob seine amalen schon angekommen sind etc all diese standard funktionalität hat auch in dieser zeit schon funktioniert obwohl wir eigentlich das system schon vom vom letzten um den hatten nur zum verständnis der karteau daote etwa sieben stunden und nur 60 minuten waren tatsächlich nicht erreichbar wir habt ihr denn diese minimale downtime erreicht und welche hauptschritte könnt beziehungsweise dürft ihr denn den zuhören also zum einen was war es vorbereitung und ein fassenplan eben schon möglichst viel vor dem cut over er in in in der produktion zu haben und zu testen das war die eine Sache gerade wenn es um bei der masser der daten und der zweite teil war diesen cut over auf anderen umgebungen schon zu üben und genau zu wissen minne zioes oder eigentlich sogar auf sekunden ebene wer waren was wo machen muss und es immer weiter zu optimieren versuchen möglichst viele Dinge parallel zu machen und so haben wir uns eben auf diese 60 minuten runter optimiert parallel und koordiniert das sind die wichtigsten elemente höre ich da gerade raus aber was ist denn da besonders wichtig und wie viele leute aus ihren teams wandende überhaupt beschäftigt das weiß ich allextoktisch genau im cut over ich würde sagen dass wir haben den cut over selber an einem tag um 21 uhr circa begonnen mit 5 6 leuten und dann je nachdem wieder planen es aufgezeigt hat es neutere zugekommen oder weggegangen im endeffekt live waren wir dann um 1 uhr des erste mal oder einer 30 dann gab es noch nacharbeiten ich würde sagen overall waren immer 7 8 leute damit beschäftigt diese die die tatsks durchzuziehen wenn man überleg was da alles dran hängt eine überschaubere anzahl von personen aber ich meine hey der folg gibt euch erricht ihr hat vorhin einen wichtigen sats gesagt der mir noch ein gedächtnis geblieben ist unterschätzen niemals die komplexität einer netzeganbindung innerhalb eines weltkonzerns habt ihr da einen beispiel in der umstellung der migrations dass dazu passt da war eine große herausforderung in der tatss wenn man so eine kipp von sammbar wie gesagt als wenn man naart kernbanksystem ausgeht dann es ist natürlich so dass es auch sich quasi ohne kernbank funktioniert hat aber viel der funktionalitäten kommt eben daher dass man das man an das systeme angebunden hat die tatss hat diese verbuchung tatsächlich vornehmen und das läuft eben über diverse netzextrecken allerer kuhleure sowohl innerhalb des lufthenser konzerns als auch zu angeschlossen in partner alliance star alliance a jeder mange anderer partner die wir da angebunden haben und das ist einfach in der some der komplexität die dahinter steckt mit den verschiedensten im ruten die solche netzeckverbindung annehmen müssen sondern können sollen aus psychiothekern oder eben aus praktisch anbegegen anbindung es können tatsächlich ein großes thema gewesen zu schauen wie kriegen wir diese ganze listeanverbindung sauber gebaut wohl wissen dass bei den das waren deutlich mehr als hundert verbindung um die es da ging und jede davon sozusagen mit ihren einzelnen eigenarten das ist eine komplexität die einfach viel zeit braucht weil jede dieser verbindung einzeln eben eingeschaut werden muss und mit unterschiedlichsten deuten koordiniert werden muss das ist tatsächlich eine für eine der größeren technischen strategis gewesen die wir die wir an der stellarten und glaube eines der lördingskriss wie war das nach vorne hin angehen würden vielleicht auch einen konkretes beispiel jetzt an hand an ein technischen beispiel in dieser alten on chemiswelt oder in dieser klassischen netzwerker welt da sprechen schlicht man sehr viel über konkrete ip adressen ip ramesch es etc wenn man in mit cloud system sich bescherbar mit cloud systemen arbeitet dann sind es alles naming services ja das heißt die ip adresse die vorge die vergeben werden in 99 prozenter fälle dynamisch vergeben aus der range steben wird verhanden ist ja und das bedeutet wenn man ein system hat wie sambar mit an den 200 stütz stellen teilweise tief in ein partnersysteme in in die malzen mor aber auch tief in den luftanzer konzerren rein dann heißt das das Dinge die halt immer fest verratet über irgendein welches ip adressen oder ip adressen ranges plötzlich so nicht mehr funktionieren das heißt dass die ganzen feierwolls nicht mehr funktionieren weil diese feierwolls natürlich aus sicherheitsgründen immer so getwiegt sind dass nur das minimalste was man eventuell braucht auch offen ist und das funktioniert in in in in in dieser in der herangehen zweise halt nicht oder nur anders oder nur mit aufwand und das ist so der punkt der der den den ich würde sagen ich persönlich glaube ich etwas unterschätzt habe andere bei uns im unternehmen haben wir das schon vorher gesagt und haben gesagt kris fangen damit an das wird das schlimmste ja und ich dachte immer so Leute ich streppe ziehen kann nicht so schwer sein doch ist es und wenn die streppe steht christ der also so wenn man zum usilean nach oben arbeiten das ist wenn ich irgendwie so ein endliches geschafft habe mit den feierwolls in leer vier konaktivität zu machen dann kommen solche späse wie dns also manche nutzen dann halt nicht doch nicht die starten ip sondern den es dann ist die frage auf welchem den es aber konfigurier ich welche privaten ip und wenn ich das geschafft habe dann kommt irgendein auch noch im usilean noch weiter oben dann oder auf der ähnlichen kategorie dann das ganze thema es ist elzertisch harte weil auch die können dann auf den diverser kule aufgesetzt sein und müssen eben entsprechend eingeschütt werden also von daher die ganze latte ist glaube ich ein großzulöhring für die die uns jetzt zuhören und der ähnliche herausforderungen hätten macht euch das ganz vorne auf den projektplan weil die gefährliche erkenntnis oder die die tragische erkenntnis ist eben wenn ich irgendwie eine backen application habe dann kann ich immer noch relativ kann ich noch noch ein bisschen drum rum zaubern wenn ich eine verwendigverbindung nicht habe dann steht das ganz zu den und zwar so lange bis die verbindung steht und erst danach kann ich danach funktional weiter testen also das ist sicherlich ein großes thema wenn so komplexen begrazen jetzt seit ihr ja erfolgreich gewesen und man kennt es ja auch von der it oder wenn man gerade mit dem vorgesitzen spricht und das projekt vorstellt dass man lieber nochmal einen plan b haben sollte falls etwas nicht so auf anheb funktioniert wie sollte gerade fixe ip-adressen oder nameserver probleme sind ja nicht direkt mit dem ersten planen losbar typischerweise gab es in dem projektsituationen bei denen ihr auf alternativen Lösungen umschalten mustet ja es gab eigentlich zwei momente der eine moment war als wir von der grundachetiktor abweichen mussten das war schon relativ früh und ein zweiter moment war als wir einen den klaren benen nutzen mussten oder ziehen mussten doch dieses dieses dieses diesen zeitpunkt an dem des rechentzentrum abgeschalten wird noch ein bisschen zumindest ist zu verlängern ja wir hatten irgendwann mal so ein sulfé bräuter mehn den konnten wir dann zumindest auf ende merz erschieben das war ein klaren be aber dann war dieser plan be weg und deswegen wäre das für mich auch immer ein learning wenn man hinten so einen harten anschlag hat dann ist wahrscheinlich auch und ist eigentlich ist es unumgänglich auch ein klaren se zu haben und der plan c sollte mit der sollte mit wachsen ja so höher die konvidens ist um so weniger aufwand stecke ich da rein den auch wirklich umzusetzen und wenn die wenn man sich so ein bisschen unsicher wird dann dann sollte man eventuell des so beländsten dass man auch hier investiert um auch denn den plan c auch einschalten zu können ja das ist die eine Sache ist sich einen im kopf zu haben und es andere ist ja auch den schalter drücken zu können und in umzuswischen zum glück haben wir unserem plan c nicht ziehen müssen aber ich glaube es hat uns alle etwas rüger schlafen lassen das wird den hatten und wenn es nur der war mit einem großen die verwagen dort hinzufahren die rechner abzuholen und irgendeinen andern einiger maßen klimatisierten raumzustellen das wäre so der alle alle alle alle schleimste wir es jetzt gewesen lassen wir eben zusammenfassen projekt gemeistert umstellung erfolgt erstmal durchartem aber wie sieht es denn mit der zukunft aus habt ihr da noch pläne mit sachen die vielleicht noch machen wollt gleich jetzt ein bisschen gesagt dass das diese das umheben von samt an die klauter war es ein element dazu gegebener war es noch sehr entscheidend das und sehr groß ist auf uns samt gesamt modernisierungs aufs aufs samt modernisierungsworkme von daher gab es vorher aktivitäten krasatz ein bisschen angedeutet in der applicationsarchitektur zu verändern also da ist also technische komponenten wie application zu aber daten bei technologien auf einen anderen stand zu heben aber natürlich haben wir auch weitere Dinge vor wie eine stärkere modularisierung mal zu gucken dass wir auch unsere time to market auf verbessern können auch unterzuneben de neue kappelbilitisse in der cloud verwenden von cloud native komponenten solche Dinge mehr aber auch so banale Dinge ehrlicherweise wie kostene optimierung also eine cloud umgebung man dann nackt erst mal reingeht dann gibt man erstmal auf nochmal sicher logischerweise wäre es mal sicherlich in die vorhin dass es aber aber da gibt es natürlich noch den mehr länger dann den die wir da immer entsprechend optigen können sehr gut aber jetzt zum schluss noch eine freiche frage hat es den spaß gemacht ist eine gemeine frage weil weil also hinterher wenn es gefängt funktioniert hat es natürlich immer spaß gemacht aber andere kwirken drauf schaut in der situation wenn man da drin steht und dann sagt ich habe jetzt irgendwie auch eine konzern vorstand an der schöne versprechen müssen zu sagen hey wir machen das umigration und es gibt kein es ist es ist es gibt keinen zurück also in dem momento wie ein schalter umgelegt haben ich habe gesagt muss es auch funktionieren werden ein paar Sachen finden die wahrscheinlich nicht funktionieren so war es dann tatsächlich auch Gott sei Dank auch so was geplant hatten durchaus welche was es geplant hatten aber es nicht aber wie wir es gehofft hatten das sind die wir auch relativ zeit eine griff bekommen aber das macht natürlich dann relativ wenig spaß wenn man dann merkt wir sind jetzt live es gibt kein zurück 95 90% funktionieren genau wie sie sollen aber es gibt dann auch so ein bis fünf prozent die funktionieren noch nicht unterhängen echte usr dran unterhängen echte prozesse dran und das hat echte Auswirkungen auf mitarbeiten da so Kollegen oder eben auf Kunden und dann unter zeitdruck zu sagen das beste was ich machen kann ist dafür zu sorgen dass es in dieser neuen umgebung funktioniert und ich glaube was mir ist es mit spaß gemacht hat kris was der punkt zu sagen hätte es ein bisschen eingedeutet dass wir in der cloud rolling die pläumens machen können dort ist gerade mit der kubernetes technologie und wir hatten mal gesagt das ist so ein item eines unserer modernisierungsthemen war zu sagen wollen rolling die pläumens ermöglichen und dann waren die alte in der situation zu sagen wir können es nicht irgendwie alle paar Stunden hier in der downtime machen und dann gesagt okay jetzt dann ziehen wir halt dieses beklagge item vor uns sagen wir machen jetzt rolling die pläumens und hoffen wir das ist klappt und das war das war das hat spaß gemacht das hat spaß gemacht und das war auch irgendwie an learning was ich da daraus gezogen habe das hat was ich um den was sagen wollte ich glaube man braucht es macht am meisten spaß wenn man auch mut hat und wenn man gemeinsam mut hat nach vorne zu gehen und solche Dinge einfach mal zu machen und wenn man schnell genug lernt und eine gute druppe zusammen hat um solche um um um die meisten eventualitäten die so auf einen einschlagen irgendwie hinbekommen dann dann sollte man bis nutzen eben um mutig zu sein das das halte ich für wirklich wichtig und es macht dann auch spaß wunderbare schlussworte ihr beiden vielen dank für dieses spannende Gespräch an kriss von der lps und dominik von maisen mor vielen dank das hat richtig das hat richtig spaß gemacht eigentlich gar nicht nur anschließend danke schön dass wir hier seit dort dass ich ihr seid auf der und damit bedanke ich mich auch an alle die heute eingeschaltet haben und ich freue mich euch wieder bei einer neuen folge von klautorizonte dem abs podcast auf deutsch begrüßen zu können
Podcast Summary
Key Points:
Migration des Kernsystems "Sammbar" von einer On-Premise-Infrastruktur in die Cloud (AWS) aufgrund notwendiger technischer Modernisierung und der geplanten Abschaltung des Rechenzentrums.
Projekt wurde unter starkem Zeitdruck und mit agilen Methoden durchgeführt, um Flexibilität bei unvorhergesehenen Herausforderungen zu bewahren.
Technische Umstellung beinhaltete den Abbau veralteter, datenbankintensiver Strukturen und die Hinwendung zu Cloud-nativen Technologien wie Containern, anstatt eines einfachen "Lift-and-Shift".
Enge, vertrauensvolle Zusammenarbeit zwischen den Unternehmen, Nutzung von Fokus-Workshops (z.B. EBA-Workshops von AWS) und ständige Risikoabsicherung durch alternative Pläne (Plan B/C) waren entscheidend für den Erfolg.
Summary:
In der Podcast-Folge diskutieren Igor, Dominik von Meißen Mor und Chris von der LPS die erfolgreiche Migration des Kernsystems "Sammbar", eines europäischen Vielfliegerprogramms, von einer On-Premise-Umgebung in die AWS-Cloud. Hauptauslöser waren die notwendige technische Modernisierung einer über 15 Jahre gewachsenen Anwendung und die drohende Abschaltung des alten Rechenzentrums. Das Projekt stand unter enormem Zeitdruck, da das System zum Stichtag voll funktionsfähig sein musste.
Statt eines einfachen "Lift-and-Shift" entschied man sich für eine grundlegende Architekturüberarbeitung hin zu cloud-nativen Technologien, um Skalierbarkeit und Kosteneffizienz zu nutzen. Die Zusammenarbeit wurde agil gestaltet, um auf unbekannte Herausforderungen reagieren zu können. Kritische Erfolgsfaktoren waren die frühe Einrichtung einer produktionsnahen Testumgebung, die konzentrierte Arbeit in fokussierten Workshops (wie AWS EBA) und die ständige Erarbeitung von Fallback-Plänen.
Besondere Sorgfalt galt der Datenmigration und dem Cutover, da es sich um ein transaktionales System handelt, in dem Buchungen nicht einfach rückgängig gemacht werden können. Die vertrauensvolle Partnerschaft und der effektive Wissensaustausch zwischen den Teams waren für die Bewältigung dieses komplexen Vorhabens entscheidend.
FAQs
Es gab mehrere Auslöser: eine geplante Abschaltung des Rechenzentrums und der Wunsch nach technischer Modernisierung. Man wollte nicht nur einen einfachen 'Lift-and-Shift' durchführen, sondern Cloud-native Vorteile wie Skalierbarkeit und Elastizität nutzen.
Die Cloud ermöglicht schnellere Bereitstellung von Test- und Entwicklungsumgebungen, bessere Skalierung bei Lastspitzen und Kosteneffizienz durch moderne Plattformen wie Kubernetes. Zudem entfallen hohe Lizenzkosten für Legacy-Datenbanken.
Die harte Deadline erforderte einen agilen Projektansatz. Statt eines langen Wasserfallmodells wurde iterativ gearbeitet, um flexibel auf neue Erkenntnisse reagieren zu können und Prioritäten gemeinsam anzupassen.
Man konnte nicht vollständig auf Spring Boot umstellen, sondern nutzte einen leichteren Applikationsserver als Interimslösung. Bestehende Frameworks wie für Batch-Verarbeitung blieben erhalten, und der Cutover-Termin musste verschoben werden.
Durch frühes Aufsetzen einer produktionsnahen Umgebung und intensives Testing. Man fokussierte sich darauf, vor dem Cutover maximale Konfidenz aufzubauen, da ein Rollback von Transaktionen im Live-Betrieb kaum möglich gewesen wäre.
Durch konzentrierte Workshops wie den 'Experience Based Acceleration (EBA)'-Workshop, bei dem Experten fokussiert an spezifischen Themen arbeiteten. Diese Sprint-ähnlichen Phasen ermöglichten enorme Fortschritte und Wissensaustausch.
Chat with AI
Loading...
Pro features
Go deeper with this episode
Unlock creator-grade tools that turn any transcript into show notes and subtitle files.