Kommt es Ihnen bekannt vor, dass Teams sehr lange brauchen, um die Migration in die Cloud abzuschliessen? Das ist häufig, aber muss nicht sein. Wenn Sie sich für den Wechsel in die Cloud entscheiden, müssen Sie einige Schritten befolgen: Zuerst die Planung, dann der Aufbau und schliesslich die Verwaltung der Cloud. Natürlich gibt es bei diesen Phasen organisatorische sowie technische Herausforderungen, die eine Cloud-Migration zu einem komplexen Unterfangen machen können. Doch sie sind alle einfach zu vermeiden. In diesem Blogbeitrag gehen wir daher auf fünf typische Fehler ein, die Sie bei Ihrer Cloud-Migration vermeiden können, und erklären, wie Sie bei Ihrem Wechsel keinen Hindernissen begegnen.
1) Kein funktionierendes MVP
Das Konzept eines Minimum Viable Products (MVP) wurde bekannt durch das Lean Startup movement. Das MVP zeichnet sich dadurch aus, dass es eine Version eines Produkts ist, die gerade so viele Funktionen hat, dass sie verwendet werden kann. Auf diese Weise können Sie sofort etwas über das Kundenverhalten lernen, frühzeitig überprüfen, ob die Anforderungen erfüllt werden, und auf Grundlage des Feedbacks so lange iterieren bis Ihr MVP zur perfekten Lösung geworden ist.
Warum erzähle ich Ihnen das? Wir können diesen Ansatz auch auf unsere Cloud-Migration anwenden. Wir bringen eine Minimalversion des Projekts in der Cloud zum Laufen und iterieren von dort aus. Dieser Ansatz ermöglicht es uns, die risikoreichsten Annahmen und grössten Herausforderungen zuerst anzugehen. Auf diese Weise verringern wir das Gesamtrisiko des Projekts und halten den Feedback-Zyklus so kurz wie möglich, um auf der Grundlage des Feedbacks, das wir erhalten, Änderungen und Anpassungen vorzunehmen.
Das Schwierige an MVPs ist, sie nicht unnötig zu vergrößern. Es muss minimal sein, während das ultimative Ziel darin besteht, zu lernen und zu iterieren, um eine endgültige Version zu ermöglichen, die alle Anforderungen erfüllt. Beim MVP geht es jedoch nicht darum, die Qualität oder die richtige Technik zu vernachlässigen, sondern darum, Entscheidungen zu treffen und Massnahmen zu ergreifen, wenn wir sehen, dass sie notwendig sind, anstatt die Materie zu sehr zu verkomplizieren, alles zu erforschen und zu planen und sich dabei auf Annahmen zu verlassen.
Hier ein paar praktische Tipps, die Ihnen helfen zu erkennen, ob Sie diesen Fehler gerade machen:
Es dauert zu lange Ihr MVP zu erstellen. Nehmen Sie stattdessen Funktionen heraus und reduzieren Sie den Umfang auf der Grundlage von Analysedaten oder Nutzerfeedback.
Es dauert zu lange, Anderungen zu implementieren. Konzentrieren Sie sich auf die Verbesserung der Time-to-Market. Verringern Sie die Zykluszeit durch Verbesserung der CI/CD-Automatisierung, damit Sie den Lernzyklus häufiger durchlaufen können.
Niemand kann Ihr MVP sehen. Ein MVP muss eine öffentliche URL haben. Sie müssen in der Lage sein, Ihr MVP zu veröffentlichen, damit andere es sehen und nutzen können. Nur dieser Schritt ermöglicht es Ihnen, es weiter zu verbessern.
2) Zu wenig Fachwissen im Team
Wissen über die Cloud ist der Schlüssel zu einer erfolgreichen Cloud-Einführung. Aber was tun Sie, wenn Ihr Team keine Erfahrung mit Cloud-Technologien hat? Natürlich könnten Sie Mitarbeiter mit Cloud-Erfahrung einstellen, aber auch das wird das Problem nicht lösen, da diese wiederum keine Erfahrung mit Ihrem Projekt haben.
Die Aneignung von Wissen ist nie eine schnelle Lösung. Dies ist eher ein kulturelles Thema. Das Team muss voll befähigt sein und wissen, wie die Cloud und die Systeme funktionieren. Mein Ratschlag: Betrachten Sie das Projekt nicht als ein Team mit einem Rockstar-Engineer an der Spitze, der die ganze Kunst beherrscht, sondern als ein Team, das nur gemeinsam als Rockband auftreten kann 😉.
Wie kann man dies ermöglichen? Um Lernen zu einem Teil Ihrer Kultur zu machen, gibt es mehrere Möglichkeiten, ein inspirierendes und erfolgreiches Arbeitsumfeld zu schaffen.
Eine Idee ist die Einrichtung regelmässiger Wissensaustausch-Sitzungen, bei denen jemand aus dem Team, der sich mit einem bestimmten Thema beschäftigt hat, seine Erkenntnisse mit dem Rest des Teams teilt und sie weitergibt. Die Ergebnisse dieser Sitzungen können auch dazu genutzt werden, um neue Kollegen in Zukunft an Bord zu holen.
Eine weitere Möglichkeit ist die Implementierung von Pair Programming als eine großartige Möglichkeit zum Wissenstransfer im Team. Außerdem ist Pairing ein guter Weg, um komplexe Herausforderungen zu bewältigen, da es die Diskussion über die anstehenden Herausforderungen und deren Lösungen fördert. Genau das Richtige für unsere Cloud-Migration.
Diese Indikation zeigen Ihnen, ob Ihnen gerade dieser Fehler unterläuft:
Bestimmte Aufgaben werden immer von derselben Person übernommen. Wenn bestimmte Themen wie Testen oder Überwachen immer von der gleichen Person erledigt werden, sollten Sie eine Form des Wissensaustauschs einführen, um den Engpass zu beseitigen.
Ihr Team ist sehr vorsichtig. Wenn das Team mit Vorsicht vorgeht, könnte dies auf mangelndes Wissen zurückzuführen sein (könnte auch andere Ursachen haben, z. B. kulturelle Probleme).
Fragen Sie das Team. Das Team weiss, wo es mehr Wissen braucht. Als Team können Sie die wichtigsten Kompetenz- und Erfahrungslücken definieren, die geschlossen werden müssen. Idealerweise halten Sie Ihre Erkenntnisse in einer Skill matrix fest.
3) Kurzfristige Ausrichtung
Im ersten Teil dieses Beitrags haben wir über MVPs gesprochen, und jetzt sage ich, dass eine kurzfristige Ausrichtung ein Fehler ist? Nun, ja, beides gehört tatsächlich zusammen.
Stellen Sie sich vor, Sie kaufen einen beratenden Rockstar-Engineer, der Ihnen hilft, die Migration in die Cloud zu vollenden. Und das Ziel ist, dass die Migration innerhalb von sechs Monaten abgeschlossen ist, wenn der Vertrag mit dem Berater endet.
Raten Sie mal, was dann passieren wird? Wenn die Zeit knapp wird und der Berater sich entscheiden muss, ob er eine richtige langfristige Lösung aufbauen oder einen schnellen Weg einschlagen soll, um die Aufgabe erfolgreich abzuschliessen, dann ist es ziemlich klar, wie der Berater sich entscheiden wird.
Und genau auf diese Diskrepanz muss geachtet werden - es könnte sein, dass einzelne Personen in einem Team unterschiedliche Ziele verfolgen und das Projekt auf eine Weise vorantreiben, die nicht nachhaltig ist.
Wie können Sie das Risiko verringern, dass einzelne Teammitglieder ihre persönlichen Ziele höher gewichten als die Ziele des Teams? Stellen Sie sicher, dass jeder im Team in zwei Ziele investiert ist:
Die Cloud-Einführung so schnell wie möglich abzuschließen
Sicherstellen, dass die Lösung ein hohes Mass an Wartungsfreundlichkeit und Anpassungsfähigkeit aufweist.
Bei der Zusammenarbeit mit externen Anbietern können Sie dies verbessern, indem Sie sich um längerfristige Partnerschaften bemühen, die Sie bei der Cloud-Einführung unterstützen.
Dies sind ein paar praktische Hinweise, mit denen Sie diesen Fehler entdecken:
Die Anzahl der identifizierten technischen Probleme nimmt zu. Wenn Sie die technischen Schwierigkeiten innerhalb des Teams nicht kontinuierlich im Auge haben, sollten Sie beginnen technische Mängel zu überwachen. Achten Sie dann genau darauf, dass sich diese Probleme nicht anhäufen. Wenn das passiert, suchen Sie das Gespräch darüber, wie es möglich wäre, die weitere Zunahme zu vermeiden.
Das Team ist sich oft nicht einig.__ Sicherlich sind eine vielfältige Kultur und offene Diskussionen hilfreich. Aber wenn es schwierig wird, Entscheidungen zu treffen, sollten Sie prüfen, ob die individuellen Ziele der Teammitglieder nicht übereinstimmen.
Einige Teammitglieder sind übermässig fordernd. Ein Team funktioniert nur dann gut, wenn alle Teammitglieder auf gleicher Augenhöhe arbeiten. Wenn einige Teammitglieder ihre Meinungen und Entscheidungen zu sehr durchsetzen, schadet das dem langfristigen Engagement und der Eigenverantwortung.
4) Alle Tools gezwungernermassen nur noch in der Cloud laufen lassen
Nicht alle Software auf diesem Planeten ist für die Migration in die Cloud konzipiert und entwickelt worden. Oftmals müssen im Rahmen der Cloud-Strategie eines Unternehmens alle Arbeitslasten in die Cloud verlagert werden, um den Betrieb on-premise abzuschalten.
Aus diesem Grund bevorzugen Teams oft einen "Lift & Shift"-Ansatz für ihre Cloud-Einführung, um Arbeitslasten schnell in die Cloud zu verlagern und dann von dort aus zu verbessern. Dies führt jedoch häufig dazu, dass die Probleme der lokalen Anwendungen in die Cloud verlagert werden und die Herausforderungen der Cloud hinzukommen.
So ist beispielsweise eine Anwendung, die Zugriff auf ein Dateisystem benötigt, kein guter Kandidat für ein Re-Hosting in der Cloud. Vielmehr muss der Service von Anfang an neu konzipiert und aufgebaut werden, um die Möglichkeiten der Cloud zu nutzen.
Diese Anzeichen deuten auf einen solchen Fehler hin:
Sie benötigen Dateisysteme in der Cloud. Dateisysteme verursachen eine Menge Probleme, wenn es um hohe Verfügbarkeit und Skalierbarkeit geht. Wenn dies nicht Ihr Anliegen ist und Sie mit Ausfallzeiten leben können, können Sie mit Dateisystemen fortfahren. Andernfalls sollten Sie die Architektur ändern und neu aufbauen.
Sie müssen Software selbst containerisieren. Im Ernst: Wenn der Anbieter keine Cloud-fähige Version der Software bereitstellt, versuchen Sie nicht, die Anwendung zu containerisieren und in der Cloud zu betreiben - bauen Sie sie einfach um und wählen Sie einen anderen Anbieter.
Sie wollen den Anwendungscode nicht anfassen. Bei einer Cloud-Plattform müssen Sie auf Ausfälle vorbereitet sein, und die Anwendungen müssen für verschiedene Ausfälle gerüstet sein. Es ist sehr unwahrscheinlich, dass eine Anwendung, die nicht für die Cloud geschrieben wurde, über diese Qualitäten verfügt, so dass die Verbesserung des bestehenden Anwendungscodes einen reibungsloseren Übergang in die Cloud ermöglicht.
5) Abhängigkeiten von On-Premise-Systemen
Eine Komponente hat selten keine Verbindung zu anderen Systemen. Beim Wechsel in die Cloud sind diese anderen Systeme oft noch nicht vorhanden. Dies führt dazu, dass Entwicklungsteams Zeit darauf verwenden, die Lücke zwischen lokalen Systemen und ihrer Anwendung, die jetzt auf einer Cloud-Plattform läuft, entweder vorübergehend oder dauerhaft zu schliessen.
Die Überbrückung dieser Lücke kann sehr arbeitsintensiv sein, da die Techniker gezwungen sind, eine Netzwerkverbindung zu einem lokalen Rechenzentrum einzurichten und aufrechtzuerhalten, ohne dass das Team selbst die Netzwerkeinrichtung ändern kann. So müssen die VPN-Tunnel, Zertifikate, technischen Benutzer und alle anderen technischen Details gemeinsam mit dem IT-Betriebsteam vor Ort eingerichtet und gepflegt werden.
Während sich die zentrale Verwaltung von Zertifikaten und DNS in lokalen Systemen bewährt hat, funktioniert sie in Cloud-Systemen nicht so gut. Aber oft setzt das zentrale IT-Betriebsteam seine Prozesse für die traditionelle Rechenzentrumsverwaltung fort, und Teams, die Lösungen in die Cloud bringen, müssen mit langsamen und manuellen Prozessen arbeiten, um ihre Anwendungen zum Laufen zu bringen.
Hier ein paar Tipps, wie Sie diesen Fehler entdecken können:
Ihr Team verbringt viel Zeit damit, sich mit On-Premise-Themen zu beschäftigen. Sie möchten eine Lösung für die Cloud entwickeln. Wenn der grösste Teil der technischen Leistung für die Bearbeitung von On-Premises-Themen aufgewendet wird, ist es oft besser, die Anwendung so umzugestalten, dass sie weniger auf On-Premises-Services angewiesen ist.
Ihr Team kann keine Self-Services nutzen. In einer ordnungsgemässen Cloud-Einrichtung können Teams Self-Services nutzen, um schnell voranzukommen und die gewünschten Lösungen zu erstellen. Wenn Teams mit vielen Prozessen konfrontiert sind, die sich nicht selbst bedienen, gibt es ein grosses Potenzial, diese Prozesse mit Hilfe von Plattformteams zu rationalisieren.
Fazit
Zu Beginn einer Cloud-Migration gibt es viele Fehler zu vermeiden, damit Ihre Teams schnell Ergebnisse liefern und nachhaltige Lösungen aufbauen können. In vielen Fällen ist es nicht sinnvoll, einen Cloud-Ansatz zu verfolgen, sondern eine Lösung von Anfang an cloud-nativ zu gestalten und neu aufzubauen. Dies kann ein Entwicklungsteam erheblich beschleunigen, sofern eine Kultur des Wissensaustauschs vorhanden ist, so dass das Team selbständig iterieren und verbessern kann.
Fabian Kleiser
Fabian ist unser Head of Cloud Innovations mit Sitz in Stuttgart, Deutschland. Als Software Engineer leitet er strategische Cloud-Foundry-Implementierungen bei Mimacom und ist bekannt für seine Leidenschaft für Code-Qualität, Automation und Vereinfachung.