Cloud-Migration und -Modernisierung

Jonathan Allen:
Willkommen bei „Conversations with Leaders“. Mein Name ist Jonathan Allen, ich bin Direktor im Team für Unternehmensstrategien bei Amazon Web Services. Heute begleitet mich mein Kollege Jake Burns. Wir werden heute über Cloud-Migration und Modernisierung sprechen. Jake, möchten Sie sich bitte vorstellen?

Jake Burns:
Ja, vielen Dank, Jonathan. Mein Name ist Jake Burns. Ich bin Unternehmensstratege hier bei AWS und arbeite seit etwas mehr als sechs Jahren in dieser Position. In dieser Zeit habe ich mit über tausend Kunden zusammengearbeitet, wobei viele dieser Projekte das Thema Migration betrafen. Ich freue mich daher sehr, dieses Gespräch mit Ihnen zu führen, Jonathan, und einige der Erfahrungen zu teilen, die ich im Laufe der Jahre gesammelt habe.

Jonathan Allen:
Das ist beeindruckend, Jake. Und ich denke, zusammen hatten wir das Privileg, mit über 2 300 Kunden zusammenzuarbeiten, und ich weiß, dass wir beide selbst Kunden waren, die große Migrationen und Modernisierungen durchgeführt haben, bevor wir zu Amazon Web Services gekommen sind. Nun sind wir beide seit über 10 Jahren in dieser Umgebung führend, und ich möchte nicht zu sehr auf die Gründe eingehen, warum Kunden migrieren. Ich denke, das hat sich mittlerweile sehr deutlich gezeigt, denn Millionen von Kunden nutzen AWS. Ich möchte direkt zu den Erkenntnissen aus diesem Gespräch kommen, Jake.

Sie und ich sind in der privilegierten Lage, diese Gespräche führen zu können. Wir werden ständig nach diesen Erkenntnissen gefragt. Wenn Sie jetzt zurückdenken, sowohl an Ihre Zeit als Kunde als auch an Ihre langjährige Tätigkeit bei Amazon Web Services, was sind die drei wichtigsten Erkenntnisse, die Ihnen in den Sinn kommen? Darauf möchte ich eingehen. Anschließend möchte ich zu einigen praktischen Ratschlägen zu den Mythen über die Migration kommen, die in der Öffentlichkeit kursieren. Was sind also die drei wichtigsten Erkenntnisse, die Ihnen spontan einfallen?

Jake Burns:
Ja, wenn wir über Migrationen und Transformationen im Allgemeinen sprechen, trifft dies meiner Meinung nach ebenfalls zu. Wenn ich an meine erfolgreiche Migration in den Jahren 2015 und 2016 zurückdenke und an die Kunden, mit denen ich seitdem erfolgreich zusammengearbeitet habe, war ich zu Beginn meiner Tätigkeit in dieser Rolle überrascht, wie wenige Projekte erforderlich waren, um diese klaren Muster zu erkennen. Mit anderen Worten: Sie sind nicht so einzigartig, wie ich es mir vorgestellt hatte und wie die meisten Kunden es sich vorstellen. Ihre Situationen sind alle recht ähnlich, was funktioniert und was nicht funktioniert. Ich würde also sagen, das Wichtigste – und es ist wirklich schwer, eine Nummer eins zu wählen –, ist, anzufangen, bevor man sich bereit fühlt. Ich denke, das ist wirklich das Einzige, was die meisten Kunden, die sehr erfolgreich waren, einschließlich mir selbst, und ich glaube, in Ihrem Fall war das auch so, getan haben: Wir haben nicht gewartet, bis wir einen perfekten Plan hatten, um mit der Migration zu beginnen.

Kunden, die das tun, verschwenden am Ende Monate, manchmal Jahre in diesen Planungsphasen. Und wenn sie dann endlich anfangen, stellen sie fest, dass sie den Plan ohnehin über den Haufen werfen müssen, weil sie lernen, dass ihre Erwartungen und Pläne nicht der Realität entsprechen, und sie lernen durch die Praxis, wie man es tatsächlich umsetzt. Mein Vorschlag ist daher, die Planung so weit wie möglich zu überspringen und einfach loszulegen. Es gibt Möglichkeiten, dies auf sehr sichere Weise zu tun, auf die wir hoffentlich im Laufe des Gesprächs noch näher eingehen werden. Zweitens würde ich sagen, investieren Sie wirklich in Ihre Mitarbeiter. Dazu gehört auch, dass Sie sie mit ins Boot holen. Die erfolgreichsten Kunden sind diejenigen, die ihre eigenen Mitarbeiter einsetzen und sie in die Migration und Transformation einbinden. Und drittens würde ich Einfachheit nennen. Halten Sie es so einfach wie möglich. Schnell voranzukommen ist also ein wichtiges Thema und eine Art Methodik, die ich befürworte. Und um schnell voranzukommen, müssen Sie die Dinge einfach halten, denn Komplexität bremst Sie aus.

Jonathan Allen:
Das gefällt mir sehr gut, insbesondere „Hören Sie auf, bevor Sie fertig sind“ spricht mich sehr an. Eine der Fragen, die ich Kunden stelle und die ich auch aus meiner eigenen Erfahrung kenne, lautet: Versteht Ihr Führungsteam, warum Sie das tun? Ich denke, wenn es ein relativ junges Team gibt, das einfach denkt: „Hey, machen wir das“, und dieses Gespräch mit der Geschäftsleitung noch nicht stattgefunden hat, dann wird es zu Reibungen kommen. Ich persönlich finde den Ansatz „Fangen Sie an, bevor Sie bereit sind“ großartig. Ich mag die Einfachheit, aber verstehen Sie auch wirklich, warum Sie das tun? Wir haben gleich zu Beginn gesagt, dass wir nicht zu sehr ins Detail gehen werden, aber es gibt so viele gute Gründe.

Was ist Ihr Leitmotiv? Ist es die Markteinführung? Ist es die Kostensenkung? Ist es die Verfügbarkeit? Ist es die Zuverlässigkeit? Ist es die Erneuerung Ihres Contact-Center-Auftritts? Für mich ist dieser entscheidende Grund wirklich wichtig. Und dann ist das zweite Objekt, das ich absolut liebe, Ihr „Loslegen“, aber setzen Sie sich auch mit den Ängsten, Unsicherheiten und Zweifeln auseinander, die bei Ingenieuren, die vielleicht nicht direkt an der Startphase beteiligt sind, ganz natürlich sind? Wie will man es für sie zugänglich, freundlich und ansprechend gestalten, ohne sie beim Loslegen unverblümt zu verschrecken? Was denken Sie darüber?

Jake Burns:
Ja, ich stimme Ihnen vollkommen zu. Ich denke, das hängt sehr stark mit meiner zweiten Antwort zusammen, in der es darum ging, Ihre Mitarbeiter einzubeziehen und insbesondere deren Zustimmung zu gewinnen. Ich habe eine ganz bestimmte Methode, um Zustimmung zu erreichen, und ein wichtiger Teil davon ... Der wichtigste Teil ist sogar, dass sie das große Warum verstehen. Und du hast Recht, es kann nicht sein, weil wir auf die Cloud umsteigen oder weil wir modernisieren oder weil sogar der CEO das gesagt hat. Es dürfen keine vagen Gründe sein. Es muss etwas sein, das sie wirklich verstehen, damit sie nachvollziehen können, warum sie sich ändern sollen und warum sie zusätzliche Anstrengungen und Arbeit investieren müssen. Es sollte aber auch etwas sein, auf das sie stolz sein können. Es ist schwer, stolz darauf zu sein, dass wir in die Cloud wechseln, um Kosten zu sparen, oder dass wir ... Das mag für Sie ein echter Ansporn sein, aber wir werden das Fanerlebnis revolutionieren.

Wir werden es schaffen… Fans, die zu Konzerten und Live-Ereignissen kommen, werden ein viel besseres Erlebnis haben. Sie werden leichter an Tickets kommen. Sie werden tatsächlich die Plätze bekommen, die sie sich wünschen. Sie werden all die Vorteile genießen können, die diese Technologie mit sich bringt. Das ist etwas, worauf Sie wirklich stolz sein können. Und wenn Sie die Migrationsarbeit in den Köpfen Ihrer Mitarbeiter mit diesem Ergebnis verknüpfen können, das nicht aus der Luft gegriffen, sondern real ist. Es muss nur kommuniziert werden. Das wird nur sehr selten kommuniziert, dann werden sie stolz sein, diese Arbeit zu tun. Und wenn es schwierig wird, was immer der Fall sein wird, haben sie einen zusätzlichen Grund, sich durchzubeißen, weil die Arbeit, die sie tun, einen Sinn hat und für sie von Bedeutung ist.

Jonathan Allen:
Eine Sache, die ich meinen Ingenieuren immer vor Augen halte, ist, dass sie nicht um 3 Uhr morgens im Rechenzentrum sein und irgendwelche seltsamen Änderungskontrollen oder Wartungsarbeiten durchführen sollten, sondern lieber näher an den tatsächlichen Ergebnissen, die sie liefern, um diese Erfahrung für die Kunden wirklich real zu machen.

Jonathan Allen:
Lassen Sie uns zu einigen Mythen über Migration und insbesondere Modernisierung übergehen. Ich bin der Meinung, dass sich um dieses Thema definitiv eine Mythologie entwickelt hat. Und ich denke, dass es aus guten und schlechten Gründen eine Reihe von Objekten gibt, die dieses Thema umgeben. Sie und ich sind in der privilegierten Lage, zu sehen, was funktioniert. Welche Mythen müssen Ihrer Meinung nach ausgeräumte werden?

Jake Burns:
Ja. Ich denke, einer der Mythen ist, dass dies schwierig oder kompliziert sein muss oder dass es lange dauern muss. Ich glaube, all das sind sich selbst erfüllende Überzeugungen. Wenn Sie glauben, dass es kompliziert sein muss, werden Sie es kompliziert machen. Und wenn Sie glauben, dass es lange dauern muss, dann wird es das auch, aber in Wirklichkeit ist das nicht der Fall. Meiner Erfahrung nach gilt: Je erfolgreicher eine Migration ist, desto schneller ist sie in der Regel abgeschlossen. Ich würde also sagen, dass Geschwindigkeit das Risiko tatsächlich verringert, solange Sie alle anderen Dinge richtig machen. Außerdem erhöht sie Ihre Erfolgschancen und zwingt Sie dazu, das gesamte Objekt zu vereinfachen. Mit anderen Worten: Machen Sie die Dinge einfacher. Ich beginne gerne mit den ersten Grundsätzen, gehe zurück und vermeide es, das zu tun, was ich als „Migrations-Regentanz“ oder „Cargo-Kult“ bezeichne, bei dem man einfach eine Reihe von Kästchen abhakt, wie „Unternehmen A hat all diese Dinge getan und war erfolgreich. Also muss ich all diese Dinge tun, und ich muss nicht unbedingt verstehen, warum, aber wenn ich einfach alle Kästchen abhake, werde ich erfolgreich sein.“ Das funktioniert selten. Es gibt wirklich keine Abkürzung, um die Schritte zu verstehen, die für eine erfolgreiche Migration erforderlich sind. Aber die gute Nachricht ist, dass es wirklich einfach ist, wenn man zu den ersten Grundsätzen zurückkehrt und darüber nachdenkt, was wir eigentlich tun. Auf der grundlegendsten Ebene besteht eine Migration darin, dass Sie Server vor Ort nehmen und sie in einer virtuellen Umgebung in der Cloud neu aufbauen. Das kann sogar in einer virtuellen Umgebung vor Ort geschehen.

Wenn man es so betrachtet, ist es gar nicht so schwierig. Es ist nicht schwer zu verstehen. Und wenn man von diesem sehr einfachen, grundlegenden Verständnis dessen, was wir tun, ausgeht und sich fragt: „Was muss gegeben sein, damit wir dabei erfolgreich sind?“, wird das gesamte Objekt viel einfacher, als wenn man Migrationsanleitungen von Personen befolgt, die dies möglicherweise noch nie gemacht haben oder vielleicht einen Anreiz haben, es komplizierter zu gestalten, weil sie dadurch mehr Geld verdienen. Das Ganze wird viel einfacher, als wenn Sie Migrationsratschläge von Personen annehmen, die dies möglicherweise noch nie zuvor gemacht haben oder vielleicht einen Anreiz haben, es komplizierter zu gestalten, weil sie mehr Geld verdienen, wenn sie es komplizierter machen und in die Länge ziehen.

Ich denke, Sie könnten erfolgreicher sein, wenn Sie wirklich verstehen, worum es geht, und von dort aus beginnen und dann vielleicht bei Bedarf Hilfe hinzuziehen. Sie werden überrascht sein, wie wenig Hilfe Sie tatsächlich benötigen.

Jonathan Allen:
Ja, ich stimme Ihnen zu. Ich finde das auf jeden Fall überraschend. Interessant finde ich jedoch, dass einige Kunden tatsächlich etwas mehr Unterstützung benötigen. Meiner Erfahrung nach gibt es den Mythos, dass jeder Anbieter Ihnen dabei helfen kann, aber das ist meiner Meinung nach nicht der Fall. Es ist interessant, dass AWS Tausende und Abertausende von Partnern hat, aber tatsächlich nur sehr wenige, die über zertifizierte Programme zur Beschleunigung der Migration verfügen, um Kunden zu unterstützen, da wir hier sehr hohe Anforderungen stellen und nur diejenigen mit dem entsprechenden Know-how zur Migration zulassen, die Ihnen helfen können. Die Anzahl dieser Organisationen beläuft sich derzeit auf einige Hundert.

Und ich möchte noch einen weiteren Irrtum hinzufügen: Es ist nicht notwendig, ein umfangreiches Schulungsprogramm zu absolvieren, um alle Mitarbeiter zu schulen. Das ist nicht der Fall, oder? Das kommt von selbst. Ich denke, Sie sollten einen Mechanismus entwickeln, der für Ihre Ingenieure in Bezug auf die Umschulung am besten geeignet ist. Ist das Paarprogrammierung? Sind das Online-Schulungen? Sind das Anreize, um die Prüfungen zu bestehen? Ich habe sogar gesehen, dass viele Kunden die Prüfung für AWS-Lösungspartner als eine Art Führerschein für die Nutzung der Cloud verwenden. Es gibt also viele Mythen, mit denen wir aufräumen können.

Ein weiterer guter Punkt ist, dass alle sehr damit beschäftigt sind, ihre aktuellen Aufgaben zu erledigen. Sie haben keine Zeit, bei der Migration zu helfen. Was denken Sie darüber?

Jake Burns:
Oh Mann, das ist eine ganze Menge, was Sie da gerade gesagt haben. Lassen Sie mich kurz auf den Teil mit der Schulung zurückkommen, denn darin steckt so viel Wertvolles. Zunächst einmal bin ich ein großer Befürworter von Schulungen. Tatsächlich schreibe ich meinen Erfolg zu einem großen Teil der Nutzung der AWS-Schulungen zu, die meiner Meinung nach wirklich unterschätzt werden. Ich bin der Meinung, dass die Qualität der Trainer, die Qualität der Schulungen und die Effektivität der Schulungen, wenn sie vom Kunden richtig durchgeführt werden, d. h. im richtigen Kontext, den entscheidenden Unterschied ausmachen können. Das war bei mir auf jeden Fall so.

Um auf Ihren Punkt bezüglich der Schulungen zurückzukommen: Ich halte den Zeitpunkt der Schulungen für äußerst wichtig. Ich mache immer folgenden Scherz: „Wenn Sie die Moral Ihrer Organisation zerstören wollen, schicken Sie alle Mitarbeiter zur Schulung und lagern Sie dann die Migration aus.“ Sie sind bereit, es zu tun, und dann bekommen sie keine Gelegenheit, es anzuwenden. Im besten Fall geben Sie ihnen die Schulung, schulen die richtigen Personen zur richtigen Zeit. Und sie gehen in die Schulung mit dem Wissen, dass sie von dieser Transformation und dieser Migration überzeugt sind, sodass sie wissen, warum sie aufmerksam sein müssen. Es ist also etwas, das ihnen wichtig ist. Es gibt etwas, von dem sie überzeugt sind. Sie wissen, dass sie die Verantwortung tragen, dass sie am Steuer sitzen, dass sie diejenigen sind, die es tatsächlich umsetzen, also sind sie aufmerksam, und dann lassen Sie sie das Gelernte sofort in die Praxis umsetzen.

Und wie Sie bereits gesagt haben, muss Theorie und Praxis gleichberechtigt sein. Sie müssen sie an die Tastatur lassen, es kann nicht nur Theorie sein, richtig? Sie müssen es tatsächlich ausprobieren. Und wenn man das tut, kann es meiner Meinung nach außerordentlich effektiv sein.

Jonathan Allen:
Ja, es gibt einige bekannte Studien, die zeigen, dass man nur 10 % von dem behält, was man in einem Schulungskurs gelernt hat, wenn man das Gelernte nicht sofort anwendet. Wenn man hingegen an einer Schulung teilnimmt und das Gelernte sofort anwenden muss, kann man 100 % des Schulungsinhalts nutzen. Das ist eine erschreckende Zahl. Ich habe das immer wieder beobachtet.

Jake Burns:
Auf jeden Fall. Um also auf das Argument „Sie sind zu beschäftigt“ einzugehen: Ich finde diese Frage hervorragend, denn wenn man die Zustimmung seiner Mitarbeiter einholt oder sogar schon vorher, ist die erste Ausrede, die man fast ausnahmslos zu hören bekommt, „Wir sind zu beschäftigt. Wir haben unsere tägliche Arbeit. Wir sind damit beschäftigt, all diese Systeme zu warten und diese Objekte zu bearbeiten. Wo sollen wir die Zeit dafür finden?“

Ich denke, dass dies mehrere Ursachen hat. Eine davon ist, dass sie tatsächlich zu beschäftigt sind. Ich empfehle Ihnen, sich anzuschauen, was sie derzeit tun und wie viel davon tatsächlich notwendig ist. In vielen Fällen ist vieles davon nicht notwendig. Vieles davon ist, mangels eines besseren Ausdrucks, nur Arbeit um der Arbeit willen. Aber es gibt sicherlich auch legitime Aufgaben, die viel Zeit in Anspruch nehmen. Schauen wir uns das einmal an und überlegen wir, wie viel davon tatsächlich zum Wachstum beiträgt. Wie viel davon trägt tatsächlich dazu bei, die Transformation und Migration insgesamt voranzubringen? In der Regel ist es nur sehr wenig, wenn überhaupt etwas, was tatsächlich die Zukunft gestaltet. Das meiste davon dient der Aufrechterhaltung des Status quo, der Wartung der vorhandenen On-Premises-Systeme oder der Erledigung von Aufgaben, die sehr einfach ausgelagert werden könnten.

Ich habe den Ruf, gegen Outsourcing zu sein, weil ich ein starker Befürworter der Nutzung eigener Mitarbeiter für die Migration bin, aber ich bin nicht gegen Outsourcing. Ich bin sogar der Meinung, dass man es genau umgekehrt machen sollte, als es der erste Instinkt der meisten von uns sagt. Anstatt also die Migration auszulagern, was in den meisten Fällen eine schlechte Idee sein könnte, sollten Sie alles auslagern, was nicht zur Migration gehört, die undifferenzierten Arbeiten auslagern, die Arbeiten auslagern, mit denen Ihre Mitarbeiter so beschäftigt sind, dass sie sich nicht an der Migration beteiligen können.

Das bringt Ihnen eine ganze Reihe von Vorteilen, darunter zum einen, dass Sie Ihren Mitarbeitern tatsächlich Zeit verschaffen, damit sie sich an der Migration beteiligen können. Und zweitens, insbesondere wenn Sie als Führungskraft die Absicht dahinter kommunizieren und Ihren Mitarbeitern sagen: „Ich schaffe Ihnen Zeit, weil ich in Sie investieren möchte, weil ich möchte, dass Sie diese neue Technologie erlernen und weil ich möchte, dass Sie die Zukunft dieses Unternehmens gestalten.“ Dies kann zusätzlich zu einer enormen Steigerung der Arbeitsmoral führen.

Jonathan Allen:
Ja, das sind großartige Gedanken. Eines der Dinge, die ich Führungskräften und Ingenieuren immer wieder vermittle, sind zwei Lektionen aus meiner eigenen Zeit, in der ich selbst mit Technologie gearbeitet habe. Die erste lautet: Der schlimmste Fehler, den ich als Ingenieur gemacht habe und in den ich auch heute noch immer wieder tappe, ist, etwas zu optimieren, das gar nicht existieren sollte. Also pflege ich dieses Objekt immer noch im Rechenzentrum. Ich versuche, es ein wenig zu verbessern. Wissen Sie was? Dieses Objekt muss nicht mehr existieren, und eigentlich sollte ich daran arbeiten, es aktiv zu reduzieren, um mir Zeit für etwas zu verschaffen, das, offen gesagt, viel interessanter ist.

Und das zweite ist, wenn man Teams zusammenstellt – ich habe einige phänomenale Teams mit sechs oder sieben Personen gesehen, die unglaublich engagiert waren, und typischerweise sind vier oder fünf dieser Leute mit etwas beschäftigt, und die sechste und siebte Person in diesem Team fragen sich: „Hm, was mache ich gerade? Ich weiß, ich werde ein neues Projekt oder eine neue Optimierung für dieses Objekt beginnen“, anstatt zu sagen: „Lassen Sie uns eigentlich die Cloud als Priorität festlegen.“ Um auf die Lektion zurückzukommen, die wir gelernt haben: Geben wir den Menschen die Berechtigung, sich aktiv weiterzubilden und daran zu arbeiten. Und es gibt zwei schnelle Maßnahmen, mit denen sich die kognitive Workload, die Ingenieure meiner Meinung nach aus Gewohnheit übernehmen, sofort reduzieren lässt. Was sind Ihre Gedanken dazu?

Jake Burns:
Auf jeden Fall. Ich stimme Ihnen vollkommen zu. Und tatsächlich habe ich das in diesem speziellen Szenario, das häufig vorkommt, auch schon beobachtet. Ich denke, es ist die Pflicht – und ich denke, das muss von der Führungsebene klar kommuniziert werden –, dass die erfahreneren Teammitglieder und diejenigen, die sich frühzeitig für die Transformation und Migration entschieden haben, die anderen Teammitglieder betreuen, damit diese nicht durch andere Projekte und Aufgaben abgelenkt werden. Oder, um auf Ihren Punkt zurückzukommen, den bestehenden Status quo zu optimieren, was meiner Meinung nach ein großer Fehler und Zeitverschwendung ist.

Es ist in etwa so, wie wir über den Übergang von Skaleneffekten zu Geschwindigkeitseffekten gesprochen haben. Das Denken in Skaleneffekten ist der Status quo, bei dem wir davon ausgehen, dass wir ständig optimieren und versuchen, unsere Stückkosten zu senken, während Geschwindigkeitseffekte eher disruptiv sind. Es geht darum, wie wir uns tatsächlich verändern und über bessere Objekte nachdenken können, mit denen wir unsere Zeit verbringen könnten.

Jonathan Allen:
Richtig.

Jake Burns:
Ich schätze Ihre Denkweise in Bezug auf Effizienz. Um jedoch auf Ihre spezifische Frage zurückzukommen: Wenn diese Personen Teil des normalen Tagesgeschäfts sind und ihre Leistung anhand der Betreuung neuer Teammitglieder oder sogar der Rekrutierung neuer Teammitglieder und deren Betreuung und Einarbeitung bewertet wird, ist dies meiner Meinung nach ein sehr positiver Aspekt. Das ist in erster Linie hilfreich, weil es ein Gefühl der Teamarbeit und der Moral fördert, dass wir alle an einem Strang ziehen, und weil es die Inklusivität und Leistungsorientierung stärkt, was äußerst wichtig ist. Aber es hilft auch, die von Ihnen beschriebene Falle zu vermeiden, in der die Mitarbeiter durch andere Aufgaben abgelenkt werden.

Jonathan Allen:
Cool. Ich möchte nun zu einigen eher technischen Aspekten übergehen. Wir beide haben miterlebt, wie das Tool in den letzten zehn Jahren mehrere Entwicklungsstufen durchlaufen hat. Das gilt sicherlich für die Zeit, seit ich Workloads migriert habe, bis hin zu dem Punkt, an dem wir heute mit dem Database Migration Service stehen. Mit dem Schema Conversion Tool wurden weit über eine Million Datenbanken migriert. Wir haben gesehen, wie AWS MGM tatsächlich bitweise verschlüsselte Kopien von Workloads erstellt und damit das Partner-Ökosystem erheblich verbessert hat. Was denken Sie darüber, einige der Mythen zu entkräften, die derzeit in der Umgebung der Tools kursieren?

Jake Burns:
Ich bin der Meinung, dass es ein Mythos ist, dass es ein Tool gibt, das alle Probleme löst. Tools lösen Probleme nur in seltenen Fällen, wenn überhaupt. Tools sind Kraftverstärker, daher sollten Sie bereits eine Lösung für Ihr Problem haben und das Tool nutzen, um diese Lösung effizienter zu gestalten.

Sie sind kein Allheilmittel. Sie sind kein Universalschlüssel, der alle Türen öffnet. In der Regel reichen die Tools, über die Sie heute verfügen, aus, um die Arbeit zu erledigen. Sie sollten nach vorhandenen Tools suchen, um Objekte zu optimieren und zu beschleunigen. Vermeiden Sie es, sich zu sehr auf Tools zu verlassen, denn oft ist dies eine Form der Prokrastination, bei der wir nur nach dem richtigen Tool für unsere Kostenoptimierung oder die Migration einer bestimmten Workload suchen, während wir in Wirklichkeit schon längst mit der Migration fertig sein könnten oder die Kostenoptimierung mit kostenlosen Tools wie Cost Explorer durchführen könnten, das wirklich hervorragend ist.

Gibt es Tools, die mehr Features bieten als Cost Explorer? Auf jeden Fall. Könnten sie potenziell besser sein? Auf jeden Fall. Aber kann Cost Explorer 99 % der Aufgaben abdecken, die Sie erledigen möchten? Ja, in der Regel schon. Und es steht Ihnen direkt zur Verfügung. Mein Rat lautet daher, die Tools zu nutzen, die AWS Ihnen zur Verfügung stellt, denn diese sind tatsächlich sehr gut, insbesondere heute. Wenn es dann Lücken gibt, sollten Sie stets neue Tools evaluieren und prüfen, ob es etwas Besseres gibt, aber erwarten Sie nicht, dass diese Tools Ihren Fortschritt erheblich beschleunigen. Sie werden Ihnen schrittweise Verbesserungen bringen, und Sie sollten diese nutzen, aber ich denke, die größere Gefahr besteht darin, dass Kunden sich zu sehr darauf verlassen und zu hohe Erwartungen an diese Tools haben.

Jonathan Allen:
Stimmt. Eine der Erfahrungen, die ich im letzten Jahr gemacht habe und die den Weg für Kunden wirklich beschleunigt hat, ist die Erkenntnis, dass es ein Irrglaube sein kann, zu viel Zeit für die Bereitstellung neuer Tools zu investieren, die ihnen Insights liefern sollen, wenn sie einen Großteil der Informationen bereits in CSV-Dateien, in der CMDB oder in ähnlichen Systemen haben. Wenn sie diese Informationen zusammenführen, in einem Data Mart speichern und abfragen können, erhalten sie tatsächlich so viele Informationen, dass sie schneller vorankommen, als sie denken.

Jake, ich möchte nun weitermachen und etwas tiefer in die technische Seite einsteigen. Sie und ich haben unterschiedliche Perspektiven auf Migration und Modernisierung, was ich sehr schätze. Ich schätze unterschiedliche Meinungen. Wir haben lange und intensiv über die verschiedenen Varianten diskutiert, aber ich möchte etwas tiefer in Ihre Sichtweise eintauchen. Lassen Sie uns also etwas tiefer in die technische Seite einsteigen. Ich habe Sie von einer einzigartigen Migrationsmethodik sprechen hören, die zur Vereinfachung des Prozesses beitragen kann. Erzählen Sie uns etwas darüber.

Jake Burns:
Kurz gesagt, sie besteht aus zwei Teilen. Der eine Teil ist das, was ich als minimal möglichen Faktorwechsel bezeichne, eine Alternative zum 7-Rs-Modell.

Im Wesentlichen plädiere ich dafür, so gut wie keine Planung im Voraus zu betreiben, wenn es darum geht, wie wir diese Anwendungen einem Faktorwechsel unterziehen wollen, und stattdessen einen iterativen Ansatz zu verfolgen. Kurz gesagt, Sie nehmen alle Ihre Anwendungen und ordnen sie nach der Einfachheit ihrer Migration. Diese ordnen Sie nach ihrer Bedeutung für das Geschäft. Diejenigen, die für das Geschäft am wenigsten wichtig sind, kommen an den Anfang.

Sie sollten also zuerst die weniger geschäftskritischen und am einfachsten zu migrierenden Anwendungen migrieren, denn denken Sie daran, dass Sie Ihre eigenen Vollzeitmitarbeiter einsetzen, die wahrscheinlich noch sehr unerfahren sind. Sie sollten also das Risiko gering halten und die Migration so einfach wie möglich gestalten. Sie möchten während der gesamten Migration Schwung aufbauen. Sie sollten also zunächst die einfachen Aufgaben erledigen und eine Reihe von Erfolgen erzielen, um sozusagen die öffentliche Meinung auf Ihre Seite zu bringen, Schwung aufzubauen und Vertrauen zu schaffen.

Sie beginnen also mit einem Lift and Shift. Meiner Meinung nach gibt es so etwas wie einen Lift and Shift in die Cloud nicht. Es wird immer einige Änderungen geben, die Sie vornehmen müssen, aber meiner Meinung nach sollten Sie die Migration nicht zu kompliziert gestalten, sodass Sie zunächst nur die wenigen Änderungen vornehmen, die unbedingt notwendig sind, um keinen Schaden anzurichten. Eine Art hippokratischer Eid der IT. In gemeinsamen Bereichen wollen Sie nichts beschädigen, nichts verteuern, nichts weniger zuverlässig machen, nichts weniger leistungsfähig machen und nichts weniger sicher oder weniger konform machen.

Solange Sie also nichts davon verschlechtern, beenden Sie den Faktorwechsel und tun nur das Nötigste, um nichts zu verschlechtern, und migrieren dann so schnell wie möglich in die Cloud. Natürlich werden Sie sofort wieder zurückkommen und mit der Optimierung beginnen, sobald Sie in der Cloud sind, um alles so gut wie möglich zu machen, aber Sie möchten die Migration nicht unnötig kompliziert gestalten.

Einer der großen Vorteile dabei ist, dass es sehr einfach ist. Sie müssen nichts mit den 7 Rs in willkürliche Buckets einordnen. Es geht lediglich um den Grad des Faktorwechsels, der erforderlich ist, um die Anwendung sicher zu migrieren. Dies kann iterativ erfolgen, sodass im Voraus nur sehr wenig oder gar keine Planung erforderlich ist. Sie können also einfach alle Ihre Anwendungen durchgehen und während der Migration entscheiden, welchen Grad an Faktorwechsel Sie durchführen möchten. Und dann kommen Sie zum Migrationsprozess. Und hier muss ich mir einen besseren Namen dafür einfallen lassen, aber derzeit ist es der nicht blockierende Multithread-Migrationsprozess.

Im Wesentlichen teilen Sie die Migration auf. Ich scherze immer, dass dies passiert, wenn man Ingenieure eine Migrationsmethodik entwerfen lässt. Wir beginnen, das anzuwenden, was wir gelernt haben. Tatsächlich kam mir diese Idee in der AWS Solutions Architect-Schulung, die ich zusammen mit meinem Team absolviert habe. Die Idee, Microservices oder Bereiche der Infrastruktur oder des Codes lose zu verkoppeln, um Engpässe zu reduzieren und asynchrone statt synchrone Prozesse zu schaffen.

Mit anderen Worten: Wir wollen nicht durch Warten blockiert werden, denn das ist reine Zeitverschwendung. Und wir wollen nicht öfter als nötig den Kontext wechseln, weil wir dadurch den Fokus verlieren. Um es für die Quelle dieses Gesprächs so einfach wie möglich zu machen, besteht die Idee also darin, jede dieser Stufen der Migration jeder Anwendung in einen separaten Microservice im Migrationsprozess aufzuteilen, jemanden für diesen Tätigkeitsbereich zuzuweisen und dann alle Anwendungen durch diese Reihe von lose gekoppelten Komponenten zu bewegen.

Und wann immer etwas blockiert wird, weil das zwangsläufig passieren wird. Wir warten auf Genehmigungen, wir sind noch mit der Entwicklung der Anwendung beschäftigt, wir übertragen noch Daten, was auch immer der Fall sein mag – dann wechseln Sie den Kontext und gehen zur nächsten Anwendung über. Das Ziel ist es, alle beschäftigt zu halten, alle Anwendungen durch den Migrationsprozess zu bringen und alles so schnell und effizient wie möglich zu erledigen.

Jonathan Allen:
Ja. Das gefällt mir. Aus meiner eigenen Erfahrung erinnere ich mich an die Zusammenarbeit mit einem Kunden, bei dem eine der ersten Workloads, die ausgewählt wurden, besonders schwierig war. Sechs Wochen lang versuchten sie, Millionen von einmal beschreibbaren und mehrfach lesbaren Images zu verschieben, ohne eine Lösung zu finden. Sie haben das dann umgekehrt und mit den einfacheren Workloads begonnen. Als sie zu dieser zurückkehrten, hatten die Ingenieure tatsächlich eine Lösung gefunden, wie sie diese bearbeiten konnten. So haben sie diesen Schwung genutzt und schließlich erkannt: „Moment mal, wir haben jetzt all diese Bausteine, die wir nutzen können.“

Jake Burns:
Auf jeden Fall. Und noch etwas, das Sie nicht erwähnt haben: Ich glaube, Sie haben eine neue Ausgabe Ihres Buches herausgebracht, und ich halte es wirklich für das beste Buch, das ich zu diesem Thema gelesen habe. Ich bin der festen Überzeugung, dass jeder es lesen sollte. Ich sage das nicht nur, weil Sie hier sind, sondern auch, wenn Sie nicht hier sind. Ich habe dieses Buch vielen CIOs persönlich überreicht, wenn ich sie getroffen habe. Es ist wirklich sehr beeindruckend. Könnten Sie uns vielleicht ein wenig über das Buch erzählen und was es Neues in der gerade erschienenen Ausgabe gibt?

Jonathan Allen:
Ja. Danke, Jake. Ja, die zweite Ausgabe von „Reaching Cloud Velocity“ ist heute erschienen. Im Wesentlichen wurden etwa sieben oder acht Kapitel aktualisiert, insbesondere die Kapitel zum Betriebsmodell, insbesondere zu Migration und Modernisierung, insbesondere einige anspruchsvollere Themen, über die wir manchmal nur schwer sprechen können, über die Kunden nur schwer sprechen können, und ich wollte hier etwas Klarheit schaffen. Also, schauen Sie es sich an. Vielen Dank, Jake.

Jake Burns:
Großartig! Danke, Jonathan.

Jonathan Allen:
Eine gute Unterhaltung. Danke, Jake. Und unseren Zuhörerinnen und Zuhörern danken wir herzlich für ihre Teilnahme an „Conversations with Leaders“. Für 2025 haben wir wieder eine herausragende Reihe globaler Technologieführer eingeladen, die wichtige Fragen diskutieren und einzigartige Perspektiven an der Schnittstelle von Wirtschaft und Technologie präsentieren werden. Abonnieren Sie unseren Podcast, damit Sie keine Folge verpassen. Bis zum nächsten Mal, bleiben Sie gesund.

Jetzt anhören

Jetzt anhören

Jetzt anhören