Verwende Kubernetes noch nicht
(matt-rickard.com)Startups in der Early Stage sollten Kubernetes nicht vorschnell einführen.
In den meisten Fällen ist es noch zu früh.
Kleine Teams (1–10 Personen) sollten besser einen serverlosen Container-Service nutzen.
(AWS ECS - Fargate, GCP Google Cloud Run)
13 Kommentare
Ist k8s nicht inzwischen eher keine Frage von persönlicher Vorliebe mehr, sondern eine des Überlebens?
Ich denke, man muss heute vielleicht nicht unbedingt AWS kennen, aber k8s sollte man auf jeden Fall beherrschen.
Ich widerspreche dieser Meinung.
Ich denke, der einzige Nachteil von k8s ist die Lernkurve, genau das eine.
Selbst wenn ein Team nur aus etwa fünf Personen besteht, ist es anfangs zwar schwierig, aber sobald das Niveau im Umgang mit k8s ein gewisses Maß überschreitet, kann man absolut nicht mehr zurück. Die dadurch entstehende Produktivitätssteigerung ist gar nicht vergleichbar.
CI/CD, GitOps, Canary-Deployments und so weiter kann man auch ohne k8s umsetzen, aber sie zusammen auf k8s zu betreiben, ist leichter zu verstehen und einfacher zu verwalten.
Da ich den Migrationsprozess selbst erlebt habe, erinnert mich die Aussage, dafür sei es noch zu früh,
an die On-Premise-Zeit, als man die Einführung von AWS Cloud hinauszögerte, weil sie noch ungewohnt war.
„Konzentriert euch auf das Business“ – es geht mir nicht um solche grundsätzlichen Aussagen, sondern ich finde es schwer, Entscheidungen zuzustimmen, die zu einem Lock-in auf eine spezielle Technologie führen.
Wäre es ein Artikel gewesen, der dazu rät, PaaS wie beanstalk/app engine/heroku aktiv zu nutzen, hätte ich voll zugestimmt. Aber die Vorteile, die kleine Teams heute durch die Wahl von ECS/cloud run/docker swarm gewinnen, sind inzwischen so gut wie nicht mehr vorhanden. Vor 4–5 Jahren wäre das vielleicht noch etwas anderes gewesen.
Aus Kostensicht ist Serverless klar im Vorteil.
Dem stimme ich auch zu. In den meisten Fällen sind
docker-swarmoderdocker-composemehr als ausreichend.Das ist auch eine Meinung, die in den Hacker-News-Kommentaren sehr oft zu lesen war..... [1]
Ich bin etwas irritiert, weil der Artikel stillschweigend von der Prämisse ausgeht: „Kubernetes ist schwierig“.
Inzwischen hat sich das Kubernetes-Ökosystem stark weiterentwickelt, sodass es gar nicht mehr so schwierig ist – es sei denn, man installiert Kubernetes On-Premise direkt selbst.
Außerdem kann man bei der Kubernetes-Betriebsführung den Grad der Komplexität zu einem gewissen Teil selbst bestimmen; eine grundlegende Konfiguration aufzusetzen, ist nicht schwer. Wenn man später dies und das an Add-ons anhängt, wird es natürlich schwieriger.
Es gibt inzwischen auch viele Leute wie mich, die ihre erste Deployment-Umgebung direkt mit EKS kennengelernt haben.
Konkret gesagt verstehe ich nicht, warum das Aufsetzen eines grundlegenden k8s Deployment und Ingress (natürlich mit der DB als separatem Managed Service) unbedingt schwieriger sein soll als das direkte Einrichten von AWS ECS Fargate, wie es in dem dortigen Artikel beschrieben wird.
Schließlich muss man bei beiden gleichermaßen VPC, Cluster, CDN und Load Balancer konfigurieren ... und in den Kommentaren gibt es sogar viele Beiträge, die sagen, ECS sei eher unbequemer gewesen.
[1] https://news.ycombinator.com/item?id=31795160
Sehe ich genauso. Das grundlegende Setup ist meiner Meinung nach weder besonders schwierig, noch ist der Wartungsaufwand besonders hoch. Ob man in der Cloud ein komplexes Setup betreibt oder es in ein Kubernetes-YAML-Setup auslagert, kann ich ehrlich gesagt nicht sagen, was daran nun wirklich besser sein soll.
Unser Unternehmen stellt gerade von ECS auf EKS um, weil wir mit inzwischen mehr als 100 Entwicklerinnen und Entwicklern den Bedarf dafür gespürt haben, und manchmal bereuen wir es ein wenig.
Sie sagen zwar: „Bei der Kubernetes-Betreibung kann man den Grad der Komplexität bis zu einem gewissen Maß selbst bestimmen“, aber wenn man sich noch nicht gut auskennt, neigt man dazu zu denken, dass alles, worüber im Kubernetes-Ökosystem gesprochen wird, wohl nötig sei, und baut es dann auch alles ein.
Sie sagten, dass man in beiden Fällen eine Load-Balancer-Konfiguration braucht, aber ich finde, es gibt einen Unterschied zwischen „man muss nur ALB kennen“ und „man muss ALB plus Ingress kennen“.
So wie man in kleinem Maßstab keine MSA braucht, finde ich, dass Kubernetes mehr Dinge mit sich bringt, die man kennen muss, als man zunächst denkt, und dass es für eine Größenordnung, in der man sich auf die Anwendung konzentrieren sollte, durchaus Overkill ist.
Wenn allerdings jemand die Kubernetes-Umgebung bereits gut aufgebaut hat, hatte ich den Eindruck, dass die Bereitstellung von Anwendungen darauf weniger Lock-in-Effekte mit sich bringt, weil sie in einer cloudunabhängigen Ausdrucksweise definiert wird.
Wenn ich mir das so anhöre, scheint es diese Aspekte tatsächlich eindeutig zu geben. Ich glaube, ich habe vieles von dem, was ich bei der Nutzung von Kubernetes gelernt habe, als zu selbstverständlich angesehen.
Und ich stimme auch zu, dass es angesichts der vielen Add-ons, die derzeit für Kubernetes erscheinen, schwierig ist, bei der Auswahl die richtige Entscheidung zu treffen.
Da ich selbst keine Migration wie ECS -> EKS erlebt habe ... würde mich interessieren, ob es abgesehen von einem Lock-in-Effekt nach dem Umstieg Dinge gab, die sich spürbar verbessert haben.
Ach ja, nur zur Info: Meine Erfahrung basiert auf EKS. Das unterscheidet sich stark davon,
k8sOn-Premises direkt zu installieren undetcdsowie die Control Plane selbst zu betreiben, haha.Aus Sicht von jemandem, der mit
k8sangefangen hat, kam mir beim Lesen des Artikels eher der umgekehrte Gedanke: Muss man wirklich extra Zeit investieren, um ECS zu lernen ...?Jedenfalls denke ich, dass man es nicht unbedingt so offiziell festlegen muss, sondern zunächst einfach die Methode nutzen sollte, mit der sich das Team am wohlsten fühlt.
Ich stimme dem Ansatz zu, mit k8s zu starten.
Dem stimme ich sehr zu.
Nicht nur bei zehn Leuten, sondern auch bei Unternehmen einer einigermaßen überschaubaren Größe sehe ich die Einführung von k8s eher kritisch.
Sinnvoll ist das meiner Meinung nach erst, wenn der Vendor Lock-in bei einem Cloud-Anbieter ein wirklich kritisches Niveau erreicht oder wenn parallel auch On-Prem-Infrastruktur genutzt wird.
Ich hatte schon den Eindruck, dass man den Tech-Stack von Enterprise-Unternehmen manchmal träge einfach übernimmt.
Passend dazu ist gerade ein dazu schön aufbereiteter Beitrag auf Hacker News aufgetaucht, den ich hier teilen möchte.