 it's bizarre to me that we still, as an industry, accept flaky tests. We have a test that checks the login page that fails half the time. And that test takes five seconds, right? And it fails 50% of the time. That five, not even five seconds. Sometimes they can fail in upwards of three or four minutes. You've got 2,000 developers making 20 changes a day. You've got months worth of wasted compute and time and energy and happiness even on these flaky tests. And so what we try to do at BuildKite is think about the person who's just trying to do that job. Hi, this is your host, Saptal Bhartiya, and welcome to another piece of our live talk. Today we have with us Keith Bit, founder and CEO of BuildKite. Keith, it's great to have you on the show. Thanks for having me. It's my pleasure to host you today. And of course, we are going to talk about BuildKite's acquisition of Package Cloud. But before we go deeper into that acquisition, I would love to know a bit about the company because it's the first time you and I are talking. So talk a bit about what is BuildKite all about? What problem that you saw in that space that no one else was solving that you felt, hey, we have to do something about it? Yeah, so BuildKite's been going for just over a decade now. Like this is almost year 13, not 13, year 11 of BuildKite. So we started out basically, well, I'm an engineering by trade. That's what I do. I'm a programmer and around a decade ago, I basically started out just trying to build a non non shitty Jenkins. That was the goal because I was using I was very familiar with CI CD toolings. I was very familiar with Travis. I was very familiar with Bandoo, tools like tools like that. And the company that I was at didn't allow me to use self that the company I was working for didn't allow me to use hosted CI CD services anymore. They said, we don't really feel comfortable giving our source code out. We don't really feel comfortable giving our deployment secrets out. So we need you to bring it in house. And I really don't want to use any of the self-hosted tools like Jenkins. And so I thought, why isn't there a hybrid model? Like why can I not have my why can I not supply the build runners themselves on my own infrastructure by just have a SAS cloud based orchestration piece? And nothing like that existed on the market then. So on a weekend, I thought, I'm going to try building one and see how far I get. You know, I'm still working on it a decade later, but I got something working on that weekend. I took it to work and work said, yep, this satisfies our requirements. You can use this thing. And then I thought, great. So a few weeks later, I kept working on it. I kept working on it. I put a credit card form on there. People started buying it. Grr grr grr. And yeah, I've been doing it for a decade. How much programs you see has been done either it's from open source community, where you do see there's a booming ecosystem which goes beyond just janking and it's like very well, you know, defined ecosystem for CI CD pipelines. There's a plenty of great open source tooling now that does CI CD pipelines. And back when I built this thing, that ecosystem did not exist, you know, like this was 10 years ago. I don't even know the CNCF foundation existed, but I could be wrong. So please correct me if I'm wrong on that. But because Hudson was acquired by one of the big tech companies and then the community didn't like it. So there was a fork and that became Jenkins. I think that's the history, but I'm not too sure. And so but then and then there was a bunch of small open source things. But at the end of the day, what I find that most enterprise are after a good support, a strong support partnership with the owner and the caretaker of the tooling. And so I think the open source stuff is great where to get started, but when you start having two thousand, three thousand, four thousand developers using it day to day, it I think it starts to make sense that the commercial offerings can fill in all the gaps that the open source one started. How you have seen the whole evolution of continuous delivery and I'm not just talking about from the perspective of tools and technologies, but how the industry, how your customers are looking at it. When I started BuildKite, you know, I had this idea for the hybrid model. You know, BuildKite handles the orchestration and you bring the compute. Now, the agent that you install on your infrastructure is in Go. So wherever Go could run, your builds could run. And at the time, 10 years ago when I wrote this, you know, Go could compile to Windows XP, which I thought was kind of cool. So you could run builds into Windows XP. I don't know who was doing that. But the idea at the time was for you to use cloud services. So I wanted it to be cheap, you know, I'm a developer. I'm very sensitive to price. And so at the time, I remember I could get myself probably still the case today, a five dollar a month digital ocean box. All right. And I knew that I could install my Ruby application on that and still the agent on that. And then with a relatively generous free tier on BuildKite, I could have CI CD for five dollars a month. Basically unlimited, super fast, and it would be great. Compare this to at the time, you know, other private, hosted CI CD services were like easily 300, 400, 500 dollars a month. They weren't really catering to developers, catering to businesses. And so, you know, I've always been floating around the cloud native world. You know, we were built in the cloud. We were hosted on the cloud. The build runs that we execute on are on the cloud. A couple of years later, after launching BuildKite, Docker came on the scene. That was relatively new, you know, I think two years into the creation of BuildKite, Docker emerged. And that was different. That was something new and interesting. But because BuildKite's agent was written in Go, we could use Docker on day one, a couple of years later, Kubernetes. But, you know, at the end of the day, you know, I've been able to see in the evolution of all these services and technologies over the past decade. And sure it's changed, but it's not changed. Really, you know, it's still at the end of the day, someone's trying to run a test, you know, we've managed to build all this a lot of complicated, complex, expensive infrastructure for at the end of the day, what we're doing is trying to make some better login works or forget password flow works, you know. And so we've built a lot of machinery around what are some very simple, simple operations. And so, you know, as much as the tools like, you know, Kubernetes and Docker are fantastic for isolation and workload, orchestration, you know, I do feel sometimes they are slightly more complex than they need to be. And, you know, I do see a lot of people jumping onto Kubernetes probably too early than they should. I think that it is a tool for teams of thousands, hundreds of thousands, certainly not a tool for teams of three or four. And I feel like people get themselves in a rut, you know. Oh, my Kubernetes stuff, so I can only Kubernetes didn't make me three people, maybe next week or next year. Just put that down the line, just use something else for now. This complexity is not going to go away anytime soon unless there's a next Kubernetes which comes in simplifies thing. I'm just using the term Kubernetes in general, just the way you use the term Linux and Kubernetes nowadays. How to help customers deal with these complexities without overwhelming them with it, without consuming a lot of their time and resources and cost and help them because then we look at the whole CI CD and you can look at CD and CI to separate things depending on who you talk to so that the whole idea is they should be able to move fast, they should be able to remain safe and secure so innovation should not cripple the speed, the speed should not cripple the innovation and same thing with the security. How do you see things heading and how you folks make it easier for your customers so that they can maintain their velocity and safety and security. Yeah, I mean, I think it's our whole industry, it's not just running on computers, it's the industry itself over the past 20 years, I've been in industry for two decades now. The industry likes to abstract. Everything's complicated, let's simplify abstract. Everything's complicated, let's simplify abstract and those abstractions then forget about the requirements of the previous generation of tooling. So like, oh, whoops, we forgot we needed this, let's add it, whoops, we forgot we needed this, let's add it again. And then that abstraction then becomes complicated. And then everyone goes, oh, this abstraction is too complicated, let's do it all over again and then simplify. You can see the same thing happen in backend technologies. You can see the same thing happening in front-end technologies. We don't write HTML and CSS anymore. We've written these abstractions on top of things. And I think it almost, and honestly, not advancing isn't popular. It's not a popular thing. Like, oh, we are not going to add this. We're gonna stay simple. That's not, you can't put a version 4.0 with no changes. You know what I mean? So you always have to be adding net new things to stay relevant. And so how do you solve it? I don't know. I actually don't know how the industry will solve this because it's a loop. It's a loop. So sure, Kubernetes is complicated and it's complicated for very good reasons, because it's being run in some of the biggest companies in the world by some of the most smartest people in the world. Sure, something will come along that says, we have simplified Kubernetes, but I guarantee you that thing over a number of years will get complicated, will become complicated or add features, add features. And then that'll be like, oh, this thing is too complicated. What do we do? I think that might just be the nature of our industry. We're in a loop of forging new ground, trying new things, and then realizing that, whoops, we forgot to add X and then we add X and then we keep doing that. And then we break out of the loop and then try again, but ultimately come back into a more complicated set. With running your own infrastructure, calling, you know, that was complicated and slow you to call someone and say, hey, I need a server. They go, yep, servers on the way. That was annoying and complicated. And then you had to worry about monitoring those servers, making sure they're plugged in, making sure you had UPS, making sure you had backup strategies, making sure you had off-site backup strategies. Like that was complicated and annoying. Sure, but the cloud environment, we've just substituted one set of complexities for another set of complexities. Now we have to worry about logging and monitoring and data.builds and, you know, I am security permissions and cloud this and cloud that. So, I don't know. I think the TLDR is complicated systems required, complicated machinery. So in a way that we can sort of go back, I think, is to create simple systems that require simple machinery. Now let's look at BuildKite. You did touch upon that, but in the previous portion, you also talked about the completion, but just look at the set of customers you deal with, how you make their developer's life easier through BuildKite. And let's also see what role this acquisition is going to play in that bigger vision that you have for CI-CD. What we sort of specialize in, Ryan, is taking your commit from your computer to production in the fastest time possible. We like to think of ourselves as a bit of a developer experience platform, not too much a DevOps platform, not too much a CI-CD platform. We're trying to help a developer, you know, get their stuff to production as quick as we can. And the process in the DevOps life cycle that we play in is that of build, test, package, deploy. That is where we live. So a big part of the building test process once you've got through those two phases is the package phase. You know, you've taken your code, you've tested it, you made sure it works and you package it up. Now, in a commercial environment, or if you're doing anything, you know, you're working on a business or any code that you want to keep private, once you've built that package, where you put it is a bit of a difficult question. Well, do I use the service that comes with my SCM provider? Well, that doesn't support X, Y, Z. Does it support private? No, it doesn't. How much does it cost? Oh, that's too expensive. Maybe I can use some big platform. Oh, wow, that's like $10,000. I'm not paying for that. Maybe I'll run it myself. Okay, so what we see is a lot of people end up just running their own package services. You know, they run their own Debian servers, they run their own YUM servers, they run their own RubyGems and NPM servers. And then another way to look at this is through supply chain security, you know, people want to know where that package is built, who they were built by, when they were built by, as they've been integrity checked. You know, are there any CVEs in this package? And what we identified is that, you know, we talk to customers all the time and we get them to stack rank all the problems they have in there, commits production process and say, what's the most annoying part of this for you? And time and time and time again, packaging and artifact management was the number one problem. Number one problem. And so, you know, they would keep saying to us, Bill, can't you just add artifact management? Can you just do that? And we thought, okay, let's figure out how to make this happen. The package cloud have been floating around. We've been sort of on this, a very similar journey, package cloud and Billkite for the past 10 years or so. And we reached out to them and said, hey, we think that we can, what if we bought package clouded to Billkite and hooked it all up. So, you know, you could host packages within Billkite. You could host your RPMs, your NPMs, whatever package you want. You could put it inside Billkite first class and have it all just work. And package cloud said, yes. And so, the train's actually been closed, I think six weeks ago now, is part of Billkite. And we have four steam ahead, building our new packages product with the technology of Billkite cloud. And in fact, I'm in San Francisco right now. I usually live in Australia, but today I'm in San Francisco meeting all our customers, walking them through the prototype that we have and getting nothing but great feedback so far. Now, let's look at use cases, user-based. Of course, it depends whether you can or cannot name a few companies. Name drop is always good, but talk a bit about what kind of customers or what kind of use cases that you see, not only of Billkite, but also of package cloud. A lot of companies, there are two types of artifacts you can think about. So an artifact is any file that is created from the building test process. Now, and there are two types of artifacts, deployables and non-deployables. Your deployable artifacts are things like your MEs, your Amazon EC2 images, your Docker file packages that you take and then put on a computer somewhere and then serve customer traffic. The other big type of artifact are the non-deployable package types. So you think about that, your internal developer tools, your internal libraries, your internal frameworks, your internal SDKs. So anything that a developer might use to do their job, that would be a non-deployable artifact something that doesn't actually touch. Now, companies, what they find, what teams end up doing is they create a lot of non-deployable artifacts, a lot of internal tools. Imagine a car company, imagine a company where you could order a breeder off your phone, all right? You can go on your phone and say, I want a breeder right now, right? That app that you use, it's not just on my phone, it's on an Android. It's on every flavor of Android. It's on a bunch of different devices and that app that you order a breeder from, it's not just that app, there's also the driver's app, you know? The app that the driver uses to get to you. Then you've also got the app that the restaurant has that says, hey, the burritos, I'm gonna make one. So one ends up happening is, you know, sure there is one app that the customer has, but there is a whole ecosystem of apps that drive this whole supply chain of the burrito and there's a lot of shared code between it. So these organizations, they have a significant amount of non-deployable packages because of mobile phones and old versions and stuff. This means that companies have to maintain a long, long history of different versions of those applications. So all those internal tools, you know, the latest version might be version 60, but they have to maintain version 59 all the way down to version 12 because of old phones, old ecosystems, blah, blah, blah. They don't want to turn those things off because people still need burritos. So over time, you can imagine just the sheer number of files and packages that accumulate. There's just a lot, a lot of files and these files are important. Not only are they important when ordering comes around and it's security compliance time, they have to supply documentation and history of those files. Who made the file? When did they make the file? Who signed this file? Who approved this file? Packages have a whole life cycle attached to them. The same with deployable image as well, like a Docker image that has a whole life cycle as well. Once it's created, it has to be checked for integrity. Who made this Docker image? Is it the right Docker image? Does it have the right things installed? You know, you might want to do some supply chain security checks on it. You might want to do some validation, you might want to do some testing on it. And only then when all those things are correct, will that Docker image be allowed to go to production? So it's actually quite a complicated space because there's a lot of unique important steps that have to be done on the way once a package is created for it to go out to production. And that's what we're really aiming to do. We're trying to build just some simple Lego bricks that developers can put together to build their own life cycles and workflows around these different packages and the different package types. Can we also talk a bit about, you know, through this acquisition, what impact is going to be on the customer? Like suddenly they feel, hey, you know, this was before and this is now. I just once again, the focus is on developers. How is this acquisition going to improve their life so they can take rest during Christmas or, you know, peak seasons? I am a developer as well at heart, so I have no intention of making the system worse. If anyone does they, they're Googling, if anyone's to Google the history of package cloud, they'll see that we acquired it from a private equity company. And so that's not really a thing that companies do, you know, like developers specifically, they know what happens when tools end up in the hands of private equity. Now, don't get me wrong, I'm not trying to bash private equity by any means. That was the case with package cloud. They was a very, very, very small team, just trying to, you know, do whatever they could with the resources that they had. They wanted to move faster, but the ecosystem of private equity had a formula and an algorithm they were trying to adhere to. And so certainly for the package cloud customers that they, if you're an existing package cloud customer, you will probably have noticed over the last few years, not much has happened because the team were mostly just trying to keep the lights on, you know, and it's, there are a lot of lights to keep on, you know, and they would do a really, really great job of it. What package cloud customers should see now is a starting an acceleration of exciting things being added to the platform. So I'm not telling enough, when I'm getting rid of it or anything like that, when I've changed the price, when I do anything dodgy, that would suck. Anything that would make people upset or sad, we're not going to do. But what we are going to do is we're going to start bringing some of the features over to Pillcard. And then adding, basically a shitload more features around package management. We're adding a bunch of package types to the system. We're adding some supply chain security features to the system. And we've got some pretty unique ideas around how we can handle those different workflow stages, how we can build in some LEGO bricks for developers to use. There's some pretty good ideas there. But ultimately, at the end of the day, what we are, the things that we don't compromise on are the security and the scalability and the reliability of the platform. And package cloud has, the last couple of years had two developers working on it and their status page is outstanding. Like, they have such fantastic reliability and I got to hand it to the team that were running this thing. They just did not let this thing go down. And so we plan to continue that same reliability track because the thing about these packages is that, especially those deployable package types that I spoke about earlier, customers rely on the system to be up to take those packages and deploy them. If the system is down, deploy it down. That's like an incident. That's like you're waking developers up in the middle of that. So we have no intention to change that. Keeping it reliable, solid, that's not going to change. When we look at CI CD, talk a bit about the importance of developer culture, developer experience within companies because tools are not sufficient if you don't have a right culture. Yeah, yeah. But the thing about culture is that tools often influence the culture. Like the tools influence the culture. And I think that a lot of people don't quite realize that. If you use tools that are a little bit crappy, then your culture is always going to be a little bit crappy. Think of a construction site. Everyone's trying to build a house. If the tradespeople, if the builders have a crappy hammer, they're not going to have a good day. If their hammer broke 50% of the time, I'm pretty confident that that tradesperson would throw that hammer on the bin. If every second nail just didn't go in the hole, they'd be like, this hammer is crap, it's going in the bin, I'm getting a new hammer. I think that that industry, like the building industry doesn't really accept or tolerate tools that kind of don't work. And it's bizarre to me that in 2023 developers are still accepting tools that just are a little bit crappy. And you see this time and time again in the world of flaky tests. It's bizarre to me that we still, as an industry, accept flaky tests. We have a test that checks the login page that fails half the time. And that test takes five seconds, right? And it fails 50% of the time. Not even five seconds, sometimes it can fail in upwards of three or four minutes. You've got 2,000 developers making 20 changes a day. You've got months worth of wasted compute and time and energy and happiness even on these flaky tests. And so what we try to do at Bill Kite is think about the person who's just trying to do that job. Yeah, so like we think about the team and think about the dev platform team that we mostly work with, but what we really try to focus on is Tracy. Tracy's job for the day is to make this button green. That's her job. But all she wants to do, she's got some shit going on in her life, you know, there's a new thing happening tonight. She's got to do this thing. She's got this birthday present for her on call, whatever. But what's going on in her job today and she'd be giving a hard time about it, get this button on to production. We try to make her day good. Her day just a little bit better and just provide a tool that just doesn't fall over. That just works and just, you know, just makes her day just a little bit easier. That's what we try to focus on. Because what we've found is that, you know, companies, the best, so we have the chance to work with the best companies in the world. We work with the likes of Uber, Pinterest, Airbnb, Slack, and a bunch of other companies that we're not allowed to tell you about because of their legal teams. Much as we like to say their names, we're not allowed to say their names. But one thing that all happened in common is that they ask their developers, like, are you happy? Are you happy with what you have? And 90% of the time, free food is not an answer that they talk about. Now, no one really gets excited about the free food, about the free gym, about the whatever cool perks they get at the office. Time and time again, the developers always talk about are the systems good? Are the tools that we use good? And I've been doing enterprise sales for so many years now. And it still saddens me to hear that, you know, leadership at some companies don't take this topic seriously enough. They don't take the happiness of the developers seriously to the point where they will buy second-class tools and they won't change them. Even though they know they're an issue, they know the developers hate them, but they won't change it because of some stupid multi-year contract, because of some stupid procurement thing, because of some stupid budgeting thing. And the developers just get told, hey, yeah, now we've got this thing, just use it. Just use it, we've already paid for it. So I think most of these companies, not because they don't like the work, is because they just don't like the tools. Coming back to that trades people analogy, and that, you know, if the boss of the construction site kept giving the builder a crappy hammer, at some point, that builder was like, I'm not working here anymore. I'm going to a different construction site. I'm going to a place that has good hammers. So I think it's the same thing with developers. Now last question before we wrap this up is, and it will be kind of unfair to not even ask this question, which is generative AI or shared GPD. What does this mean? What does generative AI mean for CICD pipelines? We can look at it from two different lenses. One is generative AI for CICD, and second is CICD for generative AI workloads. BuildCard has had hundreds of thousands of developers use it, and we've seen hundreds of thousands of pipelines across the platform, and they're all different, but they're all kind of the same. They're all a little bit different, but they all share the same structure, build, test, package, deploy. Build, test, package, deploy. They're all sort of the same thing. And so generative AI is good at pattern matching. It's good at taking a bunch of data and pooping out something that looks like what it's seen before. And so I think the opportunity for us is to, can we use generative AI and tools like that to take away some of the boilerplate setup for CICD pipelines? I have a Rails app that I wanna push to Heroku, for example, or I have a Node.js app that I wanna do some testing on and push to Vercel or something like that. Those pipelines are pretty much the same anywhere else. And so we got two choices right now. We can handcraft some pipelines and some templates and give them out to the world and say, hey, you can just use these templates, or maybe we can have generative AI. We can input a bunch of pipeline definitions and then have it spit out something that would most likely work. So I think in terms of generative AI and large language models and how they can be applied to the build and test package deploy process, I think we're gonna see them shine in just taking care of the boring YAML farm management, boring configuration management. Just things that you kind of have done a thousand times before, just let the computer handle it. The computer will figure it out. So I think that's what we'll see it in right now. I think that's where it will see it. It's most applicable. Keith, thank you so much for taking time out today and talk about this topic acquisition, the whole market ecosystem. Thanks for those insights. And I'd love to have you back on the show. Thank you. Love to come back. Thank you so much. Have a great day.