Crossover edit
===

​[00:00:00] 

Grant: All right, you're listening to the Enterprise Ready Podcast.

Speaker 4: And the Cube List podcast.

Grant: This is our very first crossover episode. So you've got me, grant Miller, the host of Enterprise Ready.

Speaker 4: You've got Benji Deru, the co-host of Cube List.

Speaker: And hi, I am Mark Campbell, the other host of K. 

Speaker 4: Pretty exciting to have to have a crossover episode. It's like we're in the eighties. I'm very excited. It's like night writer and Baywatch. That's, no, that's

Grant: I was thinking more about the MCU, but that's just

Speaker 4: I'm dating myself a little bit, but I, you know, like there was like an episode of like growing pains, I think, and like some, I don't know, just the crossover brings back old memories.

But the important thing here is that we are gonna do something that I've wanted to do for years with Cube List, and that is talk [00:01:00] about. What replicated does in the open source context of course, and, and some other stuff too. I, I'm gonna, I think it's always interesting to understand about the business aspect and the go to market and all that stuff, but I'm really excited 'cause Grant and Mark also happened to be co-founders of Replicated, and so this is the big episode where we kind of get to talk about the history of replicated and the impact it's had and is trying to have all the time.

So I'm, I'm really excited to talk about this and, uh, it's somewhat the shill episode, let's be honest. But at the same time, I'm very excited to actually get an opportunity to go through all the projects that Mark and Grant have worked on over the years and some, and maybe some upcoming stuff.

Right. Grant 

Speaker 5: and Mark,

Grant: Yeah, we have a really exciting thing we wanna announce today. So that's why we're, we're, we're really bringing this together is, uh, one of the biggest launches in replicated history.

Speaker 4: Wonderful. And it's open source related, so that's Cube List. That's why you're here. Alright. Why don't we start off a little bit. I think typically we have a very technical audience on Cube List. Obviously it's a little different with Enterprise Ready [00:02:00] but we really like to understand, um, the background of folks.

So, I mean, I'd just love to hear a little bit about your background Grant how you came into this world. Um, and then mark you as well.

Grant: Yeah, sure. So, I mean, the quick backstory puts Mark and I together is, uh, as we started a separate company together now that's like 13, 14 years ago, called Look io. And look, IO was sort of a live customer support chat, chat, but for mobile applications. So our first customer was hotel tonight, and we basically helped people as they were booking hotel rooms, talked to a customer support agent and that company was very quickly acquired by live person.

After about, you know, from start to finish, nine months in and out. Mark and I were young and had never seen the startup equity that we had earned turn into cash. And so, you know, we're able to, to turn that company around, sell it for a couple million bucks, and felt like we were kings of the world for some amount of time until we realized [00:03:00] that, a couple million bucks is just not that much in this world today and after taxes and the stock goes down and all of a sudden you need to get a real job again.

That's how Mark and I kind of came into the, came into the software world together. And then we started replicated over 10 years ago. Um, and this has been basically really around a lot of Mark's early experience, you know, and kind of his entire experience around infrastructure and, you know, his career doing.

Installing networks in prisons all the way through to, being an application developer. And we saw this opportunity to basically enable software vendors to distribute their applications into secure customer environments. And we thought that would really change. And this is 10 years ago.

And we thought that the, the technology that was enabling that was gonna be docker. And that much has been true. I think like when we started the company, the idea that software [00:04:00] would be self-hosted in the future was, was pretty heretical. And we got laughed at, like literally, investors laughed in my face.

Some Salesforce exec exec laughed in my face when I told 'em that we were gonna make on-prem software. Cool. Again. But obviously, you know, that ecosystem developed a lot around Kubernetes and. You know, we've been kind of in the ecosystem for now. Yeah. 10 years building different products.

And one thing we'll get into maybe a little bit later, kind of in the enterprise ready side of the show is just some of the challenges that we went through, you know, as that market really shifted, you know, we had missed products, product cycles and just had other, other challenges, uh, that we had to address over the last few years.

But yeah, that's kind of the quick, uh, the quick backstory to

Speaker 4: the, the origin story of, of replicated, um, mark, what a grant talked about that you did. Networks at prison, stuff like that. Just from a technical side. Because you know, I'm gonna, the crossover, who's gonna win here? It's [00:05:00] gonna be nerds versus enterprise. But we're, we'll, we'll try and balance it out.

But mark, on that note just tell us a little bit about your technical background, like where you came up, and just a few things about that.

Speaker: Yeah, I mean I, you know, in, in, in School studied computer science, but like, you know, first Job and spent the first bit of my career doing like more like IT work, you know, installing, you know, networks and routers and stuff like this and servers and I think, you know, learned a lot about that process, which I think is.

I don't know. I think it makes it really interesting and you actually understand how software and how computers work a lot better because of that. And it's, I mean, to this day, replicated is still building a lot of infrastructure software. We're still like, really, you know, active in Kubernetes and Docker and containerization and some of the new stuff that we're gonna talk about here today.

Um, so it's definitely like, stayed relevant throughout my entire career. But like, I mean, I, I definitely, am happy to have transitioned from it, work into writing application code and

Speaker 5: What 

Speaker 4: was that 20 years ago like? That was a while ago.

Speaker: Maybe more, but

Grant: Yeah, maybe 30. Yeah.

Speaker 4: But [00:06:00] so I.

Grant: it's great. It's like, I, I always describe Mark as like the true full stack developer, right? Like all the way from the IT side, the networking side, racking and stacking all the way through. You know, he is building mobile apps at some point, you know, for very popular consumer applications and had that, the full breadth of knowledge of what it took to, to get, you know, applications into production.

Speaker 4: I like to think of Mark as a full, full stack because he does like backend, front end and infrastructure. But I've never thought about the mobile. So would it be a full, full stack 

Speaker: it's even, even more so with AI now, right? Like I don't have to, you can

Speaker 4: Yeah, you just think it and then it's done.

Speaker: all are.

Speaker 4: Which is interesting too, uh, that maybe we can talk about. It's a podcast. We have to talk about AI at some point, but we can save that a little bit for later. So, okay, so you guys started replicated over 10 years ago. And the idea was to quote unquote make, uh, on-prem.

Cool. Again, I, I think on-prem is definitely viable. Important, critical. I'm not sure it's cool. [00:07:00] But the mission is still in progress. What, uh, what was the first, like, let's talk about the first chunk of the replicated journey. Like, what was that? So you, you raised some money and you're focused on this new technology called Docker and you're thinking about Kubernetes and that it's still early, it's pre 1.0, I'm pretty sure from that timeline.

And you guys wanna attack this on-prem problem. What was kind of the first, what was the first few salvos like, how did you go about attacking that problem?

Grant: Yeah, I mean the funny thing is Mark actually initially built some deployment tooling around Minecraft. And so that was kind of like the in you remember that at start, mark.

Speaker: Yeah, we did. We were making it so that you could, you could spin up your own Minecraft server and host it like really, really easily in like, you know, seconds, which was like wow. At the time, right, because you didn't have to go figure out how to like get everything and all the dependencies and everything deployed.

Grant: And that kind of helped us be like, oh wow, this technology is super powerful. We can do something interesting with it. You know, we, we saw the business opportunity around what [00:08:00] replicated would become, right? Sort of this, hey, the, you know, I always called it like the post Snowden, uh, world, where just like, I think we started to understand that like wherever data went, it could be like tapped into and so companies and countries would need more control.

And I thought we would just like, have a little bit of a like a recognition that like maybe multi-tenant SaaS wasn't the like be all, end all solution. And it actually makes a lot of sense if you can automate software. To allow your customers to operate that, that automation in their own infrastructure.

And we knew that eventually it would become more cloud-based. So it was never anti cloud, right? We always assumed that like the end customer would actually run software in their own VPC, not necessarily only in like a true on-prem data center, but you needed the software to be completely portable in the same way that it could run in the data center.

It could run in a, you know, in A VPC. And so, we had that thesis. We looked around the market. I thought we were gonna [00:09:00] get customers like Slack and Dropbox and Evernote to become like our first, first customers. I was really focused on the SaaS side. And then we met Tom Preston Warner from GitHub and he gave us just, you know, an investor in both replicated and Shipyard.

And he gave us a ton of insight. And that insight, you know, from building GitHub Enterprise was, a lot of what led to us creating the enterprise ready site, right? It was like, here's what enterprises expect from true enterprise ready products. And one of those things was a deployment option and being able to self-host.

And we looked at what made GitHub Enterprise really good, like the admin console, how it worked, how it operated, how you would configure some of the monitoring. And so we started to really build a version that of GitHub Enterprise that you could, could basically deploy any application. And uh, and Tom also introduced us to our first three customers.

So that was, you know, two of which were open source companies, so Travis ci, NPM, and Code Climate. And those folks were kind of in the GitHub ecosystem, needed to [00:10:00] self-host next to GitHub, you know, next toub Enterprise. And so, you know, they were all kind of early adopters evaluating containers and so they were like, Hey, yeah, we wanna ship this container and you know, we need to give customers an easy way to, to run it and operate it.

And so we wrote, mark wrote our original, our own scheduler. So we had, something that was a little bit like a almost Docker composed, like pretty simple. Not quite all the functionality of Kubernetes, but uh, but was, was designed to be, you know, to, to help these enterprise applications get deployed, you know, onto one or more nodes inside of a customer environment.

Speaker 4: Mark that was like Mesos days and like when was that? Right? When you wrote your own scheduler?

Speaker: Yeah, I mean, it was the the, at the time I think it was like swarm kit or something from Docker where they were talking about it and it came out, but like you could run docker containers, but like overlay networks and service discovery and all the things that we take for granted in Kubernetes was not there yet.

And so we had to build something proprietary basically. We didn't think it was general purpose, but it [00:11:00] was, easy to define the, you know, here's five containers that run, or, you know, multiple containers that run. We weren't solving software defined networks or anything like this. It was using host networking.

But it would it, it, it's still out there being used a little bit today. Um, but like, it, it was definitely, when we saw the Kubernetes ecosystem start to take off, we were happy to adopt that and get out of the world of building that layer ourselves though.

Speaker 4: Um, I think, uh, you know, grant, I wanna go back for one second. Just because again, it's a mixed audience, so I wanna make sure everyone understands what on-prem means. Can you just give me a, a 32nd explanation of what on-prem software means and your delineation between cloud and data center was helpful for me, but maybe just explain that again for like 30 seconds.

Grant: Yeah. So, you know, it, it is, it's a, it's a great point. The word on-prem kind of comes from this idea that the data center or like, you know, that your, actually, your servers were on-premise, so you would have servers in a closet in your office and [00:12:00] you would install software in there, like you would install a CRM or install some other, you know, some databases that were using.

And those were only accessible from your local network. And that's kind of where the terminology for on-prem software came from. What happened, I'd say more recently, and I actually, you know, even stopped saying on-prem as much, and I say self-hosted because what this means is that you need, there's like, it really differentiates between multi-tenant SaaS, right?

A software vendor deploys their software onto a cloud that they can control. Versus that software vendor packages up the automation, maybe gives you a helm chart and then, and allows you to run their application on any infrastructure that you have access to. And that could be, a VPC within your AWS account, or that could be a true on-prem data center.

And that methodology has become more important in the last, like I'd say, five to seven years. I think it's become a little bit [00:13:00] of a mixed, you know, bag between these different hybrid deployments. People talk about BYOC, people talk about, you know, data plane control plane. But what we've seen is there's been a real resurgence in interest in different deployment options that give customers more control of the data so that they're not sending their data out to thousands of different vendors, but instead bringing the applications to where the data already resides.

Speaker 4: Right, and that's probably for security reasons, but also because in today's world, data is seems like you gotta gate keep that stuff for these big corporations. Is

Grant: V. Yeah, very true. So in, you know, initially very much around security and compliance, but then to your point, uh, proprietary data has become really powerful and important in terms of training these AI models. And so, you know, if, if you're sending your data all off to some SaaS service who has the rights to train on it and to own the learnings from your data, then you might have a problem with that because your data might be the most important data in your in your sector.[00:14:00] 

And then they could use that data and learn and sell something to your competitors. So there's a lot of different reasons why I think folks are being much more thoughtful about where the data goes and, and who gets access to it. And ultimately it just. You have to trust all these vendors. If you're sending your data out to thousands of vendors, it's basically the weakest security posture is your security posture.

If you have a thousands copies of something, whoever has the least secure environment is like, that's the security posture of your data. And so if you can control, you know, bring the applications to the data, you can control who accesses it, you, you know, what's going on versus, versus sending it out there to, to thousands of different vendors.

Speaker 4: Totally. Okay, so let's nerd out for one sec here. Let's take, let's put the nerd break on. Okay, mark. I am a SaaS company. I'm a dev tool company early and replicated career. Uh, you said code climate, I said Travis ci. I think you guys had Circle CI as well as a customer. Why couldn't I as a [00:15:00] developer there, like what are the main highlight challenges of why I'd use replicated the software to do my software?

Because, you know, I'm a computer nerd. I think I know everything. Oh, I could do it this weekend. What were like the main nerd challenges? Mark and then follow up Grant. What are the main like business challenges for actually deploying on-prem? But Mark, let's start with you.

Speaker: Yeah, I mean like look, you can, right? Like I think we worked with really technical customers who. A lot of them that ended up becoming really good, replicated customers were successfully actually shipping on-prem software before Tra CI had one. NPM had one, you know, HashiCorp shipped Terraform Enterprise on-prem before they came to replicated.

Um, it's really the diversity of those customer environments that start to become really complex. Though you wanna ship to five customers running in AWS great. They're probably all pretty similar, but that's not the way the world actually works. Like you wanna ship to 20 or 50 different enterprise customers.

They're running in different cloud providers, they're running in different regions, they have different types of disks and networking configurations and [00:16:00] everything. And so what we focused on was trying to build. There was a few different parts to it, but the part on the technical level that became valuable was building that interface, that abstraction around those different environments so that you could, you could, you know, ship to your customer on AWS next customer comes in, they're on Azure, and you wanted to be able to run in that environment.

And we were able to actually give high confidence that it would actually work in that environment because we had been installed in those environments before. We've been ba we've gone through those, those battles before.

Speaker 4: So, okay. So it's really like, it's really like permissioning and upgrading, right? That's one of the big things like that you guys,

Speaker: Yeah. I mean, 

Speaker 4: to upgrade on these different disparate environments. Like when you're talking about bad environments, are we talking about like. We're talking about like re L five, right?

We're talking about like barely containers on there, or what are we talking

Speaker: Yeah, there's two, it's like that, right? There's these, like these early days, you know, Docker wasn't accepted everywhere yet. Like, and some of these environments weren't compatible, but then also just like the environment themselves. Like they, you [00:17:00] might be an enterprise customer that's running chef or puppet or something in a very more like legacy way that's like resetting that server all the time.

And so any changes that, you know, you'd come when you deployed your software and you make to it, they'd get overwritten and reset. And so all of the stuff like that that we'd have to learn how to work around, detect, um, and then, you know, you don't wanna sit there and try to do an install at an, at a, with your enterprise customer and then find out it didn't work and then have to like pull in an engineer and figure out why.

So like a lot of the software that we ended up building was stuff like pre-flight checks that would able, you were able to validate that environment prior to actually performing the installation so that you knew it was gonna, work.

Speaker 4: Right. And then there's also one of the thing that always interested me about your tech was the air gap stuff. So talk to me a little bit about like what air gap means and like what the challenges there were.

Speaker: Yeah, a lot of these, the software, like you were talking about before, you know, like you, the reason you bring it in on-prem is because you wanna make sure that you're not sharing that data. You're not sharing, you know, you don't want to go to a Multinet SaaS, you don't wanna share with the, the SaaS provider.

And so some of [00:18:00] these many of these enterprise environments don't allow outbound connectivity. So you can't you certainly can't get inbound connectivity, but even that, you're, you're, you have to figure out how to get that software running without being able to rely on APT Repose or Docker hub or anything like this running.

So we would, we create an air gap package, which is essentially, it's a Tar G zipp of the application and all the container images in the metadata, but then cryptographically signed to prevent tampering with it and licensed. And so you deliver this tarball onto the, into that enterprise customer environment.

And then we would. Deliver in, over the course of replicated the solution changed a little bit. As Kubernetes adopted more and more we would just deliver into the enterprise registry that they actually had. And then you could perform the install from there. But early on, you know, there it was before Docker registries really, you know, where a thing that you, you

Speaker 4: They weren't like, ubiquitous in enterprise orgs. Wait, so, those pieces of software that you're installing, it's not just my application, right? It's not just, uh, CircleCI or, or Travis. Right. Uh, which I, I wanna say that [00:19:00] was Rails. I think that was a Rails app, I believe. I don't know. Yeah. And, but it's also the underlying database.

It's Postgres. It's Redis. So it's all the infrastructure of those of that, of those applications. Right. So you're not just delivering this application, you also have to support like this version of Redis and that version of Postgres. Is that right?

Speaker: Yeah. I mean, it, it can be right. And it can also be that, your customers don't all look the same. And some of them are running it in AWS and they wanna run Postgres on RDS and some of them wanna run it in a container, or they have like their own way to run Postgres, so you have to talk to their team.

So getting it to work in their environment is a big challenge. You can't, if you want to send software, if you want your enterprise customer to run software, you want to not be super opinionated. You want to kind of be able to like, try to, when it's reasonable, meet their opinions about how that software should actually shape and look and run in the environment as long as it's gonna be compatible.

Speaker 4: Right, but you basically have been installing open source software in and application software for, since the beginning of this whole thing is really

Grant: Yeah, [00:20:00] for sure.

Speaker: Absolutely.

Grant: Yeah. And, and I would also just add like, I think the shape of the problem really changed as the, as the, the landscape evolved, right? So in the beginning, there was no Kubernetes, this is really even before there was Docker composed. And so like, we had to provide some orchestration, right?

And that was what our scheduler did. And then, you know, we had to provide, after there was Kubernetes, we had to provide some packaging. So we had this product called cots, uh, which was, you know, a way to, to basically package, Kubernetes applications and, and leverage customized to do last mile configuration.

And then, you know, helm really became the foundation for how people package. And so then, and you know, this is kind of brings us to today's problem that we think about. It's really about the entire commercial software distribution lifecycle. So we sort of discovered that like, basically every one of these software vendors goes through the same [00:21:00] process, these seven different phases and stages.

It kind of mirrors the DevOps lifecycle, but it's uh, it's, it's a developed stage so that everyone would be familiar with that. It's really focused on you. You need to be truly kind of portable and secure. Um, and then it's a testing phase. And so we built a, a really comprehensive compatibility test harness so you could spin up different versions of Kubernetes, different hardened images and test your application.

Uh, then it came down to licensing. So we needed to provide licensing and entitlements. Then it was around release and you need to give people release channels, the ability to kinda give customers different versions, to your point, upgrades. Then we had to focus on installation. So how do you make sure this is easy to install If the customers ha has Kubernetes or they don't have Kubernetes, we needed reporting, so you know, what's going on, some telemetry health checks, what's happening with these instances as they're running?

As [00:22:00] well as maybe some custom metrics supportability, which is like, you know, hey, there's an issue with this, uh, environment. Can I look and see what's happening? How do I support this customer? And so that life cycle, we kind of have purpose-built solutions within each of those, and that's kind of what we call the replicated platform.

And we try to continuously look at each phase and make sure that we can add a lot of value, because ultimately the value that we were bringing, I. Eight years ago, five years ago, just doesn't have as much significance in today's world. And so we needed to kind of change the value proposition for replicated throughout that time.

And, you know, that's, I, I think that's like a really interesting challenge that many businesses face because you kind of initially come out at and you're attacking like a very specific need in the market. But we see this in AI a lot, but then the market moves and changes and there's new dynamics.

And so, you know, your team's ability to, to [00:23:00] see those changes in the market, predict them and then kind of get ahead of what's happening is really important. And I think is, you know, in a ever changing and ever increasingly changing world, it's an important skill that, that a lot of companies will continue to need to, to really develop.

Because. One thing that's for sure is that, you know, next year will not look the same as this year.

Speaker 4: I mean, you mean next week will not look the same as this week? Yes. It's, it's insane the pace of things. Um, I don't think there is an AI yet for like replacing your C-suite every other week, but it seems like that might be coming sooner than later. So, okay. So you've gone through a lot with replicated.

Both of you have obviously, um, you've gone through a bunch of product cycles. It sounds, it's a very robust product. As a application company, I turn to replicated and I say, Hey, I need you guys to help me sell these big enterprise contracts. And then you guys have, you're basically working in as hostile [00:24:00] environment as possible for software.

And they're all disparate and it's all like, you know, that, that one company and they, they all have these various needs. So

Grant: But I, I think, I think maybe my my, my point real quick is it's also just all the tooling that you need around that, right? So it's the idea of how, you know, you're not just doing that with one customer. You have a entire process and you have, you know, lots of different teams that you're coordinating to in order to make that happen.

And so there's, you know, you need kind of specific tooling, just like you need, DevOps tooling, right? You're not just you don't just, we're not yo lowing it up to, you know, get push Heroku master anymore, right? We actually have like, purpose-built tools that kind of do each of these phases.

And and the same side, the same thing happens when you're doing self-hosted deployments, right? You need to be, you know, think about how do you do licensing, how do you do air gapping? How do you do. Testing, like, you know, how do you do security? All of these things are very different in that commercial software distribution [00:25:00] world.

And you can either build all that tooling yourself, which like, GitLab and GitHub have 40 people that are on the distribution team and, and they're really focused on, you know, how do they package their application and make it installable and keep customers running and have fully licensed and, you know, easy to, to update and manage and monitor and support.

Or you can use a tool like Replicated.

Speaker 4: Okay. And so, one of the reasons why we're finally getting around to doing this episode is because you guys have some really interesting open source stuff coming up. Um, can we talk about that? Can, can we hear about what the latest and greatest is?

Grant: Yeah. So this is this is a really, it is a really interesting product that we're launching. It's actually new kind of total. New line of business, new brand for replicated it's called Secure Build. And so listeners can go to secure build.com and find out what it is exactly. But the whole concept is that we are [00:26:00] partnering with open source projects to provide zero CVE images of their project.

Every, each one of these projects. For example, we have like Wvi eight Timescale db coder, R Clone they all get a landing page that's specific to their project and they, they, you know, reference that landing page on their docs in their registry and for their, for their community who care a lot about security.

And they want to see the image go from a hundred CVEs to zero. Those community members can now click through and purchase a zero CVE version of that project with a six day SLA for critical and 13 day for the other CVEs. And we will, you know, be building these basically by mapping the full dependency tree.

You know, all of these projects have [00:27:00] dependencies. We're, you know, we're basing these off of minimal, uh, minimal images, but they still have some dependencies. When one of those dependencies publishes a CVE we rebuild the entire build chain in order to create, you know, these, these images that have all the fixed CVEs, you know, addressed.

And we keep an SLA on that. We handle all the commercial terms around this. And what makes it really unique and special is that we're partnering with these open source projects and giving them 70%. Of the direct subscription revenue to their project back to the back, to the maintainers. So, deviate timescale, you wanna buy one of these secure build images.

Those people that actually built the project are gonna be the ones benefiting the most from it. And, you know, that's what we think is, is that actually has the opportunity to create a very like, sustainable open source world. One that is focused on [00:28:00] security. But, we will probably talk about it, but I think you had the founder of chain guard on this, on this podcast a couple years back, and they've been, you know, in this market, developing this market for the last two years.

So they have chain guard images, which is what, uh, has really propelled their business to about, I think they're gonna do a hundred million of a RR this year by basically selling secure open source. And so our perspective was. Why not do something very similar, but leverage the open source community as our channel partner so they can share these builds out, and then give that and, uh, use that as an opportunity to give back to the, to those open source projects.

Because we all benefit from the work that they do. And if enterprises are really excited about buying these zero CVE images let's have it benefit both the creators who made these things as well as the, the companies that do the building.

Speaker 4: Okay, so that's [00:29:00] kind of big news. So just, this is my layman's understanding. Basically, as a corporation, I want to use Postgres in my internal, in my enterprise environment. And if I just pull from Docker Hub Postgres 17, God knows what that's gonna be. From a few security angles, but specifically the CVE, it could be just a old version of Ubuntu or whatever in the Docker file.

And so there might be all these CVEs, let alone in the dependency chain, like, you know, SSL and or uh, open SSH, all that kinda stuff. So you guys, I can pull an image from secure build.com, is that right? Secure Build. I can pull an image to secure to build.com. That would be PROGRES 17, but it's secure build one.

And I have basically, I can sleep at night knowing like you guys have scanned this for all the CVEs. It's a minimal build of that image. And it's all like super and you got the SLAs and all the Enterprisey stuff and obviously you guys replicated is pretty good at Enterprise. So it's a lot of [00:30:00] confidence there.

And then to boot. It's the app store model where you're actually giving the majority of the revenue from that back to the open source maintainers themselves. Is it the maintainers or how do you del how get as an open source project do I have to reach out to, uh, secure.build or, sorry, secure build.com and, um, and sign up?

Or are you guys gonna just do this for the whole open source world or how's that gonna work?

Grant: Yeah, so right now you need to become an official partner. Basically if, if you're an open source maintainer and you have a project and you distribute a container. That, you know, it's distributed image. We wanna talk to you. And so just come to secure build.com, sign up. We'd love to, to have a conversation and hopefully make you a partner.

Um, it really, there's not a lot of requirements. We're just asking that, Hey, if you become a partner, you inform your community. You, we also want to get embargo access. So if you ever find like a critical CVE in your, you know, code directly that you're gonna like, tell some of your other distros, like, Hey, there's a, [00:31:00] you know, we're fixing this vulnerability.

You know, make sure that when it's out you have the patch ready. We wanna be included on that list. But that's about it. You know, validate that your release works. Once you have it tell your community about it and keep shipping. Great open source.

Speaker 4: That's pretty cool. Mark, to shift the NERD meter back over to Nerd a little bit. Can you tell us a little bit about the technical challenges and like what's happening underneath the hood?

Speaker: Yeah, I mean, so like Grant mentioned, we're kind of, we had to build the entire, uh, dependency tree, right? Timescale DB is not just like a single go binary that's statically compiled, that has a lot of other dependencies and everything they have to be in, in there at build time and at runtime. So mapping all that out and then building it, we're actually kind of, taking advantage of some of chain guard's open source work that they've done.

They created wolfie as a, as an operating system and Milan as a build tool. So we're using that which is basically a glib C version of a alpine, minimal con, minimal operating system a PK based. So we build them all, host an [00:32:00] A PK repository and then. To create definitions of what these OCI images look like, what Postgres 17, 17.5 16 look like.

'cause we wanna keep the old major versions as long as they're still in, you know, not past end of life. We build them, we generate an SBO m for them, publish that. We scan the image pretty regularly. And also we scan the canonical image, the image that's like, you know, in Postgres, like the docker hub library image for Postgres.

We identify what those canonical images are. We scan it, we scan ours. And you can see the differences between the two. And then when any package gets updated, right? We're not like, we're not going in and saying, oh, there's this vulnerability. We need to go address the code in, open SSL or whatever that is to address the vulnerability.

We're waiting for the, the, that package to get. A new release because it has the vulnerability addressed in it, but recompiling, lib cell or, or open ldap, whatever it is, doesn't do enough for us. And so we have maintained, we know what depends on that, what depends on that, all the way down. And so ultimately [00:33:00] if something, not even a direct dependency, but you know, like multiple layers up the tree get rebuilt.

Postgres 17.5 gets rebuilt in a new SBO m in vault in security scan and everything gets published on the site. So you should be able to pull that version then.

Speaker 4: So I can, so if a CVE is not fixed or something, I, I, I won't be able to get it off of

Speaker: Yeah. That, that'll still have the C So the way it

Speaker 4: is good. It's a good thing, obviously, but yeah,

Speaker: yeah, the way it kind of works in practice is, you know we say it's CVE free, like when A CVE gets disclosed, if there's no fix upstream that CVE is going to be in the image that we're distributing to. But what we can do is have this SLA on once that.

Release. Once the fix for that CVE is published, we can make sure it gets into every image that you're using and like, upstream open source images that are sitting on Docker hub may or may not do that. They all have different SLAs. They might not even know about a

Speaker 4: I don't know if they have SLAs. Actually. I doubt I doubt they have [00:34:00] s.

Speaker: So like, yeah, that's the advantage that we can give.

Speaker 4: I mean that that's a pretty cool product. I really like this app store model where you're trying to kind of help, uh, the open source community, um, monetize these things. 'cause you know, there's a lot of talk these days about with what Hasi did and all that stuff. There's a lot of talk about like, what's the future of open source?

So this seems like it could be a really good, um, a really good way to monetize.

Grant: we, we, we think it's a really powerful, uh, way for these projects to monetize. I mean, obviously, again, chain guard's gonna do a hundred million this year on these, on these images. Dockers getting into it, Wiz is getting into it. There's gonna be a, I think you're gonna see more and more enterprises are really buying this as a solution.

And we think, hey, the, the best people to validate that these images are, are the right ones. And to, keep us in the loop on any, vulnerabilities in their project directly are the maintainers. So let's really, let's partner with them. Let's build that in and. [00:35:00] Then they're, they're the, they're also closest to their community.

So they can, you know, they can share these out. They can make this part of, you know, hey, how, here's how we, we work with our community when they have questions around CVEs. Our position is, uh, is actually that the images that, that these projects publish, you know, on docker hub should sort of be like more developer friendly images, right?

They, those should be kind of fatter images that have, bash maybe they're based off of, you know, a larger os so that you can get in there and like actually kinda like kick the tires a little bit. But then the secure build images should be kind of production ready, production grade. So they should rip out everything else possible and then keep that SLA on removing, removing as many of these CVEs as, as they can instantly.

Um, and the other angle that we think is important to take from like a how do you monetize without changing the license. Is actually inspired by what Linker D [00:36:00] did. So Linker D actually stopped stopped basically producing a stable release. They only produce edge releases. So if you want to use linker D and you wanna use the open source, you're just gonna get an edge release.

And so that's kind of always just like built, you know, almost nightly, but it's kind of like a, a fairly frequent build of linker d whereas, uh, they, they kind of keep they say the vendor ecosystem, which is really buoyant, offers buoyant enterprise linker D and those customers get a stable release and they get some assurances around, security and they get some assurances around, you know, support and things.

And so we are trying to build the platform on which maybe the next linker d says, Hey, instead of, building all this stuff ourselves. We're gonna partner with Secure Build and say, secure Build is actually our secure and stable release. So we're, we're gonna do this with Schema Hero [00:37:00] in a couple weeks, which is Schema Hero is a, a project that we started, that we donated the CNCF.

We're the core maintainers on it. And our intention is to stop creating a stable public release. And instead we are going to say, Hey, if you want the stable release, you want an image for that, it's actually available alongside of our secure build. So you can, you'll be able to go to secure build.com and subscribe to the Schema Hero image, and that'll be 500 bucks a month.

And that's gonna get you the SLA around the around security and the secure and the stability that you're looking for. And we would love to see more open source projects. Take that exact same. Uh, approach because we think it will accrue more of the value upstream to maintainers. And so instead of the cloud providers and, you know, the chain guards of the world who are gonna create their own builds of these [00:38:00] things, we think this is a way to really drive more value to maintainers.

And so, you know, we're putting that out there and, you know, we're gonna lead the way with, with our CNCF project that we know that we're maintainers on. And, you know, we'd hope to talk to other folks that wanna do the same thing. And we, you know, we've already had some really great conversations.

Obviously we, we've only been doing this for a couple of, uh, like a couple months and we already have, you know, in, in stealth and we already have 10 open source projects that are launch partners, right? And so, over 200,000 GitHub stars are represented in those launch partners. So we think we have, we've really found a nerve that is going to drive open source maintainers.

To partner with us and to actually promote these secure builds to their community.

Speaker 5: Okay. That's 

Speaker 4: super interesting. Um, not to what's Schema hero, just outta curiosity. I know what Schema Hero is, but Mark, you wanna tell us what Schema Hero is real quick?

Speaker: I mean, grant mentioned it, it's just an open source project that we created, and it's A-C-N-C-F sandbox project. Now. It's [00:39:00] declarative schema migrations for different databases. So instead of writing, liquid base or flyaway or whatever migration files, you just define the, the way you want your schema to look in the database.

And the schema hero calculates what those migrations should look like on, at deploy time.

Speaker 4: Right. And so this is A-C-N-C-F project, and now I can have a CVE free. I. Um, with confidence copy of it. Excuse me. If I'm using secure build.com, and like you said, there's gonna be 10 other projects that you've already signed up for this. If I am a open source project listening to this, probably on the Cube list side, not the enterprise ready side.

How do I sign up? How do I sign up for this? Just secure build.com.

Grant: Yeah, SCR bill.com. Click partner and you know, fill out a little form and, and we'll get in touch. You'll probably talk to me and Mark and we will, figure out how we can, you know, may maybe we already have a build of your project coming. I mean, you know, we're able to leverage most of the, the Wolfie Os.

Library, which has about a thousand different images in it. So, you know, we're starting to kind of build that entire catalog and we should have that out [00:40:00] soon. But we'd love to get the community really involved and, and make sure that maintainers who wanna get paid, get paid.

Speaker 4: Okay. That's super cool. Um, mark, can we maybe talk about what Wolfie is in a little nerd for like 45 seconds? Because I know that's a

Speaker: can try. Let's do it. I mean, so yeah, Wolfie Wolfie is, uh, an operating system chain guard released. Um, and like that's the core of their base images. One of the challenges with Alpine, right? A lot of us went to Alpine container images because they were small and minimal. Um, and then you had to adopt a whole bunch of different tooling, like a PK, as a repository instead of Apt or Yum.

But one of the biggest challenges with Alpine is that it's not gypsy based, which meant that like you have to recompile special versions of your application to make them work in Alpine. And generally speaking, most, like, most go apps would work, but like not every app was really trivial to be able to do.

And so they basically chenga created this uh, as a separate project, um, that they're built that they based a lot of their stuff on too. Uh, and it's a glib [00:41:00] c. Minimal operating system. That's a, that uses a PK as a package manager.

Speaker 5: So this is 

Speaker 4: a way to like handle the, the builds for all these other

Speaker: Yeah. Melange is like a tool that they, that they've open sourced, that's like the building tool. You're not gonna run this on your desktop or anything like this. It's definitely meant to run in, kind of like these shell list containers running in your production environment. It's definitely hardened and meant to be that way.

But it's, it's basically just a minimal version of, of Linux that is compatible with most builds. Like we've gone through the process of onboarding some folks into Secure Build that didn't have a wolfy compatible version of their, their package build. And it was pretty straightforward. If you have a make file, then you can build on Linux.

It's probably likely to work and like, it works on Arm and X 86

Speaker 4: Yeah, I was gonna ask, um, is there, so I can have Armand XA six images with secure build?

Speaker: Most, most of the images as long as the application supports it. And right now the ones that we have in the [00:42:00] launch partner do. But like they, they're, they're multi architecture images across the board.

Speaker 4: Is this really a, is secure build really something for me as a local developer? I. Or as like a local dev or not as much. It's more for like the enterprise

Speaker: Yeah. It's more for like the enterprises. I think, you know, like one of the other advantages, you know, we talk about Schema Hero as, as an example, you know, shipping this CVE free version. And obviously the advantages there that we, you know, are I, as a developer, an open source maintainer or schema hero, I don't need to worry about maintaining and, you know, responding to CVEs and having this minimal version.

But it also lets me really stop kind, trying to balance between minimal, but like a nice developer, you know, like I wanna, I'm a developer, I wanna learn schema here and pull the image, but it's like, I wish it had curl and GI and bash and everything in it. And so you end up kind of. Being a little bit in one foot in both sides of a, you know, a developer friendly container that you can use to debug stuff, but also a minimal one.

So this actually just splits that and says, look, pull the developer friendly, fatter container image down [00:43:00] to your local dev environment when you're learning, when you're onboarding with the tool, when you wanna debug something. But one of the things that we worked really, really hard on is trying to make sure that the secure build images are drop-in replacements.

Like we've done stuff to, like, we've wrote a lot of tooling to make sure the entry point in the default ARGs and everything like this in these images work the same as the canonical one does. So if it works locally, obviously, you know, test everything, but if it works locally, you should have high confidence.

It's gonna also swap that out with a secure build image. And it's also gonna work.

Speaker 4: How did you, what the tooling underneath that? I, I think I know the answer, but how, how are you doing all these concurrent builds and, and doing all that stuff?

Speaker: So one part of Replicated Grant mentioned it earlier that we built is this thing called compatibility matrix, which allows you to spin up ephemeral VMs and Kubernetes clusters really, really quickly to test your application prior to shipping. So we had all this essentially like a hypervisor that could create X 86 and arm builds, uh, or VMs on the fly using firecracker.

And so we just leverage that. And so whenever we're trying to run [00:44:00] a new build or build, you know, a whole part of the tree over again because the dependency high up was fixed we just spin up a whole bunch of firecracker VMs on our own compatibility matrix, which is in a very lockdown and kind of tight controlled environment that we've, this is a GA product that replicate it's had for a while.

And we're able to use that to actually run all these builds. We're not like reusing any of the infrastructure or anything. Every time we build a piece of software on a on one architecture, one version, um, it's a brand new VM and it gets thrown away afterwards. You muted.

Speaker 5: So it's a fresh 

Speaker 4: firecracker, if you will.

Speaker: Yeah, exactly.

Speaker 4: So I mean, I think that that's kind of interesting. Obviously I, I've been a cohost with you for a while and I, I have. I'm a replicated fan. So I know a little bit about this, but I think it's really cool that some of the, that grid product you're talking about, which obviously you use for your, maybe not obviously, but to me it's obvious for your customers to test these different [00:45:00] adverse environments to install their application on.

You're now repurposing that for these, for this build, for this secure build product, right?

Speaker: Yep. That's exactly it. And I, I think, you know, we're able to create the VMs on the fly. We're able to, you know, we, we will get to the place where we're actually like using some of that same. Our, like our core product is evolving to start doing some hardened, you know, STIG and different types of testing on these, and we're gonna like, when that's available, we'll apply it into Secure build also so that we can test the images in all those different environments.

We'll, like it is not, it is something that we intend to keep pace with. Replicated as replicated introduces support for something new. We will make sure the secure build also has support for that.

Speaker 4: So this is a first class product launch that we're talking about here.

Grant: This is, uh, this is a really big investment for us. For a couple of reasons, right? I think. One, we talked about the commercial software distribution lifecycle, and what we have seen is that our customers, right? So ISVs and open [00:46:00] core companies are often required to address all these CPEs in order to deliver into secure environments.

So if you're delivering into, FedRAMP environments or into you know, large banks they're gonna scan your images and they're gonna push back on, on CVEs. And so by being able to, build and, and deliver dependencies that actually have those addressed, it's just a, a core need for our customer base.

I think that's what makes part of this so compelling for us is, you know, Mark's talked about some of the technology, that's just one of the components, right? We also have all this registry code. That, and, and that we've been running it replicated that gives, you know, separates out what. Images and, and helm charts can get delivered to different customers, you know, on different timelines with expiration and delivering different entitlements.

And so we've had that for that cortex for a while. Combine that with compatibility matrix, combine that with our, you know, ideal customer profile being [00:47:00] one that both needs to be able to ship zero CVE software because it's just required by their customers. But also, almost half of our customers are replicated, are already open source and open core companies, right?

So they've been, they have products out in the open source community that people are downloading and running. And so we think we'll be able to partner with them. We think we'll be able to help them ship zero CVE, commercial products and then and then expand our reach to these open source projects who maybe, aren't really monetizing very well today.

And. This is gonna be kind of a turnkey enterprise offering that they're gonna be able to offer that, kind of on the low end, right? At maybe like a thousand bucks a month. But it should be something that has pretty broad appeal and, you know, click through terms that, that their customers can just buy with.

And there's no support contracts, something else required. You know, we already have some of our of our partners who are asking to say, Hey, we want to have an [00:48:00] add-on to put our support contract on this, right? So it may be our image is 500 bucks a month, but you can buy support for another thousand. Or you can buy some private images for another, you know, thousand on top of that.

And you can get the enterprise package all the way through this. So we're really excited about, you know, what we're gonna be able to do with this. You know, I think the foundation of security and reliability together is, is where replicated, you know, is really gonna shine here. And I'm, uh, I think it's just such a, such a, an obvious area for us to enter into.

You know, we, we ra we will get into the story a little bit later. We've raised a lot of money and, you know, I think this is a really important area for us to invest that in.

Speaker 4: Sounds great. So yeah, I mean, let's talk about the rest. I mean, I've been excited to get replicated on here for a long time. So, uh, you, you, you just brought it up. You talk about raising money and kind of the story of replicated as a business. Um, uh, I don't know, do you have any learnings, any lessons?

I, I'm sure you have a [00:49:00] thousand, but like anything interesting that has happened in the last, let's say two years that have changed a lot of things for you guys.

Grant: Yeah, we'll, we'll get into a lot of them and may might go back a little longer than two years. But maybe we not, not back to the, you know, to my birth. We'll stick it to the last, you know, maybe since 2021. In 21 we raised, um, a series C of $50 million. This is on the heels of a, of a series B in 2020.

And so I think within. From 2020, like kind of, we raised the series B maybe like, call that August or, or September of 2020 until like the, basically the end of 21. We went from about 20 something people to 135. So rapid growth, rapid, rapid growth, raised tons of money. We're scaling it up. The business was growing really well.

We were doubling year over year. Um, but we made a [00:50:00] couple of mistakes. Number one, we let our go-to market team just hire way outta sync with our engineering team. We were really packing on the people in go-to market. So we had 80 folks in go-to market and only 50, four in the rest of the company.

And you know, we had kind of said we were gonna scale that way in order to like, add capacity, so that this is a concept that like when you're hiring sellers. And marketing people, it's all about how much capacity and throughput do you have as an organization. It sort of assumes that you have like an unlimited amount of market and opportunity.

And we just didn't. So what we had built in cots and curl and troubleshoot, like we launched this, you know, in, at the end of 19, it really had what we thought was product market fit, what I think turned out to be a little bit more like message market fit. Um, and even then that message eventually started to really like, not land as well, but what we were selling was, distribute your Kubernetes application [00:51:00] into customers of, of all different types, uh, meet all, meet your customer where they are.

You know, and then we were using, you know, huge amounts of cash in order to, to get new customers. And so, uh, it was a very inefficient business. And while we were scaling up the business, I think the underlying market changed and we went from. Some, something that was like, packaging could be, it could be customized, it could be just give, operators to, everything became Helm charts.

And so, uh, helm really won out and we, and our product just wasn't like that great with Helm. Like you could put a helm chart in, but we would still deploy it with our tooling. Kind of like, almost like an Argo kind of deployment where it didn't support all of the different helm, functionality hooks and all these kind of things.

And so, uh, and it, it added more complexity and didn't solve enough problems. So that was and, but I think the free money of 2021, that era where customers were just buying and everything was working, [00:52:00] um, as that kind of got the brake slammed on it at the start of 22, we realized that the product.

The customers weren't getting that successful. We'd oversold many of our customers, both in terms of how much they were contractually obligated to pay us versus the value that we were providing. As well as, you know, how we were telling everyone this was the easy button for on-prem software, and unfortunately there just isn't an easy button for self-hosted on-prem software.

It's a very hard problem. And so we had to reset expectations. We didn't have much data around who was using what. So we had to get the data. We were obviously bloated from a company perspective, so we had to let you know, we basically get down to about 35 people, I think at our low, and today we're around 42.

Um, but you know, we had to let a ton of people go. We, turned over most of our exec team, right? We just, we went through all the challenges that you go through when you're trying [00:53:00] to, steer the ship a different direction and change everything dramatically. 

Speaker 4: This on an episode of Silicon Valley. I'm pretty sure. I think I

Grant: Yeah, it's, it's, it's, uh, you know, it's pretty close.

Speaker 4: Are you? Yeah. Are you, are you quoting a TV show or are you actually telling me what happened? I replicated,

Grant: This is, this is very much. Yeah. This is, I think maybe in the, like, the follow up to what happened in Silicon Valley when, you know, Richard's complaining, you're kind of telling the camera, oh here's how, how everything went wrong. A lot of stuff went wrong. 

Speaker 4: Sorry. I should have said spoiler alert before I made that joke. So I mean, like I, we've seen, I've seen it personally funded company, shipyard, you know, you, uh, but other friends also, just like the board's, like hire sales, hire marketing. It's go, gas, gas, gas. And you're like.

Then you wake up and you have, you said 135 employees

and then you're like, that's not gonna work. And then cut to now you're it sounds like you guys are getting rights. You feel, obviously you don't, the whole point is that we don't know hindsight 2020. But it feels like from just knowing you for years [00:54:00] and just talking to you, it feels like you guys feel like you're kind of right sized and you're kind of starting to focus on, on a lot of the, the product that, that folks want and need.

And like you said, the challenge around you know, a magic button for something that there's just no magic button for. Sam Altman will give us a magic button for it, like in six months, but for right now, there's no magic button for on-prem software. Um, it sounds like you guys have learned a lot from that.

Grant: Yeah. I think it's it's been one, it's been one of the more challenging experiences. I, I, I look at where we were. I mean, I'm actually much happier now than I was when I was running the 135 person company. At that point, I felt like I had lost control of the company. It was, you know, things were a little bit weird back in 21.

A lot of people were kind of focused on workplace activism. And so that was a really important topic and people wanted to get work at a place that really believed all their same social you know, beliefs. And those are conflicting and not everyone believes the same things. And so it just, it was a difficult [00:55:00] company to run and ultimately we just weren't creating enough value for customers.

And so that's what we came back to. We got the data, we understood what was happening with customers. A third of our customers weren't really using our product. We'd oversold too many of them. We kind of made a commitment to like, not just like fire everybody, every customer and start from scratch.

We're like, we're gonna figure this out. We're gonna try to make the transition happen and we're gonna build things that, that really make this process better so that our, that our customers can offer world-class customer you know, self hosted software. And so, you know, we've, that's things like the distribution lifecycle was, that was a, that was the vision.

Hey, we need to deliver on this. So we introduced compatibility matrix testing in order to, to, if you get your testing right, you can move on to the next phase. Right? So then it was, we need to be able to, you know, to do reporting. So we introduced a lot of reporting tooling and an SDK to distribute your helm chart.

And actually just a couple weeks ago we launched this new enterprise portal, which is a fully [00:56:00] white labeled, end customer experience for doing installs and updates and getting support bundles and, and seeing all the security artifacts that you package with your application. So it's all these things kind of, have become a very complimentary, there's a lot of, you know, really good kind of overlap between what we're doing.

You know, we're making our customers much more successful. You know, we have. Not because they're growing, but because we're actually creating products that really help them to help them deliver this way. You know, I, I think the future looks, looks much better at replicated. But it was a real challenge for a long time there.

You know, and we were, I think at our peak we were burning almost two and a half million a month, you know, and so that's just unsustainable. You know, even you raised $85 million, you can't do that for very long. But at that point we thought, oh, we're gonna raise a hundred million after this. So, you know, we cut the burn down dramatically.

We got near break even. We tried to figure out what we're gonna do next. And now the key thing is investing in secure bill and investing in the core products are [00:57:00] replicated and helping, software vendors deliver amazing self-hosted software and, you know, focusing on the supply chain security side.

'cause ultimately replicated is a core part of the supply chain security for a lot of commercial software. And

Speaker 4: Yeah. What's the stat you guys have on your site? How many Fortune a hundred

Grant: Yeah, it's generally around like 60, 70%, you know, of, of the Fortune 100, uh, you know, are deploying applications that are delivered through Replicated.

Speaker 4: I always think that that stat's super impressive. Also, 'cause I can do the math on the, for I, that's 60 or 70 companies that are using it. So I, I appreciate the ease of math there.

Grant: yeah. You're, you're, you're welcome. Yeah, exactly. It's 

Speaker 4: thank you, thank you for making me feel so smart on your homepage. Okay, cool. I mean, I, I really feel like you guys have been through it and you're, and I'm excited about the secure build.

I'm also excited about the other stuff. I personally am waiting, I want to use your, your grid product personally. For Shipyard, but I, I, I, I have my, I have plans around that at some point, so I, I really [00:58:00] like where you're going with all that stuff. Is there any, anything else that we haven't covered from the replicated story side that you want to touch on?

I feel like we hit most of it, but in

Grant: I mean, there's, there's the other part that I think, you know, you mentioned it earlier, but I think it's just foundational in this day and age is ai, right? And I think we actually have a pretty interesting story around this because, you know, we were adopting copilot, mark was very early to all these tools, right?

What was the next one? Super Maven Mark, right?

Speaker: Yeah. And a little bit of, you know, cursor here and there, but like, we were just like, you know, I think. As an engineer, if it's effective for you, if it's useful, use it. And we'd see kind of like, you know, various adoption across the org. And then I, like, I, I think we realized that there, there's a lot of different things that kind of came together.

One was when you really, really dig into these tools and you start really using you know, cursor really well, not just like using it, it's, it's auto [00:59:00] complete's really good, but when you actually start using it better. But then you also start using tools like Bolt and V Zero to like to do some product discovery and mockups.

And instead of sending kind of really bad and hard to understand wire frames internally, you're actually sending clickable product demos that you can actually share with a customer and get feedback before we build them. And then we adopted Devon and have Devvin doing a lot of background tasks on, on, on various parts of the, of, of the stack and eventually.

You know, a few months ago we, we just pulled the entire engineering team together. And actually it was a little bit more than the engineering team. We pulled in product managers, we pulled in some other folks and just did like a, an ai week where we're like, everything we do this week is gonna be written with ai.

Everybody's gonna get really good at using these tools, figure out where it's good, where it's bad, how to use them, get a kind of, give you an opportunity to, to force you to take a pause and learn how to use these tools to do the job that you're actually trying to do. And I think since then, we've had, you know, a lot of usage, a lot of adoption of 'em.

And I think [01:00:00] we are, we're at a point now, look, it's not like a hundred percent of the code written that replicated as being generated by ai, ai but every developer has all of access to all the tools and is getting pretty effective at using them and using different models. Like last week, I think there was a huge Google Cloud outage which brought down.

You know, anthropic and, and in Gemini at the time. And it was noticeable because everybody was like, wait, I gotta figure how to write code by hand again. Like, you just, you realize how much you're relying on these things and how much more efficient you are as an engineer.

Speaker 5: So, okay. 

Speaker 4: Actually, just to, again, nerd a little here on the cursor front. What is the right way to use cursor? I've heard a lot of things these days is so YOLO mode. You still don't mess with YOLO mode, do you or

Speaker: No, everybody's in agent mode. Right. You like first

Speaker 4: mode, but agent mode. Is that correct?

Speaker: agent mode, uh, I don't know

Speaker 4: Is that the same thing now? Maybe it's

Speaker: think it is. Yeah. And it's like the default now too, but 

Grant: we don't, we don't allow it to RMRF. Anything though, you know, we keep a couple of

Speaker 4: Yeah. But I think it, like it's, it's, [01:01:00] I've heard stories of it, like committing stuff and then, uh, pipelines like 

Grant: We, we, we haven't seen anything too crazy. I, you know, our position is you have to lean into as many of these tools. Ultimately, I think Mark told the story, but like I. He was just on the cutting edge of all these AI tools as they were emerging, right? And it was about, I dunno, almost a year ago when like, they just started to all really click and it was, it was clear that it was like, okay, this stuff is working.

We need to use it more. Um, super Maven got acquired by Cursor, so like, you know, we were like forced in using Cursor, but it was, you know, it was fine. Super Maven, it was was quite good too. And I started using it. So this is Benji. I think you'll, you'll really love this, right? Like I started, I, you know, a year ago this time I would prototype from a product perspective and I would use Google Slides and I would draw a little boxes and I would, you know, create each page as a new slide.

And that's how I would communicate the vision of what I wanted this to build. And then about, I don't know, six to nine months ago, I got my hands on bolt [01:02:00] and I said, you know what, instead of a, a. Instead of using a Google slide, I'm gonna describe what I wanna do here in Bolt. So I had it build a single page, and then I had to build a couple pages from that page.

And then eventually I basically ended up with like, I'll call it like an ai, like digital mock of my entire replicated, you know, application, right? Or, and except this version had all the new features and things that I wanted to build already prototyped into the ui. So using mock data, you know, as the backend, right?

Instead of like, doing front end, back end. I was basically just doing a, a front end mock with mock data files and being able to prototype that way. And to Mark's point, give, giving your team something that they can see. So they, when you tell 'em you're gonna build this amazing, you know, experience now they can see it, they can understand it, you can communicate it so much better.

Then you take it to customers and you have seven features or nine features [01:03:00] in this thing, and you, what you key in on, you know, I show this to 20 customers, what are the three features that everybody lights up on? So now all of a sudden I'm really using this inspired methodology where I'm prototyping, I'm showing stuff to customers, I'm getting the team on board, and now we're building.

And 

Speaker 4: so what you're telling me is that Grant is now a vibe coder.

Speaker: Well, it's like, think of it this way, like, it's like it's prototyping, sharing with customers, but it's more than that. It's not like, oh, well yeah, this prototype really worked. Give it to an engineer and they gotta go zero to one on it. No, because it turns out Bolt is writing React components, right?

And it like, sure has mock data and it's not, we're not deploying that code into our production environment. But I, I know like for Secure Build, you know, and I've done this on other projects where I've worked with Grant too, you know, where I'll just, I'll download that from there and I have the zip file, I'll drag it into Cursor and I'm like, okay, here's a bunch of React components.

Modify them to fit the, the, the, the shape of this project. Remove the mock data call in the server actions or the APIs or whatever it is that we actually have and so yeah, it works really, really good.

Speaker 4: So [01:04:00] basically, really the, the product development side of. I mean, I just, you know, I'm always scared of Grant touching too many things 'cause you know, I'm scared of him. But, but it sounds like, it sounds like Grant, I mean, I, it makes perfect sense to me. Honestly, grant was always slightly too dangerous with knowing stuff.

Um, and so now he actually has these tools are actually enabling him to bridge the gap. And so you're not like designing something in Google Slides, then getting someone to do in Figma and then like someone to like do some react. That's not right. Like, you're skipping like seven steps and getting straight to product.

Grant: right and.

Speaker 4: and the iteration cycles, that's the, that's huge 

Speaker: it's so much faster. It's created an interesting challenge where you're constantly blocked on code review, though I feel like code review becomes a huge bottleneck because like we can just produce code so much faster and folks who weren't producing code before were, but you know, we still want code review, you know, a second set of human eyes on everything.

Sure, we use some [01:05:00] AI tools to assist with code review, but it's not okay just to, for grant to like, vibe, code some code, send it to an AI code reviewer, and then deploy it to prod. We're not doing that. Anybody's doing

Grant: And so, and let me, let me tell you what the routes of the story, Benji. So, I was using Bolt initially and I was creating all these mocks and I realized I had mocked up a bunch of things, but now I needed it to get built. And so I told Mark, I said, look, I want the development environments.

I wanna start to use these. And so I got the development environments and I made some, I made some changes to our internal admin tool, right? Just some front end changes some react stuff. I said, okay, I got the workflow pretty good. Let me make a change to the front end of our like core, you know, web app, the vendor portal.

And I made some of those changes. Again, code review by the team, got some feedback, made some adjustments, got that process going. And there was about a two or three month period where I became one of our most prolific developers. And I did this for a couple reasons, right? I wanted to be able to, to [01:06:00] understand the process of what it's like to work at replicated as an engineer.

I taught myself how to program 15 years ago. I'm, I was a shitty engineer, right? I taught myself PhD, HP, and some sql. And I was just enough to prototype things, but I, you know, I'd never contributed a line of production code to replicated until three months ago. And so with the help of Cursor and Windsurf and these tools and having our development environments, you know, running, I was able to say, okay, I've got the dev environment.

I. I can, I know what I want the product experience to feel like, and I want it to do so I can read the code that comes through and understand what's happening, but I just couldn't author that code by hand and create that syntax. But I can read it all. I read everything I write. So it's, you know, there's, I think the difference between a vibe coder and, you know, maybe someone who's like an AI assisted programmer is I'm reading all the code and when I see something that looks off, which I have caught many things that are off right that, you know, there's some funny, some funny stories in there.

But I'm reading it all and I, it, I had so many interesting [01:07:00] insights as a CEO who was programming the first of which was our schedules were all off because we were allowing the managers to set the meetings. Ics who are are, are engineers. Their job is not to show up to meetings. That's not why I pay them.

I pay our engineers to develop great products and to ship things that customers are gonna love. And if, if that means you don't show up to a meeting because you're in flow and you're trying to get something done, that's totally fine. So I had to change our, our engineering culture to allow that to happen and say we, we canceled all of our weekly meetings.

We said are, we're no longer gonna have any weekly meetings. Our, we, our meetings are at most every other week to increase the amount of focus time our engineers get. I said, if you're the way that I kind of realized that like I work and a lot in Mark works and a lot of our best engineers work is that they have this mentality that I call get it done today, right?

Which means you wake up in the morning, you open up your development environment, your editor, and you look at and you say, what do I want to [01:08:00] get done today? And you've chunked something pretty big that you're gonna try to do. And you start and you get it done and you ship a PR by the end of your day.

And maybe, you know, you get a bunch done before dinner. You go have dinner, you come back and you do a little bit more. The next day is all about getting that, that that PR into production and you're working with other folks, you're reviewing their prs, you're doing that work, but now you get that, that new PR into production and the next day is another get it done today day.

So you get to tackle maybe three major things every week if you work this way. And so, but you had to change. We had to change how, how we work to make it in order to make that possible. Because, you know, if you have a, a one-on-one or a team meeting in the middle of that workflow, that just doesn't work.

So we need to make sure that we structure our calendars around giving our, our engineers, our core engineers the most productive time possible. And I wouldn't have understood that had I not been, working as an engineer [01:09:00] on this team for a couple months.

Speaker 4: I refuse to call you an engineer, but that is an inspiring story

Grant: It's, uh, I mean, you can, you can call me whatever you want, but I'm, I, that's what I, you look at my cursor usage, you look at my commits, you look at my prs, and again, I had, we have an amazing team that was reviewing every PR that was giving me feedback. And so it wasn't like

Speaker 4: you learned a lot from this, obviously

Grant: learned a ton. I was building go handlers, I was doing the whole thing.

So I was doing backend and front end by the end of all this, right? I could do anything that, you know, like, again, I'm not gonna do what Mark built with this, you know, this secure build factory and all of the dependency graph mapping and everything else, but to build a standard web application to, you know, to use, to build a migration in Schema Hero, to add a new table, to add some new columns, whatever else I could do that, without a problem, you know, to add some ghost services, you know, to handle whatever we're doing, not no big deal.

That's a world away from where I was before [01:10:00] the nerd Here, I'll, I'll, I'll bring it to a little bit Nerdier. So I was reading a lot of fantasy at the time, epic Fantasy. So I was reading, uh, I had just finished Name of the Wind and I was reading some Brandon Sanderson, miss Born. And if you haven't read Miss Born, one of the things that happens in this book is one of the main characters does not is not able to do like the magic that the rest, you know, the main characters can do.

He's not mis born and at some point he becomes mis born. And so I felt like I had been in this world where I couldn't actually do the magic system that, you know, mark and all of our engineers could do. So like this, the programming as magic and all of a sudden I was code born. I was able to write, you know, great code that could get into production and build things and really create something magical for our customers.

And, and, and that was this kind of interesting parallel that I was able to draw. Because of what these AI tools, the powers they've given me.

Speaker 4: Uh, do you have a name for that?

Grant: [01:11:00] Yeah. I, I called it code born.

Speaker 4: You call it code Born. So you so Grant is code born? No. I mean, I think that. Putting on my enterprise ready hat for a second. I think that for anybody, especially in the C-suite side here as someone that straddles the engineering and CEO stuff myself the more you get hands on in this world and this ecosystem, the more you're gonna understand what you should be doing.

And it pains me to say how great a job, it sounds like Grant's doing over there. Um, and understanding that and getting rid of these meetings, stuff like that, that's right where it's at. I think that at Shipyard we use these tools as well. I'm really playing with Cloud Code right now, personally, that's my thing.

I don't know. Mark, have you played with Cloud Code yet?

Speaker: a lot. Yeah, for sure. That's a, it's pretty popular on the team too.

Speaker 4: Yeah. I I, I don't know. It, it being A-C-L-I-I think is kind of cool. Anyways, uh, the, the point is, is that, uh, the point is, is that replicated or, or Grant being the CEO of replicated and actually, I. For frankly, knowing what a [01:12:00] go module is is pretty impressive to get there and to do that stuff.

So is, do you have any num and, and we gotta wrap up here, but do you have any like raw numbers on productivity results since you started changing this fewer meetings to stuff or every other week meeting thing and the get it done today mentality that you were talking about?

Grant: It's, it's so hard to really measure engineering productivity, right? It's in, I think we look at prs, look at things. I mean, I think it's about, I think there's a feeling which is like, are we shipping stuff that our customers really appreciate? NPS has moved up a couple of points, right? I think it's up four or five points, which I think is a good indicator of like, we're building the right things.

Um. I think there's a lot of other I think overall team, the team feels happier. I, mark and I always say engineers wanna be on teams that ship great software. They want to be moving things forward. They don't want to be, constantly just fighting fires and constantly just in meetings.

They want to build stuff. That's what, and you [01:13:00] wanna get cu you wanna build stuff that customers use. And so that's what we're doing. And yeah, we've, you, you have to make a lot of changes. We made every, and Mark mentioned earlier, we made all of our PMs, all of our ems, they all got on these tools. They all made prs.

Because I think I, I always liken it, if you're an EM and you're not doing development daily, but your team you're basically and you haven't programmed in 10 years, this is like, you know, the, you were building. Carriage and now forward has rolled out the Model T and he's got the assembly line, and you need to go figure out how this new process works and what's new stuff that's being built.

And so, you know, I, I think every engineering manager, every product manager has to get so deep into these tools in order to stay relevant in this new world. And so, I put some other CEO eing things on hold in order to do that. In, in order to get really deep in, in all this and kind of understand what the opportunities were and what the challenges were, I.

Speaker: [01:14:00] And to be clear, it's not always just about like, oh, we can move faster. There's a lot of stuff that might not be the top priority. Like I, I'll give an example. We ship a CLI and over the years as we built it, it's become a little bit inconsistent with the way the flags work. Probably pretty common, right?

Um, never high enough of a priority to go do. It's a little annoyance and it introduces a little more friction when somebody's signing up and

Speaker 4: Dash H. Or Dash or dash help,

Speaker: Yeah, like this flag, that flag. There's like inconsistent. And you know, what we're able to do though is just describe that problem to Devin.

Come back in an hour or two and have a PR that's backwards compatible that fixes that. So we're able to like put the polish on stuff that we weren't able to really do before. Pay attention to some of the details that, maybe we were in a hurry to get the first version out and then we didn't come back and like make that modal look a little better.

Or that UI or that CLI work a little better and able just to like, anybody can do that now. And we don't have to go say, Hey, that's what we're gonna do for this sprint and not gonna ship any functionality. We're gonna go clean that up. Which we probably [01:15:00] should have done, but you know, now we're able to 

Speaker 4: time is time is of the essence in this environment. No, that's, so those are just some pretty good insights I think. Have you guys done any code refactoring with it or Not yet?

Speaker: yeah.

Speaker 4: Like big swaths of code refactoring.

Speaker: Yeah, we kind of like, we'll even like, talk through it. Like one of the things that I'll do is I'll just chat PT on voice mode put some headphones in and walk around, like describing the architecture that we have right now and like having it come up with better ideas for it and then dropping it into a markdown doc or a canvas in chat, pt, feeding that into cloud code and having it come up with a work plan to be able to go implement it all.

Speaker 4: Super cool. Yeah, I, I wanna hear more about all this workflow, but I think we're out of time. So the big thing in my mind, my big takeaway is secure bill.com. When is that official, when is that coming out?

Grant: It'll be live when this podcast is going out. Hopefully this podcast will go out the same day that we launch. Uh, you'll be able also be able to wa watch all of our fun AI generated [01:16:00] ads that I've created about 15 different AI ads with VO three to, to kind of talk all about what Secure Bill does.

They are quite irreverent, a little bit unhinged. Hopefully they don't offend everyone too much. Hope you can be offended a little

Speaker 4: Is Cube List is taking a big step back from endorsing those videos on any level. Secure build. Very proud to, to, to promote, but I don't trust a grant video, an AI generated grant video.

Grant: but if you do get, if you do, if you are offended, just let me know on Twitter. Just tell me how terrible I am. I'd, I'd like to know. It's totally fine. Just, just tell me, hit me on LinkedIn. 

Speaker 4: At Elon Musk, right? Is

Grant: I'm just at Grant m. Do not send me an email. I don't wanna know privately, I wanna know publicly. I think it's important to get public recognition for what I've done wrong.

So if you really hate these commercials, uh, let me know in the comments. And in, in and on Twitter.

Speaker 4: Grant can take the heat. Also think that AI stuff we talked about is super cool, but I, I feel like the big takeaway is [01:17:00] secure build.com, uh, the journey of replicated. And, uh, I have a feeling in a few years we're gonna come back and do another one of these follow-ups, see how replicated it's doing. Thanks for letting me moderate and talk through this stuff.

Um, again, been a big fan of replicated for years and love seeing what you guys do and, and learning and, and all the, the various things that you guys have taught me personally. Um, and now you're sharing with everybody. So it it, thanks for coming on and doing this guys, and, uh, yeah, good luck with Secure Build.

I look forward to seeing how that goes.

Grant: Yeah. Benji, thanks for having us. And I'm gonna for those Enterprise ready listeners on the YouTube channel, I'm gonna roll a clip or one of the commercials for you right now. Here we go. 

[01:18:00] 

​