Minimum Viable App
Web-App Boilerplate für Kubernetes
Moderne Client-Server-Software wird in der Regel als Service bereitgestellt: als selbst-gehostete Web-App oder Software-as-a-Service in der Cloud, die über den Browser oder dedizierte Client-Anwendungen konsumiert wird. Die Minimum Viable App beschreibt eine Web-App die für den Betrieb in Kubernetes optimiert ist und soll dabei helfen, die nach wie vor klaffende Lücke zwischen Entwicklung und Betrieb von Software zu schließen indem sie moderne Best-Practices in ein überprüfbares Framework gießt, an dem die Entwicklung einer Web-App ausgerichtet werden kann.
Die Minimum Viable App zeichnet sich aus durch:
- Deklarative App-Konfiguration, um den Zeit- und Kostenaufwand für Entwickler und Betreiber zu minimieren
- Saubere Schnittstellen mit der zugrundeliegenden Engine und Infrastruktur, um maximale Portabilität zwischen Ausführungsumgebungen zu gewährleisten
- Kongruentes Verhalten in Entwicklungs- und Produktions-Umgebungen
- Unterstützung kontinuierlicher Deployments für maximale Agilität und Zero Downtime
- Skalierbarkeit ohne wesentliche Änderungen an Tools, Architektur oder Entwicklungspraktiken
- Instrumentalisierbarkeit in Form von Metriken, Logs und Traces
- Integration von modernen Authentifizierungs- und Authorisierungs-Protokollen (SSO)
Eine Minimum Viable App kann in jeder beliebigen Programmiersprache geschrieben werden und eine beliebige Kombination von Dependencies (Datenbank, Message-Queue, KV-Storre, etc.) verwenden. Sie dient dem reibungslosen Zusammenspiel von Entwicklung und Betrieb - gemeinhin DevOps genannt.
Was ist eigentlich eine "App"?
Eine "App", oder Anwendung, ist ein Konglomerat an Software, in der Regel bestehend aus einer selbst entwickelten Software (unserer Minimum Viable App) und ihren Abhänigkeiten wie Datenbanken, KV-Stores oder Object-Storage.
Der Begriff "App" ist leider maßlos überlagert, weil er alles bezeichnet was Software ist und irgendwie ausführbar oder nutzbar gemacht wird. Unsere App in Kubernetes ist also in der Regel eine "App of Apps". Wir unterscheiden hierbei zwischen unserer Custom App - also dem Code den wir selbst schreiben und als Anwendung benutzbar machen wollen - und etwaigen Dependency-Apps.
Im Kontext der Minimum Viable App konzentrieren wir uns auf die Custom App und betrachten dabei Entwicklungs-Prozesse, Laufzeitumgebung und den Betrieb der Software.
Für unser Verständnis einer "App" ist es irrelevant, ob die Anwendung ein Monolith oder ein Konstrukt aus Microservices ist oder in welcher Programmiersprache die Software geschrieben wurde. Die Minimum Viable App beschäftigt sich mit der kleinsten atomaren Einheit, nämlich einem einzelnen Prozess in einem Container. Ein Monolith ist folglich eine einzelne Custom App während eine Microservice-Architektur ein Konglomerat an Custom Apps darstellt, die untereinander einen Abhängikeitsgraphen bilden. Das Prinzip der Minimum Viable App ist hierbei auf jeden einzelnen Microservice anwendbar.
Eine App könnte also eine Golang-Binary sein, die auf externe Datenbanken zugreift - aber auch PHP- oder Python-Code, der von einem Supervisor wie Nginx oder GUnicorn ausgeführt und dadurch erreichbar gemacht wird.
Die Minimum Viable App (kurz MVA) klärt die Frage, wie man eine isolierte, selbstständig lauffähige Anwendung für den Betrieb in Kubernetes bereitstellt. Sie ist das fehlende Puzzle-Teile an der Schnittstelle zwischen Dev und Ops - ein klarer Vertrag zwischen Entwicklung und Betrieb hinsichtlich der Laufzeitumgebung und der nötigen Anforderungen an die Beschaffenheit und Funktionalität der Software, um einen reibungslosen und für alle Parteien bedienbaren Betrieb der Software zu gewährleisten.
Entwicklung
Kann in jeder Programmiersprache implementiert werden
Wird in einer gemeinsamen Code-Base verwaltet
Deklariert interne Abhängigkeiten (Libraries, etc) versionsgenau
(nicht mit “latest”)
Wird automatisch versioniert
(Semantic Versioning, Conventional Commits)
Implementiert automatisierte Build- und Release-Prozesse
(Pipelines)
Distribution
Wird in Form von Containern ausgeliefert
Schnittstellen
Exportiert ihre APIs via Netzwerk
Laufzeitumgebung
Funktioniert unabhängig von der URL/Hostname
(d.h. benötigt nicht immer den gleichen Hostnamen um zu funktionieren)
Funktioniert ohne TLS
Ist durch Environment Variablen konfigurierbar
(Liste von Client Libraries)
Kann in mehrere Environments deployt werden
Nutzt keine lokalen Volumes
(S3, KV, etc)
Ist für gängige Industrie-Standards paketiert
(Docker, Helm)
Nutzt keine provider-spezifischen Dienste sondern generische externe Abhängigkeiten
(Postgres vs RDS)
Spricht mit externen Abhängigkeiten nur über Netzwerk
(kein lokal installierter Sendmail)
Deklariert externe Abhängigkeiten versionsgenau
(nicht mit “latest”)
Sicherheit
Nutzt moderne Verschlüsselungs-Methodiken
(z.B. kein htpasswd für Hashes)
Integriert mit externen IDPs
(keine eigene User-Verwaltung, keine SSO-Tax)
(BONUS) Stellt Audit-Logs zur Verfügung
(BONUS) Ist mit externen Secret-Management Systemen integrierbar
Betrieb
Wird automatisch deployt
(kein manuelles Eingreifen nötig, Continuous Deployment)
Kann horizontal skaliert werden
Hat eine vollständige Betriebs-Dokumentation
Kümmert sich um Datenbank-Migrationen zur Runtime
(Init-Container)
Hat kurze Startup Zeiten für Prozesse
Kann vollständig zur Runtime konfiguriert werden
(niemals zur Build-Zeit)
Schreibt Logs nach STDOUT
(NICHT in ein File)
Loglevels per Config umschaltbar
(Best-Practice: Info -> Debug)
(BONUS) Strukturierte Logs (JSON) per Config umschaltbar
(BONUS) Ist mit OpenTelemetry instrumentalisierbar
(Tracing)
(BONUS) Bringt Dashboards für Grafana mit
Exportiert Prometheus-Metriken unter /metrics
(Client-Libraries)
Implementiert Healthcheck-Endpoints für Startup, Liveness und Readiness
Implementiert Error-Handling
(Exception-Logging, ggf. sowas wie Sentry, Stacktraces vermeiden)
Delegiert HTTP-/Proxy-Management an Environment
(Ingress, kein nginx-Voodoo im Container)
Delegiert TLS-Management an Environment
(cert-manager)
Delegiert DNS-Management an Environment
(external-dns/Admin)
