Читать книгу Handbuch Infrastructure as Code - Kief Morris - Страница 26

Wenn Sie mit Infrastructure as Code beginnen, haben Sie eine steile Lernkurve vor sich. Das Aufsetzen der Tools, Services und Arbeitsweisen zum Automatisieren der Infrastruktur-Bereitstellung erfordert viel Arbeit, insbesondere, wenn Sie sich gleichzeitig auch noch in eine neue Infrastruktur-Plattform einarbeiten. Der Wert dieser Arbeit wird erst dann sichtbar, wenn Sie beginnen, Services damit zu bauen und zu deployen. Und auch dann wird er eventuell denen nicht deutlich werden, die nicht direkt mit der Infrastruktur arbeiten.

Stakeholder drängen Infrastruktur-Teams oft dazu, schnell und mal eben manuell neue in der Cloud gehostete Systeme zu bauen und sich erst später um das Automatisieren zu kümmern.

Es gibt drei Gründe dafür, warum das eine schlechte Idee ist:

 Durch die Automation sollte das Bereitstellen schneller gehen, auch für neue Elemente. Implementieren Sie die Automation erst, nachdem ein Großteil der Arbeit erledigt ist, opfern Sie viele der Vorteile.

 Automation erleichtert das Schreiben automatisierter Tests für das, was Sie bauen. Und sie macht es einfacher, etwas schnell zu korrigieren und neu zu bauen, wenn Sie Probleme finden. Wenn Sie dies als Teil des Build-Prozesses tun, hilft es Ihnen dabei, eine bessere Infrastruktur zu bauen.

 Das Automatisieren eines bestehenden Systems ist sehr schwer. Automation ist Teil des Designs und der Implementierung eines Systems. Um ein System, das ohne Automation aufgebaut wurde, um diese zu ergänzen, müssen Sie das Design und die Implementierung des Systems deutlich anpassen. Das gilt auch für das automatisierte Testen und Deployen.

Cloud-Infrastruktur, die ohne Automation aufgebaut wurde, müssen Sie schneller abschreiben, als Sie denken. Die Kosten für das manuelle Warten und Beheben von Fehlern im System können schnell deutlich wachsen. Ist der Service, der darauf läuft, erfolgreich, werden Sie die Stakeholder dazu drängen, ihn zu erweitern und neue Features hinzuzufügen, statt innezuhalten, um ihn neu zu bauen.

Das Gleiche gilt, wenn Sie ein System als Experiment bauen. Haben Sie einen Proof of Concept zum Laufen gebracht, wird es den Druck geben, sich mit dem nächsten Thema zu beschäftigen, statt zurückzukehren und das System richtig neu zu bauen. Und eigentlich sollte Automation auch Teil des Experiments sein. Wollen Sie Automation zum Managen Ihrer Infrastruktur einsetzen, müssen Sie verstehen, wie das funktionieren wird, daher sollte es auch Teil Ihres Proof of Concept sein.

Die Lösung besteht darin, Ihr System inkrementell aufzubauen und die Automation direkt mit zu berücksichtigen. Stellen Sie sicher, dass Sie Werte bieten, während Sie gleichzeitig für die Möglichkeit sorgen, das kontinuierlich zu tun.