Ya know what's great about debating tools? Because we have a separation, different things can innovate at different rates and people can do different things.
You can move from deploying to AWS to Kubernetes all while your CI pipeline and config management stay the same. Maybe at another time you change your CI system.
In all of this we can even have tool fights. Jenkins vs CircleCI. vim vs emacs. And new players can come along like vscode.
Different departments in the same companies, sometimes billion dollar companies, can even do this.
This is one of the reasons I personally like a separation of concerns with projects.
There is one thing about Helm...
> But to keep everyone using the upstream Helm chart, wouldn't all Helm charts eventually have to look the same, and just be a templated version of the entire Kubernetes API with all CRDs included?
I don't think so. Without being long winded, this is about user experience and encapsulations. Kubernetes is hard to learn. Then do learn the business logic for installing all the things you use. To use the old wordpress example, should someone installing wordpress into a cluster need to know the business needs of MySQL to create the k8s config for it? Most app devs don't want to learn all the k8s object configs... it's a lot to learn.
As for CRDs, that's about dependency management.
But, if we make Kubernetes really hard, with lots of CRDs we have to start to deal with what CRDs are in what clusters? And, what experience does that provide for end users? How do we not make the UX barrier to entry to high for the people who need to use it?
Are users interested in Kubernetes or are they interested in their apps and core business logic?
from Hacker News - New Comments: "WordPress" http://bit.ly/2SkRSxu
via IFTTT
No comments:
Post a Comment