Agile / Cloud Computing / DevOps / Digitalisierung / Software-Test / Testmanagement

Road to Success 2/2: 6 Schritte zu flexiblem Umgebungsmanagement mittels Cloud

In Teil eins meiner „Road to Success“ habe ich einen kleinen Einblick in meine Erfahrungen zum Thema Umgebungsmanagement gegeben. Im zweiten Teil geht es nun konkret um die Umsetzung in 6 Schritten. Ich bevorzuge hier den Einsatz von Cloudservices- bzw. Ressourcen, weil sie großen Nutzen im Bereich Verfügbarkeit, technologische Bandbreite und reduziertem Wartungsaufwand liefern.

road-to-susscess_teil2

Anfangs hilft es mir immer, wenn ich versuche mir einen Überblick über die bestehenden Systeme zu verschaffen. Um diesen zu bekommen, gehe ich wie folgt vor:

 

  1. Analyse der bestehenden Umgebungen/Systeme unterteilt in

    1. Verwendete Technologien/Plattformen (.NET, Java, C, Windows, Linux, Mainframe, Mobile, Web, Desktop/Client, etc…)
    2. Bestehende Software bzw. Applikationen sowie Abhängigkeiten zu Standardsoftware identifizieren (z.B. SAP), Reifegrad der eingesetzten Software beurteilen, Adaptionsaufwand beurteilen, aktuelle Kosten, etc…
    3. Hardware/Infrastruktur (Anzahl Server, Kapazität, Art (Webserver, Applikationsserver, DB-Server) geplante Verfügbarkeit, Ausfallzeit-Toleranzen, aktuelle Kosten, etc…)
    4. Lizenzen (Welche & Wie viele Lizenzen, aktuelle Lizenzkosten, Floating oder Node-locked, SLAs die damit einhergehen, etc…)

Habe ich diese Informationen beisammen und in mehreren Abstimmungsrunden mit den beteiligten Personen einen gemeinsamen, verifizierten Wissensstand aufgebaut geht es nun an Schritt 2:

 

  1. Entwicklung einer Bewertungsmatrix, welche Umgebungen/Systeme Cloud-tauglich sind

Datenschutz, Systemkomplexität, Verfügbarkeit und Nutzungshäufigkeit sind unter anderem gute Kriterien zur Bewertung, aber auch je gängiger und standardisierter eine Technologie/ein System desto einfacher.

Meist geschieht das in Form einer einfachen Excel-Tabelle, wobei ich für jedes Kriterium Punkte von 1-3 vergebe; 1 für wenig geeignet, 3 für sehr gut geeignet, K für „Kriterium“. Vereinfacht könnte das ungefähr so aussehen:

Matrix

Die Matrix ist folgendermaßen zu verstehen:

Der Webserver hat niedrige Datenschutzbestimmungen, daher gut geeignet, weil es nicht viel zu beachten gibt (3). Die Nutzungsfrequenz ist mittelmäßig, daher ist die Ausfallsicherheit (die durch die Cloud gegeben ist) nur mittelmäßig relevant (2). Einen Webserver zu installieren ist sehr einfach, er eignet sich also sehr gut um ihn schnell in der Cloud verfügbar zu machen (3).

Das ERP-System hat beispielsweise eine sehr hohe Installationskomplexität und scharfe Datenschutzrichtlinien, welche es ungeeignet macht einfach in der Cloud zur Verfügung gestellt zu werden. Die Nutzer (in unserem Fall dann Entwickler und Tester) würden aber davon profitieren, wenn das ERP-System hoch verfügbar wäre.

Die Nutzungsfrequenz der Benutzerverwaltung ist wiederum sehr gering, also muss dieses System nicht unbedingt in die Cloud, da nur wenige von der erhöhten Verfügbarkeit profitieren würden.

Am Ende komme ich in diesem einfachen Beispiel zu der Beurteilung als erstes den Webserver in die Cloud zu stellen. Obwohl die anderen beiden Systeme die gleiche Gesamtbewertung haben, würde ich in diesem Fall mit der Benutzerverwaltung fortsetzen, weil es eine geringere Installationskomplexität hat als das ERP-System und daher besser geeignet für einen Host in der Cloud ist.

Wichtig ist, sich für die Erstellung der Bewertung ausreichend Zeit zu nehmen und die diese nicht im stillen Kämmerchen durchzuführen. Eine Regelmäßige Abstimmung mit Administratoren, Systemverantwortlichen, Entwicklern und weiteren Stakeholdern ist empfehlenswert.

Achten Sie auch darauf, die für Ihr Unternehmen/Projekt geeigneten Bewertungskriterien zu finden –diese können sehr vielfältig und unterschiedlich sein und unterscheiden sich je nach Ausgangssituation.

Bevor wir nun mit der Umsetzung starten können, fehlt noch ein letzter konzeptioneller Schritt:

 

  1. Cloud-Service Anbieter evaluieren und auswählen

Mit diesem Punkt kann teilweise schon parallel zu Schritt 2 begonnen werden, wenn sich die Matrix beispielsweise gerade im Review befindet. Es geht hier darum jene Anbieter auf dem Cloudmarkt zu identifizieren, welche die meisten Vorteile für die benötigten Systeme und Technologien bieten. Entwickelt man beispielsweise schon sehr viel im .NET und Microsoft Umfeld ist wahrscheinlich die Azure Cloud besser geeignet, wohingegen bei Projekten im Linux-Umfeld die Amazon Cloud von Vorteil ist. Hierzu gibt es aber ohnehin gute Quellen im Web welche die Vor- und Nachteile der jeweiligen Anbieter deutlich machen.

Kommen wir nun also zum nächsten Schritt, der Umsetzung:

 

  1. Mit kleinen Schritten starten und einzelne Systeme als Pilot in die Cloud verfrachten

Machen Sie sich in diesem Schritt mit der API und der Benutzeroberfläche des gewählten Cloudanbieters vertraut. Richten Sie gemeinsam mit den Netzwerkadministratoren die Firewallregeln, die DMZ sowie die NAT Einstellungen ein, um problemlos aus dem Firmennetzwerk mit der Cloud interagieren zu können.

Ist all das geschafft, kann bereits der erste virtuelle Host eingerichtet werden – und in unserem Beispiel ein Apache Webserver installiert werden. Ich würde diesen nun so konfigurieren, dass er mit der Entwicklungsumgebung verbunden ist und zu einer Rand- Tageszeit (in Abstimmung mit dem Team) den „Schalter“ umlegen. Somit ist bereits der Webserver in die Cloud gewandert und dort verfügbar.

Wichtig ist jetzt, weiterhin Step-by-Step vorzugehen und nicht zu schnell zu viel zu wollen. Parallel zur Umsetzung ist es nun Zeit mit dem nächsten Punkt in meiner Checkliste zu starten.

 

  1. Regelmäßige Feedbackrunden etablieren

Rufen wir uns nochmal ins Gedächtnis warum wir all diese Schritte gesetzt haben – die Verfügbarkeit der Entwicklungs- und Testumgebung soll erhöht werden und die Flexibilität (Stichwort Skalierung) des Umgebungsmanagements soll gesteigert werden. Weitere Ziele die wir erreichen möchten sind Kostentransparenz und Entlastung der Tester und Entwickler durch Abbau von Umgebungs-Workarounds.

Um sicherzustellen, dass diese Ziele erreicht werden, ist es unerlässlich regelmäßiges Feedback der Stakeholder und Core-User einzuholen. Ähnlich einer Retrospektive in Scrum sollen die gewonnen Erkenntnisse ins weitere Vorgehen einfließen.

Mein Tipp hier: Bevor neue Dinge ausprobiert werden, lieber das bereits bestehende optimieren und lauffähig halten, sonst läuft man Gefahr wieder nur halbfertige Umgebungen zu haben.

Haben Sie es bereits so weit geschafft, ist es Zeit für den letzten und extrem wichtigen Schritt.

 

  1. Aufbau von Provisioning- und Deploymentautomation

Alleine zu diesem Punkt gibt es unzählige Dinge zu erwähnen und hier möchte ich auf einen anderen Blogartikel verweisen, in dem es explizit um Infrastructure as Code geht. In diesem beschreibe ich eher auf technischer Ebene was es mit Deploymentautomation auf sich hat. Wichtig hierbei wieder: Kleine Schritte gehen, regelmäßig prüfen und das Vorgehen anpassen.

Die Ziele hier sind weitere Entlastung des Personals durch Abbau manueller Tätigkeiten mittels Automatisierung.  Zusätzlich steigt das Vertrauen in das Umgebungsmanagement, weil Umgebungen mit relativ geringem Aufwand wieder neu aufgebaut werden können.

In der absoluten Endausbaustufe gibt es dann eine Art „Selfservice“ mithilfe dessen sich Projekt- oder Produktverantwortliche eigene Umgebungen für ihre Entwicklungs- und Testzwecke konfigurieren können.

 

War’s das?

Wenn Sie bis hierher gelesen haben, denken Sie nun vielleicht eines der folgenden Dinge:

„Klingt interessant, das möchte ich versuchen.“

oder

„Puh, ganz schön viel zu tun. Ob wir das schaffen?“

In beiden Fällen möchte ich abschließend sagen: Beide Gedanken sind richtig und berechtigt! Es ist nicht leicht, so gravierende Umstellungen technologischer und organisatorischer Natur zu schaffen. Es ist eine lange „Road to Success“ – und alle 6 Punkte gewissenhaft durchzuarbeiten ist nur möglich wenn es dafür die Bereitschaft und die Ressourcen in der Organisation gibt und die richtigen Personen daran arbeiten.

Im Sinne von Agil und DevOps gibt es aber kaum ein anderes Thema, welches so viele Beteiligte ins selbe Boot holt, durchrüttelt, zusammenschweißt und als starkes Team wieder preisgibt. Also fangen Sie an oder bleiben Sie dran!

 

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*