WorkstationsLinux
Produktions-HostsLinux
Lücke zwischen Dev und ProdKeine OS-Überraschungen
Dasselbe OS, von Anfang bis Ende
Der Laptop einer Blax-Engineer läuft auf Linux. Die IDE läuft auf Linux. Die Shell ist dieselbe Shell, die auf dem Server liegt, auf den Sie deployen werden. Die Pfade, der Paketmanager, die Signale, die Art, wie ein Prozess einen CPU-Kern bindet: identisch in jedem Schritt. Wenn ein Bug nur in Produktion reproduzierbar ist, liegt es selten an "Produktion hat ein anderes OS"; es ist etwas Spezifisches, und wir finden es schneller, weil das OS selbst nicht Teil des Rätsels ist.
Warum das nachts um zwei zählt
Produktions-Vorfälle tauchen gern zu den schlechtesten Uhrzeiten auf. Der Engineer, der am Freitag um zwei Uhr nachts ans Telefon geht, hat keine Zeit, in dieser Nacht das OS zu lernen. Er nutzt es, auf seinem Laptop, auf dieselbe Art, wie er es auf dem Rack nutzen wird. Dieselben Diagnose-Werkzeuge, dieselben Logging-Konventionen, dasselbe Shell-Muscle-Memory. Linux-Vertrautheit ist Teil der Incident-Response-Ausrüstung, nicht etwas, das man im Moment der Not aufschnappt.
Es passt zum Rest
Linux ist das Substrat unter jeder anderen Überzeugung, die wir haben. Docker ergibt nur Sinn, weil Linux uns Namespaces und cgroups gegeben hat. Open Source als Standard funktioniert nur, weil Linux selbst Open Source IST. Unser WebSocket-Runtime wählt dieselben Event-Loop-Primitiven, die der Kernel anbietet. Jede dieser Entscheidungen ist günstiger, zuverlässiger und besser debuggbar, weil das darunter liegende OS dieselbe langweilige, allgegenwärtige Sache ist.
Welche Distribution, und warum das egal ist
Intern mischen wir Fedora, Ubuntu, NixOS und Raspbian je nach Aufgabe, und unsere Produktions-Hosts sind meist das, was das Team des Kunden problemlos warten kann. Es geht nicht um die Distribution. Es geht darum, dass "Linux" die Familie ist, in der wir leben, so wie eine Tischlerei in "Holz" lebt, ohne eine Religion daraus zu machen, welche Eiche sie diesen Monat gekauft hat. Wählen Sie, was für Sie passt; wir liefern darin.
Was das für Ihr Projekt heißt
Ein Linux-natives Team wählt beim ersten Mal die richtigen Werkzeuge. Cron, systemd, iptables, ssh, fail2ban, journalctl, die Standard-libc, das Standard-Prozessmodell: das sind für uns keine Spezialfertigkeiten, das ist, wie wir ohnehin arbeiten. Ihr Projekt zahlt keine "OS-Einarbeitungs-Steuer". Sie vermeiden auch die leisen, aber realen Kosten eines Stacks, der auf macOS aufgewachsen ist und von Case-Sensitivität überrascht wird, an Symlinks scheitert, oder vergisst, dass es in Produktion kein Homebrew gibt.
Die kleinste Lücke zwischen Dev und Prod ist die Lücke, die die meisten Bugs schließt. Wir haben das OS vor zehn Jahren aus dieser Lücke entfernt.
Weitere Perspektiven
Neugierig, wie das in der Praxis aussieht?
Diese Essays sind das Warum. Das Wie zeigt sich in den Projekten, die wir ausliefern. Schreiben Sie uns, dann sprechen wir über Ihren konkreten Fall.