4 ms·
But the value isn't equal. If you think of the business value implemented in code as the "picture" and the run time environment provided as the "frame" the fram
by lanstin 5y ago
But the value isn't equal. If you think of the business value implemented in code as the "picture" and the run time environment provided as the "frame" the frame has gotten much larger and the picture much smaller, as far as what people are spending their time on. (Well, not the golang folks that just push out a systemctl script and a static binary, but the k8s devops experts). I have read entire blogs on k8s and so on where the end result is just "hello world." In the old days, that was the end of the first paragraph. Now a lot of YAML and docker files and so on and so on are needed just to get to that hello world. Unix was successful initially because it was a good portable abstraction to managing hardware resources, compute, storage, memory, and network, over a variety of actual physical implementations. Many many of the problems people are addressing in k8s and running "a variety of containers efficiently on a set of hosts" are similar to problems unix solved in the 80s. I'm not really saying we should go back, Docker is certainly a solution to "depdendency control and process isolation" when you can't have a good static binary that runs a number of identical processes on a host, but the knowledge of what a socket is or how schedulers work is valuable in fixing issues in docker-based systems. (I'm actually more experienced in Mesos/docker rather than k8s/docker but the bugs are from containers spawning too many GC threads or whatever).
If someone is trying to debug that LB and doesn't know what a socket is, or debug latency in apps in the cluster and not know how scheduling and perf engineering tools work, then it's going to be hard for them, and extremely likely that they will just jam 90% solution around 90% solution, enlarging the frame to do more and more, instead of actually fixing things, even if their specific problem was easy to fix and would have had a big pay off.
- coryrc 5y agoKubernetes is complicated because it carries around Unix with it and then duplicates half the things and bolts some new ones on. Erlang is[0] what you can get when you try to design a coherent solution to the problem from a usability and first-principles sort of idea. But some combination of Worse is Better, Path Dependence, and randomness (hg vs git) has led us here. [0] As far as what I've read about its design philosophy.
- EdwardDiego 5y agoWho is using K8s for Hello World levels of complexity? Complex problems often have complex solutions, the algorithm we need to run as developers is - what's the net complexity cost of my system if I use this tool? If the tool isn't removing more complexity than it's adding, you probably shouldn't use it.