Vor anderthalb Jahren, im Herbst 2018 erreichte uns die Anfrage eines möglichen Neukunden, der einen bekannten Webshop betreibt. Dabei ging es um den kompletten Neubau des Shops.
Was zunächst nach einem netten kleinen Projekt klang, wurde mit der nächsten Aussage zur Herausforderung: Das Projekt lief bereits seit drei Jahren und war bisher schon zweimal mit unterschiedlichen Lösungsansätzen und Umsetzungspartnern gescheitert.
Auweia. Na, das kann ja was werden. Aber erstmal Informationen organisieren und das Angebot schreiben.
Ein paar Telefonate später war klar: Der Kunde wünscht sich eine Individualentwicklung und war vorher krachend damit gescheitert, die vermeintlichen Standardlösungen anzupassen. Ach ja, und in einem Jahr soll der bestehende Shop abgeschaltet werden.
Inhalt
- Ein Death-March-Projekt?
- Das erste Release
- Rollout
- Ablösung des alten Shops
- Betrieb und Wartung
- Weiterentwicklung
- Epilog
- Tech-Stack
- Prozesse
Ein Death-March-Projekt?
Also, einen No Risk Tech Stack gewählt: Spring Boot + Vue.js und etwas Microservice-Architektur, Kubernetes als Runtime und natürlich DevOps. Und tatsächlich: Wir haben den Auftrag bekommen. Aber wie ging es weiter?
Klar ist, nach zwei Fehlschlägen braucht der Kunde vor allem Sicherheit. Wir haben daher noch vor dem offiziellen Projektstart einen kleinen Prototypen gebaut: Schnell ein paar Texte und Bilder auf eine hübsche Webseite gesetzt, die URL vom Checkout-Button des alten Shops kopiert und fertig ist der Webshop Ultralight, der aber immerhin schon ein Produkt verkaufen kann. Das Ganze haben wir dann mit Gitlab CI automatisch auf einem kleinen Kubernetes Cluster in der Google Cloud installiert.
Wir sind also am ersten offiziellen Tag des Projektes bereits mit einem funktionierenden Shop gestartet, inklusive DevOps und Continuous Deployment. Diese vertrauensbildende Maßnahme hat dem Kunden, wie erwartet, erstmal eine ganze Menge Sicherheit gegeben. Von dort aus haben wir Iteration für Iteration weitere Features hinzugebaut. Dabei sind wir nie vom Prinzip des funktionierenden Shops abgewichen. Natürlich war dieser Shop nie wirklich live.
Das erste Release
Großartig an der Geschichte war auch der Product Owner des Kunden, da er den Sinn eines Minimum Viable Products verstanden hat. Der PO sagte: "Wir haben da so eine Seite mit Sonderaktionen, die jede Woche wechseln. Da sind nur vier oder fünf Produkte drauf, die könnten wir doch als Erstes ablösen". Geniale Idee. Wir hatten ein Ziel und sind nach etwa drei Monaten mit der ersten Seite dann auch wirklich live gegangen.
Bisher waren Releases bei unserem Kunden immer ein Riesenthema, das viel organisatorischen Overhead und auch hin und wieder auch längere Ausfallzeiten des Shops mit sich gebracht hat. Dank Automatisierung konnten wir wesentliche Verbesserungen erreichen.
Rollout
Wir haben die Möglichkeiten von Kubernetes ausgenutzt und automatisch aus unserer Gitlab-Pipeline Deployments auf allen Stages durchgeführt: Dev, Test und auch Live. Und das auch ggf. mehrmals täglich. Durch die Microservice-Architektur waren die einzelnen Deployments eher klein und konnten dank Kubernetes jederzeit und ohne Downtime durchgeführt werden. Dafür haben wir uns GitOps-Prozesse in unsere Pipelines eingebaut, sodass Releases einfach durch einen Merge-Request in unserem Repository ausgelöst werden können.
Ablösung des alten Shops
Von da an haben wir praktisch mit jedem weiteren Zweiwochensprint weitere Seiten vom alten Shop übernommen und den alten Shop nach und nach entkernt. Die letzte Seite haben wir dann Ende November 2019 übernommen und den alten Shop abgeschaltet.
Und wenn sie nicht gestorben sind …
Aber halt. Normalerweise wäre die Geschichte jetzt zu Ende. Aber eins der DevOps-Prinzipien heißt: "You build it, you run it". Das heißt jetzt kommen noch so unsexy Themen wie Betrieb, Monitoring und Rufbereitschaft.
Betrieb und Wartung
Zum Glück haben wir bei iteratec einen Hang zur Automatisierung. Also haben wir mit dem Kunden zusammen, ausgehend von der User Journey, die einzelnen Prozesse im Shop hinsichtlich ihrer Kritikalität beurteilt und Schadenssummen für eine Stunde Ausfall berechnet - grob etwa den Jahresumsatz mal Marge und dann auf Stundenebene runtergebrochen. Wenn gar nicht mehr gekauft werden kann und der Schaden eine festgelegte Summe übersteigt, gilt die Störung als kritisch.
Also haben wir für alle Prozesse, wo ein Ausfall den Verkaufsprozess entsprechend stark stört, automatische Tests geschrieben, die alle paar Minuten checken, ob man noch bis zum Checkout kommt. Sobald ein Test dreimal hintereinander fehlschlägt, liegt eine kritische Störung vor und das System erstellt selbsttätig ein Support-Ticket in unserem Ticketsystem.
Wir sind mächtig stolz auf dieses System, denn sowas haben wir vorher auch noch nicht gebaut. Aber wenn man selber Rufbereitschaft hat, kommt man auf solche Gedanken. Am ersten Wochenende gab es auch tatsächlich mal einen Ausfall und wir konnten unser schönes Alarmsystem gleich testen.
Das ist jetzt zwei Monate her. Seitdem ist Ruhe, absolute Ruhe. Gestern haben wir uns gefragt: Ob es wohl noch funktioniert? Also haben wir einen Probealarm ausgelöst. Es geht noch. Seitdem ist wieder Ruhe. Wir haben also Zeit für ein System investiert, das absolut nichts zu tun hat. Das Konzept nennt man im normalen Sprachgebrauch: Versicherung.
Weiterentwicklung
Nach der Version 1.0 geht es natürlich weiter. Neue Features werden in Zweiwochensprints entwickelt und Rollouts erfolgen manchmal sogar mehrmals täglich. Die automatisierten DevOps-Prozesse geben uns und dem Kunden die Sicherheit, agil im besten Sinne vorzugehen. Die Microservice-Architektur zahlt sich gerade in der Phase aus. Jedes einzelne Release ist eher klein und beinhaltet somit wenig Risiko. Die Selbstheilungskräfte von Kubernetes (automatischer Neustart von Containern) sorgt für einen stabilen Betrieb und das Monitoring lässt uns Problem erkennen, lange bevor sie akut werden.
Tech-Stack
- Spring Boot und Micronaut
- Kotlin
- Gradle
- VueJS
- Headless CMS (GraphCMS)
- Google Kubernetes Engine
- Google PubSub
- Google Memory Store (Redis)
- Kustomize
- BrowserStack (Selenium Grid)
- Logging Monitoring: DataDog
- Gitlab CI
- Lasttests mit Locust
Prozesse
- Scrum mit Zweiwochensprints
- DevOps
- GitOps
- Nächtliche Lasttests auf dem Live-System
Noch Fragen?
Wie können Sie agile Methoden in Ihrer Organisation umsetzen, damit sie einen echten Mehrwert liefern? Erfahren Sie, wie wir Sie unterstützen können:
Guido Zockoll - arbeitet als Senior Software-Architekt bei der iteratec GmbH in Hamburg. Davor hat er sich in verschiedenen Kundenprojekten mal als Software-Architekt, mal als Projekt- oder Programm-Manager für agile Vorgehensweisen und pragmatische Lösungen stark gemacht. Sein Spezialgebiet sind Cloud-Native-Architekturen, DevOps und Microservices.