01
Schritt 1: Den eigenen Bestand messen
Die meisten Diskussionen drehen sich um gefühlte Größen. Diese vier Zahlen beenden sie in zehn Minuten.
docker compose config --services | wc -l # Anzahl Dienste
docker compose ps
docker stats --no-stream # tatsächlicher Bedarf statt Schätzung
# Wie viele Menschen liefern aus, und wie oft?
git shortlog -sn --since='12 months ago'
git tag --sort=-creatordate | head -20Vier Werte entscheiden: Anzahl der Dienste, Anzahl der Menschen, die pro Monat ausliefern, das Verhältnis von Spitzenlast zu Grundlast und die Zahl der Umgebungen. Alles darunter ist Geschmacksfrage und kein Architekturargument.
Wann welche Betriebsform trägt
| Situation | Trägt | Kippt, sobald |
|---|---|---|
| 1 bis 5 Dienste, ein Team, gleichmäßige Last | Docker Compose auf zwei Servern | Der Ausfall eines Servers nicht mehr hinnehmbar ist |
| 5 bis 15 Dienste, ein Team, schwankende Last | Amazon ECS mit Fargate oder Azure Container Apps | Eigene Operatoren, eigene Ressourcentypen oder ein Service-Mesh nötig werden |
| Mehrere Teams mit eigenen Releasezyklen | Kubernetes als verwalteter Dienst, also EKS oder AKS | Niemand die Upgrades verantwortet |
| Regulierte Last im eigenen Rechenzentrum | Kubernetes im Eigenbetrieb | Das Team keine Rufbereitschaft stellen kann |
Bevor du weiterrechnest, gehört die zweite Frage gleich mit auf den Tisch: Ein Cluster als verwalteter Dienst und ein selbst betriebener Cluster sind zwei völlig verschiedene Projekte, mit unterschiedlichem Aufwand, unterschiedlicher Haftung und unterschiedlichen Kosten. Die Abwägung steht unter Managed Kubernetes oder selbst betreiben.
