Wo ist hier der Betrieb?

Ich kann mich noch an eine Zeit in der Enterprise IT erinnern, gar nicht so lange her, wo die Rollen Entwicklung und Betrieb klar getrennt waren. Als Entwickler musste man sich über betriebliche Themen nicht viel Gedanken machen.

DevOps, GitOps, Infrastructure as Code

Dann wurde in der Arbeit auf DevOps umgestellt und schließlich setzte ein engagierter Betriebskollege ein modernes System mit GitOps, ArgoCD, Vault usw. auf; die einfache und geniale Idee - Infrastructure as Code.

Über die Einrichtung einer Web Application Firewall (WAF) und diverse andere betriebliche Themen musste ich mir aber nach wie vor keine Gedanken machen. Dass es so etwas wie eine WAF überhaupt gibt, weiß ich erst seitdem derselbe engagierte Betriebskollege einen Vortrag darüber gehalten hat.

Aber zumindest Kubernetes Manifest Files, ArgoCD, Vault Secrets, Graylog, Dynatrace, usw. waren keine leeren Worte mehr, sondern sehr praktische Dinge.

Eigene Web Projekte - Wo ist hier der Betrieb?

Als ich begann, mehr Zeit in eigene Web Projekte zu investieren, stellte ich fest, das diese irgendwann irgendwo laufen sollten. Was für eine Erkenntnis! Ich war es immer noch gewohnt, nur inhaltlich und entwicklungsmäßig über die Dinge nachzudenken.

Betriebliche Sicherheit, Ausfallsicherheit, Skalierung, Monitoring, Netzwerkthemen, betriebliche Updates usw. (ich weiß peinlicherweise nicht einmal jetzt alle wichtigen Begriffe) – um diese Dinge hatten sich immer andere gekümmert.

Mein erster Reflex – die Suche nach einem Betrieb.

Firebase

Firebase war naheliegend, einfach einzurichten, perfekt! Ich blieb vorerst im kostenfreien Spark Plan. Irgendwann werde ich schon auf den Blaze Plan umsteigen, dachte ich.

Aber ich stieg nicht um und als ich mich selber ehrlich befragte, musste ich mir eingestehen, dass ich mittelfristig nicht umsteigen würde. Warum? Weil meine Bedenken bezüglich des Pay as you go Modells zu groß waren.

Was ist, wenn ein Script ständig auf meine Web Applikation zugreift? Bin ich dann eine arme Kirchenmaus, wenn ich das nächste Mal auf mein Konto schaue? Vielleicht Paranoid, aber es war mir einfach zu heiß.

In der Arbeit habe ich gesehen, wie verletzlich eine Web Applikation ist. Die APIs, auf die die Seite zugreift, sind in den Browser DevTools einsehbar. Und findige User brauchen nur ein Script schreiben und auf diese APIs zugreifen. Bei der Web Applikation, die wir in der Arbeit entwickelt haben, wurde das ständig gemacht und führte immer wieder zu Problemen.

Auch hatte ich den Eindruck – wenn man sich früher mit Betriebsthemen auskennen musste, dann muss man sich heutzutage mit der Produktpalette und dem Preismodell des gewählten SaaS Providers auskennen.

Sliplane

Ich begab mich also auf die Suche nach Alternativen; wenn möglich mit einem fixen Preismodell. Und nachdem ich Sliplane ausprobiert hatte, entschloss ich mich, meine Web Projekte dort zu hosten.

Das Deployment über Dockerfile finde ich super! Alles was Build und/oder Deployment betrifft, schön in einer Datei zusammengefasst. Beim Erstellen der Dockerfiles ist Junie eine große Hilfe gewesen. Ich bin später auf den Artikel LLMs are the End of Serverless gestoßen und denke da könnte etwas dran sein.

Die Web Oberfläche für diverse Einstellungen und Informationen ist sehr abgespeckt aber ausreichend. Das finde ich auch super. Wenn die Konfiguration eines Systems über eine komplexe UI Oberfläche erfolgt, macht mich das immer etwas skeptisch. Ich mag es viel, viel mehr, wenn die Konfiguration über Text passiert, den man versionssichern kann – “Infrastructure as Code”-mäßig eben.

Und wenn sich im Repo meiner Web Applikation etwas ändert, wird automatisch ein neues Deployment gestartet, einfacher geht’s nicht!

Was mir zusätzlich taugt, ist die Möglichkeit PostgreSQL, MongoDB und weitere Datenbanken als Service zu nutzen. Und es gibt auch Services für “KI-Dinge”, wie zum Beispiel Ollama. Das könnte für mich ein Einstieg sein, um KI-Integration wirklich praktisch auszuprobieren und damit Erfahrung zu sammeln.

Self Host

Und mit Docker und dem Informationsangebot zu betrieblichen Dingen auf der Sliplane Seite geht es genau in die Richtung in die ich mich mittelfristig entwickeln will, nämlich das Wissen und die Erfahrung aufzubauen, um bald in der Lage zu sein, selber zu hosten.