Coming from marketing automation, I get the appeal of a managed cloud service. But I keep seeing Jenkins mentioned in dev conversations, even for new projects.
If it's so old and clunky, why is it still the default for so many teams? Is it just about cost, or is there a workflow reason you'd pick a self-hosted setup over something like CircleCI or GitHub Actions? Trying to understand the real trade-offs. 🤔
Old and clunky? Yeah, but it runs.
You can't argue with a Jenkinsfile in source control and a pipeline that works exactly the same way today as it did three years ago. Cloud services change their pricing, their feature set, their whole UI on a whim. My pipeline doesn't break because someone decided to "improve" the platform.
Cost is part of it, but it's more about control. I don't want to debug why my cloud provider's runner decided to hang for an hour. I can ssh into the Jenkins node and see the process myself. That's the trade-off. You trade convenience for predictability.
If it ain't broke, don't 'upgrade' it.
Old and clunky is relative. It's more like a rusty crowbar. Ugly, but you can pry open anything.
Cloud options are great until you need to run a pipeline that touches an on-prem database, needs a specific kernel module, or uses a weird custom hardware key. Jenkins just doesn't care. You point it at a box, it runs your job.
The real workflow reason is flexibility. Your cloud CI service won't let you install some random binary on their runner. With Jenkins, you can do anything, even the stupid things you'll regret later. That's a feature, not a bug.
That "works exactly the same way today as it did three years ago" point really hit home. We had a major workflow break last year when a cloud service deprecated an API version. It was a scramble.
But isn't there a hidden cost to that predictability? Someone still has to maintain that Jenkins server, apply security patches, handle scaling. Is that usually a dedicated person, or just extra work for the dev team?
Trying to figure it out.
You're absolutely right, that hidden cost is real. When I was on a smaller team, Jenkins maintenance became "volunteer" extra work that always fell to the most senior dev who could handle the Linux server. It wasn't a dedicated role, just another thing that ate into their week.
That said, after my own platform migration headaches, I see that maintenance as a known, predictable cost. The cloud service's "convenience" just swaps it for an unpredictable risk - like your API break. You're trading hours of patching for the potential of days of frantic scrambling.
Maybe the real question is whether your team has anyone who can own that rusty crowbar, or if you'd all rather rent a shiny, unpredictable drill.
Always backup first