Warum Managed Services nicht alles sind: Das Argument für manuelle Deployments

Manchmal lohnt es sich, einen Schritt zurückzutreten und sich zu fragen: Verstehe ich eigentlich, was da unter der Haube passiert?

Ich meine damit nicht, dass du ab morgen deinen eigenen Cloud-Anbieter bauen sollst. Sondern eher: Weißt du, warum deine Services erreichbar sind? Warum HTTPS funktioniert? Was passiert, wenn jemand deine Domain aufruft?

Die versteckten Kosten der Bequemlichkeit

Cloud-Plattformen sind fantastisch. Keine Frage. Du klickst ein paar Buttons, und schwupps – deine Anwendung läuft irgendwo auf der Welt, wird automatisch skaliert, hat SSL-Zertifikate und wasweißichnoch. Das ist großartig.

Aber irgendwann kommt der Moment, in dem genau diese Bequemlichkeit zum Problem wird. Wenn um drei Uhr nachts dein Managed Kubernetes-Cluster merkwürdige Fehler wirft. Wenn deine Rechnung sich verdoppelt und du keine Ahnung hast, wieso. Wenn du ein kleines Projekt auf alter Hardware betreiben willst, anstatt jeden Monat 50 Euro für Basis-Hosting zu zahlen – und dann feststellst, dass das gar nicht so einfach geht, wie gedacht.

Das ist kein Plädoyer gegen Cloud-Anbieter. Ganz im Gegenteil. Es geht darum, zu verstehen, was eigentlich passiert. Darum, nicht hilflos zu sein, wenn etwas schiefläuft.

Was du wirklich lernst, wenn du es selbst machst

Letztes Jahr habe ich ein Wochenende damit verbracht, einen kleinen Kubernetes-Cluster auf ein paar alten Laptops aufzusetzen. Nichts für Produktion – einfach ein Hobbyprojekt zum Lernen.

An diesem Wochenende habe ich mehr über Container-Netzwerke gelernt als in zwei Jahren Klickarbeit durch Managed Services.

Ich habe verstanden, warum DNS-Konfiguration wichtig ist, damit Services sich gegenseitig finden. Ich habe verstanden, wie SSL-Zertifikate wirklich funktionieren – nicht nur "HTTPS aktivieren", sondern der komplette Handshake, die Zertifikatskette, was passiert, wenn etwas abläuft. Ich habe verstanden, dass Load Balancer keine Magie sind – sie sind einfach Software, die Routing-Regeln umsetzt.

Und ich habe gelernt zu debuggen. In einer Managed-Umgebung schreibst du ein Ticket. In deiner eigenen Infrastruktur musst du das Problem lösen. Diese Fähigkeit wächst mit der Zeit. Beim nächsten Fehler hast du bereits Modelle im Kopf, mit denen du arbeiten kannst.

Die praktischen Vorteile, über die niemand redet

Viele Artikel über DevOps-Fähigkeiten drehen sich um Karriere oder "10x Engineer"-Status. Verständlich. Aber hier ist etwas Direkteres: Geld.

Eigene Infrastruktur ist nicht kostenlos, aber sie kann für bestimmte Anwendungsfälle deutlich günstiger sein. Ein Managed Kubernetes-Cluster für 200 Euro im Monat lässt sich oft ersetzen durch Hardware, die du schon hast, oder Dedicated Server für 40 bis 80 Euro. Für Startups, die ihre Runway im Auge behalten müssen, ist das nicht trivial.

Dann ist da noch die Kontrolle. Willst du eine Legacy-PHP-Anwendung betreiben, die dein Kunde nicht migrieren will? Experimentierst du mit ungewöhnlichen Netzwerkkonfigurationen? Brauchst du Datenhaltung in einer bestimmten Region aus Compliance-Gründen? Bei Managed-Plattformen bist du auf deren Angebot beschränkt. Bei eigener Infrastruktur entscheidest du.

Klein anfangen, ohne zu ertrinken

Ich weiß, was du denkst: "Klingt gut, aber ich habe keine Zeit, Sysadmin zu werden." Verstanden. Musst du auch nicht.

Fang klein an. Wirklich klein. Bevor du dich an Kubernetes wagst, stell sicher, dass du verstehst:

• Wie Domain-Namen aufgelöst werden (Hinweis: Es geht um DNS-Server, TTLs, und ja – dein Domain-Registrar ist wichtiger, als du denkst)
• Was passiert, wenn du einen Container startest
• Was ein Reverse Proxy macht und warum du einen willst
• Wie TLS-Zertifikate ausgestellt und erneuert werden

Das sind keine glamourösen Fähigkeiten. Aber sie sind grundlegend. Wenn du die Einzelteile verstehst, wirkt das Zusammensetzen viel weniger einschüchternd.

Deine Infrastruktur, deine Regeln

Das Schöne am Selbst-Deployment ist: Es geht nicht darum, moderne Tools abzulehnen. Kubernetes ist tatsächlich mächtig. Cloud-Plattformen bieten unglaubliche Bequemlichkeit. Es geht darum zu verstehen, was du benutzt – statt es als Black Box zu behandeln.

Ob du nun die gesamte Infrastruktur eines Startups auf selbstgebautem Kubernetes betreibst oder einfach verstehen willst, was deine CI/CD-Pipeline eigentlich tut, wenn sie "deployt" – dieses Wissen macht dich zu einem besseren Entwickler. Du schreibst besseren Code, weil du seinen Kontext verstehst. Du triffst bessere Architekturentscheidungen, weil du die trade-offs kennst. Und wenn etwas schiefläuft – passiert immer – kannst du es selbst beheben.

Entwickler, die den kompletten Stack verstehen, werden nicht verschwinden. Sie werden wertvoller, je mehr die Branche erkennt, dass Abstraktion nur eine bestimmte Strecke trägt.