Kohsuke Kawaguchi, creator of Jenkins, has finally openly admitted what was pretty obvious long time ago - rubbish quality of Jenkins.
And I know some of those problems, such as service instability
A Jenkins instance, especially a large one, requires too much overhead just to keep it running. It’s not unheard of that somebody restarts Jenkins every day.
They expect Jenkins to defend itself better from issues such as pipeline execution problems, run-away processes, over resource consumption so that they don’t have to constantly babysit the service.
Every restart implies degraded service for the software delivery teams where they have to wait longer for their builds to start or complete.
Every Jenkins admin must have been burnt at least once in the past by making changes that have caused unintended side effects.
the whole thing feels a bit like a Frankenstein
I’ve been saying this years!
Why then such low quality tool became so popular? With so many great alternatives?
I think that people fell into the trap of “free” and “open-source” tool. It’s Ok-ish on a small scale, but couple of years later when there’s a lot more jobs\plugins\pipelines crammed into the tool, it all starts falling like a domino.
People waste a lot of time to just maintain Jenkins in a working state, forget about adding more stuff. How do I know it? Because I’ve been there myself. Here comes the real cost of Jenkins - time wasted on support. Add to that unreliable builds that everyone start hating. And lack of progress further.
Even at this stage not many people realize that the problem is in choice of tool. They could have paid a small fee for commercial product of better quality, and save a lot of money by not wasting their time. No… they don’t realize that. Instead they hire a DevOps guy who knows Jenkins, to unload all this tedious work on them.
Hence you get lots of vacancies requiring Jenkins knowledge. Newbies see this and think - wow, Jenkins must be a great tool if so many companies use it! It’s a vicious cycle.
Kohsuke talks about 2 strategic directions:
- Cloud Native Jenkins - completely redesign Jenkins on Kubernetes \ microservices platform
- Jolt in Jenkins - continue current product but improve the process, shorter release cycles etc.
I think it’s yet another mistake. Why? Because:
- by spreading efforts on 2 directions they’ll deliver less then now, not more
- they shoot themselves in the foot by switching from Java platform, that exists everywhere, to Kubernetes, which is not and will not be adopted by all companies and use cases
- Jolt in Jenkins - no matter how much you try, if the core is designed badly, you can’t fix it with niceties like a few more plugins or BlueOcean front-end
Indeed it must be re-designed form scratch. And indeed they need to change their development process. And learn from 10 years of mistakes.
But … if they do - they will be just building a completely new product. Why even call it Jenkins?