Den größten Teil meiner Laufbahn habe ich in Startups verbracht – mit knappem Budget, zu wenig Personal und einer Deadline im Nacken. Da ist es leicht, dem Druck nachzugeben und Abkürzungen zu nehmen, um heute etwas auszuliefern. Der Preis: Ein paar Jahre später stehen Sie vor einem solchen technologischen Chaos, dass es Ihnen die Freude an der eigenen Arbeit raubt und in den Burnout treibt.
Leider spreche ich aus eigener Erfahrung. Ich habe einmal die Arbeit von drei Personen allein gestemmt, und nach drei Jahren in diesem Tempo war ich an dem Punkt, an dem mir alles egal war und ich am liebsten den ganzen Tag nur stumm an die Decke gestarrt hätte.
Keine Sorge – das ist eine Weile her, und ich habe mich vollständig erholt. Mit etwas Disziplin konnte ich auch verhindern, dass mir in den folgenden Karrierestationen dasselbe passiert. Mit der Zeit habe ich einige zentrale Zutaten herausgearbeitet, die meine Innovationsfreude langfristig auf Touren halten.
Heute habe ich das Glück, in einer Rolle zu sein, in der ich meine Erfahrungen weitergeben und anderen helfen kann, ihre Visionen Wirklichkeit werden zu lassen.
Das ist meine Geschichte und meine Erfahrung. Sie haben sicher Ihre eigene – und ich bin gespannt darauf.
Das Dream-Team
Stellen Sie sich ein Entwicklungsteam aus 5–10 Personen vor, das
- kontinuierlich neue Features pünktlich ausliefert
- von Ausfällen erfährt, bevor die Kunden sie bemerken
- Bugs schnell behebt – und mit "behoben" meine ich in Production, nicht im git-main-Branch
- noch Kapazität hat, neue Technologien zu erforschen und auszuprobieren
Und das Ganze über Jahre, ohne die Puste zu verlieren!
Klingt zu schön, um wahr zu sein? – Schauen wir es uns an. So würde ich heute ein neues Projekt aufsetzen. Es wird ein cloud-basiertes Projekt, in meinem Fall auf GCP.
1\. Kennen Sie Ihre Grundlagen
Security wird oft stiefmütterlich behandelt. Engineers halten das Thema für sperrig und beschäftigen sich gerade so weit damit, wie nötig, um die minimalen Cloud-Defaults zu überwinden und loslegen zu können. Schließlich kaufen Ihre Kunden keine Security – sie kaufen Features. In ihren Augen ist die Sicherheit des Produkts selbstverständlich.
Leider führt diese Haltung schnell zu schlechten Gewohnheiten – "Security-Keys im öffentlichen Git", schon mal gesehen? : )
Kernpunkte:
- Etablieren Sie im Team einen Security-Standard für die eingesetzten Technologien. Wenn Sie zum Beispiel mit einer neuen Cloud starten, sollten alle (nicht nur die DevOps-Leute) die Grundlagen kennen. Bei GCP etwa kann sich ein durchschnittlicher Entwickler innerhalb weniger Stunden mit dem Security-Modell vertraut machen.
- Sorgen Sie für eine feste Ansprechperson für Security Best Practices. Wenn es im Team niemanden dafür gibt: Google etwa hat in unserem Beispiel Partner, die genau dafür da sind, Ihnen jederzeit als fachlicher Sparringspartner zur Verfügung zu stehen.
Denken Sie an das Shared-Responsibility-Modell der Clouds – sie liefern sichere Bausteine, aber es liegt an Ihnen, sie sicher zusammenzusetzen.
Sobald Sie Ihre Security-Grundlagen verstanden haben, können Sie mit der Architektur beginnen.
2\. Architektur entwerfen – aber realistisch bleiben
Wir alle träumen davon, dass unser Unternehmen zum nächsten Twitter, Uber oder Google wird. Doch keines dieser Unternehmen war von Anfang an global aufgestellt.
Die Herausforderung besteht darin, klein zu starten und trotzdem Raum zum Wachsen zu lassen. Mein Vorschlag: Bilden Sie eine kleine Task-Force im Team, die darauf achtet, dass das Team nicht zu sehr in taktisches Denken abrutscht – was zwangsläufig passiert, wenn man im Modus "Features rausballern" steckt. Diese Task-Force sorgt dafür, dass die richtigen Trade-offs gemacht werden, zum Beispiel:
- Ich habe einmal einen Batch-Job-Manager für die ElasticSearch-Datenbank entwickelt. Eine Active/Active-Scale-out-Implementierung hätte den zehnfachen Aufwand bedeutet; eine Singleton-Variante hingegen konnte das Hundertfache an Last bewältigen – und es ist akzeptabel, wenn sie wegen eines Bugs oder Wartungsfensters mal 10–15 Minuten offline geht.
In diesem Fall haben wir uns bewusst für einen Single Point of Failure entschieden, weil es für unsere Geschäftsanforderungen ausreichte.
- Strategisch könnten Sie zum Beispiel ein cloud-agnostisches Produkt entwickeln wollen. Mit Kubernetes (K8s) als Anwendungsplattform erreichen Sie bereits etwa 80 % dieses Ziels. Allerdings nutzen Sie weiterhin Cloud-Services außerhalb von K8s – Load Balancer, Message Queues etc. – und es ist Aufgabe Ihrer Architektur-Task-Force, sicherzustellen, dass im Deadline-Stress kein anbieterspezifischer Service hineinrutscht. Und wenn doch, dann als bewusste, gut dokumentierte Entscheidung.
Ihre erfahreneren Tech Leads werden diese Rolle ohnehin übernehmen, aber es lohnt sich, das formaler zu organisieren und sicherzustellen, dass ihre Stimmen Gehör finden. Wenn Post-Mortems mit "Ich habe euch vor einem halben Jahr gesagt, dass das auseinanderfliegt" beginnen, ist das ein Zeichen, dass die Architektur-Task-Force nachjustiert werden muss. Das Stichwort lautet: Teams vertrauen.
Damit die Architektur-Task-Force erfolgreich ist und das ganze Team davon profitiert, müssen Product Owner und Management darauf vertrauen, dass die Engineers im besten Sinne handeln. Verantwortungsbewusste Engineers geben Feature-Druck schnell nach – und genau daraus entsteht der "Ich hab's euch ja gesagt"-Modus.
3\. Beginnen Sie das Coding mit dem CI/CD-Teil
Das mag etwas radikal klingen, aber ich hoffe, ich habe Ihre Aufmerksamkeit. Die klassische Falle lautet: "Erst die Features, die Tests kommen später." Unter Deadline-Druck sind Tests meist das Erste, was gestrichen wird.
Ein persönliches Beispiel: Ich hatte einmal ein Projekt mit einer großartigen Architektur, dem nur ein Baustein fehlte – wir hatten null Zeit darauf verwendet, uns Gedanken über das Testen zu machen. Im fünften Scrum-Sprint stellten wir fest, dass wir konstant 2–3 Tage vor dem Sprint-Review im "Integrations-Wahnsinn" steckten – und es wurde von Sprint zu Sprint schlimmer. Unser zweiter Fehler: Wir konnten den Feature-Wahn nicht stoppen und dem Produktmanagement klar kommunizieren, dass wir zurück ans Reißbrett mussten, um beim CI nachzubessern (siehe Hinweise zum Vertrauen in Teams im vorigen Kapitel). Ein Jahr später hatten wir ein nachträglich angeflanschtes CI, das öfter kaputt war als nicht, und eine ständige Quelle der Frustration für die Engineers. Dieser Big Ball of Mud wurde so groß, dass selbst mit Carte Blanche fürs Investment niemand im Team sich darauf einigen konnte, wie er am besten neu zu gestalten wäre.
Wenn Sie CI und CD von Anfang an in Ihre Kernarchitektur integrieren, passiert zweierlei:
- Sie werden sich fragen, woher Sie eigentlich wissen, dass das System funktioniert. Das führt automatisch dazu, dass Sie Ihren Code mit Operational Metrics instrumentieren.
- Wenn Sie nächtliche CI-Fehler debuggen müssen, entwickeln Sie sowohl die Skills als auch die Werkzeuge (z. B. saubere Logs und Tracing-Datenerfassung), um bereits aufgetretene Probleme zu analysieren und zu beheben. Genau diese Skills und Techniken braucht Ihr Team auch, um Production-Outages zu debuggen.
Als Nebeneffekt haben Sie Logging- und Monitoring-Systeme bereits vor dem Produktivstart im Einsatz. Eine Warnung zu Monitoring- und Logging-Frameworks: Die Betriebskosten – ob SaaS oder Eigenbau – können sehr schnell beträchtlich werden. Ich empfehle dringend, die potenziellen Kosten abzuschätzen und in die Entscheidung einzubeziehen.
Erst wenn Ihre CI-Praxis solide etabliert ist, dürfen Sie sich gelegentlich "Erst Features, Tests später" leisten. Mit "später" meine ich "nächster Sprint" – es sei denn, es handelt sich um Wegwerf- oder Demo-Funktionalität, die Sie ohnehin per Feature Flag wieder deaktivieren.
Jede Cloud bringt eigene native Monitoring- und Logging-Services mit, die für Sie passen können oder auch nicht. Bei K8s ist der CD-Teil weitgehend standardisiert, beim CI-Teil müssen Sie selbst gut recherchieren. Die drei großen Hyperscaler bieten zwar CI-Tools an, aber das ist ehrlich gesagt nicht ihr Kerngeschäft.
4\. Wer es baut, betreibt es auch
"You build it – you run it" ist in kleinen Unternehmen ohnehin gesetzt, weil es schlicht keinen SRE-Zaun gibt, über den man die Sachen werfen könnte. Die Frage ist also nicht, wer Production verantwortet, sondern wie sich die Verantwortung für den Production-Workload anfühlt.
Das Schöne ist: Wenn Sie die vorherigen Schritte beherzigt haben, fällt Production Ownership Ihrem Team ganz natürlich zu. Schauen wir, warum:
- Sie haben mit Security begonnen und somit bereits eine Perimeter-Trennung etabliert. Sie wissen, wo Sie nach Problemen suchen müssen – Situationen, in denen Entwicklungscode versehentlich auf die Produktionsdatenbank zugreift und Schaden anrichtet, sind schlicht ausgeschlossen.
- Ihre Architektur ist realistisch und passt zu Ihrem Team. Sie ist klar und leicht verständlich. Sie betreiben zum Beispiel keine komplexen verteilten Systeme, wenn es nicht nötig ist – und wenn doch, dann beherrschen Sie sie auch. Mit Ihren Observability-Tools finden Sie Problemquellen schnell.
- Ihr CI ist stabil und vertrauenswürdig, Ihr CD läuft reibungslos. Wenn Sie also einen Bug fixen müssen, sind Test- und Deploy-Prozesse schnell, einfach und kosten weder Nerven noch kognitive Energie. Das minimiert den Frust durch Bugs und verhindert die Situation der Continuous Maintenance.
Ihre Anwendungen haben Observability bereits eingebaut – Sie müssen nur noch Monitoring-Dashboards konfigurieren und Alerts einrichten.
Ein weniger offensichtlicher Aspekt von Production Ownership, gerade für Engineers, sind die Betriebskosten Ihres Produkts. Ich bin überzeugt, dass Engineers die Cloud-Billing-Modelle kennen sollten und wissen sollten, wie viel Geld ihre Software verbraucht – aus folgenden Gründen:
Keine Überraschungen auf der Rechnung
Sie müssen das Cloud-Billing-Modell verstehen, um Ihr System sauber zu designen (Bill Shock, schon mal erlebt?) – sowohl die Anwendungs- als auch die CI/CD-Architektur. Und damit es rund läuft: Richten Sie Billing-Budgets und Alerts ein.
Kennen Sie Ihre Unit Cost
Es ist hilfreich für Produkt- und Vertriebskollegen, die "Unit Cost" zu kennen. Wenn Ihr Produkt zum Beispiel Edge-Geräte überwacht, dann ist die "Unit Cost" der Betrag, den jedes überwachte Gerät zu Ihrer Cloud-Rechnung beiträgt. Diese Kennzahl ist sehr nützlich für Geschäftsmodelle und nimmt das Rätselraten aus der Kapazitätsplanung.
Wenn Ihre Application Metrics stehen, lässt sich die App-Logik durch einen genaueren Blick auf die Billing-Daten meist gut den Kosten zuordnen.
5\. Menschen arbeiten für Menschen
Wir lieben unsere Bits, Bytes und formale Logik – aber am Ende sind wir ein Haufen Menschen, die zusammenarbeiten.
Wir gehen zu Startups, weil wir an etwas glauben und dafür brennen.
Liebe Manager: Vertrauen Sie darauf, dass Ihre Engineers im besten Sinne handeln. Hinterfragen Sie ihre Ideen, aber lassen Sie ihnen Raum zum Innovieren. Achten Sie aufmerksam auf Anzeichen, dass Ihre Engineers in den Defensiv-Modus rutschen – ab da wird plötzlich jedes Feature kompliziert umzusetzen, und Ihr Projekt beginnt zu stagnieren.
Wir können den ganzen Tag über Clouds und Technologie reden – aber wenn die Arbeit keinen Spaß macht, hält Innovation nicht lange.