22.06.2023

FÜR ENTWICKLER

Die Evolution der Applikationsentwicklung zu einem cloud-native Ansatz

Ein durch und durch cloud-native Unternehmen zu werden, ist kein leichtes Unterfangen. Dazu bedarf es einer ganzen Evolution. Aber durch welche Phasen dieser Evolution müssen Unternehmen gehen, um beim gewünschten Zustand anzukommen? Und wie sieht dieser Zustand überhaupt aus? Schauen wir es uns einmal zusammen an!

The evolution of application development to cloud native

Phase 1: Normalisierung

  • Teams für die Anwendungsentwicklung verwenden Versionsverwaltung.
  • Teams für die Anwendungsentwicklung verwenden die üblichen Entwicklungsverfahren.

Dies geschieht zum Beispiel, wenn Git oder SVN verwendet werden. Es gibt dabei die Hauptversionen sowie zusätzliche Features, die es einfacher machen, die Kontrolle über den Anwendungscode zu behalten. Zudem gibt es Versionierungen für Release-Prozesse.

Falls dein Unternehmen noch nicht in dieser Phase angekommen ist, habt ihr in den letzten 20 Jahren wohl in einer Höhle gelebt. Setze die Versionsverwaltung umgehend durch. Jetzt sofort.

Phase 2: Standardisierung

  • Teams entwickeln mit einer Reihe Standardtechnologien.
  • Teams deployen an eine Standard-Betriebsplattform.

Standardisierung kann die Effizienz deines Unternehmens drastisch erhöhen. Das bezieht sich zwar nicht nur auf dein Tech-Team, aber speziell für die heißt das, dass sie mit Container-Technologie wie Docker, Docker-Compose oder Kubernetes arbeiten werden.

Diese Phase ist das Fundament für das Unterfangen, ein Unternehmen cloud-native zu machen.

unikube_c-ndem_Infographic

Phase 3: Expansion

  • Anwendungen bestehen aus mehreren kleineren, beweglichen Elementen und lose gekoppelten Services.
  • Anwendungen sind auf den Umfang, die Widerstandfähigkeit und die Geschwindigkeit von Veränderungen ausgerichtet.

Dein Unternehmen verwendet serviceorientierte Architektur, Message-Brokering, Event-Streams und lose gekoppelte Interfaces (REST-, GraphQL- etc.). Ganz nach dem Motto „Divide et impera“, also „Teile und herrsche“, können dadurch spezialisierte Teams kreiert und schnellere Entwicklung sowie eine bessere Handhabung komplexer Anwendungen umgesetzt werden.

Um in dieser Phase anzukommen, ist es wichtig, für deine Anwendung bereits von Anfang an eine Struktur aus individuell entwickelten Services einzuplanen. Es ist nämlich wirklich anstrengend, eine monolithische Anwendung zu einem späteren Zeitpunkt aufzuteilen.

Phase 4: Automatisierte Bereitstellung der Anwendung

  • Teams verwenden existierende Deployment-Muster erneut.
  • Versionsverwaltung für Deployment-Muster und Konfigurationen.
  • Automatische Provisionierung der Entwicklungsumgebung.
  • Teams verwenden einen Standardsatz an Build- und Testsystemen.
  • Service-Discovery wird in Anwendungen verwendet.
  • Security-Teams sind am Design und Deployment beteiligt.
  • Automatisiertes Security-Profiling von Code und Config-Manifesten.

Zu den Technologien und Ansätzen, die möglicherweise während der 4. Phase eingesetzt wurden, gehören Helm, Quay, GitHub Actions, Continuous Integration, ArgoCD, Service Mesh, Network Policies und Pod Disruption Budget.

Anwendungen (oder besser gesagt: kleine, robuste Services) haben eine hohe Release-Häufigkeit. Umfassende automatisierte Deployment-Muster (z. B. bei der Verwendung von Helm in allen Bereichen) mit GitOps sind vorhanden. Ein „Anstoß“ des Source-Management-Systems löst nachvollziehbare Änderungen an der Infrastruktur und den Anwendungen aus. Alle Teammitglieder (mit besonderem Schwerpunkt auf die Entwickler) kennen die Schlüsselelemente der kontinuierlichen Integrationspipeline und lösen aufkommende Probleme ganz selbstständig. Zudem sind auch Mitglieder eines spezialisierten Security-Teams an der Entwicklung von Architekturen und Services beteiligt. Sobald Sicherheitslücken auftreten, werden Security-Updates umgehend erstellt.

Phase 5: Automatisiertes Application-Management

  • Entwicklerteams können auf alle Services für die Entwicklung zugreifen.
  • Produktion kann für das Deployment nachgebildet werden.
  • Anwendungen verwenden Muster von fortgeschrittenen Betriebsplattformen.
  • Anwendungen verwalten sich selbst sowie die Betriebsplattform.

Beispiele: Operators, CRD (Custom Resource Definitions), Auto Scaling und Probes.

Dein Entwicklungsteam jagt einen komplexen Bug, der peinlicherweise alle deine Service beeinflusst? Kein Problem – in Phase 5 können deine Teams die Komplexität deiner Produktionsentwicklung nämlich im Handumdrehen provisionieren. Und obendrauf managen alle Service ihre eigenen Lifecycles, ohne dass manuell eingegriffen werden muss.

Ein neues Update benötigt eine Datenmigration? Auch kein Problem, denn deine Kubernetes-Operators ermitteln das verfügbare Update in deinem Registry und wenden die nötigen Scripts automatisch an, um die Daten deiner Anwendung konstant zu halten. Anwendungen informieren Kubernetes dabei selbst über ihren Zustand – sind sie bereit, neue Anfragen zu bearbeiten oder wird mehr Kapazität benötigt? Können wir es ein bisschen zurückschrauben, um etwas Geld zu sparen? In Phase 5 muss sich dein Team um solche Fragen glücklicherweise keine Sorgen mehr machen.

Bist du bereits bei Phase 5 angekommen? Wenn ja – Glückwunsch! Falls nicht, mach dir aber keine Sorgen. Soweit wir es beurteilen können, sind bisher sehr wenige Unternehmen wirklich in Phase 5 angekommen. Wir empfehlen, dass jedes Unternehmen möglichst schnell bei Phase 3 ankommen sollte und daraufhin sofort versuchen sollte, Phase 4 als mittelfristiges Ziel zu verfolgen. Falls das deine Strategie ist, dann bist du schonmal auf einem guten Weg zum zukünftigen Erfolg.

Wenn du mehr Einblicke in das Kubernetes-Ökosystem erhalten möchtest, folge einfach Michael Schilonka auf LinkedIn.

BLUESHOE GmbH

ADRESSE

Bahnhofstraße 3a
82166 Gräfelfing bei München

FOLLOW US

Footer
© 2023 BLUESHOE GmbH