True, but I'm not talking about simple users. I'm talking about companies extending Kubernetes or building adjacent software. Even if their service doesn't necessarily integrate with Kubernetes, there is frequently a temptation to "follow your heroes".
Look at the whole Cloud Native Foundation thing, I think most of their projects are developed using Go.
So if you're using that stack, it's easy to assume that all new development everywhere is in Go.
It will probably balance out once the newness wears off Go (I think this is already happening).
This is true in general. Kubernetes was ported from Java to Go, though I have no idea how large it was when it happened... that said I agree with you, and it's more likely that a new tool would appear than any of these deciding to suddenly re-write the universe.
Kubernetes is always brought up when discussing Go. I wonder if Go might ultimately be its Achilles' heel? If so, I wonder how that might manifest itself?
In my experience, the end result is having a team of kubernetes fanatics reinventing the wheels themselves and forcing everyone to use their custom ego filling tools instead of paying $100 per month to an already existing solution.
Most developers just need something like heroku, tsuru, appengine, or openstack. But because kubefans want to have fun too and try to be as cool as Google or Facebook we end up having to deal with tons of custom Golang tooling with fancy names, half assed documentation and grumpy looks when you ask for help because you don't understand the 38 steps guide to deploy a service.
being written in go does not imply anything about ease of deployment. kubernetes is written in go.
in fact, the type of project that sees something that works exceptionally well (like ES) and then decides to partially reimplement it (to the point of maintaining API compatibility) is a pretty big red flag that it is NOT going to be easier to use in the long run.
I've heard this argument before, and I point out Kubernetes to them. Is that code base complex enough, because it's pure Go doing just fine and runs on plenty of systems?
Part of the issues with Kubernetes is that it started as a Java project and then it became a Go project. If anyone started a large Go project with that mindset it would look messy no matter what you did.
Maybe a 100 devs Go is fine, but it gets to be a nightmare as you scale beyond that.
Language abstractions exist to prevent having developers build their own ad-hoc abstractions, and you find this time and time again in languages like Go. You can read the Kubernetes code and see what I mean, they go out of their way to work around some of the missing language features.
As a developer, I love the idea of operating, maintaning, deploying and monitoring the services I work on, as long as I'm using s proven platform such as appengine, tsuru, openstack, heroku, etc.
I don't want to waste my life understanding your custom reinvented wheel Golang tooling around kubernetes and 50 steps guides to do anything.
Kubernetes is infamous for being one of the worst examples of a Go codebase in the community. And that proves my point really, this codebase sticks out like a sore thumb because it's no idiomatic Go.
70% of cloud tools on CNF are built with Go; Kubernetes is just one of many.
Also, since Kubernetes was originally started as a Java project you should consider whether the team was trying to code more with Java idioms than with Go ones.
I've worked with Kubernetes extensively since it became popular.
Of the maybe hundred of companies I've worked with trying to onboard to Kubernetes, I don't think a single one really had a use case that justified the increased complexity.
Kubernetes seems so great until you're suddenly drowning in YAML, un-upgraded clusters out of their support window, the need for an unbelievable amount of extra tooling (e.g. ArgoCD, Helm, CSI plugins, Operators), etc.
Plenty of places made it work by paying for huge teams to manage it, but deploying software on regular old Linux servers is fine for most people with just a small amount of discipline.
As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node footprints.
However I think the rule of enterprise software is that it’s increasingly fragmented and diverse - that’s partially why Kubernetes and containers were so attractive because it allows operations to unify footprint on prem and have a path to cloud.
Nobody in an enterprise ever stopped using a piece of technology. It lives on forever (and public cloud just gives it new places to live).
Whether Kubernetes is important for you, and whether Go matters as a language for implementing it is very much the question. Kubernetes was started in Java, and Kubernetes developers themselves describe it as incoherent mess of dozens of daemon programs in various stages of completion in the process of refactoring Java idioms into Go while introducing redundancies due to Go's limited code organization facilities.
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.
Still, part of the industry is moving towards simple solutions.
A refreshing experience was a mobile app Apple device, with Swift and Swift UI. It was a real joy, works as expected, produces concise code, small files, live preview and reasonably fast build time. Sure, it's closed environment, but last time I felt so productive doing UI dates back to Visual Basic.
Counter-example: a simple web app, nothing fancy, and my node_modules filled with around 500MB of files, hundreds of declarations of injected things everywhere.
But nobody forces us to use Kubernetes, nobody forces us to climb the Rust learning curve, nobody forces us to use this multi-platform framework that solves all the problems of the universe.
I try to stick to standard solutions, oft proposed by the vendor: Kotlin on Android, Swift on Apple, c# on Windows. Server code: stick to Java, or try the simple Golang (another refreshing language).
Also, I try to stay late to adopt tech, just starting to be confident in Docker and will see in a few years if Kubernetes could be useful.
But, an architect needs complex solutions to justify its job, a team lead needs as many dev as possible to tell at the next family dinner, and the new dev wants to try this new fancy tech to put on his resume. So they are all fine with that. Just don't tell the company ownership.
It’s kinda like all those “we rewrote our Ruby app in Go and it’s 1000x faster so Go is awesome” articles. Containerisation is good for those things, but it’s still possible that Kubernetes is an excessively complex solution to the problem!
Look at the whole Cloud Native Foundation thing, I think most of their projects are developed using Go.
So if you're using that stack, it's easy to assume that all new development everywhere is in Go.
It will probably balance out once the newness wears off Go (I think this is already happening).
reply