AWS Cloud Developement Kit – Infrastructure as Code

Es lohnt sich, gelegentlich innezuhalten und den technischen Fortschritt, den wir sowohl privat als auch bei der Arbeit erleben, hinsichtlich seiner Bedeutung und seinem Tempo einzuordnen. Ob uns Ray Kurzweils Singularität bevorsteht, die Menschheit sich mit Gray Goo auslöscht oder wir um des Überlebens willen der Weiterentwicklung bedeutend engere Leitplanken setzen müssen: Der Fortschritt in der Informationsverarbeitung ist atemberaubend und er begeistert uns.

AWS CDK: Neue Wege gehen – ein Anwendungsfall

Die Amazon Web Services (AWS) gehören aktuell zu den führenden Cloud-Computing-Providern. Als AWS Advanced Consulting Partner machen wir uns die Dienste der Plattform in etlichen Projekten zunutze, sowohl auf Kundenwunsch als auch aus eigenem Antrieb.

In den vergangenen beiden Jahren sind zwei Ereignisse glücklich zusammengefallen: Zum einen haben wir für einen großen Automotive-Kunden ein Ladedienst-Backend für elektrische Fahrzeuge in AWS umgesetzt, das hohen Ansprüchen gerecht wird: hochverfügbar, selbstheilend und unterbrechungsfrei wartbar. Und zum anderen hat AWS ein Cloud Development Kit (CDK) auf den Markt gebracht, mit dem es – endlich – möglich ist, Infrastructure as Code umzusetzen. (Bisher verbarg sich hinter diesem Begriff viel zu oft lediglich eine Infrastruktur-Beschreibung.) Da wir im Ladedienst-Projekt einige gute Ideen realisiert haben und zukünftige Projekte darauf aufbauen können, haben wir uns das CDK nicht nur angeschaut, sondern gleich dazu genutzt, die Projektinfrastruktur als Blaupause zu entwickeln, um sie beliebig oft instanziieren zu können.

Unsere Zielsetzung: auf Knopfdruck (und mit ein paar Parametern) ein Projekt in der Cloud auszurollen.

• CI/CD komplett mit Code- und Artefakt-Verwaltung, einem Build Server und dynamisch erzeugten Build Agents.
• Eine möglichst flexibel einsetzbare Betriebsumgebung, prinzipiell selbstheilend und unterbrechungsfrei wartbar, bei Bedarf hochverfügbar. Falls etwa eine Vorproduktion benötigt wird, auch mehrfach.
• Ein beispielhaft verfügbarer Service („hello world“), der dann zeigt, wie Unit- und Systemtest ineinandergreifen.

Und das alles natürlich in einer Hochsprache entwickelt! Zur Auswahl standen C#, Java, Python, und Java-/TypeScript. Wir entschieden uns für Java, denn die meisten unserer AWS-Projekte werden in Java umgesetzt – und: Wir kennen uns damit aus. Wir wissen, wie wir damit stabile Anwendungen erschaffen, wie wir statische und dynamische Testverfahren nutzbringend einbinden und welche Tools wir wie einsetzen können. Ein weiterer großer Vorteil von Infrastructure as Code für uns: Wir können längst verinnerlichte Handgriffe in die neue Technologie übernehmen.

Rechts unten die generierte Build-Umgebung, die alles mitbringt, was das Entwicklerherz begehrt: Zentrales Element der Jenkins CI, der mit Multibranch Pipelines so viele Build Agents hochfährt, wie er für Build und Test gerade braucht. Den Quelltext zieht er aus dem Git und die fertigen Artefakte werden ins Artefakt-Repository archivert. Dass ein Sonar für die statische Analyse mitläuft, versteht sich von selbst.

Links die Betriebsumgebung – oder -umgebungen, ganz nach Wunsch. Je nach Belieben natürlich auch hochverfügbar: Ob ein oder mehrere Applikationsserver je Farbstrang dauerhaft laufen, ist trivial zu konfigurieren. Datenbanken und Lastverteiler sind übrigens „automatisch“ hochverfügbar; ein großer Vorteil der AWS-Dienste.

Klar, dieser Ansatz ist nicht für alle Projekte passend. Wer beispielsweise seine Dienste serverless betreiben kann, sollte zumindest in Erwägung ziehen, das auch zu tun. Für jene, die ausschließlich AWS-Projekte abwickeln, wäre die charmantere Lösung, die Build-Infrastruktur komplett auf AWS-Bordmittel zu verlegen und etwa CodeCommit, CodePipeline und CodeDeploy zu verwenden. 

Was haben wir gewonnen?

Inzwischen gibt es Architektur-Quickstarts von AWS, aber wir haben bewiesen, dass wir auch ohne Guides verwertbare Lösungen finden – und darauf sind wir stolz.

Auch die für den Betrieb zuständigen Kollegen, die unter anderem auch die Ladedienst-Cloud 24x7 betreuen, haben einen leicht zu erkennenden Nutzen: Je ähnlicher sich Projekte in ihrem Aufbau sind, desto leichter lassen sich viele davon betreiben. Und wenn die Blueprint erprobt ist, verlieren selbst Security Audits das letzte bisschen ihres Schreckens.

Die größten Vorteile liegen jedoch bei der Projektumsetzung: Dass das Setup innerhalb eines Arbeitstages gelaufen ist (statt in ein bis zwei Wochen) wird von Kunden sehr positiv aufgenommen. Und da das Team mit dem Umgebungslayout bereits vertraut ist und sich auch nicht mit den mühseligen und leidlich unkreativen Initialaufgaben beschäftigen muss, geht es ab Tag zwei an die Materie. Das begeistert den Kunden und unsere Kollegen.