Innovation mit MACH (Part 3): Das Wie und Warum der Umstellung auf Cloud-native

In meinen vorangegangenen Artikeln haben wir uns angesehen, warum Business Capabilities Microservices bestimmen sollten und welchen geschäftlichen Wert es hat, API-first zu sein. Dies bringt uns zu der Frage, wie Unternehmen durch Cloud-native Technologien modernisiert werden. Hier spreche ich darüber, wie die Cloud genutzt wird, und nicht über die Cloud-Dienste selbst.

Inhalt

• Was ist Cloud-native-Development?
• Warum sollten Unternehmen die Cloud-Native-Development vorantreiben?
• Drei Vorteile einer Umstellung auf Cloud-native
• Wie passt Kubernetes ins Gesamtbild?
• Erfolgreich sein mit Cloud-native

Was ist Cloud-native-Development?

Cloud-native-Development ist ein agiler und verhaltensabhängiger Ansatz. Dabei nutzen Unternehmen Cloud-Dienste so, dass es für sie organisatorisch und kulturell sinnvoll ist. Skalierbare Anwendungen laufen in modernen, dynamischen Umgebungen unter Verwendung von Containern und deklarativen APIs, vorzugsweise organisiert durch Kubernetes. Die Bausteine verwenden ein Microservice-Modell, eine serverlose Plattform und das DevOps-Betriebsmodell.

Warum sollten Unternehmen die Cloud-Native-Development vorantreiben?

Wir empfehlen unseren Kunden, sich von einer rein IT-getriebenen Denkweise zu befreien und in jeder Phase der Cloud-native-Entwicklung, von der Planung bis zur Entscheidungsfindung, eine geschäftliche Sichtweise einzubringen. Die IT-Abteilung hat vielleicht das beste Verständnis für die technische Implementierung. Aber das beinhaltet nicht unbedingt ein Gesamtbild des Unternehmens. Versuchen Sie, sich auf die Denkweise „Business-Impact first“

einzulassen – denn die heutige Technologie kennt kaum Grenzen, und fast alles, was man sich erträumen kann, ist mit einem ausreichend großen Geldbeutel machbar. Es besteht jedoch immer ein Kostenrisiko, daher sollte der Schwerpunkt auf dem geschäftlichen Nutzen liegen. Jede Cloud-Lösung sollte auf die Hintergrundprozesse und Zukunftspläne des Unternehmens zugeschnitten sein. Behalten Sie die Sichtweise der Endnutzer und die Customer Experience im Auge. 

Drei Vorteile einer Umstellung auf Cloud-native

Bessere Customer Experience mit DevOps

Das DevOps-Mantra „Fail fast, fix fast“ und die kurzen Zyklen von CI/CD bedeuten, dass robustere Tests durchgeführt werden können, bevor die gesamte Anwendung integriert wird. DevOps-Praktiken helfen Unternehmen, Anwendungen, die häufig aktualisiert werden müssen, zuverlässig, nahtlos und ressourcenschonend bereitzustellen. Selbst wenn Sie nicht grundsätzlich ein „technisches“ Unternehmen sind, können Sie sich mehr auf die Entwicklung konzentrieren und müssen sich weniger Gedanken darüber machen, was passiert, nachdem das Update live gegangen ist.

Verbesserte Kontinuität mit einer stabilen Cloud-Architektur

Die Umstellung auf Cloud-Native ist ein probates Mittel gegen Ausfallzeiten und nicht verfügbare Dienste. Bei der Cloud-Native-Entwicklung geht es darum, einen Wettbewerbsvorteil zu haben und den Betrieb schlank genug zu halten, um jede Marktentwicklung zu überstehen. Mitarbeitende, Produkte oder Dienstleistungen sind nicht an physische Standorte gebunden, wenn Sie die MACH-Route wählen. Mit Cloud-Native ermöglichen Sie integrierte und automatisierte Backups, eine bessere Datensicherheit, die Vereinheitlichung von Prozessen über eine einzige Schnittstelle und eine bessere Transparenz.

Auf sich verändernde Marktanforderungen reagieren

COVID hat uns gezeigt, dass Agilität und Geschwindigkeit entscheidende Instrumente in turbulenten oder wettbewerbsintensiven Märkten sind. Unternehmen, die während der COVID-Periode erfolgreich waren, konnten innerhalb von Stunden auf plötzliche Veränderungen reagieren, neue Kundenwünsche erfüllen und Resultate liefern. Wenn Sie eine Chance noch vor der Konkurrenz erkennen und sich damit in eine Schlüsselposition auf dem Markt begeben, sollten Sie besser ein Cloud-natives System haben.

Wie passt Kubernetes ins Gesamtbild?

Kubernetes kommt ins Spiel, wenn Sie eine Lösung aufbauen, die auf Containern in großem Maßstab basiert. Sie stellen mehrere Container bereit und skalieren diese, betreiben zahlreiche Dienste und skalieren diese nach oben und nach unten. Hier wird die Organisation durch Kubernetes entscheidend. Erfahrungsgemäß ist Kubernetes als Kernstück ein guter Ausgangspunkt, um Cloud-nativ zu werden. Die folgenden Fragen helfen Ihnen dabei zu entscheiden, ob Sie Kubernetes benötigen:

• Warum setzen Sie Kubernetes ein? („Weil alle anderen es auch tun“ ist keine gute Antwort.)
• Wie hilft es Ihnen, die Anforderungen Ihrer Benutzer zu erfüllen?
• Ist es ein gutes Werkzeug, eine gute Vorgehensweise oder Methode, und als Lösungsansatz geeignet, um die Bedürfnisse bestimmter User zu erfüllen? (Es gibt keine Einheitsgröße für alle.)

Erfolgreich sein mit Cloud-native

Wenn Sie sehr lange Erfahrung mit traditionellen IT-Projekten und Development haben, wird der Übergang zur Cloud nicht über Nacht erfolgen. Es bedarf tiefgreifender Veränderungen auf allen Ebenen, indem Sie die IT, die Geschäftsmodelle und die eigenen Arbeitsweisen reflektieren. DevOps, Agile und End-to-End-Entwicklung ersetzen das herkömmliche Development, um das Beste aus der Cloud herauszuholen. Die Skalierung wirkt sich auch auf die Kosten aus. Hier eine 4-Phasen-Checkliste für den Einstieg:

Phase 1: Die Basics

Für den Einstieg in Cloud-Native benötigen Sie Kubernetes, verwaltete Datenbanken und einen verwalteter Nachrichtenbus. Ihre Entwicklungsteams gewöhnen sich an die Umgebung, CI/CD-Prozesse etc. Alte Gewohnheiten ändern sich nicht über Nacht. Stellen Sie sicher, dass Ihr Team genügend Spielraum hat, um herauszufinden, welche Methoden für sie am besten geeignet sind.

Phase 2: Self-Service über Templates

Wir führen von einem zentralen Plattform-Team verwaltete Plattform-Vorlagen ein, um Datenbanken, Lambdas etc. im Self-Service-Modus einzurichten. Dies wird für eine schnelle Skalierung in der Zukunft entscheidend sein. Einige Teams bleiben immer in Phase 1, weil sie nur eine stabile Kubernetes-Umgebung benötigen. In Phase 2 geht es darum, den Phase-1-Teams Vorlagen für die Zukunft zur Verfügung zu stellen.

Phase 3: Einrichtung von Landing Zones

Eine Landing Zone ist eine vorkonfigurierte Cloud-Umgebung – bereitgestellt durch Code – mit einem Standardsatz an gesicherter Cloud-Infrastruktur, Richtlinien, Best Practices, Leitlinien und zentral verwalteten Services. Eine gut funktionierende Landing Zone kümmert sich um Sicherheit, Verwaltung und Einhaltung der Bestimmungen, standardisierte Mietverhältnisse, Identitäts- und Zugriffsmanagement und Netzwerke. Wir richten diese Landing Zones auch mit Budgets und Zugang zu nur bestimmten Funktionen ein und unterstützen die Infrastrukturanforderungen in den ersten Tagen. Ziel ist es, die Zuständigkeiten zu begrenzen und einen reibungslosen Übergang zu einer Phase zu gewährleisten, in der die Teams Eigentümer der Infrastruktur sind und sich an die Bereitstellung und Überwachung gewöhnen.

Phase 4: Autonomie und Zugang für Entwicklungsteams

In der letzten Phase der Umstellung auf Cloud-native haben die Entwicklungsteams direkten Zugang zu einem definierten Satz von Cloud-Funktionen und verfügen über höhere Budgets, die vom Finanzteam über automatisierte Tools festgelegt und überwacht werden. Es wäre sehr riskant direkt mit Phase 4 zu beginnen, ohne die Phasen 1, 2 und 3 zu durchlaufen: sehr hohe Kosten, Sicherheitsprobleme und häufige Systemausfälle können die Folge sein.

Die Umstellung auf Cloud-native erfordert Nischenkompetenzen, um viele bewegliche Teile zu verwalten, ohne hohe Kosten zu verursachen. Überwinden Sie Einstiegshürden, indem Sie Ihrem Team genügend Zeit und Ressourcen geben. Sie werden zusätzliche Werkzeuge für die Bereitstellung, Beobachtbarkeit, Verwaltung und Sicherheit benötigen. Sie müssen nicht bei Null anfangen, wenn Sie den B2B Accelerator+ mit seinem Kubernetes-Beschleuniger nutzen, der Sie schneller auf den Markt bringt.