Modern SAS products are increasingly delivered via the cloud, rather than as downloadable executable programs. However, many potential users of these SAS products may need that software deployed on-prem in a private network. Organizations have a wide variety of reasons for preferring on-prem software, such as security, integration with private tools, and compliance with regulations. The cost of setting up a bespoke on-prem version of a SAS offering was often prohibitive for both the vendor and the potential users.
Replicated leverages the portability of containers to help SAS vendors ship an on-prem or multi-prem version of their software. Replicated gives SAS vendors a suite of ready-made components to help install and manage an instance of their software on-prem. Replicated has seen a lot of growth in its six-year lifespan, today 50 of the Fortune 100 companies manage apps with Replicated. Grant Miller is the founder and CEO of Replicated.
Replicated recently closed a Series B fundraising round to help scale their work in the cloud native space, including the launch of their Kubernetes off-the-shelf platform. Grant returns the show today to talk about the next generation of tools on the replicated platform, how Kubernetes is changing enterprise IT, and why the on-prem software market is not going away anytime soon. Grant, welcome back to the show. Thanks so much for having you.
I really appreciate it. We've talked before a bit about Replicated and multi-prem environments, but let's just revisit the problem statement that you're tackling, which is packaging and deploying applications to multiple environments, to the cloud or to on-prem. Why is that difficult? Yeah, that's a good question.
Ultimately, what Replicated is really focused on is sort of an even more nuanced version of that, which is funny. We're focused on enabling software vendors. These are ISVs, so folks that have been packaging applications as JARS, and OVA's for the last five, ten, twenty years, but also modern SaaS companies to take their applications, package them up, and deliver them into a whole variety of different end customer environments. These are complex enterprise environments where an IT organization at some big bank will run one of these applications privately.
Oftentimes, this has been called on-prem software, but we think about it today more like multi-prem, because it's not just data centers and server closets where these applications are running, but instead, many of these applications are being installed into an enterprise, who's an end customer, into their own cloud environment that might be in AWS, but it's a VPC, so it's a virtual private cloud that's secured within their own AWS account, but it's out of the control of the vendor. So this idea of third-party software is just complex, and it's more complex than first-party software development. Most of the software development lifecycle, the SDLC, the sort of way that your audience will think about writing, building, testing, deploying, monitoring, managing code, most of the tooling around that is focused on first-party application development and delivery. And so where replicated really takes a unique and more complicated angle, is saying, well, this is for third-party application delivery and management, and doing that with lots of different vendors, lots of different enterprises gives you a very complex matrices of applications that need to run in different environments with different requirements, and supporting that, the challenging part is as an ISV or as a SaaS company that's approaching doing an on-prem distribution, it's a pretty daunting challenge, right?
For most ISVs, what's happening today is that they're moving away from these more traditional packaging methods of delivering a binary and 127-page install guide, and now they're delivering more robust, fully orchestrated Kubernetes applications. And so they're sort of starting at square one in terms of how do I deliver a Kubernetes application, which is in itself a complex application, into a variety of different environments. And so that's really the problem that replicated the solving, you know, we've built a bunch of open source tools around that. You know, since we last spoke, I think Mark, my co-founder and I were on your podcast about a year ago, and lots happened in that time, right?
The company has, we've raised $25 million as part of our Series B, we've added incredible customers like Puppet and UiPath and Tripwire and many others that aren't public yet, and these companies are all facing the same challenge, which is they have a modern Kubernetes application that they need to deliver into a customer environment, and they know that they can build their own tooling to solve this, but they can't build everything. And so they come to replicated, looking for the best practices and sort of the tools to help them get there faster. As the number of customers that you work with has increased the number of different software vendors that need to have an on-prem option of their software, what have you had to change about the replicated software suite? What have you had to change?
What else have you had to build out to allow these companies to have an on-prem deployment option? Yeah, you know, we've been around for six years. And so throughout that time, this ecosystem has really evolved. And you've talked a lot about the container wars in the very beginning, but ultimately, you know, what's happened in the last three years is Kubernetes has become the de facto solution for how most modern organizations are going to develop and deliver a cloud native version of their application.
And so we've had to really embrace Kubernetes, which we've done, we've had to really focus on making sure that these installations are easy to run for a whole variety of end customers, right? If you're a software vendor and you're delivering to, you know, 100 different enterprises, you basically have 100 different end customers or operations teams who are trying to deploy your application, and they have all a whole variety of different experiences with Kubernetes. Some are really Kubernetes savvy and some are much less so. And so replicated provides sort of the foundation to deploy the customers who are not super Kubernetes friendly.
They just wanted to deploy, you know, what we call multi-node software appliance. They don't even really have to know its Kubernetes in the hood. So they can install that on a VM or on a bare metal. They could scale it out to multiple nodes.
It sort of makes it easy to do that. Or we can help you deliver into the most advanced customer who has a fully, you know, GitOps pipeline for deploying existing Kubernetes applications. And they want to add one more application, you know, this new vendor's application into that deployment pipeline replicated to facilitate the delivery of that. So there's really been a lot of technology behind the scenes that we've been building to streamline it for the least advanced, but also allow that most advanced user and everyone in between to sort of, you know, chart their own path and find, you know, the automation that they might need or the integrations are looking for to make this sort of, you know, this transaction, right?
It's between a vendor and a customer to make that transaction successful. When you have a large ISV that starts using replicated, you have a lot of demands on replicated. Like, you have to be sure you're regulated properly, you're compliant, the proper controls are in place, and there's no data loss or data security problems. So how do you make sure the platform is properly secure?
Do you have any testing procedures or have you gotten a third-party security review? How do you ensure that things work as securely as intended? Yeah, it's a really great question. Particularly in light of the SolarWinds hack, you know, which was really a hack around the delivery of their software, right?
So someone basically got into their software delivery pipeline and then was able to bring malicious code into, you know, hundreds of thousands of customer environments. And so we take security very seriously, like the most enterprise software companies. But yeah, I mean, we do third-party audits. We have, you know, a constant focus on security within the team.
We're always working to make sure that, you know, our testing suite is robust. You know, we do a bug bounty program. You know, we follow the ISO 27,000 security practices. We're constantly looking for ways to sort of evaluate different threats to do threat modeling and, you know, just make sure that our pipelines are secure.
And a lot of that's just done through as much automation as possible, right? We don't do anything by hand, and we don't let any single person do anything. So everything goes through control. Everything is very focused on, you know, how do we make sure that the software that we're delivering is authentically ours, is, you know, the bugs are fixed quickly.
And we work with our vendors. You know, no one's perfect. There are sometimes, it's funny. Some of the security issues that we've had were more just like design decisions that, you know, we didn't expect people to use the software the way they were using it.
And when people brought it up to us, this is how they were using it, you know, we needed to change things. So we have addressed, you know, some vulnerabilities in this past year. You know, nothing that I would say is like super severe, but we worked with, you know, our customers and we took, I say, like a pragmatic approach to, you know, to getting patches out and to working with customers to make sure that they didn't have, you know, vulnerable versions of our software on the wild any longer as well. The process of updating a third party application, like if I'm operating, like, let's say I run an enterprise company and I'm purchasing software from an ISV and that ISV is deployed using replicated into my data center.
Of course, updates need to happen to that ISV application. How has the process of automated updates and other maintenance things, reliability, uptime, how have the processes around that changed over time, the management of the third party ISVs on the enterprise's infrastructure? So for many years, the way that vendors would deliver their applications was a very bespoke and somewhat custom process. You know, everybody would sort of create their own way to deliver their software and, you know, it might, like, I think it's funny, you know, when you look back, you know, probably seven or eight years ago, everyone was writing their own type of orchestration.
Sometimes it was just, you know, a more advanced version of Apps Scripts, but everyone was kind of orchestrating some of their services together and figuring out different ways to do service discovery. And so we didn't have such a consistent pattern as we have with Kubernetes. So for an IT admin, 10, 15 years ago, you know, the first thing was read through these runbooks and these instruction manuals that were provided with every piece of on-prem software and figure out, you know, what the recommended sort of next steps were based on, you know, what things you were seeing was it slow, where you having intermittent, you know, connection issues, and then you would try different configuration tweaks to address those things, right? So this was a very manual way to operate software.
And we spent a lot of time as an industry, you know, running software this way, where sort of the knowledge was sort of within these operations folks who would sit in a knock and sort of monitor all the applications that were running and, you know, have a 24 by 7, follow the sun, you know, type model where people were always on staff, you know, looking at the logs, you're looking at metrics and trying to figure out what they needed to do next. And that was the sort of only way you could run these applications, updates to your point, you know, again, you would refer to a new manual and we look at, you know, what processes need to be shut down, when do you need to start a new application. You know, when do you need to start the next one up? Like, you basically were doing orchestration somewhat manually, and you're depending on your configuration and your implementation.
You know, once again, you were focused on like, how do I bring this up correctly? And, you know, for many organizations, like if you think about, you know, running an exchange server or CRM, anyone that's been in the industry for 20 plus years sort of knows that IT often had downtime issues, right? They couldn't keep these internal services up and running. They didn't have that many, but oftentimes your email would be down or some other service would be down that your company provided.
And that was a somewhat persistent problem within the ecosystem. So, you know, and it sort of mirrors, you know, I kind of refer to this as application-based operations, right? And it mirrors the same issues that many of the web-scale companies were facing in terms of running their own applications on the first party side, right? And this is why Google and Twitter and Uber and Facebook and everyone built their own orchestration systems, things like Borg and Peloton and Tupperware.
And they built these tools in order to, you know, they couldn't throw more humans at this problem, but they needed more automation to actually manage the applications and manage the responses. And they wanted developers to be able to write sort of manifest that describe how these applications should run. And, you know, I refer to that as platform-based operations, right? So, on the first party software development side, you had this shift, you know, from app-based operations to platform-based operations, which is very largely kind of categorized just in containerization and ultimately in the wide-spread adoption of Kubernetes.
But the same thing is now happening on the third-party application side, whereas Kubernetes has become fairly ubiquitous within the enterprise, as well as ubiquitous within the ISV and SaaS company, sort of architectures. Now it's become this canonical way to deliver third-party applications. And so what we have is a shift from manual operations of third-party applications, like we were talking about before, to a much more automated operation of third-party applications done through platform-based ops. So instead of managing all these different applications independently, an IT admin can focus on managing a Kubernetes cluster, and then the cluster can automatically operate all of the applications that are deployed to it.
And so an update process doesn't need to be, you know, run this bash script or this command or, you know, shell into this server. Instead, it can be, you know, as easy as commit this new manifest in diversion control, create a pull request, allow someone else to review your request, merge that in, right? This is a very production grade pipeline. And then once it's merged in, it could be automatically deployed either through, you know, whatever CI, CD process that that organization already has set up, or if they're using some type of GitOps pipeline, you know, maybe Flux or Argo could deploy it out.
And so you have a, that entire commit, you know, pull request workflow can be automated through a product like the replicated COTS project. And, you know, our belief is that the more automation you can put around the sort of management of third-party applications as private instances, then the more demand there will be for applications to be deployed this way. Because ultimately, the sort of consumption of third-party applications as private instances is a much more secure and potentially like, you know, much better way to run applications. This is, you're giving control to the organization who wants to run the application.
And so they can decide, you know, how to actually deploy it, what to expose the internet. They don't have to have every single application, you know, on the public internet. This could all be behind, you know, private IPs and deployed and secured with a Beyond Court model. So there's really a lot you can do if you deliver software this way.
And, you know, we're seeing industry move very strongly in this direction. Can you say more about that, the add-on benefits of this model, like, and tie it back to the BeyondCorp model? Yeah, sure. So it's funny when BeyondCorp was first launched, everyone thought that like, you know, there's like, oh, Google is putting every service that they have on the internet.
And the reality was that Google is putting every service they have behind what's called a access control, right? So like an access proxy. And that serves for course-screened access control to determine if someone maybe is within an organization should be able to even access the sort of web server for an application. So everything had a front-facing kind of like, can you log into the generic service?
Then within BeyondCorp, you know, it was doing things around device attestation. You can basically start to validate that, you know, this device is secure. It has a secure key on it. And, you know, it's updated in terms of its browser or software.
And you can do all these different attestations. But ultimately, the services that are running are actually not running on the public internet. Just the proxy is. And then all the services are running in a private network that Google would host or that any company who's modeling a BeyondCorp model would run those, you know, on private IPs within a VPC.
And so what we're talking about is how do you get those applications? Those third-party applications into that VPC. And like, what applications are they? And ultimately, you know, those applications, they can either be open source, all internally written by the company that's deploying them, or they can be third-party applications that are delivered by vendors as private instances.
And so, you know, obviously we believe that the market for delivering these applications is third-party, you know, private instances is enormous because the software market is enormous, right? We don't need to all be reinventing the wheel. Instead, we can, you know, take, we can all build our own part and then sort of buy from each other and move much faster. And what we're seeing is if you think about the broader world, right, so the advantages of running these applications as private instances is now you have taken this data surface area, which would have potentially been delivering your data or copies of your data to hundreds, if not thousands of different vendors.
You know, have their own security posture, right? They have, you know, different numbers, employees, maybe have 200 employees. Various employees have different access to different amounts of data, and you know, and they all have their security posture. And so what happens is when you're using sort of the SaaS based model for everything, you end up with hundreds of thousands of people and thousands of companies that have access to some of your data.
And this is sort of a challenge in a world where the relationship that companies have with the data that they touch is changing. I would say that maybe like five or ten years ago, any organization thought that they owned any amount of data that they touched. But now you look at that, you know, some big bank and they think about customer data, not as data that they own, but as data that they are stewards of or that they might be custodians of. And so that custodial relationship is different than one of a, you know, I own this data because when you're just a steward for data, you don't do whatever you want with it.
You actually have to be thoughtful about what does the real owner of that data, that person, what should I be doing with their data on their behalf. And generally it isn't give access to another 250,000 people. And so this model, what it allows you to do is say, well, let's reduce that surface area by reducing the number of vendors we send data to. Instead, let's bring the applications to where our data already resides.
And so, you know, this is what it is. This is multi-prem. You bring applications to where data resides. You run these third party community-based apps in a private instance.
And now you have, you know, a whole suite of tools and applications that your company can run. They can access through kind of that secure authentication. And you as an organization don't have to be as concerned about like, where has the data gone, right? You know, because you control it.
Now, you can still set this up wrong, right? So, you know, you can still expose an S3 bucket without authentication. So, you know, an organization takes their own security and their own data security into their hands rather than relying on their vendors to actually do this correctly. And so that's really the top idea here is that, you know, it's just a different model of enterprise software for a different age where data privacy matters more, where companies are using more software.
You know, data residency is a big deal. And, you know, the reality is you can actually do all of this in a cloud environment, right? By an enterprise, I don't need to have my own data center, right? But replicated, we recognize that it's okay to have some number of vendors, right?
Maybe I'm working with Google and Amazon and Microsoft. That's three vendors, and I'm using their infrastructure as a service. So, they're racking and snacking machines for me and giving me programmatic access. But it doesn't mean I need to work with 3,000 vendors, right?
There's a big difference. And so, you know, when you look at that spectrum and you say, how can I reduce it down? Maybe I'll work with, you know, 20 different hosted vendors and then the rest of these applications I'll deploy into my own environment. Like, that is a much more sort of realistic future for any company that really cares a lot about data privacy and data security.
You know, obviously, you know, there's going to be some services and some organizations, right? Like a local flower shop is never going to worry that much or have the sort of sophistication to do this. But, you know, their providers might need to be thinking about this, right? Their providers might need to think about how do they reduce their surface area, so they're not sending that data on to a third level of vendors.
When you look at the AWS Outpost model, this on-prem AWS option, do you have any thoughts about, and I guess I should say for people who don't know, AWS Outposts are these things where AWS will give you a server to put in your data center, like a physical on-prem server. When you think about that with all your knowledge, you know, over the last six years of building replicated, do you have any thoughts about where the future of on-prem and cloud software is going? Yeah, I mean, I think that the Outposts example and, you know, Microsoft has a version of this and Google has their, you know, Anthos, they're all similar concepts. And basically what it tells me is that we're blurring the lines between cloud and on-prem.
And so if you think about the lines as, you know, well, this was, I drew a circle around my data center, I drew a circle around my cloud environments. It's like, you know, now you can run Outposts, which is all these AWS services in your own data center. Or if you want, you can run Kubernetes on top of your cloud environment and run all of your on-prem components in your AWS account or lift and shift your VMs. And so you can move things back and forth.
Now you're not going to move applications like, you know, on-demand back and forth. But, you know, any sophisticated organization is going to have a variety of these environments. And, you know, for some organizations, they do want to have, you know, that data governance and data privacy and, you know, regionally have, you know, the data in the country that they reside in or that their jurisdiction is in. And so an outpost might be a really good idea.
Now the difference between something like Outposts and Replicated is, you know, Outposts is really about delivering sort of AWS core services into an on-prem data center, right? And Replicated is about enabling these third-party applications. So, you know, third-party vendors to deliver their application suite into any environment, via the AWS outpost environment, a GKE environment, or, you know, a VPC in AWS. It doesn't really matter.
It could be, you know, an open Red Hat, OpenShift cluster, it could be a Rantra cluster. It doesn't matter to us at all. We're just trying to give the tools that allow ISVs and SAS companies to operationalize and scale the delivery of their Kubernetes applications into a variety of customer environments. I'd love to get into a little bit more about the engineering of what you've built over the last year since we have last spoken.
What are some of the hardest engineering problems you've had to solve? So, you know, I guess the first part is, you know, just acknowledging that so many things have happened over the last year, both from a global perspective, right? We went through a pandemic that we're still hopefully coming out of right now. The world was really turned upside down.
And, you know, it was difficult. It was difficult. It was difficult. You're for Replicated in some ways, right?
In the beginning of the year, you know, we were doing well. We had the new COTS products that were starting to really gain some traction. But, you know, we didn't know what happened in the market. And so, you know, our team was, we were 18 people, I think, you know, in mid-March or April.
And, you know, since then, we've really grown the team pretty significantly. So, we've added another 20 people to the team. We were very fortunate over the summer to bring on our chief product officer. And so, our chief product officer is a man named Mark Punzak.
And Mark was the head of product in GitLab for about, I don't know, three years. And really helped sort of create their strategy around DevOps and sort of the holistic, you know, DevOps lifecycle within GitLab. And Mark has been an incredible partner for helping us sort of determine what our roadmap is and should be. So, he's recently been spending a lot of time with our customers, making sure they understand where we're going and what we're focused on.
But ultimately, you know, Mark's vision is that replicated will continue to focus on making it easier for vendors to deliver these applications in complex environments. And at the foundation of that is just making sure that it always works. And so, you know, we've spent a lot of time building out pretty sophisticated test grids to validate our software and our customer software across multiple different environments and versions and, you know, making sure that you can deploy it onto a RHEL server or onto a GKE cluster or onto, you know, an air-gapped environment. I've been really just automating so much of the testing.
And then, you know, pretty soon we'll actually be enabling our customers to sort of hook into all that testing as well for the release of their own software. And so, there's a very concerted effort on making sure that this works because it's hard, right? There's a lot going on here. There's a lot of variables.
And so, you know, controlling as many of those variables and allowing the testing is a big important part of it. You know, I'd say that we've also accomplished a lot in terms of, you know, again, more around maturity of this product. When we talked last year, the COTS project was maybe, you know, four months old. And so now it's matured to a 1.0 version, you know, well well beyond that.
We've added layers of authentication and different authentication providers. We've done, you know, significant work around integrating with some of the other tooling and ecosystem. You know, things for backups like Valero, you know, we've always had some monitoring support with Prometheus, but really finding, you know, as many of these other projects that we can integrate with to create a very, very kind of comprehensive, robust, and stable platform for the delivery of the system. And so, you know, we've had a lot of different applications that we've had in the delivery of these third-party applications.
And, you know, it's an ongoing effort, right? I think when you look at what the alternative to replicate it is, you know, some of these teams, you know, have 20, 30 people who were building all the tooling to enable them to deliver their applications in the customer environment, right? They're focused on this kind of delivery. I think Palantir, you know, has built a pretty big system around this.
You know, I know GitHub has, there's a lot of different sort of solutions out there. You look at the challenges that on-prem delivery has caused for a company like Atlassian. And so, you know, they're going to end of life their server products, which are the, you know, the sort of half of their on-prem offering. And, you know, for Atlassian, that challenge was they're going to maintain their data center product, which is what their biggest customers use to deliver their products on-prem.
But, you know, Atlassian had basically two different companies to support these two different products, right? Gere server versus Gere Cloud. These were, you know, completely different code bases, completely different support processes, releasing. So, you know, this can really provide a massive amount of cost if you don't, you know, do it sort of correctly.
I mean, you know, correctly is the wrong word. I don't know about faulting Atlassian. They've been around for 15 years building an amazing company. You know, they've had a massive adoption and Kubernetes wasn't available when they were first delivering their on-prem version.
But, you know, a lot of these companies now, you know, are making this transition to use Kubernetes as the foundation for their software delivery in the customer environments. And, you know, with that, you know, it's just, it's either build all this tooling themselves or find a partner like Replicated to help them do it faster. Have there been any customers that you've interacted with that have kind of pushed the boundaries of what you have and maybe proven that you needed to change or rearchitect certain aspects of how Replicated functions? Yeah.
I mean, one of the advantages, slash disadvantages of Replicated is that our customers are and have always been these sort of cutting edge software companies, right? So, you know, when we first started, it was Travis CI and Circle CI and, you know, NPM using our tooling to deliver their products. And we've continued to work with the sort of most advanced engineering teams out there, right? So, HashiCorp uses Replicated to deliver every instance of Terraform Enterprise.
And, you know, these customers understand the problem, they understand the technology, and when they see an issue, they're often right. You know, I like to say, when our customers give us feedback, most of the time our response is in something like, no, or, you know, maybe later, it's always like, why didn't we think of that, right? Because it's just such good feedback and almost always a very, very sort of useful and correct idea. And so oftentimes we implement those things.
And, you know, we take a lot of our roadmap from customer requests and figuring out where customers want. You know, I'd say that there's a really great example of exactly what you're talking about with Circle CI. So maybe two or three years ago, Rob Zuber, the CTO of Circle CI, gave a talk at KubeCon. And he talked about using Kubernetes to deliver Enterprise software.
And at that time, they were a customer replicated and they were using our sort of like version one of the product that we refer to as like the replicated native scheduler. We wrote a run scheduling before there was Kubernetes. And Rob talked about how at some point Circle CI was going to stop using Replicated and deliver their entire Enterprise product as a Kubernetes application. So, you know, we said this in this KubeCon talk.
So obviously, you know, one of your bigger, more high-profile customers, who has been with you for several years, saying publicly that they're going to get off of your tools and not be a customer anymore, would generally be a bit disconcerting. But, you know, I still remember, you know, my co-founder, Mark and I watched and talked together and we agreed. We knew that Rob was right. We knew that the answer wasn't our original product, our version one.
We knew that as the world shifted to Kubernetes, we needed to have a different solution to enable them to actually succeed, not, you know, just in the packaging, because Kubernetes becomes packaging. But succeed in the delivery and the operationalizing of this entire workflows and process of delivering the software to all these different customers. And so, you know, we got on a call with Rob and we explained, we was like, hey, we watched your video and we agreed, you're not wrong. Like, this is absolutely right.
But we want to make that transition with you. And they, you know, they basically pushed us and said, okay, well, here's the stuff that we would need. And it took us probably, you know, a full year to really have the right solution. And that was the COTS product that we launched, you know, five quarters ago.
And so now, you know, the team of Circle is moving, you know, their customers over to COTS. And that's the same thing that we've seen with most of our vendors, right? We've had to make a very interesting sort of product transition. It's not that we made a pivot because we were always doing the same thing, right?
And we talked about how do you deliver modern applications into complex customer environments, you know, this modern on-prem concept. But we needed, you know, a technology and a solution that really embraced modern architectures around Kubernetes and then brought value beyond what we were doing before, which was the packaging. We really had to focus where our value was. And so that value became, you know, an automation in workflows, in supportability, you know, in preflight checks and all these different things that we offered.
And ultimately, we've successfully transitioned just about every one of our customers over to this new tooling. And it's been, you know, widely loved. I think, you know, one of the things is sort of like more of a business comment. But when you look at a company like Replicated and this product market fit concept everyone talks about, and everyone thinks they have product market fit, even before you have it, because I thought I had it.
But what I realized after, you know, we actually had it when once we launched the COTS project and started to really, you know, take off, I realized the key indicator for what product market fit is. It's actually around what is your close rate from POC. So from proof of concept, proof of value to someone buying and becoming a customer. And before Replicated COTS, you know, I think we were probably, you know, converting about 30% of POCs to customers.
And that's just not high enough. You can't really run a full go-to-market organization off of 30%. And so after we introduced COTS, we bumped that up to about 75 or 80%. And it turns out there's some threshold.
I think it's around 50% where you actually have product market fit. So if you're closing, you know, 50% of the POCs that you're doing, then you have a really scalable go-to-to-market motion and you have a product at the market once. But if you're not closing it at that rate, then you really don't have it yet. And so for us, I think we found that by working in conjunction with our customers, by believing, you know, what we thought the future of software would be, and just working pretty relentlessly to get there.
It was definitely a tough few years when we knew we didn't have it. So I think we look back at the success we've had throughout 2020 and the company more than doubled in revenue, we more than doubled in headcount. You know, we added these incredible customers. A lot of it comes back to the fact that we were able to really partner with some of these incredible customers.
You know, get their feedback, iterate, and they trusted us enough to know that we would build the right thing for them. And, you know, and so for that we'll always be grateful, right? And it's not just actually Corp and Circle. You know, it's folks like Forward Networks and Tripwire and Puppet.
These companies just came in and they embraced what we were doing. I think oftentimes they knew that they didn't really want to be responsible for these tools. And if a vendor could successfully do it, that it would actually free them up in terms of a lot of resources. So I think that's why they were maybe a little bit more willing to work with us when, you know, because they knew that it was an important enough problem.
That if we solved it for them, they would get, you know, a 10x return on whatever, you know, revenue we generate from them. They'd be generating, you know, 10x that in terms of cost savings. So yeah, I think customers are really, really important part of it. What do you have planned right now around open source projects in the replicated ecosystem?
Yeah, so, you know, we have a few core open source projects. The ones that I've been talking about primarily as COTS, and that stands for Kubernetes off the shelf software. The other ones that we have all, you know, within the same vein of core replicated open source projects. The ones called troubleshoot, and that houses these two kind of related but sort of separate use cases, one for generating support bundles, which basically collect all the different information logs, data, etc., from a running instance, put it through redaction.
That way, you know, you don't have any sense of data leaking, bundle it up, and then actually analyze it both in the customer environment and in the vendor environment to make sure that, you know, any self remediation can be done. So that's a support bundle within the troubleshoot project. And then also within the troubleshoot project is preflight checks, which do a very similar thing, which is like, you know, basically look at the running cluster and then make sure that it conforms to the requirements of the application, right? Does it have enough memory, CPU, you know, I-O, whatever else you might need in order to make the application run successfully?
And most of the time, these things are running, you know, an update or running at install time, you know, and they basically just try to keep people away from the foot gun, right? Like, the worst thing to do is to try to install software when you have under-provisioned the actual underlying, you know, like servers. So you want to make sure that you have all the resources you need. You want to make sure that you're running the right versions of things because this is all easy to check.
And by putting these, you know, kind of checklist in front that run automatically, you kind of prevent those like dumb human errors that often cause, you know, hours of troubleshooting. So as much as we can do to automate those, we try to do that. And then another project we have also kind of core replicated is called Curl, also with K. And this is really around, we call it kind of your Kubernetes URL.
So it's a distro creator. Think about it as a way to declaratively manage the add-ons that you would use in, you know, a custom version of Kubernetes. So if you want to, obviously we use it to allow software vendors to embed Kubernetes underneath their application when deploying into a customer that doesn't have an existing cluster. So you go into someone, they don't know much about Kubernetes.
You want to deliver your application that's Kubernetes based. How do you, you know, kind of bridge that gap? Well, you have them run this installer. It installs onto a single node or on a multi-node.
It can do multi-master. It's really, you know, pretty comprehensive. You know, it's built on top of, you know, vanilla Kubernetes, kind of powered by Kuberium. You can select different, you know, sort of plugins.
You could have, you know, Rook and Sapphire. You could have OpenDBs. You could have Calico. You could have Weave.
You sort of pick all the different add-ons slash components and their versions. And then this tool basically builds the installer. It cannot build the TAR-GZ delivered to an air-gapped environment along with the install script. Or you can just run it straight from, you know, a curl.sh URL that we host for you.
And that project is once again, completely open source. You know, it's a fairly deep project in terms of making sure that Kubernetes is easy to get running anywhere. And we open sourced it because we just want more Kubernetes ubiquity, right? We don't think that, you know, getting a Kubernetes cluster up and running with a new version of the new version.
And then the cluster up and running with the required network and ingrass, et cetera, should be a proprietary technology. We think that should just be like table stakes for anyone to be able to do at any point. So, you know, there's a lot going on around that in terms of cluster API and, you know, other sort of interesting projects and SIGs. But we think that curl is a really good example of a way to kind of implement that.
And then, you know, the sort of fun one slash like kind of related but not cord-or-replicated business is a project that my co-founder started called SchemaHero. And we recently donated SchemaHero to the CNCF. And, you know, SchemaHero is basically a way to declaratively manage schema migrations for databases. So, it's a Kubernetes operator and you sort of write your migrations in what we call a Kubernetes custom resource.
So, it's sort of like defined in Kubernetes language and sort of DSL. And then you apply that and it sort of manages the migration of the schema in the background almost like an ORM would. So, you know, you can version control these schema migrations. You don't have to worry about like this, you know, a schema migration needing to run through, you know, 30 different sets of migrations before your servers up and ready.
And this actually is a project that some of our customers end up using because if you know much about schema migrations, you know, most of the time they were sort of imperative and they would sort of run on top of one other. You'd have to run them in order and then, you know, there would be challenges around like some version of a, not, you know, some version change then causing an error in the migration run. And so, this just felt like a really simple project that would have a lot of value. And I think, you know, since donating at the CNCF, there have been a handful of new contributors and more folks using it.
So, that's available at schemahero.io. Well, Grant, as always, it's been a pleasure talking. Do you have any closing thoughts on this ecosystem and plan for the future? Yeah, well, thank you for having me.
It's been great. Ultimately, we continue to be incredibly enthusiastic about the future of the Kubernetes ecosystem. I think it's come very far, but we're still just in the early innings. You know, just in the last year or two is when a lot of big companies who were kind of waiting for the container wars to be over who have come off the sidelines and they've started to really use Kubernetes.
And a more beyond just the labs function, beyond just, you know, a test. They're starting to put it into real production use cases. We're seeing, you know, tons of folks within the Fortune 100, from the Global 2000s, who were adopting it across all the different projects. And so, the Kubernetes ecosystem is going to continue to be a very, very important part of the future of software.
And I think that, you know, the shift to remote and sort of everyone working completely independently from their homes, you know, in terms of the technology world has shown that software is a core core part of the world, right? This is, you know, how we interact with our loved ones now. So, how we do so much more than we used to do. I think it really accelerated the idea that, you know, software is eating the world.
It's almost like software now is the world. And so, as such, the tools that are built for software developers are going to be increasingly important, right? So, you're going to see more and more, you know, developer tools, more and more highly technical products out there that allow organizations to build and create value for their customers through software. So, you know, I think that the trend has always been in our favor, but I think that even more recently, we've really sort of it's been proven how true it is that the future is going to be, you know, kind of so software in its own.
So, software enabled. And so, it's a really exciting time to be part of this industry, to be part of this field. You know, I think that the communities that we're developing and the way that we're approaching this is really special. And we owe a lot to the people that have sort of learned from the mistakes of past projects and past, you know, foundations and have taken that and made sure that this organization, the CNCF, and Kubernetes, this entire ecosystem can endure and can last.
You know, I think a lot of the vendors have realized they have to play somewhat nicely together in order for the ecosystem to move together holistically. So, it's a really, really exciting time. You know, we're always hiring. We always love passionate software engineers, you know, who are curious about technology and curious about, you know, just learning in general.
So, you know, if folks are out there and looking to join a company and work on kind of really nerdy infrastructure, software problems, you know, we love to talk to them. And, you know, they can just come to Replicate, look at the job openings or shoot us an email. I'm always available at justgrantatreplicated.com. I'd love to hear from listeners of the show.
You know, the response we've gotten from previous episodes has been really strong. And I think your audience is super, they're just, they're very much engaged in the content and they're engaged in the sort of pursuit of what's next. And we just love those folks. So, thank you for having me.
Well, thanks for coming back on. Until next time. Thank you.