Hosted Jenkins or Self-Hosted Jenkins

So, with each new project I take a pragmatic approach to evaluating the pros and cons in light of the specific project conditions and requirements. Jenkins has always been my go-to CICD platform. It strikes a balance between long-term strategy and short-term execution. However, I recognise that Jenkins, hosted or self-hosted isn’t right for everyone. But I’ll leave that to one side for the time being. In this post I want to focus on what questions you should ask - and take you through the process of asking those questions - in order to assess whether hosted or self-hosted Jenkins is the best solution for your particular project.

Is the dev team in a region with good access to a hosted Jenkins service provider?

Sometimes, when working remotely, access to a hosted Jenkins service may be slow and unreliable. Software developers need excellent connectivity to the Jenkins service. After all, no one wants to wait 15 minutes for pipelines to run or files to copy between remote sources. We experienced these issues first-hand when supporting a development team in China. Poor connectivity to our services in Europe caused a huge amount of wasted time. To resolve the problem we set up a self-hosted Jenkins service in mainland China and this provided excellent connectivity for the team. If you experience a similar constraint, I recommend self-hosting closer to the development team. The benefits outweigh the costs.

Do we have the right skills in the team to setup and manage Jenkins?

This one is important because setting up and managing Jenkins requires specific technical capabilities. Skills with Linux hosting, systems administration, infrastructure security and automation are essential. We wouldn’t recommend setting up or maintaining Jenkins without this expertise. The risks are too great and failure is not an option - the costs of wasted time, bottlenecks, failed releases and unhappy developers are high. But what does having the skills available really mean? For me, it means a number of people in the team have the necessary skillset. That way we are not dependent on just one or two people for maintenance and support. It also means I won’t be vulnerable if/when my Jenkins guy leaves. To sum up: if we have the right skills in the team, and it’s large enough so we are not dependent on just one or two people, I would consider a self-hosted Jenkins for a project. That said, we would still go the hosted Jenkins route unless there were compelling technical reasons for self-hosting Jenkins.

Do we have the time to manage Jenkins?

We usually have the necessary skills in the team, but still we don’t assume we will self-host. Setting up the tooling can take up a lot of time - time that can often be better spent on the actual project. Setting up a self-hosted Jenkins service will cost us at least 4 weeks for one or two engineers. By selecting a hosted Jenkins service, we can instead use that time for high value work and focus on helping the development teams with more of their start-up tasks. We can even be more involved with planning new ‘ways of working’. The value of that 4 weeks can be the difference between getting the job done or having to make a string of compromises. Does time spent on infrastructure setup and maintenance correlate with technical debt? The issue for me is that when working on a project I want each man-day to be high value. I get concerned when a project diverts effort away from where it is most needed: Is the value derived from Jenkins based on the uptime or the hosting? The project defines what time is available. You might consider self-hosting if the project has sufficient time, your team has the necessary skills, and there is a compelling technical reason for self-hosting. Otherwise, using a hosted Jenkins you can save time and your team can focus on more valuable tasks.

Do we want to do strategic work or maintain Jenkins?

When you run a team, it’s difficult to balance strategic work with maintenance work. Strategic work is making progress. Strategic work is the Jenkins pipelines, the test and infrastructure automation. It is everything you do on top of Jenkins. Maintenance, on the other hand, is monotonous. It interrupts strategic work and is a constant distraction. With Jenkins you have to be ready to perform security and plug-in updates. This means, when you least expect it, you may have to drop strategic work in favour of maintenance. This is frustrating and difficult to manage. If strategic work is more important, then a hosted Jenkins service is the best choice.

Do we need complete control over the Jenkins service?

Businesses with regulatory requirements will have concerns about security, data protection and governance. In cases where regulatory requirements are a key issue, we would recommend self-hosting. At Servana we provide a bespoke Jenkins service for a reason: As an MSP we know that each of our customers is different, with varying requirements and project demands. We expect our customers to request updates and changes. Nevertheless, there is inevitably a small compromise with a hosted Jenkins service. If you need full control of the hosting for the Jenkins service, choose to self-host Jenkins.

What if the Hosted Jenkins service is too slow?

This is a tricky one because many different issues can affect the speed of a Jenkins service. Tasks like downloading dependencies, for example; or using insufficient specifications for the Jenkins agents at setup. Equally, compiling languages such as C, C++ or Java can be resource intensive. All these symptoms of slowness would be exactly the same if you self-hosted. The difference, however, would be the support you are able to call on to help resolve these issues. If you are self-hosting, the onus is on you to resolve the issues - and this would further increase setup time. We find that optimisation is a never-ending task. However, it is definitely worthwhile and, if you are self-hosting, we recommend you perform all kinds of optimisations. With a hosted Jenkins service you can enjoy all the optimisations we’ve already put in place. And if you have a new challenge, we will work with you to resolve it.

We want a no-frills hosted Jenkins service?

I take ‘no-frills’ to mean ‘just Jenkins’, with none of the extras that you can expect from a provider like us here at Servana. There are many good options for no-frills Jenkins hosting. We would recommend looking at the marketplaces on service providers such as Amazon Web Services, DigitalOcean, Google Compute Platform or Azure Cloud Platform. They provide automated installers so you will be online fast. But there are no guarantees, and the responsibility for the final configuration, security setup and ongoing operational reliability is yours.

Do we need more than Jenkins?

Our hosted Jenkins services contain many upgrades that add value to the Jenkins service. For example:

1. Security features, including secrets management

2. Adequate artifact storage and dependency caching

3. Identity management and single sign on

4. Reliable build and test agents

5. Regular maintenance and updates.

As outlined above, there are significant differences between our hosted Jenkins service and self-hosting Jenkins. And we are always adding new feature to ensure we help our customers succeed.