Klassisches Deployment vs. Container Deployment

Tom Whiston Mär 28, 2019
Klassisches Deployment vs. Container Deployment

Die klassische Deployment-Methode ist ein Risiko- und Change Management-Prozess, bei dem der Erfolg daran gemessen wird, ob Service und Stabilität ohne Unterbrechungen gewährleistet sind. Der genaue Prozess kann verschiedenartig sein, aber die meisten verlaufen folgendermaßen oder ähnlich.

  • Schlimmstenfalls → Das neue Feature wird fertiggestellt, der Code an das operative Team übergeben, man hofft darauf, dass das Change Board die Genehmigung erteilt und dass das Deployment durch das Operations Team erfolgreich verläuft.
  • Besser → Es gibt einen manuellen Change-Prozess, bei dem Sie den Code via SSH oder FTP auf den Server hochladen und zusätzlich ein paar Upgrade-Schritte erledigen.
  • Bestenfalls → Sie arbeiten in einer virtuellen Maschine, eine CI/CD Pipeline liefert Ihren Code an einen Server. Änderungen geschehen via Scripts oder Configuration Deployment Tools, aber Sie haben vermutlich keinen Zugriff auf die virtuelle Maschine und können somit weder die Anpassungen verifizieren, noch den Gesamtzustand prüfen.

Die bekannte Deployment-Methode

Vermutlich ist die Anwendung fest an ihre Umgebung gebunden. Doch die Umgebung ist auch leicht veränderbar, da Personen SSH Zugang gewährt wird. Darüber hinaus sieht diese Umgebung vermutlich nicht so wie die Entwicklungsumgebung aus und möglicherweise haben Ihre Entwickler nicht einmal Kontrolle darüber, wie die Live-Umgebung sich verhält. Zudem ist es sehr wahrscheinlich, dass Deployments mehrere manuelle Prozesse beinhalten, die, um erfolgreich zu sein, auf ganz bestimmte Weise erfolgen müssen. All diese Faktoren erschweren den Change erheblich und aufgrund der hohen Kosten werden das Experimentieren und die Kreativität unterbunden.

Da ist es wenig erstaunlich, dass der Deployment-Prozess als hohes Risiko angesehen wird. Es gibt zahlreiche Stellen, an denen nicht-nachvollziehbare Änderungen auftreten können. Die oben beschriebenen Prozesse sollten eigentlich Risiken minimieren. In Tat und Wahrheit rufen Sie Angst vor neuen Releases hervor und stehen dem Erfolg im Weg. Deswegen werden Change Management sowie das Ausbleiben von Serviceausfällen als die wichtigsten Erfolgsfaktoren angesehen. Bei diesem Szenario ist es extrem schwierig, Change zu ermöglichen, aber sehr leicht möglich, alles kaputt zu machen!

Wie man es vereinfachen kann

Containerisierte Deployment-Strategien setzen hingegen auf Geschwindigkeit als Hauptkennzahl. Es geht darum, in möglichst kurzer Zeit einen möglichst hohen Mehrwert für die Stakeholder zu schaffen. Hierbei gilt es, die vorhandenen Mauern zwischen Entwicklung und Operations einzureißen. Somit können Entwickler selbst Änderungen in Form von automatisierten Tool durchführen, welche die Infrastruktur basierend auf versionierten Config-Files konfigurieren. Dafür werden einige neue Design- und Entwicklungs-Konzepte benötigt.

In der Container-Technologie können Sie Sie Ihre Dienste nicht per SSH verwalten. Stattdessen konfigurieren Sie ihre Umgebungen mit Konfigurationsdateien und deployen Gruppen von Diensten über eine Deployment Pipeline, getriggert von Ihrem Versionskontrollsystem. Der schnelle und automatisierte Prozess brennt das Deployment-Konzept in das „Herz“ des Anwendungsdesigns, dies bedarf aber auch einer komplett neuen Denkweise.

Sie wollen mehr zur Implementierung von Container-Technologien erfahren?
Wir haben für Sie die 20 meist gestellten Fragen in einem Dokument beantwortet:


Laden Sie sich die wichtigsten Infos jetzt herunter

 

Infrastructure as code

Indem man die Infrastruktur als etwas ansieht, das versioniert, streng abgegrenzt und deploybar ist, sind Änderungskontrollen und Rollbacks leicht durchführbar und Anwendungen laufen fast überall. Das Ziel ist, dadurch eine Berechenbarkeit für Runtime-Umgebungen zu erlangen und instabilen Server-Setups vorzubeugen, indem man (virtuell) die gleiche Umgebung entwickelt, die man live ausrollt und die Umgebung nach und nach (täglich/stündlich) wieder aufbaut. Docker beispielsweise ermöglicht es, dass dieser Prozess extrem leichtgewichtig und flexibel ist, wobei die Zeit für den Aufbau im Vergleich zu virtuellen Maschinen (VM) erheblich verringert werden kann.

Gesamtverantwortung

Weil Container so leichtgewichtig, einfach zu entwickeln und auszurollen sind, können Sie das Single-Responsibility-Prinzip auf Ihre Applikationen ausweiten. Jeder Container ist für nur eine Aufgabe verantwortlich. Durch diese Unabhängigkeit können Sie zielgerichtet auf aktuelle Bedingungen eingehen und nach Bedarf skalieren - Sie müssen das System nur dort anpassen, wo es nötig ist.

Automatisierung ist der Schlüssel

Der gesamte Build-Prozess sollte automatisiert ablaufen, im Idealfall komplett ohne menschliches Zutun (in einer Produktionsumgebung kann jedoch ein manueller Auslöser sinnvoll sein). Jede Änderung an ihrem Source Code (oder Container) Repository sollte eine Reihe von automatischen Tests auslösen und ein Deployment auf eine Umgebung, die möglichst der Produktionsumgebung entspricht.

Somit wird klar, dass dies allein schon dazu beiträgt, Ängste abzubauen, die im Zusammenhang mit Deployments bestehen. Was könnte Ihnen mehr Sicherheit geben als die Tatsache, dass die notwendigen Schritte für den Deployment-Prozess zuvor schon hundertfach erfolgreich durchgeführt wurden?

Diese Automatisierung bringt weitere Vorteile mit sich - wenn korrekt angewendet, können sich Container eigenständig reparieren. Falls Ihr Container abstürzt, startet sofort eine neue Instanz. Das Skalieren ist einfach, da Container-Plattformen wie Kubernetes bei Bedarf eine Auto-Skalierung zulassen, unveränderbare Runtime-Images die Informationssicherheit unterstützen und vertrauliche Informationen zur Laufzeit in einem temporären Dateisystem untergebracht werden können.

  

An weiteren Informationen rund um die Container-Technologie und 
Cloud Computing interessiert? Dann abonnieren Sie jetzt unseren Blog: 


Jetzt für den nine Blog anmelden

 

Und was ist mit der Plattform?

All diese Ideen führen zu einer wichtigen neuen Problemdomäne...

  • ... Wie kann man eine Anwendung bauen oder eine existierende Anwendung anpassen, um diese für Container passend zu machen und um einfache Skalierung zu unterstützen?
  • ... Wie kann die Komplexität gesteuert werden?
  • ... Wer kümmert sich um die Systeme, die den Workflow rund um das Development unterstützen?

Auch wenn gemäss Rightscale die Nutzung der Container-Technologie seit 2018 deutlich zugenommen hat, wissen wir aus Erfahrung, dass die Komplexität immer noch einer der häufigsten Hinderungsgründe für einen Umstieg auf Container darstellt.  Es ist daher sehr wichtig, dass Sie mit einem Partner zusammenarbeiten, der Sie zu der für Sie idealen Anwendung führt, dabei sicherstellt, dass Ihre Anwendung problemlos läuft und eine persönliche Deployment-Strategie für Sie entwickelt.

 

PS: Wenn Sie interessiert an weiteren Unterlagen zu den Grundlagen oder der Implementierung der Container-Technologie sind empfehlen wir Ihnen unsere Wissensseite rund um die Container-Technologie. 

Tom Whiston

Strategic & Agile Consultant @ Nine
Find me on Github