Java Magazin 10/15

Continuous Delivery in der Cloud: Auch Umgebungen fallen vom Himmel

Autor:

Wir Entwickler scheuen die Infrastruktur. Sie bietet keinen funktionalen Mehrwert, ist ein reiner Kostentreiber und daher langweilig. Dennoch werden nur 10 Prozent der Gesamtkosten einer Anwendung für die Entwicklung neuer Funktionen ausgegeben, der Rest landet in Verwaltung, Abstimmung, Konfiguration und Betrieb. Durch DevOps und Continuous Delivery können die Konfigurations- und Betriebskosten der Infrastruktur gesenkt und das Budget für die Entwicklung von Funktionalität erhöht werden. Daher ist es in unserem eigenen Interesse, dieses „leidige Thema“ in den Griff zu bekommen.

Milliardensummen werden investiert, um in Zukunft die Enterprise-Plattform aus dem hauseigenen Rechenzentrum in die Cloud zu holen. Ob dies sinnvoll ist oder nicht, sei dahingestellt, aber heute schon können wir die geleisteten Investitionen in die neue Technologie für un-sere Zwecke einsetzen. Wir möchten eine Infrastruktur auf eigener Hardware bauen und mit einer entsprechenden Toolchain versehen, um nicht mehr Anwendungen kontinuierlich, sondern komplette Umgebungen samt ihrer Infrastruktur zu deployen.

Bisher unterliegen die meisten Infrastrukturen keinem vollständigen Lifecycle-Management, sprich sie werden irgendwann in Prosa spezifiziert, händisch aufgesetzt und am Leben gehalten. Eine neue Infrastruktur aufzusetzen oder zu aktualisieren wird von vielen Firmen gescheut, da aufgrund der mangelnden Erfahrung Risiken und Aufwände nicht abzuschätzen sind. Auch wenn wir als moderne Entwickler es gelernt haben, unsere Software täglich mehrfach zu bauen und zu releasen, tun wir dies meist auf einer statischen und nicht näher spezifizierten Umgebung. Dadurch gibt es zwei Klassen an Änderungen: Änderungen im Quelltext der Anwendung können innerhalb von Stunden durchgeführt und releast werden; ein genauso wichtiges Update an einer DB-Konfiguration dauert weiterhin Wochen und Monate.

Bei normalen Anwendungen waren Anpassungen außerhalb des Quellcodes eher die Ausnahme. Aber die heutigen Anwendungen müssen auf einer auf Performance getunten Infrastruktur laufen, der NoSQL-Zoo will betrieben werden, hochperformante Messaging-Lösungen wie ZeroMQ oder RabbitMQ wollen ihren Beitrag leisten, oder neue Container wie Vert.x oder Mikrocontainer à la Spring Bootstrap verdrängen die Java-EE-Server aus
etablierten Nischen. Der bisherige One-Size-fits-all-Ansatz der Enterprise-Java-Infrastruktur reicht nicht mehr. Um auch solche neuen Lösungen optimal entwickeln zu können, muss auch die Infrastruktur neben der Anwendung mit der Lieferung ausgerollt werden.

Release Early, Release Often
Eine statische Infrastruktur hält Continuous-Delivery-Unterfangen auf, ganz gleich wie agil und kontinuierlich die Anwendung darauf gebaut wird. Häufig wird die Infrastruktur lediglich in großen Programmen unregelmäßig neu aufgesetzt und dann mit einem minimalen Aufwand am Leben erhalten. Dieser klassische Wasserfallansatz (Abb. 1) führt in der Infrastruktur zu den gleichen Problemen wie in der Anwendungsentwicklung (…).

Vollständiger Artikel

Weitere Inhalte zu Continuous Delivery

Vortrag

Continuous Delivery in a Box