Jenkins is Dead, Long Live Jenkins!

[Darren] (0:03 - 0:22) Everything will do everything else reasonably, but it won't do it just as Jenkins did. Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development. [Pinja] (0:22 - 0:32) Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna. [Darren] (0:38 - 0:44) Welcome back to the DevOps Sauna. After a long week, I am once again joined by Pinja. [Pinja] (0:44 - 0:45) Hey there. Darren, how are you doing? [Darren] (0:46 - 0:51) Well, it's Friday, the recording day today, so I've kind of been in zombie mode all morning. How about you? [Pinja] (0:51 - 0:57) Pretty much the same. It's been a really long week, and I do feel like a walking dead at the moment. [Darren] (0:57 - 1:24) Yeah. Speaking of things that are dead, there's a tool we all know and love and kind of hate at the same time, Jenkins. And honestly, I make this joke on the podcast every so often that Jenkins is dead, mostly because it's funny and because it's a little bit true. But something kind of interesting has happened over the past few years with Jenkins from my view, but maybe first we should open up by just for any listeners who don't know what Jenkins is. [Pinja] (1:24 - 1:46) Let's talk about that a little bit. It is not the most familiar tool for myself as well. So we're talking about Jenkins, which is the open source automation server. It is used for CI/CD, and I know it's written in Java. How about that? It's flowing on from Hudson. But what are the specifics? Why do we love to hate Jenkins? What's going on with that? [Darren] (1:47 - 2:41) Yeah, so Jenkins follows this kind of tech establishment of being established in an earlier time and not really keeping up with the times. I like to make this joke about the text editor Vim. There's this text editor called Vim that a lot of nerds swear by, and the problem is it has a learning curve. And I maintain Vim doesn't have a learning curve. It has an attitude problem. And the idea behind it is it takes a long time to learn, a long time to understand how it works. But Jenkins is actually the opposite. Jenkins is very easy to implement for the first time and extremely difficult to get doing exactly what you want it to, because it's kind of customizable with plugins. The base Jenkins is a great automation platform that forgets that humans will at some point have to use it. And then you use all of these plugins to basically make it functional. [Pinja] (2:42 - 2:59) And what I learned during my tenure in this industry is that it's got its lovers. There are so many people who like the customizability, the ability to use the plugins, and it's got a huge support in the community. But what I also hear is that it's a little bit clunky, isn't it? [Darren] (3:00 - 4:13) Yeah, the UI looks like it hasn't been updated since 2008. The previous iteration, Hudson, was retired officially in 2017, I think, when Jenkins took over and kind of, in my opinion, looks very similar. And this was a program that I think started in the mid 2000s, maybe earlier. And the thing about it is it's an automation server, and it does automation really well. And we can't take that away from it. And it's so customizable that it's actually, when you get it set up, it's really functional and really useful. But I think when facing the decision of how to build pipelines today, everyone has this idea that they want to get behind a single pane of glass. So that's why the offering of GitHub and GitLab is so enticing at the moment. Because these both have built-in pipeline systems, you have GitHub Actions, GitLab Workflows, I forget the title, I may be blanking on it. But you have these built-in pipeline systems, where everything is a one-stop shop for your programmers. You put the code here, the code is built here, they even have like artifact storage built in, so they can be stored here. [Pinja] (4:13 - 4:48) And we can talk about, for example, they're like Atlassian has their own tool for this, but whatever you're using at the moment might also determine which CICD pipeline management system you want to take in. And just thinking about the cognitive load that developers have at the moment, is Jenkins too much for that at the moment? I know, as I said, it's got its lovers, there are that devoted group of people who really like it. But how do we move away from that? What about the majority of people, of developers, who might not be experts in Jenkins at the moment? [Darren] (4:49 - 6:00) That's the thing, actually, with Jenkins, the devoted followers are a big driving force for it, because it does have a great community. But like most CI/CD tools, like everything connected to GitHub, GitLab, CircleCI, they're all done with YAML. So it's like a declarative language that's just saying, here's how the pipelines are structured. And you can use that in Jenkins, if you install a plugin that allows for the use of YAML, but usually you have to use this language called Groovy. And it's like, it's only used in Jenkins. And it's a little bit more, I think it's a bit more flexible, but that makes it a bit less simple. So, we come back to this cognitive load. And the whole idea of cognitive load is that if we give developers 10 different systems they have to log into, then they're going to forget nine of them, they're just going to want to push their code. And that's actually something we've seen in security for a long time, where we can build the best security tooling. And if the developers have to learn how to manage a third party tool, just to understand the messaging from it, most of the developers will ignore it. [Pinja] (6:00 - 6:04) So I think it's fair to say that this is not just a Jenkins problem, is it? [Darren] (6:04 - 6:35) Oh, no, definitely not. This is a problem with the general cognitive requirements on developers today. And again, is why GitHub and GitLab made the single pane of glass so popular. The idea that everything's behind GitHub, you put your code, you look at how your deployments are going, you look at how your builds are going, you run your testing directly there, and you get the results immediately. The single pane of glass, I feel like it's been touted as the kind of death knell for something like Jenkins. [Pinja] (6:35 - 6:46) Yeah, the single pane of glass is something that we keep hearing, it comes up in conversations when we talk about developer platforms, we talk about platform engineering. How are they different, Darren? [Darren] (6:46 - 7:48) Yeah, so platform engineering is actually something kind of interesting. So developer platforms have existed for a while, and platform engineering is, in my opinion, just the latest buzzword for them. So I'm always a little bit tentative to head towards that idea. But we were both at The DEVOPS Conference in Scandinavia. There were three talks that I remember specifically that focused on platform engineering. And these are talks that are all available on videos on our website. So if any of them interest you, feel free to look them up. We had VELUX lenders,Emma Jeppesen and Dan Grøndahl. They spoke about the importance of abstracting internal workings away from developers about basically creating not a silo, but this kind of filter to ensure that developers were seeing things that could augment their workflow and not interrupt their workflow. Then we had Zander Havgaard, who was talking about this golden path and kind of funneling developers into it. [Pinja] (7:49 - 8:46) Zander mentioned this elephant paths where in the jungle, when elephants cannot use the dedicated paths, they make their own. And that's what we as humans do as well. When we see something that is easier, we use that too. And in addition, from IKEA, we had Björn Ramberg and Supriya Chitale. And they actually gave us a peek at the single pane of glass they use internally at IKEA. So all these three talks that had a little bit different angles. Emma and Dan were talking more from the Developer Experience. Zander was talking about how do you actually implement DevOps in a small organization, in a startup. And Björn and Supriya had the angle of a huge corporation, IKEA, and inner sourcing at IKEA. But all of them mentioned, and we're talking about basically platform engineering and the single pane of glass. So this topic is not perhaps new, but it's not that a term that has come up that much lately before now. [Darren] (8:47 - 9:27) It's something that a lot of people are starting to work towards. And that's actually one of the strange things that happen in DevOps, in that we're an EvoCoder DevOps company. So we both like to know the best practices and like to try and determine them. So for us, this kind of platform engineering Developer Experience approach isn't something new. And then we go out to clients and find out that they're not talking about it yet, or that they're still using all the methodologies, or they're still using Jenkins on a server that sits under someone's desk. So we have this kind of repetition that we maybe have an expectation of people to be more advanced in their DevOps journey than they are. [Pinja] (9:27 - 10:12) And if we say that we have one single place, we have the IDP, the internal development platform, and we have the single pane of glass, does it really matter what's there behind it? Because we have people we, yes, we have the devoted followers of Jenkins. But there are other reasons why companies might be using Jenkins and the likes. So for example, it's legacy reasons, they have already invested in it. The customizability is one, but it's also the self-hosting, I guess, with Jenkins, that can be one element here. But when does it make sense? When should we bother with ourselves, whether it's actually Jenkins or something else? So what are the prerequisites to keep on using the older services? [Darren] (10:12 - 11:50) This is actually the curious thing, because the single pane of glass, I feel, was actually meant to kill third-party systems like Jenkins. It was supposed to remove the point of having these interconnected systems by saying, hey, you could get everything from us, reduce the load on your development team. And for the most part, that's actually true. But I think the single pane of glass is actually now that platform engineering teams are jumping on it and building these internal development platforms, they do become, it's actually become kind of protection for Jenkins. So that's why we have this Jenkins is dead, long live Jenkins idea that I'm, to be honest, quite shocked every time I go to a company and I see they're still running Jenkins, because it's, not because it's bad, but because it's everywhere. Like anyone who's been established for more than a decade is not unlikely, I will say, to have moved to like a GitLab, a GitHub fully hosted experience. They are often still running Jenkins in some capacity. And this is actually true for all third-party tooling, even if they do have that single pane of glass. Like for example, if we look at GitHub, GitHub Advanced Security does a reasonable job at everything it does and covers a fair amount of the use case requirements for security tooling, but it doesn't remove the need for something like Snyk. So the idea that the single pane of glass is now being built by development teams to use the tooling they want to, and in a way to hide that tooling from the people who don't want to see it. [Pinja] (11:50 - 12:34) Yeah. And if it's working in the background, and if it works, like if we think about what is a, what does a good internal development platform look like? And what I keep hearing, what is being appreciated by companies who take on background engineering and IDPs is that it's the unified Developer Experience, meaning in this case, the single pane of glass, because it's supposed to help the developers, right? And reduce the cognitive load. You can go into one place and look what you got, and you don't have to go any further. Like you said, like even if GitHub Advanced Security has all the things basically needed, but it might be lacking automated vulnerability scanning that Snyk could, for example, provide. Maybe that's perhaps the solution. [Darren] (12:34 - 13:51) I think it kind of started with Kubernetes because Kubernetes dropped in, when was it? 2014. And all the people excited about Kubernetes decided that all the developers in the world needed to know how to use it. And Kubernetes is complicated. Like Docker is a kind of more simplified version that developers like. I don't know any developer who likes Kubernetes. Kubernetes is liked by infrastructure people like myself, who want to be able to manage scalable infrastructure because it interests them. And the idea of abstracting this tool away was kind of a requirement for getting Kubernetes in place in a lot of companies, because the developers took one look at it and thought, if I start learning this, this is going to be 50% of my job. Whereas a Docker file anyone can create, because they're written in such simple syntax, you can just pull up a container locally and then push that container and have that installed anywhere. So this isn't a new thing. And it's like, yeah, when you have developers who want to develop, the worst thing you can do for them is put all these roadblock tools in their way, and security gets a bad reputation for doing it. But hey, Kubernetes did it, and Jenkins did it, so security is allowed to as well. [Pinja] (13:52 - 14:24) So we get to give a free pass for security, don't we? But there's not just developers who benefit from IDPs. We can also look at platform teams, right? And what does a single-payment class do for them? Because then they got all the unified views for that, for CICD, observability, and our favorite security, of course. So, in that sense, what do we have in the background? We have the devoted Jenkinsists, if we might call them that, or the ones who actually might want to have just that one place to view things. [Darren] (14:25 - 15:38) Yeah, and it actually kind of pulls everything back because I don't think anyone's putting together a good IDP, an internal development platform without infrastructure as code. And this is one of those mechanics that allows small teams to operate these 10 different platforms because, simply, if it's cognitive load for the developer, it's cognitive load for the platform team too. So you kind of have to be able to spring this platform out of infrastructure as code. And this, again, it just gives a one place to look with the combination of that and the monitoring. And I'm actually thinking about the release times of these podcasts because yesterday we recorded a podcast about this idea of progressive delivery, which ,if you're interested in that, go listen to the episode. But one of the things was about, we now have the bandwidth to use the information we're getting. And that can be information from the end user, yes, but it can also be information from the developers. And being able abstract that platform team out and say, these are my stakeholders, these developers, I don't care about the end users of the product, I care about keeping these developers happy. [Pinja] (15:39 - 16:00) Yeah, and usually happy developers equals higher quality product, as long as there is the understanding on what you're doing, and what is the value that you're trying to create. But we should not overlook the importance of happy developers, and that they have what it needs to actually create this quality, quality software and quality services and quality products. [Darren] (16:01 - 16:28) Developer joy, it goes back to TDOC in London last year, where we had Sven Peters standing on the stage talking about developer joy and how to keep because as he said, development is never a job people get into because they're like, okay, I need a job, they get into development, because they're like, hey, I like making the computer do things. And so it's ensuring that people can keep it as an interest point and not just work. [Pinja] (16:29 - 16:56) That is a very, very important point. And it is all about getting the tools in place, because we've seen the statistics, how long does it take, and how much time from a developer's workday usually does it take to work with different tools. And if it's a tool that you specifically need to learn, just for that one piece, it might actually be a slowing factor for that developer for that organization as well. [Darren] (16:56 - 17:21) 100% it would be. But that's why the IDP is so powerful in this case, because, you know, if they like internal platform team want to use Jenkins, they absolutely should, if they would feel most comfortable using Jenkins, they can, because they're abstracting the function of Jenkins out of the hands of developers who are either not prepared to or unwilling to use it. [Pinja] (17:22 - 17:53) And there is like, if we think of Jenkins as an example, again, as we mentioned, there are reasons why companies might not want to steer away from them. And it is a huge cost to go away to replace and go away from the legacy tools and replace them. So there is the bright side that the IDP and the single payment class can bring to the, let's call it the dark side of the legacy tooling that goes behind and goes under is actually working under the hood. We can use that analogy here. [Darren] (17:53 - 18:22) Yeah, I think under the hood works, or I guess behind the window. But yeah, as I said earlier, Jenkins is easy to take into use and very hard to get rid of just because of the amount of time you spend customizing it and getting it to do everything you need it to. And then you'll find that after you've customized something so plugin-based, that nothing else quite fits the bill. Like everything will do everything else reasonably, but it won't do it just as Jenkins did. [Pinja] (18:23 - 19:03) Correct. So there are a lot of reasons why we should be looking into having a good IDP, a good internal developer platform. And this is one of them, because we need to connect all the unless we want to go on that path and actually start replacing them. And as I say, there might be things that Jenkins is doing like no other tool is doing. [Darren] (19:03 - 19:20) Yeah. Really the focus becomes revolving around platform engineering, about making sure you have a platform where your developers can iterate, making sure they can do what they need and not caring about what's under the hood. Because as long as it gets you from A to B and the platform team can manage it, it's just fine. [Pinja] (19:21 - 19:33) Yeah. And that might actually just feed the appetite for the ones who want to keep using Jenkins and for the ones as well who do not want to see the UI, the outdated UI as many think of Jenkins never again, unless they actually really, really need to do that. [Darren] (19:33 - 19:41) So you heard it here that we give you permission to keep using Jenkins. You're absolutely allowed. Okay. I think that's what we have time for today. Thank you for joining us today. Thank you, Pinja, for joining me in this hour again. [Pinja] (19:41 - 19:45) Thank you, Darren. And as you said before, Jenkins is indeed dead, but long live Jenkins. [Darren] (19:45 - 19:48) I think that's a good place to end it, to be fair. Long live Jenkins. [Pinja] (19:48 - 19:51) We'll now tell you a little bit about who we are. [Darren] (19:51 - 19:56) I'm Darren Richardson, Security Consultant at Eficode. [Pinja] (19:56 - 19:58) I'm Pinja Kujala. I specialize in Agile and portfolio management topics at Eficode. [Darren] (19:58 - 20:07) Thanks for tuning in. We'll catch you next time. [Pinja] (20:07 - 20:10)