My War on Kubernetes
Find the English version below
Hi ,
Ich muss direkt ein Geständnis machen: Ich bin auf Kriegsfuß mit Kubernetes.
Dabei trifft Kubernetes gar keine Schuld. Meine Projekte sind es. Beziehungsweise die Teams, in denen ich mich bewege.
Es sind Teams mit maximal 30 Software-Entwicklern, noch ein paar Business-Menschen und Designer oben drauf. Aber es sind nicht soooo viele Entwickler.
Diese Teams brauchen kein Kubernetes!
Nein. Noch deutlicher: Diese Teams können kein Kubernetes halten!
"Aber Marcus. Das ist doch kein Problem. Ich habe das doch schon bei XY gemacht, und es war so einfach, wenn man sich an YX hält und das ZY-Prinzip einhält."
Ja. Ich meine auch nicht den technischen Aspekt. Du brauchst nur ein paar relativ clevere und motivierte SRE/Admins/DevOps, und dann wird der technische Teil von Kubernetes wenig Probleme machen. Oder zumindest nicht mehr als die klassische Administration.
Doch das eigentliche Problem mit Kubernetes ist der sprunghafte Anstieg der Gesamtkomplexität.
Plötzlich MUSST du gitOps praktizieren. Plötzlich MUSST du blue/green Deployment machen. Plötzlich MUSST du die Abstraktion BareMetal->VM->Node->Pod->Container->JVM verstehen. Plötzlich MUSS deine Applikation stateless sein.
Du betreibst kein Kubernetes mit einer einzelnen Komponente. Du hast auf einen Schlag haufenweise Komponenten in deinem System. Und jede ist ein mögliches Bottleneck. Jede Komponente in deinem System ist ein Single Point of Failure.
Natürlich weißt du das. Du bist ja von Kubernetes überzeugt. Also muss alles redundant betrieben werden. Also noch mehr Komponenten im System. Wie mache ich eigentlich eine Datenmigration mit redundanten Systemen? Die Frage muss ich mir auf einmal stellen.
All das sind natürlich lösbare Probleme. Ich habe sie schon oft gelöst. Es gibt haufenweise Literatur dazu.
Aber brauchst du das wirklich? In den Teams von 30 Software-Entwicklern oder weniger brauchst du das nicht. Behaupte ich.
Wenn du "nur" 30 Entwickler beschäftigst, dann hast du einfach noch keinen so großen Use-Case, der ein Kubernetes mit all seiner Komplexität rechtfertigt. Du hast ganz andere Sorgen. Du musst dein Produkt an den Start bringen. Du musst es am Markt groß machen. Du hast konkrete Feature-Wünsche, die umgesetzt werden müssen.
Dir geht es noch nicht darum, ein System zu bauen, an dem hunderte von Entwicklern arbeiten können. Dir geht es noch nicht darum, ein System zu bauen, das vollständig ohne Downtime auskommt. Du brauchst noch kein System, das mit Teilausfällen klar kommt.
Dein größtes Problem ist, den Bedarf deiner Kunden zu decken. Darauf musst du dich konzentrieren. Darauf musst du all deine Ressourcen investieren. Kubernetes ist diese Investition noch nicht wert.
Rule the Backend,
~ Marcus
Hi ,
I need to make a confession right off the bat: I'm at odds with Kubernetes.
It's not Kubernetes's fault, though. It's my projects. Or rather, the teams I'm part of.
These are teams with a maximum of 30 software developers, plus a few business people and designers on top. But there aren't that many developers.
These teams don't need Kubernetes!
No. To put it more bluntly: These teams can't handle Kubernetes!
"But Marcus. That's not a problem. I've already done this with XY, and it was so easy if you stick to YX and adhere to the ZY principle."
Yes. I'm not talking about the technical aspect. You just need a few relatively smart and motivated SREs/Admins/DevOps, and then the technical part of Kubernetes won't cause much trouble. Or at least no more than classic administration.
But the real problem with Kubernetes is the sudden increase in overall complexity.
Suddenly you MUST practice gitOps. Suddenly you MUST do blue/green deployment. Suddenly you MUST understand the abstraction BareMetal->VM->Node->Pod->Container->JVM. Suddenly your application MUST be stateless.
You're not running Kubernetes with a single component. All of a sudden, you have a ton of components in your system. And each one is a potential bottleneck. Every component in your system is a single point of failure.
Of course, you know this. You're convinced by Kubernetes. So everything has to be operated redundantly. So even more components in the system. How do I actually perform a data migration with redundant systems? Suddenly I have to ask myself that question.
All these are solvable problems, of course. I've solved them many times. There's plenty of literature on the subject.
But do you really need it? In teams of 30 software developers or fewer, you don't need it. That's what I claim.
If you "only" employ 30 developers, you simply don't have a big enough use case that justifies a Kubernetes with all its complexity. You have other worries. You need to launch your product. You need to make it big in the market. You have specific feature requests that need to be implemented.
You're not yet concerned with building a system that hundreds of developers can work on. You're not yet concerned with building a system that can operate completely without downtime. You don't yet need a system that can handle partial failures.
Your biggest problem is meeting your customers' needs. That's what you need to focus on. That's where you need to invest all your resources. Kubernetes isn't worth that investment yet.
Rule the Backend,
~ Marcus