• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Dr. Wolf-Gideon Bleek 21. November 2017

Von den eigenen Maschinen in die Cloud – ein Erfahrungsbericht

Die Herausforderung

Insgesamt fordern moderne Onlineshop-Systeme ein anspruchsvolles Maschinen-Setup, um den Marktanforderungen gerecht zu werden. Latenz, Seitenabfrage-Volumen, Backend-Systeme uvm. haben unterschiedliche Charakteristika bezüglich Prozessorlast, Datenvolumen und Reaktionszeit. Um dem Kunden ein ansprechendes Einkaufserlebnis zu geben, müssen Hardware- (bzw. Virtualisierung) und Software-Setup gut aufeinander abgestimmt sein und zu unterschiedlichen Zeiten unterschiedlich groß dimensioniert sein.

Wir haben deshalb die folgenden konkreten Probleme adressiert, die wir mit dem Schritt von der dedizierten Hardware zur Cloud lösen wollten:

1. Radikal in verschiedene Richtungen skalieren: Das System soll an jeder Stelle so skaliert werden können, dass es mit dem aktuellen Anfrage-Volumen zurechtkommt. Die Skalierung soll innerhalb von 20-30 Minuten möglich sein (Wir erwarten keine Reaktionszeit von einigen Sekunden.)
2. Hardware-Beschaffung – aufwändige Prozesse los werden: Wir wollen für die Hardware-Beschaffung keine aufwändigen Prozesse durchlaufen. Benötigen wir ein Set von Maschinen, um einen neuen Dienst auszuprobieren, dann wollen wir das innerhalb weniger Stunden machen können. Benötigen wir Maschinen in einer anderen Region (um durch Lokalität kurze Latenzzeiten zu erreichen), dann wollen wir das ebenfalls innerhalb weniger Stunden umsetzen können.
3. Arbeitsteilung reduzieren: Derzeit können neue Maschinen nur genutzt werden, wenn sie durch einen Prozess gehen, der die Administratoren bzw. das Ops-Team involviert. Dadurch entsteht zwangsläufig ein Zeitverzug, weil man auf deren Arbeitsleistung warten muss. Unser Ziel ist es, diese Wartezeit los zu werden, um Experimente nicht zu blockieren und um Verantwortung ganzheitlich in einem Team zu organisieren.
4. Kosten für Hardware und Administration reduzieren: Mit dedizierten Geräten müssen wir die die ganze Zeit die maximale Rechenleistung vorhalten, um im Skalierungsfall Kapazitäten ergänzen zu können. Das Gesamtsystem ist auf die maximale Last ausgelegt. Für Experimente (sowie für Tests) werden separate Maschinen vorgehalten. Beides verursacht Maschinen-Kosten. Darüber hinaus werden alle administrativen Aufgaben an den Maschinen arbeitsteilig erledigt. Administratoren stellen Maschinen bereit, Developer spezifizieren die Konfiguration für ihre Anwendung, Administratoren setzen die Spezifikationen um. Diese Schleife wird so lange wiederholt, bis die richtige Konfiguration erreicht ist. Verantwortung ist geteilt, die Einrichtung erfordert mehrere Personen und erzeugt somit mehrfach Kosten.

Diese Probleme wollen wir lösen:

• Hardware-Beschaffung – aufwändige Prozesse loswerden,
• In einem Team arbeiten – Ops-Abhängigkeiten loswerden,
• Kosten für Hardware und die Administration reduzieren und
• radikal in alle Richtungen skalieren ("Sonderangebotstage" brauchen die fünffache Leistungsfähigkeit).

Diese darüber hinausgehenden Erwartungen haben wir an die Cloud:

• Schnellere Reaktionszeit als bei eigener Hardware,
• Architektur aus kleineren Elementen und
• Nutzung von Standard-Services.

Der Umstieg

Der Abschnitt beschreibt, wie wir in den beiden Projekten vorgegangen sind. Als Zielsystem wurde in beiden Projekten die Amazon-Cloud gewählt.

System A: Weltweites Shop-System auf eigener Hardware für virtuelle Güter
Das ursprüngliche System war monolithisch konzipiert und musste für den Umstieg auf Cloud-Ressourcen architektonisch neu gestaltet werden. Dazu wurde das System in Frontend und Backend zerlegt, mit Queueing-Mechanismen versehen und für die Verteilung ausgerüstet. Wesentlich dafür waren lokale und weltweit verteilte Datenbanken, die kurzfristige und langfristige Zahlungsdaten halten. Für eine Cloud-Region ist jeweils ein Minimal-Set notwendig, das je nach Last um weitere Exemplare erweitert wird. Die Frontend-Maschinen sind hinter einem Loadbalancer angeordnet, die Datenbanken sind in einem Cluster zusammengefasst.

Von der Operations-Seite wurde festgelegt, dass pro Maschine nur genau ein Dienst zu installieren ist. D.h. pro Instanz eines Dienstes muss eine separate Maschine beim Cloud-Anbieter gemietet werden. Das Development-Team und das Operations-Team haben sich die Nutzung von AWS selbst beigebracht. Gemeinsam hat man sich für einen Instanz-Typ für die webbasierten Services entschieden (M3L). Für spezielle Anwendungsfälle (z. B. Datenbank) wurden andere Typen genommen.

Es blieb bei der klassischen Arbeitsteilung: Operations hat die notwendigen Instanzen gemietet, darauf ein Betriebssystem installiert, sie in die Netzwerkinfrastruktur eingehängt und sie an das Development übergeben. Die Installation auf den Maschinen lief dabei zuerst von Hand, d. h. die Maschine wurde über die Cloud-Konsole gemietet, mit einem Image hochgefahren und dann Schritt für Schritt mit Systemprogrammen installiert und konfiguriert (Zu einem späteren Zeitpunkt wurde mit Chef das Setup der Systeme teilautomatisiert).

Aus Skalierungsgründen gab es mehrere Frontend-Instanzen, mehrere Backend-Instanzen und mehrere Datenbank-Instanzen. Der Verwendungszweck musste Operations vorher mitgeteilt werden. Diese haben die Maschinen dann von Hand in die entsprechenden Netzwerk-Gruppen eingetragen und miteinander verknüpft. Nach der Übergabe an das Development-Team wurde entweder die Frontend- oder Backend-Applikation installiert. Das erfolgte über die Kommandozeile.

Die Architektur, die als Ersatz für den Monolithen gewählt wurde, war eine Drei-Schichten-Architektur: Trennung in Frontend, Backend und Datenbank. Zu diesem Zeitpunkt wurden keine Microservices implementiert. Die Datenbank selbst unterteilte sich in einen relationalen Teil und einen dokumenten-orientierten Teil, sodass zwei verschiedene Datenbanken zum Einsatz kamen. Die relationale Datenbank war dabei ein lokaler Speicher für die Applikation in einem Datencenter. Die dokumenten-orientierte Datenbank war der weltweit zentrale Speicher für die Einkaufsvorgänge.

Die dokumenten-orientierte Datenbank musste in jedem Datencenter als Cluster ausgelegt werden, um die Ausfallsicherheit sicherzustellen, und wurde über die weltweiten Datencenter mit einer Replikation verbunden, sodass die Daten weltweit vorlagen.

Nach dem erfolgreichen Umstieg des Shop-Systems in die Cloud war man unabhängig von der klassischen Hardware-Beschaffung. Jedoch war die Beschaffung der virtuellen Maschinen noch in der Hand des Operations-Teams. Gleichermaßen waren die Ops-Abhängigkeiten nur teilweise reduziert. Das Development-Team hatte mehr Verantwortung für die virtuellen Maschinen bekommen, musste aber für eine Reihe von Einstellungen immer noch auf das Operations-Team warten. Die Kosten für die Hardware waren durch dieses Projekt primär verlagert worden. Da die neue Architektur für jeden Service eine eigene VM erforderte, waren tatsächlich höhere Kosten entstanden als bei der monolithischen Architektur. Die Skalierung war mit dem neuen Setting positiv beeinflusst. Allerdings hat die Arbeitsteilung zu recht langen Reaktionszeiten geführt und die fehlende Zerlegung der Applikation in kleinere Teile konnte die heute technisch mögliche Skalierung noch nicht erschließen.

Die klare Trennung zwischen Operations und Development blieb über die gesamte Projektzeit erhalten und konnte aufgrund der Organisationsstruktur und des beteiligten Personals nicht überwunden werden.

System B: Europaweites Shop-System für Waren:
Das europaweite Shop-System war bereits zu Beginn so konzipiert, dass es auf verschiedenen virtuellen Maschinen im Zusammenspiel installiert wurde. Diese liefen auf eigener Hardware, die ausreichend dimensioniert wurde. Dabei wurden Stoßzeiten berücksichtigt, verschiedene Umgebungen (Dev, Test, Prod) bereitgestellt und Reserven für Experimente vorgehalten. Kommt das System an seine Grenzen, wird weitere Hardware beschafft und den Bereichen zugeordnet.

Als Vorhaben für den Umstieg von der eigenen Hardware auf die Cloud-Umgebung wurde ein Teilsystem des Shops herausgegriffen, das migriert wurde.

Der Umstieg in die Cloud bedeutete nun einer besonderen Situation Rechnung zu tragen: andere Hardware, anderes I/O-Verhalten und externe Netzwerk-Infrastruktur. Die Charakteristika der eigenen Hardware-Plattform waren gut bekannt und über einen Zeitraum von 5 Jahren in ihren Facetten erforscht. Berechnungsintensive, Festplatten-I/O-intensive oder Kommunikationsintensive Anwendungsfälle waren an die Gegebenheiten angepasst worden bzw. fielen nur bedingt auf, weil alles im lokalen Rechenzentrum ablief.

Um die neue Plattform besser zu verstehen, wurde zuerst in einem Spike ein Microservice in die Cloud-Infrastruktur migriert. Diese Vorerfahrung lieferte Informationen, wie sich grundsätzlich die Situation darstellt. Wie ist der Zugriff auf die Cloud-Maschinen, wie funktioniert ein Deployment, wie verhält sich die Verbindung zwischen Hardware- und Cloud-Maschinen? Am Ende existierte also ein gutes Verständnis der neuen Plattform.

Der Umstieg sollte innerhalb eines Vierteljahres umgesetzt werden. Das Teilsystem sollte dabei aus der Cloud weiterhin mit den anderen Teilsystemen auf der eigenen Hardware interagieren. Um diesen anspruchsvollen Zeitplan zu schaffen, wurden zwei Profis als Coaches hinzugezogen. Das Team hätte es in dem kurzen Zeitraum nicht alleine geschafft.

Wichtige Voraussetzung für die Migration war der Aufbau einer Virtual Private Cloud (VPC), um die später auf der Cloud laufenden Services in die Gesamt-Infrastruktur einzubinden. Das Hochziehen der VPC, eingebettet in die DNS-Struktur, wurde als Unterstützungsleistung vom Operations-Teams und den zwei Profis gemacht. Das Development-Team wäre damit überfordert gewesen. Das angestrebte Ziel, ohne Kollegen aus dem Operations-Team neue Maschinen nutzen zu können, ist nur teilweise erreicht worden. Wir würden "NoOps" deshalb als einen Nordstern für das Projekt bezeichnen. Insbesondere das Detailwissen beim Zusammenschließen der verschiedenen Netze war für das Development-Team nicht anders verfügbar.

In einem Workshop wurden alle Abhängigkeiten zu dem, was in die Cloud migriert werden sollte, erarbeitet. Ziel war es, so wenig wie möglich technische Kommunikation zwischen Instanzen aus der Cloud in entfernte Bereiche zu haben. Das Teilsystem in der Cloud sollte so nah wie möglich an die Idee eines self-contained Systems (SCS) kommen. Insgesamt hat das Konzept des SCS geholfen, die Einheit zu definieren, die in die Cloud bewegt wurde.

Der Umstieg auf die Cloud hilft erst mittelfristig, das Kostenbewusstsein zu schärfen. Da die eigene Hardware über langfristige Verträge bezogen wurde, kosten die Cloud-Ressourcen zuerst einmal zusätzliches Geld. Das beginnt sich zu ändern, wenn Verträge auslaufen bzw. zusätzlich benötigte Ressourcen in der Cloud bezogen werden können. Development-Teams können jetzt kurzfristig in der Cloud Maschinen anfordern, wenn sie Experimente machen möchten, ohne dass dafür langfristig Hardware vorgehalten werden muss.

Um den Umstieg von den eigenen Maschinen auf die Cloud so vorsichtig wie möglich zu gestalten, wurde das Cloud-basierte System schrittweise für die Produktion aktiviert. Dafür wurden Proxies auf der alten Seite eingerichtet, die zuerst kleinere Mengen des Traffics auf den neue Standort umgelenkt haben. Der Anteil wurde dann schrittweise erhöht und das Systemverhalten gemonitort.

Charakteristika

Zusammenfassend hier eine Übersicht über die Charakteristika der beiden Projekte.

	Shop-System A	Shop-System B
Umfang des Umstiegs	Gesamtsystem	Teilsystem (Vertikale)
Development-Projekt	Neu-Implementierung in der Cloud	unverändert außer Details
Architektur	Monolith -> Drei-Schicht	Microservices, SCS
Operations	alleine verantwortlich für Maschinen	Development größtenteils verantwortlich, Operations unterstützt
Virtual Private Cloud	vorhanden, eingerichtet von Operations	vorhanden, eingerichtet von Operations
Umstiegsverfahren	Big-Bang	Proxy zur Realisierung eines schrittweisen Umstiegs
Wichtige Befürchtungen		I/O-Verhalten und Netzwerk-Kommunikation
Umstiegszeitraum	18 Monate	3 Monate
Operations durch Development-Team	kein Ziel	Nordstern
Abhängigkeiten zu anderen Systemen	klar abgrenzbare Schnittstellen	Schnittstellen müssen erst identifiziert werden
Kosten	neues System teurer als Monolith	mittelfristig kosteneffizienter

Unsere Erfahrungen

Nachdem oben grob die beiden Migrationsprojekte ihrem Ablauf nach skizziert wurden, sollen nun die Erfahrungen aus beiden Projekten im Vordergrund stehen.

System A:

• Aufwändige VPN-Verbindungen: Das Shop-System musste vollständig in das VPN-Netz der Firma integriert werden, damit es mit allen Produktionssystemen kommunizieren konnte. Aber nur das Frontend des Shop-Systems durfte für die Kunden nach außen sichtbar sein. Das war eine Herkules-Aufgabe für das Operations-Teams, denn historisch bedingt wurden alle Teil-Netze mit allen anderen Teil-Netzen wechselseitig verbunden (sternförmig im Gegensatz zu einem Bus).
• Routing über Regionen hinweg: Mit dem Shop war eine große Anzahl von Payment-Providern verbunden, sodass in jedem Land mindestens drei verschiedene Bezahlsysteme angeboten werden konnten. Durch das geographische Routing konnte es allerdings passieren, dass eine Bezahlanfrage von Region A abgesendet wurde und die Antwort in Region B eintraf. Das Shop-System musste dann intern das Ergebnis richtig zuordnen.
• Monitoring und Alarming: Für die virtuellen Maschinen wurde ein eigenes Monitoring und Alarming aufgebaut. Dabei wurden Performance-Probleme lange Zeit nicht gesehen, weil das Messintervall nicht angemessen war.
• Weitere Environments: Für Development und Testen sind identische Umgebungen nötig, um alle Effekte zu verstehen. Diese müssen beim Cloud-Anbieter ebenfalls vorgehalten werden.
• Aufwand für eigene Datenbanken: Die Datenbank hat sehr mächtige Maschinen beim Cloud-Anbieter verlangt. Zum Zeitpunkt der Architektur-Entscheidung waren noch keine passablen Datenbanken im Angebot. Heute würde man die des Cloud-Anbieters nehmen.
• Vendor-Lock-in: Vermeidung von Vendor-Lock-in hat ganz viele Möglichkeiten verhindert und letztlich nichts gebracht: Das Cloud-Projekt stand von Anfang an unter der Maßgabe, dass kein Vendor-Lock-in begünstigt werden sollte. Deswegen wurden Services des Cloud-Anbieters nicht genutzt, sondern selbst implementiert (bspw. Queueing). In vier Jahren haben wir aber keinen Grund für einen Anbieterwechsel gefunden. Sowohl die Preise als auch der Funktionsumfang sind angemessen.
• Autoscaling: Das Skalierungs-Feature von AWS ("autoscaling") bringt bei unserem Anwendungsfall keinen Vorteil. Die Lastspitzen dauern meist nur wenige Minuten. Autoscaling braucht aber um die 20 Minuten, um eine weitere Instanz zu aktivieren. Hier lässt sich durch zeitliche Planung der Lastspitzen mehr erreichen, weil der Anwendungsfall das zulässt. Die meiste Zeit wurden allerdings ausreichend viele Instanzen über den ganzen Tag vorgehalten.
• Trennung der Zuständigkeiten ist eine große Hürde: Die Trennung der Zuständigkeit für die Maschinen macht die Arbeit schwerer als notwendig. Das Operations-Team ist für das Besorgen oder Löschen der Maschinen zuständig. Sie installieren auch das Betriebssystem und machen das Monitoring auf unterster Ebene. Das Development-Team installiert darauf die Software mit eingeschränkten Rechten und ist für das Monitoring des Application-Servers und der Applikation selbst zuständig. Daraus ergeben sich insbesondere bei der Fehlersuche langwierige Prozesse und Unklarheiten bei den Zuständigkeiten.

Lessons Learned
Mittlerweile gibt es Nachfolgeprojekte, die das Angebot des Cloud-Anbieters stärker nutzen. 1. Den Umstieg von MySQL auf relationale Cloud-DB und 2. den Umstieg von RabbitMQ auf Cloud-Queueing-Service.

System B:

• Verschlüsselte Kommunikation: Die Grenzübergänge zwischen dem in der Cloud realisierten System und dem auf eigenen Maschinen laufenden System bedeuten, dass alle Zugriffe verschlüsselt werden müssen, denn das Routing der Datenpakete kann nicht garantiert werden. Deswegen musste das Migrationsprojekt warten, bis die anderen Teams HTTPS bzw. Token-Identifizierung in ihre Schnittstellen eingebaut haben.
• Standard-Services vom Cloud-Anbieter nutzen: Die Services für Logging, relationale Datenbank und dokumenten-orientierte Datenbank waren bei Beginn des Migrationsprojekts bereits im Angebot der Cloud. Sie können direkt genutzt werden und ersparten Aufwand.
• Keine Kosten- oder Performance-Optimierung upfront: Bei der Migration gab es immer wieder Tendenzen, im Sinne von Kostenersparnis oder Performance gleich zu Beginn zu optimieren. Es hat sich aber herausgestellt, dass es besser ist, zuerst die Migration funktional angemessen fertigzustellen und dann zu schauen, wo Kosten- bzw. Performance-Verbesserungen möglich sind. Meistens ist die Entwicklungszeit teurer als das Mieten neuer Ressourcen. Trotzdem sollte man informatische Grundregeln einhalten und weder mit Prozessor-Zeit noch mit Speicher unwirtschaftlich umgehen.
• Entwicklungsumgebung für Cloud-Development: Ein neues Problem, das mit der Verschiebung der Plattform aufgekommen ist, ist die Handhabung der lokalen Entwicklung. Diese ist bei reinen Cloud-Anwendungen schwieriger geworden, denn das lokale Entwicklungssystem ist nicht zwangsläufig identisch mit dem Cloud-System. Ein weiterer Schritt – der Transfer auf die Cloud-Maschinen – kommt also zur Entwicklung hinzu. Man muss seine Entwicklungsumgebung gekonnt einrichten, um hier einen bequemen Entwicklungsrhythmus zu etablieren.
• Vendor Lock-in: Die Frage nach dem Vendor-Lock-in hat sich auch in diesem Projekt gestellt, wird aber wenig kritisch bewertet. Der Geschwindigkeitsvorteil, den der Cloud-Anbieter für die Entwicklung bietet, ist so deutlich, dass es lohnt, die fertigen Services in die Software einzubinden und damit Entwicklungszeit zu sparen.
• Auf Eigenentwicklung so weit wie möglich verzichten: In vielen Fällen überholt die Cloud-Entwicklung die Eigenentwicklung, d. h. es lohnt z. B. nicht, einen eigenen Logging- oder Queueing-Service anzubinden. Die vergleichbaren Services des Cloud-Anbieters werden regelmäßig aktualisiert und enthalten die wesentlichen Informationen.
• Infrastruktur als Code-Vorteil: Vorteile, die durch das Aufsetzen von Maschinen in der Cloud entstehen sind u. a. auch dadurch begründet, dass die Beschreibung der Maschinen als Dokumentation der gesamten Infrastruktur zu einem Artefakt im Entwicklungsprozess wird.
• Aufwändiges Rechtemanagement: Wermutstropfen bei AWS ist das Rechtemanagement, welches extrem kompliziert ist. Dadurch wird es schwierig, die Rechte zwischen Gruppen aufzuteilen. Es ist einfacher, durch gegenseitige Schulung und intensive Zusammenarbeit Vertrauen zu etablieren und dann gegenseitig die Rechte zur Verfügung zu stellen.
• Einbeziehen der Fachseite: Für das Migrationsvorhaben – unseren Proof of Concept – gilt, dass die Fachseite im Vorfeld über die Laufzeit des PoC und die zu erwartenden Vorteile informiert werden muss. Dadurch erzeugt man Verständnis und erklärt bereits im Vorfeld, warum während dieser Zeit keine Features umgesetzt werden können. Am besten veranstaltet man gemeinsam mit der Fachabteilung ein Kick-off-Meeting, in dem die wechselseitigen Erwartungen geklärt werden. 

Fazit

Der Umstieg auf eine Cloud-Plattform ist mit Mühen verbunden. Die Architektur muss für die Cloud-Plattform geeignet sein. Es ist günstig, wenn man möglichst die Standard-Dienste der Cloud verwendet, anstatt sie selbst zu implementieren.
Im Zusammenspiel der Cloud mit anderen Rechner-Ressourcen wird eine Netzwerk-Infrastruktur notwendig, die ein geschlossenes System herstellt. Verschlüsselte Verbindungen sind notwendig, wenn die Kommunikation über offene Netze läuft.

Latenzen können durch verschiedene Cloud-Standorte adressiert werden. Tatsächlich treten aber durch den Umzug vom eigenen Rechenzentrum zu einem Cloud-Rechenzentrum teilweise längere Ausführungszeiten und größere Latenzen auf. Das hat aber keinen messbaren Einfluss auf die Nutzer, wenn der Cloud-Standort richtig gewählt wird.

Ein neues System lässt sich dank der Maschinenbeschreibung in kurzer Zeit hochziehen. Das ist für Angriffs- oder Ausfallszenarien gut und kann ebenso für neue Standorte verwendet werden. Skalierung ist in der Cloud weit weniger aufwändig. Allerdings sind die automatisch angebotenen Mechanismen für den Anwendungsfall eines Shops nicht immer geeignet/ nicht elastisch genug. Ausreichend Systeme können für die notwendigen Zeiten angemietet werden.

Beim Shop-System A wurde ein großer Teil der Leichtgewichtigkeit, die die Cloud bietet, nicht erschlossen. Das lag daran, dass wegen der strikten Trennung zwischen Operations- und Development-Team Arbeitsaufträge nach wie vor durch mehrere Hände wandern mussten. Außerdem hat die Architekturentscheidung "ein Service auf einer Maschine" ein Teil der Flexibilität der Cloud reduziert.

Für das Shop-System B ist nun eine flexible Reaktion auf Last möglich. Für Zeiten mit größerer Last werden im Vorfeld zusätzliche Instanzen erzeugt, die danach wieder freigegeben werden.

Beitrag zur Agilität

Der Umstieg auf die Cloud hat in beiden Projekten einen Beitrag zur Agilität geleistet. Durch die kurze Wartezeit, bis neue Maschinen verfügbar sind, können die Developer jetzt zügiger neue Funktionalitäten testen und zur Verfügung stellen. Insbesondere technische Spikes werden erleichtert.

Das Streben nach ganzheitlicher Verantwortung wird ebenfalls durch die Cloud gefördert. Ist im Team das Know-how für die Netzwerkeinbindung vorhanden und kennt sich das Development-Team ausreichend auf der Betriebssystem-Ebene aus, kann es die Verantwortung übernehmen.

Das Ausprobieren wird insgesamt leichtgewichtiger, weil bestimmte Services schon da sind. Eine Datenbank – Logging- oder Queueing – muss nicht erst installiert werden. In vielen Fällen sind diese als Services bereits verfügbar und mit geringen Kosten nutzbar.

Großes Potential steckt in der Möglichkeit, beliebig viele Stages und Umgebung hochziehen und abreißen zu können. Dies wird ja auch gerne als Maß für Agilität verwendet. Da die Abrechnung bei Cloud-Dienstleistern nur nach genutzten Stunden geht, sind die Kosten klein und der Nutzen kann sehr groß sein. Tendenziell kann für jedes Feature, jeden Entwickler und jeden Testlauf eine eigene Umgebung erstellt werden. Das Development-Team kann den Mehrwert für seine Arbeit selbst gestalten.

Autor

Das könnte Sie auch interessieren