High availability with CloudBees CI on AWS Graviton3 and Amazon EKS

Hello, everyone. Do we recognize who this is? Maybe. Yes, I see some thumbs up and some familiar faces in the audience. That's awesome. So, um I think I'll leave this right here. Actually, I think this is gonna be a good spot.

We have a special guest that I will be bringing out momentarily, but I want to thank everyone for being here. I'm with CloudBees. If you're familiar with CloudBees, you know that we have always been associated with the open source Jenkins project. Uh Kesuke Kalagi, the creator of Jenkins, uh was with us for a short stint and had really helped uh create what is now called CloudBees CI and that is the commercial offering of Jenkins and that's what we'll be highlighting today along with some AWS uh services like EKS and Graviton 3 specifically.

Um now let me see what I need to do here in terms of flipping slides. Awesome. I figured it out. So let's kind of set the table here. Why do you care? Um why should you care if you're an open source Jenkins consumer right now? Um there are gonna be some things a little bit newer to you today from an architecture perspective. Um but to, to give you the best description in the world about how CloudBees CI differentiates from open source, Jenkins, I'd like to introduce a very special guest to the stage, our very own Jenkins butler and he is stepping out right now. Give a warm welcome to the Jenkins butler everyone. Let's go.

Good morning, Ian. Thank you. You know, I, a lot of people ask me Jenkins, you've been around so long as an open source project. If you count the history with Hudson before Jenkins forked off from that, Jenkins is now 18 years old. This tool is old enough to vote and people ask, how is that still relevant in the world of software? And it, and the answer is two things. Number one, it is the very extensible plugin architecture. Jenkins is built with, there are 1900 plugins out there in the Jenkins ecosystem. Each one of those is an integration point that enables it to work with any tools that developer teams are using or enables an optional behavior so that people can work the way they need to with it. The second thing of course is CloudBees, the main corporate sponsor behind Jenkins CloudBees has committers who do a majority of the commits to the open source Jenkins project. Keeping it fresh and vibrant.

Well, I hope it makes much more sense now. That was awesome. Bill. I appreciate that so much. Um so he's gotta, gotta take a step back here. We'll have him back out for q and a. Uh but give a round of applause for Bill everyone. Thank you or the Jenkins butler.

Ok. Um so as you, I mean, it's a, we are like this with the open source project, but CloudBees is much more than just continuous integration. Now, we have expanded into a true DevSecOps platform with compliance capabilities release automation. Today, we will be strictly highlighting the commercial continuous integration capabilities again with things like AWS EKS and then Graviton 3, if you're lucky, actually, no, we're not gonna do a demo here right now. I lied to you.

So I'll hang around the feeder here for a little bit once we're done and then our booth is right there that way. So if you'd like, we can show you uh uh uh you know, a glimpse into CloudBees CI and the active active high availability and horizontal scaling capabilities that we just released in September. And that was absolutely massive. If you know anything about managing a Jenkins instance, you know that it is extremely hard to implement high availability, especially with a large cluster, hundreds of controllers, thousands for some people. How do I go about strategizing high availability and then thousands of jobs on a given instance, how do I manage the load distribution there? And that's exactly why we introduced these features back in September and wow, we are all excited about it and some of our customers, even a lot of people in the open source community have said really good things about those new capabilities.

So, like I said, we probably won't get too technical as far as a demonstration here on stage. But I'd love to do that right after this presentation. AWS Graviton 3 arm based architecture. Everyone. If you are, even if again, you know, I'll revert back to open source Jenkins if you are an open source customer, absolutely take advantage of what AWS the cost savings that Graviton 3 can provide for you arm based architecture is basically designed to make any application extremely fast. And so as we can see that makes it a very sustainable solution, they can save up to 20% less than, you know, your regular x86 um based processors and then they are very sustainable with up to 60% less energy than some other comparable ec2 instances uh that are more general purpose, right?

So we're going to be all the controllers or the managed node groups rather in EKS are going to be running on an m7g extra large that has the perfect amount of compute that we want for Jenkins. A lot of RAM and it's going to be lightning fast which you'll see if you come and stop by the booth. All right. So you're going to optimize costs, which is extremely important to your organization, you want to be sustainable and it allows you to run a broad set of workloads. This is not just designed for Jenkins or a web application. Anything that you run on AWS could be a great candidate for Graviton 3, namely CloudBees CI.

So let's kind of dive in a little bit to the high availability and the horizontal scaling capabilities that we just released. What problem are we solving again? With a, I'll start with a more of a traditional based architecture where you might be on VMware or bare metal and that is very burdensome to manage uh from a storage perspective. We all know Jenkins is a file-based system. So with unstable and very poor performance on these overloaded controllers, we know that's one of the biggest pitfalls in open source is these monolithic, these gigantic controllers and it becomes extremely hard to maintain.

So, should that controller fail in a, at any given disaster or even a restart that's going to impact every single build. So if you're, it's a Friday afternoon and you're releasing into production and it's right before Christmas and the controller fails and you are on the last stage of your Jenkins pipeline, your release pipeline, that's going to cost you money, that's going to cost you time and that's going to cost you a lot, you know, some reputation problems potentially.

So as you'll see the horizontal scaling will keep the controller up to date. It's a fact once we take a look at the architecture, the replicas effectively make one logical controller. So if something does go down and thanks to the horizontal auto scaling with the EKS up time is um a guarantee, right? So you're effectively reducing if not eliminating downtime with your Jenkins environments. And right now, we just released uh when we GA this rolling restarts for the underlying Kubernetes version on the nodes, we are definitely planning to uh enable the same functionality for the CloudBees CI versions or the Jenkins versions, right? Um so that's a frequent ongoing part of your organizational um tasks from quarter to quarter, you need to do that. And when you have large scale environments, again, with hundreds of controllers that becomes, you know, a big thing to plan for so high availability that what happens when you use Google everyone.

But again, we, we are introducing active, active, traditionally, active, passive was really the only option in open source. And with CloudBees CI, so that introduces an extreme amount of overhead on your cloud operations team or if you're in a and you're managing a Jenkins instance and you have to worry about high availability, it should be mindless. And that's exactly what we've kind of introduced here with, with active, active. So you're maximizing your up time, it's extremely stable so that, you know, when a given controller is reaching its peak load, it will the Hazelcast synchronization that we use to maintain the state of a controller and its replicas uh will surface the exact same information and can actually scale your pipelines horizontally across the cluster so that you're maximizing your software delivery throughput. Jenkins will not have this feature. So this is very unique to CloudBees and what we've been doing that is one of the main differentiators here.

So if we want to hop into the use cases here really quick. This is a great solution again for overloaded nonperformance controllers. If you don't have high availability in place today, it's a must have for your organization and it is extremely easy to implement when you run CloudBees CI on Amazon EKS. All you have to do upgrade to the latest version enable this feature. I want to say that the default number of replicas is two, you can change that and then that will scale out based on replica sets. So CloudBees controllers are spun up as state sets, which is a great way to maintain the application and it will scale based on those replica sets.

Um so let's kind of jump, speaking of, let's jump into the architecture. This is traditional, right? There's, there's really nothing new here. This is exactly what you can do in open source. Um so when we think about the consumers, our developers, whoever is actually, you know, running these pipelines and logging into Jenkins, they're flowing through, you know, the AWS load balancer controller, we have our primary instance here and then we have a replica. And again, traditionally, with an active, passive architecture that's manual effort, you cannot automatically, you know, um or it's going to be more human touch points if you want to sort of automatically provision that.

So and, and then the storage, right? So we're using Amazon EFS, which has significantly strengthened its performance um within the last, you know, couple of years, i personally believe and then this will all run in a self hosted architecture in your VPC with Amazon EKS. So what you would need to do to spin up your controllers in high availability and horizontal scaling mode is to provision a storage class for EFS. And then that would be, you know, attached to all of your controllers so that they can actually take advantage of that shared file system. Again, it's persisting the content from one controller to the next.

Now, what happens in a disaster, right, let's say us east one goes down as it as it uh kind of tends to do from from time to time. Well, that primary controller is going to go down. And if again, we we keep going back to open source because i've experienced this. It can take hours to handle the data synchronization from one controller to the next, which again is being handled through Hazelcast right now. And with EKS, they make this so seamless that the EFS again, will, will, will sort of persist all of the storage from the primary controller to the secondary or its first replica. And again, in the event of a disaster, that controller will, will, will spin up your pipelines will continue to run, you will release your features on time and you will save your reputation.

So this type of architecture, you know, i think is extremely important for a very massive application like like Jenkins and CloudBees CI. If you are not considering running a file system based complex DevOps solution on Kubernetes, you're just doing yourself a disservice. Now I get you might not have the right resources and there are a lot of constraints involved here. Um but this is by far the best way to run our solution. And then, you know, you introduce some of these capabilities, the hot fail over the automatic adoption with the pod auto scaling. It really is incredible.

Now, the horizontal scalability aspect of this again, it it comes into play when a controller which is running extremely performed, by the way, thanks to Graviton 3 and that arm based architecture. But when you and goodness gracious, we we have some very large customers that have thousands of controllers, i think hundreds of jobs, if not thousands of jobs on each of those controllers. So when you think about how and the spikiness of, you know, when you're running your builds, if certain things are are certain pipelines are running concurrently that puts an extreme amount of stress on that environment. The disc space runs low compute UI performance gets extremely laggy. Not that you need a UI for CloudBees right. If, if in an ideal world, no one logs in to Jenkins, right? No one logs into CloudBees CI it, it, it should run headless. That's a different conversation but say we do reach an extreme amount of stress on that primary instance. Again, Hazelcast makes the state from each controller to the next extremely lightning quick. And then, you know, with that EFS storage class, all of your data will persist again in the event of a high stress scenario.

So in this architecture diagram here again, EKS, we're taking advantage of these AWS load balancer controllers. And again, you know, so these are going to be underlying managed node groups within that EKS cluster and it will just dynamically um scale your workloads across your replicas like that with EKS now is active, active high availability available with traditional architecture. Yes, it will cause you more overhead. So you're going to be spending more money, you're going to be using more of your engineering time. EKS simplifies the management, the maintenance, the performance of that feature.

Ok. Again, we're not gonna do a demo. I wanted to, I wanted so badly to do a demo. Um but we will. So again, I'm gonna hang around the feeder for a minute if any of you are interested in kind of chatting a little bit more technically about some of this. If you want to bring up a use case that you think could kind of fit uh with CloudBees. I let's do it and then we'll take the party to the booth where I can kind of prank open my laptop and we can get into the nitty gritty

Big shout out to AWS um for being an awesome partner with CloudBees. Uh big shout out to all of you for giving me the time of day to, to kind of listen in. Um thanks to the Jenkins butler who I'm gonna bring back out onto the stage as we wrap up here into q and a. What we've got here are some QR codes. So again, this will kind of take you to our website where you can review some of the documentation and then the announcement on one of the biggest, if not the biggest performance and scalability update, not to Jenkins, but to CloudBees CI in nearly a decade.

So again, thank you very much. My name is Ian Kurtz. I'm a sales engineer at CloudBees.