Von den eigenen Maschinen in die Cloud – ein Erfahrungsbericht
Vor 5 bis 10 Jahren haben viele Projekte auf eigener Hardware begonnen. Mittlerweile sind Cloud-Dienste so umfangreich und flexibel, dass die Vorteile überwiegen. Der Autor hat in unterschiedlichen Kontexten den Weg von großen verteilten Software-Systemen auf eigener Hardware hin zu cloud-basiertem Hosten begleitet. In diesem Artikel beschreibt er aus einer technischen Perspektive die Erfahrungen, die er bei dem Umstieg in zwei konkreten Kontexten gesammelt hat.
Hinweis: Das Wort "Maschine" wird in diesem Artikel synonym für das physikalische Gerät und die virtuelle Maschine benutzt. Wenn es darauf ankommt, wird der Maschinentyp genauer spezifiziert.
Das Setting
Als Betrachtungsgegenstand sollen zwei Settings dienen.
System A: Weltweites Shop-System auf eigener Hardware für virtuelle Güter
Im ersten Setting geht es um einen Onlineshop für Spiele, die weltweit laufen. Die Artikel – InGame-Währungen – sind virtuell, d. h. sie können elektronisch gutgeschrieben werden. Dieser Shop wurde in seiner ersten Version auf eigener Hardware in einem europäischen Rechenzentrum betrieben. Sowohl die Benutzungsschnittstelle (Web-Interface) als auch die Kommunikation mit den Backend-Systemen wurde auf dedizierter Hardware an einem Standort betrieben. Wesentliche Probleme dieser Konstellation waren
- die großen Latenzen für von Europa weit entfernte Länder und
- schlechte Elastizität bei hohem Datenvolumen zu spezielle Rabattaktionen.
Das Umstiegsprojekt lief in der Zeit von 2012 bis 2015.
System B: Europaweites Shop-System für Waren
Im zweiten Setting geht es ebenfalls um einen Onlineshop. Dieser ist für die Region DACH konzipiert und es geht um den Verkauf physischer Waren an Endkunden. Dieser Shop wurde zuerst auf eigener Hardware in einem deutschen Rechenzentrum betrieben. Verschiedene Komponenten des Shop-Systems wurden auf Clustern betrieben, sodass Elastizität und Ausfallsicherheit gewährleistet sind. Wesentliche Probleme dieser Konstellation waren:
- Die Elastizität konnte nur gewährleistet werden, indem immer die maximal notwendige Menge an Hardware vorgehalten wurde und
- der Beschaffungsprozess für neue oder andere Hardware war für die Development-Teams zu kompliziert und zu langwierig.
Das Umstiegsprojekt startete in der ersten Jahreshälfte 2017 und ist bisher für ein Modul des Systems abgeschlossen. Es soll auf weitere Module ausgerollt werden bis letztlich die gesamte Landschaft migriert ist.
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:
- 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.)
- 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.
- 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.
- 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.