Ep. #3, Modern On-Prem with Replicated’s Grant Miller

Joe Ruscio: Welcome back, everybody. I'm very excited today, joined by a good friend and a colleague, Grant Miller, who if you don't know is the CEO of Replicated, which we're going to talk about.

And also, it's pretty interesting if you're building any kind of enterprise software, creator of EnterpriseReady, which is pretty much a premier guide for getting your software ready for the enterprise. It's pretty self-explanatory, I guess. How you doing?

Grant Miller: Great, thanks, for having me. I'm really excited to be here.

Joe: The pleasure's all mine. So today, coming from EnterpriseReady, we're going to talk specifically about delivering software to the enterprise.

I think, perhaps, most interesting or fascinating to me, and I think probably to listeners, is how much that's actually changing now, after I'm going on, I guess, 20 years of being about the same. And so, maybe, you could start. What's the term "is modern on-prem," I think is what you've called it, and what do you think of when you think of modern on-prem software?

Grant: It's interesting, because it's a combination of terms, right? People here--

Joe: It's almost like an anachronism, right? On-prem isn't that modern.

Grant: Yeah.

Joe: If you talk to most people.

Grant: Yeah, modern on-prem really means the ability for enterprises to consume private instances of applications. And oftentimes, it's SaaS applications that are cloud-native, and deployed into a quote-unquote, "datacenter." But that's most often like, an Amazon VPC. But it's just the enterprise controls the VPC, versus it being the vendor's account. So it's a new way to consume third-party software.

It preserves a lot of the security and compliance that you get from traditional on-prem software, but gives you the agility and the advantages that you would be used to from a SaaS product.

Joe: It's interesting, because if you think about it, I mean SaaS, Software as a Service, has probably been one of the most transformational kind of things that has happened in enterprise software in the last, again, going back 20 years, when Mark Benioff was at Salesforce. Even preceding that, Paul Graham and the team at Viaweb.

You know, this notion of building software, hosting it, quote unquote, "in the cloud," really empowered, or opened up the doors for a lot of companies to consume software they wouldn't have been able to before, right? I guess, though, the question is, why, with all the benefits, that whole movement, why now? Are people actually looking to bring software back on-prem?

Grant: I think if you look at why we moved to SaaS, you have to evaluate like what traditional on-prem looked like, right? And so, from that perspective--

Joe: Like, when are we talking?

Grant: Like 20 years ago, right?

Joe: Okay.

Grant: You were going to be an IT admin at some big bank, and you were managing an ERP system, or CRM, like some Siebel software, or something, right?

Joe: Or your SMP, or something like that.

Grant: You had these huge systems, and the first problem was, you were actually installing it into a datacenter that you controlled, maybe even a server closet.

So you were physically racking and stacking machines. It would take months to get new boxes provisioned. They were incredibly expensive, right? A terabyte of disk space at that time was $30,000, 20 years ago. The same terabyte of disk space is now like 30 bucks on Amazon, right?

Joe: Right, so step one in on-premise deployment was actually, "procure hardware."

Grant: Yeah, procure hardware.

Joe: Before "install software."

Grant: Procure very expensive hardware.

Joe: Right.

Grant: Right. And then, once you procured it you had to install it and set it up and provide dual power supply and setup the OS, and the runtime. And then, you'd get this 127-page install guide, from the vendor, about all the dependencies, and how to write the JDBC connector, and what databases to set up.

And then, you, as the enterprise IT Admin, basically, became responsible for the manual operations of every application that your IT team took on as an application. You would have pager duty for who's going to be, you know, managing the ERP instance for these hours, right?

If something goes wrong, you need to get into the datacenter, and boot up the new machine. The software wasn't delivered as HA, it wasn't delivered as zero down-time. This is fairly primitive manual operation of software, where you, as the IT guy was, you were SSH-ing these machines, changing configuration files.

We call them "artisanally crafted" servers, that only one person the team knew how to manage and maintain.

That created just this nightmare of managing applications, and it really made it so that enterprise software was only available to the largest companies. Some big bank that could afford the operational overhead of employing round-the-clock, follow-the-sun type support, for all these applications.

It drastically limited, one, the number of buyers that could actually use the software. Two, because the market was small, that meant there were fewer vendors. And then three, it was just a big pain in the butt to actually manage.

Joe: The other interesting thing, maybe, and this comes from my background in previous lifetimes, actually building those solutions, closer to 20 years ago than I'd probably like to admit. From the vendor side, there used to be this common wisdom that you could only make money selling software at like $50 a license, like shareware, desktop software back in the day, or seven figure deals.

Grant: Right.

Joe: And that selling software for $10,000 a year, or $50,000 a year, or numbers that today sound pretty good for a lot of companies, was a death sentence. That's primarily because you couldn't afford to sell software that cheaply, because on the vendor side you actually had to provide all the support, provide all the post-sales, professional services, everything required to actually get those solutions up and running.

And then, let alone the cost of upgrades, and getting those down. I think SaaS has not only liberated the IT admins from that, but also, in many vendors eyes themselves, right? Historically, at least.

Grant: Yeah, sure. Salesforce really changed the game when they introduced the SaaS model, right? And they called it "on-demand" at that point. I think if you actually go back, and you read Benioff's book, you hear a lot of these reasons for why they actually decided to introduce software this way.

It was massively successful, right? They had incredible adoption. I really think the key innovation was centralizing the operation of the application into one team that knew how to operate it, knew how to operate it at scale, make it available as a website.

You saw what's happened in the last 20 years, where that model just makes it so much easier for any customer, end customer to adopt it. So it lowers the overall barrier to entry, and to start to use the software, and that creates more demand.

It's really a self-fulfilling prophecy, in terms of who ends up adopting these different technologies, because now you can start to deliver a SaaS solution for, basically, any esoteric problem that's out there. Huge advantages for the market. But the challenge that you see, is that, over that time, you've gone from having 10 SaaS vendors, to the average--

Joe: You mean across the industry, 10 SaaS vendors?

Grant: Yeah, across the industry SaaS vendors. Or even at a specific company, you might have been consuming 10 SaaS products 15 years ago. And now, the average enterprise, like Netskope, the recent numbers, about 1,053 different vendors at most, you know, the average enterprise has.

Joe: So each enterprise company is using, in some form or another, just over 1,000 SaaS applications?

Grant: Yeah, on average. A lot of that's shadow IT stuff, that like a marketing admin has just, you know, signed up, or introducing--

Joe: My finance department loves that, by the way.

Grant: Yeah, exactly. All that expense, those expenses that you see on someone's credit card, that they just--

Joe: When we were acquired, yeah, the finance team, I remember looking at our-- and they were like, "Oh, what SaaS applications are you using?" And we said, "Oh, let me pull up a spreadsheet, it only has a couple hundred lines in it." You know, we were using an average of, I think, five or six SaaS applications per employee.

Grant: Yeah, that's amazing.

Joe: Which, from the diligence process, quickly went from a, "We're just going to look at this," to, "Okay, these are all grandfathered in, because it's going to take too much time."

Grant: Oh, wow.

Joe:I guess that begs a question, and I think you alluded to this earlier. So this is 20 years ago, custom datacenters, custom installers, expensive hardware, and people all over the place. But some things, and this is for when this all clicked for me, when we chatted about this previously, somethings have fundamentally changed since then, right? What's now different, that has changed those base assumptions?

Grant: I think the most important piece is the recognition of the problem, which is that, as everyone has moved to SaaS and you have a thousand vendors, you're really taking your data and spreading it across all these different vendors, right? So you're increasing the surface area of your data pretty dramatically.

You're talking several orders of magnitude, in terms of who has access to your data. And, sure, most of these companies might be doing the right things from a security perspective, but they're probably all not doing the same thing that you're company would be, if you're a bank, right? As an enterprise, you understand that your vendors are oftentimes, you know, the weak link.

Joe: Right.

Grant: It just takes one person to expose an S3 bucket full of your data, for it to go out into the world.

Joe: The interesting thing to me, when I think about this, is on the one hand, cloud computing is this incredible force that has completely democratized the ability to create a B2B company. And you can even see this in the, in venture finance, right? You used to have to literally raise millions of dollars on a deck alone, so you could get the money to get the hardware, to get the team, and the network management, and the operators, and everyone to actually run it.

Whereas, now, literally, if you're fortunate enough to have the means, you don't need much to start an app, at bootstrap, right? Which is great, and it's caused this explosion of innovation. But, the downside of that nobody talks about, is if any company can be started by two people and a dog, the variance in security is probably going to be a lot higher than it used to be across solutions, that all look on the surface, it's good design, like very polished.

Grant: Yeah, it's exactly the problem, right? You think about, you're exposing your data not only to the team at Salesforce, but it's also all the other thousand plus applications that you're running.

Joe: Right.

Grant: And then, I think, even interestingly so, at Salesforce or Slack, these huge companies that are pretty well run, from a security, and compliance, and they think about this all the time. They've become these centers of gravity where now there's these app ecosystems around them.

Well, the application vendors get access to your account, and they're pooling all that data into their servers, right? You might be able, as Slack, or as Salesforce, you might be able to ensure that that data is transmitted to them over, you know, HTPS. But once you give it to a vendor, you don't know what they're going to, or an app, in your app store, you don't know what they're doing with it. They're putting it on their servers, or running analysis against it. I mean, this is sort of like the enterprise version of the Facebook, you know, Cambridge Analytica thing, right?

Where it was an app that was actually trading all this data from the Facebook server, the same thing could be happening on the Salesforce or Slack side, and it's just one of these little apps that everybody opts in to add emojis to their application.

Joe: That's someone with partial admin privileges just added, because it, like you said, puts funny gifs into the chat, or something.

Grant: Yeah, but it gets read access into all your Salesforce account.

Joe: Right, right. And then interestingly enough, more recently now, there's the obvious, just the security vulnerabilities, just as a good steward of your customer's data. But now, as of a couple of months ago, with the GDPR regulations in the EU, there's actually real financial consequences if you have customers in the European Union.

Grant: Yeah, I think that vendors are realizing more and more that this data that they've been collecting for a long time, that they've thought about as a huge asset, "Oh, we can do something with the data," becomes a real liability.

They have to be very cautious about how they treat that, because a lot of times modern vendors are not only just storing that data in their AWS account, but they're pushing customer data into Intercom, or into these other services that are managed, a BI tool that's hosted. And so, if you look at the number of sub-processors that your processors have what--

Joe: Yeah, there's sort of a, it turtles all the way down kind of effect, right?

Grant: Exactly.

Joe: Where you're, the SaaS company, you use SaaS companies, and they use SaaS companies, and there's probably even like--

Grant: Then they're logging it out, you know. And so.

Joe: Right.

Grant: Who knows what the debug on Verbose, and all of a sudden, it's everywhere.

Joe: Yeah, and so, certainly, I think you can argue effectively that the sheer numbe, and the increasing variance over time, and the quality of those teams, and how they approach security, has made this problem worse over time. But it's certainly always existed, right? It's certainly been a trade-off that the CIOs have always made, right?

So they're saying we're going to give up. And especially back in the day, and someone who 10 years ago switched from building on-prem software the old way, moving to SaaS. I remember giving very strong speeches about FUD.

That trade-off's always been there. So now, I guess the question is, and these can shift, if that trade-off's always been there, admittedly getting worse, than what's the other side of the equation that's changed, that now is meaning maybe things are swinging back to modern on-prem.

Grant: Yeah, that's a great question. It really comes down to the problem you described earlier around running traditional on-prem software, being this very operationally heavy and sort of manual process. Realistically, that's just how software was 20 years ago, right? Even Salesforce 20 years ago was a manual process, to run it. What we've seen, is that manual processes--

Joe: It still is, by the way.

Grant: Yes.

Joe: The Salesforce consultants are a thing.

Grant: Yeah, but I mean, even running the actual application behind the consultants with the actual instances. And sure, Salesforce is probably architecturally not super-modern, so probably still people SSH-ing the servers, and making configuration changes to databases, for a specific instance.

But, that model of managing and operating software has really been recognized as something that just doesn't scale well. And so, you've seen the sort of web-scale companies, think about Twitter and Google specifically, that had to solve this problem, and they couldn't just throw more people at it.

Joe: Right.

Grant: So instead, they threw more software at it, and they created technologies like Mesos, and specifically, Kubernetes, that were designed to operate applications at immense scale, by using automation as the key component to actually delivering applications in a way that is reproducible, repeatable, and incredibly reliable, right?

A lot of this came from some of the original automation that happened at Amazon, and then, sprung from that puppet and shaft, etc., etc. But, specifically, what we're really excited about now, is what's been happening, you know, from the, the birth of Borg, which is Kubernetes, right?

The key thing here is that we have been delivered this new methodology for operating applications at incredibly high scale and reliability.

And when you think about it, we're getting much closer to actually autonomous software, where we're writing a manifest that describes all the operations that are required, in order to install, and update, and manage, and scale, and sort of create a self-healing application.

And because of that, even at Replicated, the way that we deploy parts of our SaaS product, there's no SSH keys on the actual servers, like everything is mutable and deployed through automation. The same is true at Google, same is true at a lot of modern companies. And so, as you move towards people being able to write applications this way, what happens is, you can deliver that manifest to an enterprise.

Instead of having deliver a 127-page install guide, you can actually codify all of the information and knowledge about running that application into that manifest, and then hand over the automation to the enterprise, right? So that core piece drastically reduces the overhead.

Interestingly, too, the enterprises are likely not going to be installing that into a physical datacenter, where they're racking and stacking hosts anymore. What we've seen, is the adoption of actual infrastructure as a service, right? You know, this is AWS, or Google, or Azure providing what has kind of become known as a VPC, a virtual private cloud.

Joe: Right.

Grant: And this is, basically, the ability to run Infrastructure as a Service, and provision new hosts that don't have external outfacing IP addresses. And so, you can run these only with internal IPs, and hook them into a private network.

Or you can use a zero-trust type beyond corp style model, if you don't want to use a VPN, you can use client-side certs. But the idea is, that these machines can be restricted to only devices and other servers that you have configured to able to access them through one these, you know, access control means.

Joe: Yeah, it's interesting, there was this progression, right? So first we had virtualization. And I think also, very telling, or foretelling, I guess, once virtualization started to penetrate the enterprise, one of the interesting or innovative use cases that popped up was this notion of virtual appliances, right?

In which, these legacy enterprise vendors started to try to somewhat circumvent the process of delivering software by installing it into a base OS, wrapping that all up in a VM, or typically one VM, it may be a set of VMs, and handing that off. So as long as you had a massive VMware contract, and they had wrapped it up in VMware's virtual appliance, you could--

You still need to buy the hardware, but you could somewhat circumvent the painful installation process, somewhat help with the upgrades. It still didn't scale, I think to your point, measuring modern software processes and whether or not headcount scales were nearly with it. And then that, you want to, as you 10X the scale of the software, you want to weigh less than 10X to head count, right?

So virtualization, then, that begot the public cloud, that can create a public cloud, and then VPCs came on. I guess, probably most interestingly to this, in the last now, I suppose, five years, you mentioned Borg on a Kubernetes. But this combination of Docker that lets you wrap up all the dependencies in a very kind of thin layer, and then, Kubernetes, that allows you to, two things, right?

From a SaaS vendor's perspective, this enables this microservice proliferation, while still making it completely operable. But I think you've made, and Replicated has made a pretty interesting observation around that, is that it also then allows you to take almost exactly what you're operating as a cloud-native SaaS platform, and basically, deliver that, quote unquote, "on-premise" to a VPC.

Grant: Yeah, exactly. We think about the analogy of drug discovery, right? A drug might get designed for one purpose, but then you realize that it actually has this incredible other use case, right?

Kubernetes was designed to help people deploy web-scale software. But the realization that we made at Replicated four years ago, and the reason we started this, is we realized that containers, and orchestration, and scheduling would actually facilitate the installation, configuration, update, management, etc. of these applications in an enterprise environment.

Joe: Right, because, Kubernetes is, basically, and other orchestrators, right, if you're using Docker, the fundamental fact--

Grant: Application portability, you have to be portable.

Joe: The application layer, that as long as you have a orchestration layer that's compatible, and so, we'll just use Kubernetes for example, say, suddenly the vendors operating environment looks almost exactly as the client's operating environment, which has literally never been the case prior to now.

Grant: Yeah, exactly that. And so, there's an interesting piece, where more and more enterprises are moving to something like Kubernetes, as the sort of datacenter operating system, right? So they can take one Kubernetes cluster, and run a bunch of different applications in there.

That could be applications that they use for serving their production traffic. It could be applications they use for internal tooling. But it can all live within this cluster, and it can have a single way managing and maintaining those applications, in a very consistent and operable pattern.

Joe: Okay, so then, as a software vendor, right, a new software vendor, I probably am going to have some hosted offering, in most cases, for SMBs, SMEs. But now, the notion is, if I'm using Docker, if I'm using Orchestrate, if I'm a cloud-native application, then, in theory, it shouldn't be much work for me to wrap this up in such a way, that it can be deployed in a private instance, in a private cloud.

Now, is this something that I would typically manage? I mean, there are vendors that, if you're a large enough customer, you sign up for an instance of the software. But my team is still running it, my team is still scaling it. It might even be in your VPC. Is that what we're talking about, are we actually enabling the IT admins, IT operators to run this?

Grant: Yes, so we think that if the vendor has access, it actually invalidates the model. And we think that it invalidates the model, because the goal here, is to reduce the surface area of who has access to your data, right? And so, as soon as you give a vendor credentials to SSH in these machines, I mean, you're potentially exposing more data, because now they can, you know, go from one box to another.

Joe: Yeah, you've given them local access at that point.

Grant: Right. What we think the key here is, you said your team "manages," quote-unquote? Well, today we do management through automation. That management shouldn't require physical access, or virtual access to the actual underlying resources. It should just require the ability to deliver this automation that can then be applied.

That's what we focus on at Replicated, is delivering that automation, and then providing some tooling around, "Hey, if things go wrong, how can I get a support bundle?" "Hey, I need to license and then title this." We try to provide all the other tooling that's required to deliver the software, and things you would be building yourself, if you went down this path.

Joe: Right, it's like deliver and upgrade it, monitor it. I mean, that's fairly straightforward, to envision how that could be done. "Phone home" kind of activities. There's some more kind of interesting questions, though.

How do you handle stateful services like databases, or if your application runs a Elasticsearch cluster, or Cassandra cluster in the cloud, how do you handle getting that taken care of on-prem, if you can't access it?

Grant: Stateful services are definitely one of the more complicated pieces of this. There's a couple different perspectives we take. Number one, we see the introduction and evolution of more cloud-native databases.

So you think about things like CockroachDB, you could buy it, all these other folks are designed to sort of run cloud-native. And, you know, they're Postgres Wire compliant, they have all these other features, and things you would want, but they're sort of designed to run in the system.

So that's one really important transition that we think the market will make over time. Another piece is, like I mentioned, that a lot of times these enterprises are actually running your application in a Infrastructure as a Service provider. And so, they have access to things like RDS, or any of these other sort of managed services, that are provided by the actual cloud provider.

Some people think it's a little bit inconsistent, that an enterprise would be willing to trust the cloud, a cloud vendor, but not be willing to trust their product. They think, "Oh, they use AWS, so they should use us." Well, it just turns out that, like, it's a lot easier to get the security assurance that you need against one of the five largest companies in the world, than it is against your hundred person SaaS company. And Google, and, you know, and Amazon, and Microsoft have been really focused on incredibly deep security for a long time, just at a level that no other application vendor can actually get to.

Joe: Yeah, I mean, they literally have more people working on that problem than most SaaS, B2B SaaS companies will have employees.

Grant: Oh, 100%.

Joe: Yeah.

Grant: And so, because of that, we think it's actually very consistent for an enterprise to say, "Look, we're going to trust these two, three infrastructure providers." Also, because it turns out, infrastructure is a little bit harder to deliver as an automated thing.

There's no robot that I can buy, that will lay the bricks and mortar for building my datacenter, and setting up all the racks, and doing all those pieces. But, it turns out you have automation that deploys your application, that I can just run in my own Kubernetes clusters, so that seems to be a easier thing for me to buy from you, than it is to buy that robot that doesn't exist.

Joe: Right, it makes sense that you could setup your application for, especially if you have, per your earlier point, there's really only three. Or we'll even charitably say five large vendors you would have to target with their, their hosted database offerings, right, or their hosted stateful offerings to have coverage. Which is really no different from being back when you were doing on-prem, and you're an installer, and you would say exactly what version of DB2 your JDBC connector supported.

Grant: Right, and that's today. But we see the market moving towards just having these fully portable cloud-native databases and services, that become part of how you run applications at scale. If you're running Kubernetes today, you may be running a Helm Chart, that's a Postgres version that's a little more HA. But, generally, you're going to be better off long-term, in the next five years, moving to something like Cockroach, which is designed to run that way from the beginning.

Joe: Right, cloud-native. Another question along those lines, or maybe from a different side, is one of the great things about going on back to this whole central notion of trade-offs. And where the balance, maybe, now lands as a SaaS provider, with a multi-tenant solution, or even if I've gone doing like the kind of sea of single-tenant managed instances, with that access to the data, I can see lots of things.

Particularly now, especially when we're five years into the, the kind of rise of AI, and specifically ML, where there's this notion, and I'm seeing lots of startups pitching this notion, that, hey, with this data, we can access it, and learn it, and train, and be smarter, because we see it. I mean, you lose all that, though, if you, if you bring this on-prem, right?

Grant: You do lose the ability to centralize all that learning, from one angle. The solution to that, is actually what's called federated machine learning. And so, federated machine learning, think about it as how your phone does predictive text, when you're typing.

Those models are not sending every keystroke back up to some centralized cloud, to tell you then what, you're probably going to type? But instead, it has an algorithm that's delivered in the keyboard, that says, "Hey, here's what is most likely to happen."

It does send some learning back up. And so, it's learning on every individual phone, and then centralizing that learning. So you can do that exact same thing in sort of an enterprise edge node architecture, where each of your enterprise customers has algorithms, and all the sort of most recent thing you've learned. Potentially, if you're running a centralized service that is doing this for some number of SaaS customers as well, and you can deliver them down updates to the most recent algorithm.

You can also learn from each of those edge nodes, and then send some amount of the learning back without ever exposing the data.

Joe: Right, so some either synthesized or anonymized data, I guess, back.

Grant: Yeah, and--

Joe: Or summarized?

Grant: Yeah, it's kind of a summarized. Like, "Here's what we actually learned." There's also interesting things you can do, a new technology called multi-party computation, which we think is a really interesting use case for private computing, particularly around machine learning. We think there's opportunities there. Yeah, I mean, but ultimately, like, that data that you're running that off of, you know, I think, it's not really your data, right? It's the enterprise's data.

Joe: Right.

Grant: And so, when you centralize it, and you're learning from it, you're taking something that's not really yours, if you're, you know, just running the SaaS service, and you're trying to extrapolate all this value from it. And sure, your terms might say that you can do it, but, I don't know that every enterprise wants you in that position of where you're...

Joe: Yeah, I expect it's one of those things, probably, and particularly with the good procurement departments, who probably have different experiences with how okay they are with it. I guess what's interesting, and we've mentioned Replicated, obviously, you believe in this whole movement to the extent you're building a company around it. At a high level, what does this look like? Is this kind of like, is this sort of like a virtual appliance, but with Docker containers, and targeting a Kubernetes install? Is this something different, what's, how does this take form?

Grant: Yeah, so Replicated has really evolved. When we first started, we modeled a lot of what we did after GitHub Enterprise. So you kind of mentioned earlier, that the idea of delivering a VM, sort of these like OVAs, and that was what the first version of Replicated really took on. So like look like at GitHub Enterprise, I mean, if you're not familiar, GitHub Enterprise is about half of GitHub's revenue, and it's, you know, basically, a--

Joe: It's valued at about $3.25 billion, roughly.

Grant: Yeah, exactly. If you put a number on it. GitHub Enterprise was this really, I think, a great example of someone that, they just decided to put a great experience around managing and installing a piece of on-prem software.

Joe: Yeah, so I guess, essentially, you have a Rails application, and a relational database, probably MySQL, and then something that manages a whole bunch of Git repositories on the file system, installed on a single OS, right?

Grant: Right, that was the first version of it. Eventually, they made it possible to scale it out, to do two hosts, so you could spin these up, and there's some more HA. But we looked at that, and we took some inspiration. That inspiration was like, you need to have a great enterprise IT admin experience, for installing and configuring an application.

The first version of Replicated was container-centric, so we never shipped a VM. But instead, we shipped what we could kind of call today, a multi-node software appliance. It was designed to always scale horizontally, but it included the administrative console as part of the cluster.

And as such, you know, became what we would think about as an appliance, like it was sort of operated independently, outside of the traditional, it would just like be whatever the processes that the IT team was using to manage the other software. It was it's own sort of experience.

Joe: Yeah, but I guess, a horizontally scalable appliance, in the sense, that you would give it some number of servers for a whatever, and it would just consume what you gave it, right?

Grant: Yeah, exactly. It scaled out really beautifully. And from the vendor's perspective, we are providing them with the ability to, every time they would ship to the cloud, they could deliver to what we call the replicated unstable channel. So we provided this concept of release channel management, so you could have--

Joe: Okay, so it's sort of like Chrome's channels?

Grant: Yeah, exactly, right? You would have your cloud version. You could be doing CI/CD, and you could have a version that's deployed 20 times a day to your SaaS product. And you could deploy that same thing 20 times a day to your unstable release channel. And then you could run additional testing.

Generally, what most of our customers would do is be watching the SaaS version, find something that was within their slows. So they'd would set these frivolous, set several objectives for air rates. When they found iteration, maybe after a major release, a couple then point releases after, they would promote that to beta, and then, promote to stable.

Within Replicated, we would actually provide the licensing, and license their enterprise customers, generally, against that stable channel, so they could push this release with release notes into all these enterprise environments. The enterprise could be set to automatically update, so they could actually have the update automatically applied.

Or, of they want, they could have this set to actually, let me read the release notes, and then click the apply button. And then this would scale that update out to the, to the multiple nodes, I mean, you'd be running the most recent version. You know, and then we always added some additional, like, we call EnterpriseReady features.

Things like, hey, you need to hook this into LDAP and Active Directory, and so, we can run LDAP sync against your user table. Or you need to have a really great audit log, and we can imbed this audit log into your application. You want to have a support bundle that you generatee when a customer has a problem.. We provide that tooling through Snapshot, to provide that tooling. Basically, all the things--

Joe:It's surprising, the amount of boilerplate that goes into delivering an application in the enterprise.

Grant: Yeah, so, if you look at a lot of the larger, more traditional software companies, that have tens, or hundreds of products, they have what they call a common services team. And a common services team is basically responsible for building the common services across all these different applications. You know, because it doesn't make sense for every team to reinvent LDAP configuration, right?

Joe: Yeah, LDAP, and it's not just authentication, there's like access control, ACLs. Like you said, there's audit logs, there's--

Grant: Yeah, we really run a lot of this, this is what enterpriseready.io is all about, right? It's a lot of these features that you need for enterprise adoption, not just for on-prem, but just also for just general SaaS adoption.

Joe: Right, like literally any kind of software, or SaaS, or on-prem that you want to sell to the enterprise.

Grant: Yeah, it kind of needs this like standard set of call, like table stakes features.

Joe: Right, expect procurement to ask about these things.

Grant: Yeah, and, you know, the challenge is, that we see a lot of times, vendors will deliver those features, but only as a result of some vendor security questionnaire they had to fill out, where they needed to like check a box, to say they had an audit log. But they often didn't think about what the end user actually wanted, right, what's the purpose of the audit log? Like who's going to be using it, and how do they use it?

So they would oftentimes deliver something that was subpar, in terms of quality. And so, the goal of EnterpriseReady, was to describe these features in enough detail that you could actually build something that was useful by the enterprise IT admin, not just something that checked the box.

Joe: Right. Okay, so we've got containers in Kubernetes, is that--?

Grant: Yeah. A sort of standard Replicated platform, you can use different schedulers, you can use Docker Swarm, you can use a Kubernetes. We wrote our own software in the very beginning. And so, it really would operate, and deliver this multi-node software appliance. That's changing a bit now.

So what we've seen is, kind of introducing the like second version of Replicated. The second version of Replicated is really targeted at the idea that more and more enterprises are actually running things like Kubernetes, and they have a way to, they have a process, a pipeline for deploying applications into those clusters.

What we've built at Replicated now is a way to deliver deployable applications. So not actually deliver the multi-node appliance, but deliver the assets and the configuration, options for the customer to then build in to their own existing deployment pipelines.

Think about like a GitOp-style workflow. That's what this was designed for.

Joe: Right, so you mean then, instead of having a specific set of servers that I dedicate over to these multi-node appliances, that can then be remote updated when opted into, or whatever. Actually, hooking into like a more central use, like for whatever cluster, right? Actually just drop into the same kind of deploy release that internal proprietary applications would be in?

Grant: Yeah, exactly. Generally, most companies have a process through which they deploy internally written applications, or open-source components. What Replicated shipped, this is the new product sort of is focused on, is enabling third-party application vendors to distribute their application in such a way, that it fits beautifully into that same pipeline that their enterprise customers are using.

We sort of say, like that GitOps-style pipeline, because we think that is fast becoming the easiest way to think about infrastructure as code, and all these other components. And so, this is really third-party applications as code.

Joe: Yeah, it's an interesting thing to consider. So what do I gain? If I'm moving from this multi-node, "Hey, you just need to have a VPC, and I'll get some instances on it." By moving to this GitOps flow for third-party software, what additionally do I gain, by doing that?

Grant: Yeah, so it's really about what the enterprise wants, right? We think about it as meeting your customer where they want. And the thing that they're trying to do here, is create a standardized process that is more repeatable, it's less one-off, it's less snow-flakey.

What you're doing, is saying, "Okay, as an enterprise, if I run all applications through this exact pipeline." And they all have configurations stored, you know, in GitHub, and there's dual-control, in terms of like, a PR is made to change the configuration update, and then it's applied in this like same pattern. Which, has been a very successful pattern for software development.

If we can do that for third-party applications, what it does, is it creates less overhead for actually running these applications. Because I don't have to learn some new process, I don't have to learn some one-off admin console. I don't have to remember where to go to update this application. But instead, every time there's an update, I get a new PR, to update that application, and then I can have it deploy out through binacre, or whatever other deployment I'm using.

Joe: So I get, at some level this goes back to reducing the number of headcount I need, to operate all the things.

Grant: Yeah, exactly. If you think about 20 years ago, you needed three IT admin to operate one application around the clock. Today, maybe with Replicated multi-node software appliance, you need one IT admin to manage 15 or 20 different applications because they're all a little bit different, and kind of one-off.

In the future we see the ability for an enterprise to manage hundreds or thousands of applications as private, internal versions of those applications, with one or two IT admins.

And so, what we think happens, is this really lowers the barrier for who can actually consume, quote-unquote, "enterprise instances." And so, it doesn't have to be some big bank, or this hot crypto company that are using these applications. But, anybody that cares about the security and the privacy of the data that they're holding, can run private instances of applications this way.

Joe: Alright, well, I mean, that's interesting to see, like where Replicated's been, where it's going, and modern on-prem. So I guess, just thinking about all of this, maybe in closing. Right now, it seems like there's some obvious places, heavily regulated industries, finance and healthcare. I mean, it's as much ground as I think the public/private clouds are making, or public clouds are making on compliance.

There's always, like you said, trusting them versus trusting the unwashed masses of SaaS vendors. But where do you see this going in the broader industry, at what point has this like come full circle, and back?

Grant: Yeah, ultimately we don't believe that it should just be heavily-regulated industries that have access to secure and private applications. We think everyone should have this access. It really comes down to, what does it actually take operationally, to implement this?

Because, you know, if you think about today, like most companies the decision pretty easily, to use SaaS applications. And that's because they're just so easy. If it was just as easy to deploy a private instance, you know, into your VPC, but maybe you don't even think about it as a VPC.

But it's just as easy to deploy this full private instance that the vendor doesn't have access to, as it is to sign-up for the SaaS application, well then, why would you sign-up for the SaaS application? Why would you not use the private version, and retain that security and that control, because you're not going to have to do anything operationally additional, in order to do so?

Joe: I guess, that actually leaves me one more question. Typically today, the ability to deploy on-premise is, and partially this is because, you know, absent something like Replicated, kind of the cost to do that. Like what GitHub had to invest to build a GitHub Enterprise, for example, from scratch.

The on-prem aspect, for companies that offer both, is a lever, to get someone into a much higher-priced plan. Do you think there is a point, at which that stops to be the case? And, obviously, there'll be other levers that will get people in those higher price plans, but that the on-prem version becomes available across the pricing spectrum?

Grant: Yeah, eventually, we don't think it'll be a, that they're going to be the same price. I mean--

Joe: The same price. Yeah, yeah, because I guess, right, okay.

Grant: It's actually no more work, right, you're using the same automation, and maybe it's cheaper, because the vendors not actually supplying the hardware, you know, they're not supplying the infrastructure. The enterprise actually supplies their own.

Joe: Yeah, the margins are much better.

Grant: The margins are better. So, yeah, we don't, and again, I think you'll see price, the product just went through feature-based entitlement, versus like--

Joe: Absolutely.

Grant: On-prem. It's like, you know, it'll be the LDAP piece, or it'll be these other pieces that differentiate the price plans, versus the ability to deploy it privately. We, hopefully, someday it's the same thing as like, well, why would I not put HTTPS?

Joe: Right.

Grant: I'm not going to make that a security feature that you pay more for.

Joe: Which used to be the case.

Grant: Right, exactly.That would be our vision, is that eventually everybody has access to this, and it's just a default, because, you know, why should we distribute all this data so far, and why not just run it privately? We think it makes a lot of sense.

Joe: Yeah, great. Alright, well, thanks so much, for coming by today. Very thought-provoking stuff, for sure. I'm sure some of the listeners will be, be interested in check out enterpriseready.io, and thanks again, Grant.

Grant: Yeah, thanks, Joe.