Benjamin Wilms codecentric AG

In den heutigen State-of-the-Art-Architekturen ist es fast unmöglich, den Überblick zu behalten – und es gibt auch im Hause Netflix nicht viele Personen, die wissen, wie und warum Netflix funktioniert. Klar, wir sind nicht Netflix. Weder müssen wir so skalieren noch müssen wir so schnell sein und über 1 000 Deployments am Tag in Produktion bringen. Außerdem sind wir nicht gezwungen, in die gleichen Probleme wie Netflix zu laufen, sondern können aus den Fehlern und Erfahrungen des Unternehmens lernen. Das war für mich einer der Gründe, mich näher mit dem Thema Chaos Engineering zu beschäftigen.

Seid ihr nicht auch genervt von Prio-1-Tickets an einem Freitagnachmittag? Sucht ihr nach einem Weg, der es euch ermöglicht, das Zusammenspiel all eurer Services und der Plattform, auf der sie betrieben werden, besser zu verstehen? Dann ist Chaos Engineering der richtige Ansatz, der euch helfen kann, eure Applikationen und deren Betrieb zu verbessern!

Als Entwickler, als Architekt und in jeder anderen Rolle, die in den Prozess der Erstellung und beim Betrieb einer neuen Software involviert ist, verfolgen wir gemeinsam ein Ziel, nämlich den schönsten Ort der Welt zu erreichen: die Produktion.

Wie im echten Leben planen wir unseren Aufenthalt mit viel Bedacht. Die Entwickler sichern die Implementierung der fachlichen Anforderungen mit unzähligen Unit- und Integrationstests ab. Der Architekt verfolgt mit großer Begeisterung die Umsetzung seiner über Wochen gereiften Architektur und hofft, dass die geplanten Resilience-Patterns wie vorgesehen implementiert werden.

Manche von uns dürfen und können diesen schönsten Ort jederzeit besuchen, andere konnten oder durften noch keine Continuous-Integration- und Continuous-Deployment-Pipeline aufbauen. Daher erreichen sie die Produktion unter Umständen nur zweimal im Jahr. Was uns aber alle verbindet, ist das ungute Gefühl kurz vor dem Release in Produktion.

Denn die Produktion kann auch ein Biest sein: Schnell kommt in uns das Gefühl auf, dass sie uns hasst und wirklich alles unternimmt, um uns den Aufenthalt zur Hölle zu machen. Dann befinden wir uns im „Cycle of dying Apps“ (Abb. 1), den unser Baby oder wir durchleben.

Abb. 1: Der Cycle of Death

Abb. 1: Der Cycle of Death

Voller Enthusiasmus setzen wir zunächst neue Features um oder beseitigen Bugs. All unsere Tests laufen erfolgreich durch, und dank der CI/CD-Pipeline schaffen wir es auch kontinuierlich in Produktion. Dort angekommen verfolgen wir gespannt den Start unserer Applikation. Da wir nun aufgrund der hohen Automatisierung etwas Zeit haben, beginnen wir, uns mit den üblichen Fragen zu quälen:

  • Startet meine Applikation mit der richtigen Konfiguration?
  • Meldet sie sich korrekt bei der Service Discovery?
  • Wird sie von allen anderen über die Service Discovery gefunden?
  • Wo ist die Datenbank?
  • Circuit-Breaker-Pattern, check! Sind die Fallbacks valide und funktionieren sie im Ernstfall?

Die Liste an Fragen ist schier endlos, doch zum Glück ist die Ramp-up Time nicht allzu lang. Mit einem lauten Knall und einem gar unendlichen Stacktrace werden wir aus unseren Gedanken gerissen. Hektisch beginnen wir mit der Fehlersuche und versuchen es gleich noch einmal.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 3.19 - "Chaos Engineering"

Alle Infos zum Heft
579878102Chaos Engineering: Hin zu unverwüstlicher Software
X
- Gib Deinen Standort ein -
- or -