Die Sache mit den ETAs

Eines unserer Grundprinzipien ist: Wir geben keine ETAs. Features kommen, wenn sie fertig sind und nicht zu versprochenen Zeitpunkten. Wir sind der Meinung, dass es nicht gut sein kann, unter Zeitdruck an etwas zu arbeiten und sind fertig, wenn wir eben der Meinung sind, dass wir fertig sind; wenn wir soweit hinter unserer Arbeit stehen, dass wir sie vertreten können und gut finden. Wir haben kein Venture Capital und keine Abteilung im Rücken, die darauf pocht, neue Features schnellstmöglich und unpoliert auf den Markt zu werfen und profitabel zu machen. Daher nehmen wir uns die Zeit, die wir eben brauchen und finden diese Herangehensweise richtig und wichtig. Allerdings haben wir bei einer Sache mit diesem Grundprinzip gebrochen und das ist Uberspace 7. Unser erster ETA war Ende 2015, dann war es Anfang 2016. Jetzt haben wir daraus gelernt und wollen euch in einer Reihe von Blogeinträgen ein wenig an unserem Lernprozess teilhaben lassen und erklären, warum das alles (gefühlt) so schrecklich lange dauert. Aber erst mal ein Schritt zurück: Uberspace 7?

Gegenwart VS Zukunft

Wir nutzen für Uberspace den Red Hat Enterprise Linux-Ableger CentOS, da geht es generell etwas konservativer zu als bei anderen Distributionen: CentOS ist eine Linux-Distribution die bewusst auf langfristige Stabilität ausgelegt ist. Bislang setzen wir noch auf CentOS 6 (von 2011), das zwar regelmäßige Updates (und natürlich Sicherheitsupdates) erhält, aber eben auch keine großartigen Neuentwicklungen mehr erwarten kann. Positiv daran ist, dass durch diesen Ansatz sichergestellt wird, dass Setups mit CentOS nicht durch Updates kaputt gehen können. Die Medaille hat allerdings auch eine Kehrseite: Wir raten vielen Usern dazu, aktuelle Tools, die sehr zügig entwickelt werden, händisch mit Toast oder Linuxbrew zu aktualisieren, um einen aktuellen Stand zu erhalten - Versionen von 2011 sind meistens einfach nicht mehr zeitgemäß. Das ist eine unschöne Krücke und damit ist bald Schluss.

Seit Juli 2015 arbeiten wir daran, Uberspace mit CentOS 7 einen neuen Unterbau zu verpassen und damit auch aktuelle Versionen der von der Distribution mitgebrachten Tools bereit zu stellen. Und weil “Uberspace auf CentOS 7” so sperrig ist, nennen wir das Kind doch gleich beim Namen: Uberspace 7. So nennen wir das Projekt bereits seit einiger Zeit intern und da wir Uberspace als Hosting-Plattform bisher nie versioniert haben, gibt es bald einfach eine Version und das ist Version 7.

Evolution VS Revolution

Das ist nicht der erste Versionssprung, den wir hinlegen (und hier liegt auch der Hase im Pfeffer begraben, warum wir uns zeitlich so herrlich verschätzt haben): Unsere ersten Server laufen auf CentOS 5, der Umstieg auf CentOS 6 ging recht schnell, da unsere Arbeitsweise damals™ eine andere war und alles organisch gewachsen ist. Neue Features haben wir einfach mal eben nebenbei in vorhandene Infrastuktur “hineingebastelt”, live geschaltet und dann im Nachhinein so lange daran herumgefeilt, bis alles soweit lief. Wenn wir ehrlich sind, war das mehr Frickelei als solide Entwicklung und das war bei der damaligen Größe von Uberspace auch in Ordnung und vertretbar: Damals war Uberspace ein Experiment und wir hatten eine Hand voll Server, heute sind es über 100 und Uberspace ist unsere Haupteinnahmequelle. Wir sind konsequenterweise also dazu übergegangen, unser Produkt eher aus Sicht eines Systems Engineers, als eines klassischen Systemadministrators zu sehen. Diese Herangehensweisen sind allerdings so fundamental unterschiedlich, dass dieser Prozess Zeit kostet - mehr Zeit, als wir dachten. Denn nicht nur die Herangehensweise an Entwicklung und die tägliche Arbeit sind anders - wir mussten auch lernen, anders zu denken. Uberspace 7 bedeutet für uns also in erster Linie, uns mit vielen Aspekten auseinander zuersetzen, die uns bisher fremd waren.

• Wie gehen wir damit um, dass wir Infrastruktur in Code abbilden wollen?
• Wie provisionieren wir neue Uberspace-Systeme automatisiert?
• Wie sorgen wir dafür, dass Uberspace-Systeme uniform bleiben?
• Wie stellen wir sicher, dass Uberspace 7 unabhängig von zukünftigen Weiterentwicklungen weiterhin gewartet werden kann?
• Wie reduzieren wir das Risiko, dass ein Fehler unsererseits sämtliche Uberspace-Systeme betrifft?
• Wie werden wir agiler im Umgang mit Neuentwicklungen für Uberspace?

Dabei hat sich herauskristallisiert, dass es auf viele dieser Fragen bereits Antworten gibt, denn wir sind gewiss nicht die Ersten, die sich mit diesen Fragen konfrontiert sehen. Einige unserer Anforderungen mögen zwar relativ spezifisch für unsere Plattform und unsere Designentscheidungen sein, aber im Großen und Ganzen lassen sich unsere Ansprüche und Ziele auf folgendes eindampfen:

• Wir wollen repetitive, manuelle Prozesse automatisieren
• Wir wollen Ausfälle reduzieren
• Wir wollen schneller Features bereitstellen
• Wir wollen Fehler vermeiden
• Wir wollen unsere Abläufe verbessern

Veränderungen und Wachstumsschmerzen

Der Prozess der Veränderung setzte bereits früher ein, als uns das überhaupt bewusst war: Durch unsere Entscheidung, das altgediente pssh an den Nagel zu hängen und stattdessen Ansible zu nutzen um unsere Server zu provisionieren, haben wir uns - ohne es zum Zeitpunkt der Entscheidung wirklich zu wissen - auch gleichzeitig für DevOps entschieden, denn mit einem Tool für Konfigurationsmanagement haben wir bereits einen wichtigen Grundstein für diesen Pfad gelegt. Dass wir unsere bisher sehr freie Arbeitsweise damit komplett überdenken müssen und alle sehr viel mehr miteinander arbeiten müssen als wir das bisher getan haben, war uns zwar schon irgendwie klar, aber dass dies auch durchaus mit Herausforderungen verbunden ist, war uns nicht so bewusst.

Hinzu kommt, dass unser Team inzwischen eine Größe erreicht hat (immerhin sind wir jetzt 9½ Mädels und Jungs!), in der eine Aufteilung in mehr oder minder feste Teams und Aufgabenbereiche unabdingbar ist. Es kann nicht mehr jeder Kollege wissen, was jeder andere Kollege tut. Es kann nicht mehr jeder für Hardware, Kundensupport, Entwicklung, Dokumentation und so weiter zuständig sein. Wir brauchen Verantwortliche, die sich dann auch dediziert um diese Themen kümmern - wir brauchen eine Hierarchie und Aggregatoren.

Solche Prozesse sind nie einfach und kosten Zeit - Zeit, die wir unterschätzt haben. Aber das sind eben auch Lernprozesse und Entwicklungen, die wichtig sind und durchlaufen werden müssen um Skalierbarkeit und ein gutes Zusammenarbeiten im Team zu ermöglichen. Inzwischen können wir ruhigen Gewissens sagen, dass wir die Transformation gut über die Bühne bekommen haben und immer noch miteinander befreundet sind 😊.

Nun aber erst mal genug, hier soll es ja nur um einen Umriss gehen. Weitere Episoden und detailliertere Einblicke in unsere neue Arbeitsweise sind schon unterwegs (dabei gehen wir auch auf das Thema DevOps ein).

Abschließend möchten wir uns dafür entschuldigen, dass es im Blog rund um das Thema Uberspace 7 bisher so ruhig war und geloben Besserung und mehr Transparenz, wie ihr das von uns gewohnt seid.

TL;DR

Ja, es dauert. Ja, wir kommen gut voran. Ja, Uberspace 7 kommt bald.

✌️

Header von Rob Obsidian (CC BY 2.0)

• ← Previous Post
• Next Post →