Ask HN: Kubernetes Worth It?
To paraphrase Phil Greenspan’s famous LISP quote: “Does any sufficiently complicated micro service architecture contain an ad hoc, informally specified, bug ridden, slow implementation of half of kubernetes?” Thought that might be an interesting way of saying is it worth bitting the bullet and spending the effort to understand and use kubernetes.
6 comments
It’s wonderful software but it is expensive as hell to hire people for. You may be better off hiring junior and sending them for CKA/CKAD certifications.
The OP was asking if it's worth spending the time and effort to understand and use Kubernetes, nothing about hiring for it. In other words, from the programmer/sysops side, it's very much worth learning. Learn Go while you're at it, if you don't already know it. Nearly everything in the k8s ecosystem is written in Go, and there are lots of conventions in the space that make more sense if you know Go conventions.
Any benefits of learning Golang?
Anyone that can wrap their mind around the model of Communicating Sequential Processes[1] implemented using channels in Go will improve their programming. See also Concurrency is not Parallelism by Rob Pike: https://www.youtube.com/watch?v=oV9rvDllKEg
After I figured it out, I spent a good month writing personal projects to play with channels and concurrency and get the "these are cool I'm going to use them everywhere" urge out of my system.
1 http://www.usingcsp.com/
After I figured it out, I spent a good month writing personal projects to play with channels and concurrency and get the "these are cool I'm going to use them everywhere" urge out of my system.
1 http://www.usingcsp.com/
Interfaces and the Go way of using them is arguably more important than CSP, as the former can apply to all code while the latter is only needed for concurrent code. The Go talks have many great gems, GopherCon talks too
Interfaces are great, and easier to understand than Go's concurrency. Maybe the hardest part is getting the idea that neither interface nor implementing code need to know anything about the other.
Here's a fun experiment: dig through your codebase and find all the public methods, then look at the signatures and find the top 3-5 most common constructs. Now define an interface using those. Perhaps not very useful, but interesting to see. I bet a comprehensive audit of Go code in the wild (not including the standard libraries) would find a lot of types implementing something like this this:
Here's a fun experiment: dig through your codebase and find all the public methods, then look at the signatures and find the top 3-5 most common constructs. Now define an interface using those. Perhaps not very useful, but interesting to see. I bet a comprehensive audit of Go code in the wild (not including the standard libraries) would find a lot of types implementing something like this this:
type StringHandler interface {
Handle(string)
Parse(string)
Count() int
}