How we built an automation platform for 600+ managed servers

Ich bin der CTO von Savvii, einem Managed-Hosting-Unternehmen mit Sitz in den Niederlanden. Wir sind auf PHP-basierte Websites spezialisiert — E-Commerce, WordPress und ähnliche Workloads — und bedienen drei Kundensegmente: kleinere Kunden, Reseller und Agenturen. Jedes Segment hat andere Anforderungen, eine andere Größenordnung und andere Erwartungen.

Im Agentursegment spürten wir den Druck am stärksten. Agenturen sind anspruchsvolle Kunden, aber ihre internen Teams bestehen oft aus einer Mischung aus technischen und nicht-technischen Personen. Sie brauchen eine grafische Oberfläche. Sie können nicht in der Befehlszeile leben. Und je mehr Agenturen wir an Bord holten, desto offensichtlicher wurde es: Wir brauchten ein richtiges Control Panel, gestützt auf echte Automatisierung.

Ansible Tower und ähnliche Tools hatten wir im Blick, aber sie waren entweder zu komplex einzurichten, hatten eine inkonsistente Dokumentation oder brachten Bedenken hinsichtlich Performance und Datensouveränität mit sich. Wir wollten etwas, das wir selbst hosten, ohne Drama aktualisieren und ohne eine Woche Schulung an unser Support-Team übergeben konnten.

Wir haben einen vollständigen Vergleich durchgeführt, bevor wir uns auf irgendetwas festgelegt haben. Zwei Faktoren engten das Feld schnell ein.

Datensouveränität. Kein Tool, das Status oder Anmeldedaten in einer Drittanbieter-Cloud speichert. Selbst-Hosting war nicht verhandelbar.

UX für Nicht-Techniker. Das First-Line-Support-Team besteht aus starken Kommunikatoren, nicht aus Systemadministratoren. Was auch immer wir wählen würden, musste navigierbar sein, ohne jeden Vorfall an DevOps zu eskalieren. Zu den von uns bewerteten Tools gehörten:

Semaphore UI gewann in beiden Punkten. Die Installation war unkompliziert. Upgrades waren schmerzlos. Die Oberfläche war übersichtlich genug, dass auch ein Nicht-Techniker verstehen konnte, was passierte. Das Einbinden unseres bestehenden Ansible-Inventars verlief nahezu reibungslos — der einzige Punkt, an dem wir Hilfe brauchten, war die Anbindung unseres Inventars, und das wurde mit dem Support schnell gelöst. Die Dokumentation von Semaphore war solide, und das gab uns Zuversicht.

Die anfängliche Architektur nutzte n8n als Orchestrierungsschicht zwischen HostBill (Abrechnung), Semaphore UI und der CMDB. Auf dem Papier sah es sauber aus — Low-Code, visuell, kein Entwickler nötig, um es zu pflegen.

Die visuelle Oberfläche von n8n ist großartig für einfache lineare Abläufe. Aber sobald Bedingungen, Fehlerbehandlung, mehrstufige Callbacks und Statusverwaltung ins Spiel kamen — verschwand der Überblick. Was als sauberes Diagramm begann, verwandelte sich in eine surrealistische Leiterplatte.

Wir haben n8n durch eine Laravel-Anwendung ersetzt. Es ist echte Middleware — kein No-Code-Tool, sondern etwas, das unser Team vollständig besitzt und versteht.

Das Agentursegment, mit dem wir begonnen haben, betreibt rund 600 Server über diese Architektur. Der Gesamtumfang über alle drei Segmente wird letztlich bei 3.000 bis 4.000 Servern liegen, und wir rollen die Plattform schrittweise aus.

Als Nächstes steht der Scheduler von Semaphore für Server-Updates an — derzeit mit externen Tools gehandhabt, aber im Begriff, auf Ansible umzustellen, wobei der Scheduler die Steuerung übernimmt.

Das Allerwichtigste, das wir anders machen würden: mehr Zeit in das Architekturdesign investieren, bevor wir auch nur eine einzige Zeile Automatisierung schreiben. Wir haben mehr als einmal von vorne begonnen, weil wir nicht sorgfältig genug darüber nachgedacht hatten, welche Abläufe skalieren und welche Fehler elegant behandeln würden.