Whoa the Woes and Fix Your Infrastructure
In part one and part two of this blog series, we saw options to WHOA the WOES with the help of CloudBees as a managed Jenkins solution. But let’s reflect and take a step back. Sometimes, these woes are not on the surface—they were created out of growing pains, when your company needed new features NOW! Or when you acquired a new team, and you need to get them setup YESTERDAY!
This doesn't leave room for best practices when adding to workflows, because perhaps the easiest route was to pile more on your Jenkins instance, or just have people go off and spin up their own like an isolated company within a company—a turducken, except less delicious. It got the job done. But now? Not so much. In the long run, this will cause challenges in your software release flow. In this last blog (I know, finally!), I want to bring up the infrastructure woes—the woes below the surface—of some Jenkins implementations. Let’s see how many of you have been here with me. And not to worry—there is a light at the end of the tunnel.
Imperfect Solutions Have Their Price
As the woes (enough of this word already!) you've read about in the first two blogs ripple through your enterprise, you’re likely to experience a series of downstream effects, each with implications for how your pipeline works, how quickly you can release code, and how much the whole operation costs. Ideally, all such concerns would be tightly controlled to advance your business goals, but as you and I both know, things seldomly play out that way as enterprises scale.
Islands of Jenkins, Jenkinsteins, or Both?
The first and most profound, consequence of unmanaged Jenkins’ shortcomings is that they will inevitably dictate how your Jenkins environment is structured. Jenkins controllers tend to fall into three organizational traps, each intended to prioritize certain concerns at the expense of others. Bottom line? These approaches represent band-aid solutions that don’t solve the underlying systemic flaws they are intended to circumvent.
Islands of Jenkins— or the “Too Many Controllers” Problem
Because unmanaged Jenkins can make collaboration and standardization difficult, it’s natural for teams to want to do their own things. If permitted to, they'll spin up their own controllers, customize their toolchains, and maintain their corner of your SDLC as they see fit. This works well enough for a handful of teams, but enterprises with armies of developers will only increase their Jenkins woes. This “Wild West” scenario produces the islands of Jenkins phenomenon—countless disconnected servers/teams, often working at odds, amplifying communication, governance, compliance, and security troubles.
Jenkinsteins—the “Giant Monolithic Controller” Problem
Most of the difficulties associated with unmanaged Jenkins stem from trying to manage too many controllers. Many enterprises attempt to solve this by putting everything on one controller. While this does alleviate some maintenance, governance, and compliance concerns, it creates new problems in their place:
A single server cannot be all things to all teams. Some teams will go without preferred customizations and even essential plugins (if they introduce compatibility conflicts).
Running all your projects from a single server is likely to overload the server, slowing build and test times enterprise-wide.
A single server becomes a single source of failure, and a server outage can break your entire organization’s productivity.
Jenkinsteins + Islands—the “Worst of Both Worlds” Problem
Many enterprises start with a monolithic approach before eventually buckling under the need to give teams free rein. This combo of monolithic plus rogue servers makes for a particularly chaotic Jenkins environment that combines the downsides of both scenarios while eliminating most of their upsides.
Who’s Handling Support?
As we explore the challenges presented by unmanaged Jenkins, it’s important to remember that community support and your own team members are your only avenues for help if you run into trouble. Open-source communities are inspiring examples of people helping people, but they aren’t exactly enterprise grade. This can lead to several new sources of frustration:
Enterprises targeting rapid growth/transformation require 24/7, authoritative support to maintain pace. A lack of dedicated, reliable support services will create support bottlenecks that invariably inhibit enterprise growth.
In-house support can become an out-of-control expense. As your teams multiply, the amount of time team members spend on self-help support will also multiply. How much this costs in lost productivity, budget, and growth is anyone’s guess.
Downtime can cripple enterprises, generating significant losses. This becomes a real risk if adequate support staff aren’t on standby when catastrophe strikes.
What Is This Costing Us?
Why do all these issues matter? Because they ultimately boil down to a price tag. Worse, that price tag is often invisible. You usually know how Jenkins is helping your bottom line—but you can’t always see how it’s hurting it. Items needlessly digging into your budgets may include:
Productivity losses due to administrative overhead, troubleshooting, poorly maintained servers, security breaches, etc.
Scheduling delays because your engineers may spend 15+ hours a week on admin and support instead of code.
Work hours wasted on repetitive tasks and hopeless governance and compliance pursuits.
Missed business opportunities because you’re focused on pipeline challenges instead of innovation.
Staff bloat from trying to brute-force your way past the issues above.
Scalability bottlenecks—How can you scale CPU, RAM, and disk space as needed when chaos defines your SDLC? You’ll either pay for unused/idle resources or have your growth inhibited by a lack of resources when you need them.
Higher infrastructure bills—How can you recapture costs from idle servers if you don’t know when they’re active?
Downtime from any number of sources—Broken Jenkinsteins, unidentified bugs, compatibility conflicts, cyberattacks resulting from risky code, etc.
Who Can Help With infrastructure?
AKA, Where is the light at the end of this blog?
AKA, CloudBees CI for Maximum ROI
The next question is obvious enough: Where can you get all this? And the simple answer? The CloudBees software delivery platform. Part of that platform is CloudBees CI. CloudBees CI provides relief for all of the above woes (last usage of woe, I promise) as we have seen from the previous blogs. As the largest contributor to Jenkins code, CloudBees and its engineers are the definitive Jenkins experts. The CloudBees team loves Jenkins. But they’re well aware of its potential pitfalls, so they’re committed to maximizing Jenkins’ potential for you.
Remember this diagram from Blog #1? It shows how the CloudBees CI Operations Center (the centralized control plane we talked about earlier) restructures your Jenkins environment to facilitate the toolkit we’ve discussed, whether you deploy on premises or in the cloud.
As opposed to a single monolith controller filled with plugins that support different teams and jobs on jobs on jobs that slow down the pipeline and create long queues, each team has their own controller, their own objects, and access to a shared pool of agents if needed. For me, this meant my team had workload isolation—no other teams' plugins interfered with mine (I’m looking at you, Team Java-O). Outside of isolation, we could work together with other teams by monitoring pipeline events that my pipelines could queue off of (automation is beautiful, isn't it?), and we could even share agents across specific teams when my capacity spiked.
We’ve talked about what CloudBees CI can do to help manage Jenkins, and you could read how customers have succeeded in speeding up their release cycles, but another tool in the toolkit is CloudBees itself. Not the features, but the people. CloudBees CI is Enterprise Jenkins—we know Jenkins and contribute to the open-source community. And because we contribute a lot of code to the open-source project, we are uniquely situated to fix issues—should they arise.
With CloudBees, you have:
Customer Success Managers—Customer Success Managers help optimize your CloudBees CI experience with tips, tricks, and updates that ensure you stay on the path to growth.
Professional services—Whether you’re getting started with CloudBees, building DevOps mastery, or moving from old to new, our professional services team will get you there—quickly.
24/7 on-call support from the largest group of Jenkins-certified engineers
Assisted updates that can keep CloudBees CI current, stable, and compliant by proactively planning your upgrades with our support team.
CloudBees TV, containing many how-tos for both Jenkins and CloudBees CI.
CloudBees Docs, online documentation that provides information and forums to enrich self-help.
The Jenkins of today is not the Jenkins of yesterday—there have been advances in software delivery, and the open-source community has embraced, making it easier to integrate with the latest tech to advance your application development workflows. More integrations, more jobs, more flexibility, and more capability. Let CloudBees guide you through the flexibility and get your workflows to where they need to be—clean, efficient, compliant, and fast. You have the power already, just let us show you how to use it.
If you’re ready to maximize the potential of your Jenkins implementation, contact us for a personalized ROI assessment. We look forward to speaking with you.
In the meantime, download the Massive ROI with Managed Jenkins eBook to learn more.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.