antoniaklja

Today, average businesses spend months of engineering time dealing with day-one activities like installation, patching, and lifecycle management of the core services such as CI/CD tooling.

A typical development team spends 30% of their time on managing software delivery services with a lot of ad-hoc human intervention activities involved.

So, engineering time costs a lot of money and I'd say regardless of company size this is worth it. Especially, during the time of talent pool shortcomings you want to spend engineering effort more wisely.

Thanks for the comment! Interesting questions :)

> If going the Jenkins route, why run it in Kubernetes when there are battle tested alternatives?

With full interoperability with Kubernetes, we can take an advantage of built-in capabilities like declarative configuration, autoscaling, auth, etc. The old static VM-based approach, might be not effective cause you need to build everything around that VM - provisioning scripts, maintenance, autoscaling, security, etc. A lot of manual work and effort at the end of the day :)

> If going the Kubernetes route, why not use a Kubernetes native CI system?

There are no Kubernetes native CI systems, Kubernetes itself doesn't provide CI/CD capabilities. It's just another software with interoperability in this environment :)

Moreover, I'd say the effort related to migration two the new "battle tested" CI/CD system might be significant. Especially, in a large, complex deployment strategies.

For people already familiar with Jenkins ways of working and willing to explore k8s ecosystem, this might be good starting point.