Vorbemerkung: Mit “Führungskraft” meine ich gleichermaßen Führung auf CTO-Ebene, aber auch erfahrene Ingenieure auf Individual-Contributor-Ebene. Und täuschen Sie sich nicht - ich bin im Herzen Ingenieur und habe auf dem Weg viele Fehler gemacht. Dieser Artikel ist nur eine Möglichkeit für mich, aus meinen Fehlern zu lernen.
Ihre zwei Hauptziele als Führungskraft
Auf Engineering-Ebene sieht die Welt oft rosig aus. Neue Technologien tauchen täglich auf. Coole neue Sprachen, neue Paradigmen, die angeblich alle Probleme lösen. Neue Unternehmen bewerben Xaas-Systeme, die Ihre Technologielandschaft im Handumdrehen revolutionieren - sagen sie zumindest.
Aus einer Führungsperspektive (CTO/VP) sieht die Welt anders aus. All diese neuen Konzepte und Ideen sind cool und potenziell von großem Nutzen für Sie - aber in erster Linie haben Sie zwei Hauptziele, wenn es um eine potenziell neue Architektur geht:
- Ihre Abteilung - und Ihre Technologie muss Kunden begeistern und neue coole Sachen liefern - schnell.
- Sie müssen die Kosten im Griff behalten. Sparsam zu sein ist ein Wettbewerbsvorteil - besonders in Zeiten wie diesen (Rezession hust hust)
Aber wie bewerten Sie neue coole Architekturlösungen und bringen die Führungs- und die Engineering-Perspektive zusammen?
Vertrauen Sie den Ingenieuren - und bringen Sie die Führungsperspektive ein
Viele Unternehmen vertrauen ihren Ingenieuren, Entscheidungen auf Architekturebene zu treffen. Das ist eine sehr gute Idee. Die Führung stellt dann sicher, dass neue Entscheidungen tatsächlich in der Lage sind, Ihre zwei Hauptziele zu erfüllen. Sie machen Ihre Abteilung schneller in der Delivery (oder zumindest nicht langsamer) - und sie sind kosteneffektiv.
Ein Beispiel
In einem meiner vergangenen Aufträge arbeitete ich mit einer sehr talentierten Abteilung von Ingenieuren zusammen. Das Unternehmen war ziemlich alt und sie hatten einen sehr alten AWS-PostgreSQL-Cluster, der zum Speichern von Log-Daten (und einer Meeeenge anderer Daten) verwendet wurde.
Die Probleme häuften sich, als die Logging-Tabelle immer größer wurde. Der Neustart des PostgreSQL-Clusters dauerte ewig - und eine Wiederherstellung wäre sehr schmerzhaft gewesen. Es gab auch andere Probleme wie Zurechenbarkeit: Niemand wusste, wer Daten an diese Tabelle sendete oder von ihr konsumierte.
Zeit, nach Alternativen zu suchen.
Das Team kam mit folgender Lösung:
- Ein zentraler Kafka-Server (AWS MSK)
- Ein Microservice, der die Kontrolle (Authentifizierung) darüber ermöglicht, wer Daten an Kafka sendet und von Kafka konsumiert
- Kafka würde dann die Log-Daten an Elastic (AWS OpenSearch) streamen, wo die Daten landen würden.
Diese Lösung sah gut aus. Aber ist das die bestmögliche Lösung?
Wenn Sie diese Frage auf quantitativer Basis beantworten wollen, müssten Sie diese Lösung mit Alternativen in der echten Produktion über ein paar Jahre vergleichen. Das kann im Labor gemacht werden, aber nicht im echten Leben - zu teuer und unmöglich.
Aber es gibt einen qualitativen Weg, indem man einige einfache Fragen prüft.
Eine Checkliste für Architekturentscheidungen
Die folgende Checkliste kann verwendet werden, um zu wichtigen Fragen vorzudringen. Diese Checkliste ist ein wichtiger qualitativer Weg, um zu bewerten, ob ein Vorschlag tatsächlich seine Versprechen hält. Gleichermaßen wichtig für Führungskräfte und Ingenieure.
- Gibt es eine Null-Aufwand-Alternative? Im obigen Beispiel mit dem PostgreSQL-System hätten wir einfach die Daten automatisch beschneiden können, um die Größe zu begrenzen. Einige Konsumenten hätten das vielleicht nicht gemocht, aber das wäre handhabbar gewesen. Kein Bedarf für 3 neue Systeme und Monate an Engineering.
- Anforderungen und Probleme und vorzeitige Optimierung. Wurde das Problem wirklich gelöst - oder haben wir uns nur in eine Technologie verliebt? In vielen Architekturdiskussionen, die ich erlebt habe, wurden die ursprünglichen Probleme nicht besser gelöst. Oft wurden neue Probleme geschaffen, die wir vorher gar nicht hatten. Nicht gut.
- Alternativen. Haben wir alternative Architekturen mit Vor- und Nachteilen bewertet? Wir müssen es nicht übertreiben. Aber nur eine Lösung zu betrachten ist eine Falle.
- Kosten. Ein laufender PostgreSQL-Server und eine Organisation, die weiß, wie man ihn betreibt, ist trivial und günstig. Drei komplett neue Systeme (Kafka (MSK), OpenSearch / Elastic und ein eigener Microservice) sind ein massives Unterfangen und werden viele Menschen und Ressourcen binden. Vergessen Sie nicht, diese Kosten einzuberechnen und ein Preisschild daran zu hängen. Wie viele Leute werden wir brauchen? Was kosten sie pro Jahr?
- Entwicklungsgeschwindigkeit. Fragen Sie sich: Wird das neue Setup uns schneller machen (Zykluszeit, Deployment-Häufigkeit)? Besonders wenn Sie bedenken, dass einige Ingenieure damit beschäftigt sein werden, Systeme zu warten und Bugs in einem neuen Setup zu beheben.
- Debugging. Wie schwierig werden Probleme zu debuggen sein? OpenSearch hat Tausende von Konfigurationsoptionen - ebenso Kafka. Erwarten Sie lange Diskussionen über Shards, Retention in Partitionen und mehr. Ist das wirklich das, was Sie wollen?
- Ownership. Wem gehört das neue System? Wer führt Upgrades durch und wartet das System? Wer reagiert bei Bugs? Gibt es ein Team - oder schaffen wir Single Points of Failure?
- Wartung. Haben wir einen Plan, wie wir die Systeme warten - sind Dinge wie Ausfallzeiten berücksichtigt?
- Führen Sie ein Pre-Mortem durch. Sobald Sie denken, Sie haben eine Lösung - bewerten Sie, was potenziell schiefgehen könnte. Das ermöglicht Ihnen, versteckte Herausforderungen zu entdecken und das Risiko während der Übergangsphase zu managen.
Fazit
Die IT-Landschaft eines Unternehmens wird sich im Laufe der Zeit weiterentwickeln. Es ist die Pflicht aller - aber besonders von Senior- und Führungskräften - dass diese Änderungen das Unternehmen schneller machen und kosteneffektiv sind. Die in diesem Artikel vorgestellte Checkliste kann Sie qualitativ zu einer Antwort führen. Nutzen Sie sie, wann immer Sie einen Teil der Architektur Ihres Unternehmens überarbeiten müssen.
Mehr
- Tolles Foto oben von Alex Wong
