Boris Renski is the Co-founder and CMO of Mirantis, an open source platform for Kubernetes on-prem container orchestration. In this episode, Boris discusses how Mirantis has been able to effectively pivot multiple times as technology has evolved.

Transcript

Intro

Michael Schwartz: Hello and welcome to Open Source Underdogs, the podcast about successful open source business models.

I’m your host, Mike Schwartz, and this is episode 32, with Boris Renski, Co-founder and CMO of Mirantis.

This episode highlights how sometimes you have to pivot when your market reality changes. In their case, a way for managing virtual machines and towards containers and Kubernetes. Without further ado, let’s Boris tell the story in his own words.

Boris, thank you so much for joining us today.

Boris Renski: My pleasure, thank you.

What Does Mirantis Do?

Michael Schwartz: The Mirantis website says “Take back control of your container infrastructure.” Keeping in mind that this is a podcast for business people – can you help explain what that means?

Boris Renski: Basically, as anybody living in the open source world today would attest to, there’s a lot of talk about doing hybrid cloud, using containers, and Kubernetes. And this is one of a kind of most common waves that is happening right now, at least when it comes to a cloud infrastructure.

And one of the things that typically happens in hybrid cloud is that you need to find a way to very cost efficiently run Kubernetes container-based infrastructure on premises.

And the problem with Kubernetes and containers in general is that this is a cloud-first, cloud-native of technology that was initially adopted by developers for building containerized apps and running them in the public cloud.

In the public cloud, a lot of the low-level infrastructure constructs are solved for you. So, you don’t need to ever wire up the servers together, you don’t really need to connect the storage and deploy your custom storage enterprise solutions, etc. – it’s all there. It’s all within an API call.

So, now, with containers becoming a mainstream fabric for building applications and running hybrid applications, the problem of cost-effectively running them on-premises is becoming increasingly more acute. And the most common solution to that is to run them on top of some sort of virtualization layer, like VMware for instance. Which makes things simpler, but it adds a layer of complexity, and it also adds cost.

So, what we ultimately do is we enable companies to run hybrid cloud infrastructure with the on-premise piece, the containerized on-premise piece running directly on bare metal, leveraging exclusively open standards, and we do it in a very cost-efficient fashion.

Pivots

Michael Schwartz: Ok. So Mirantis is in a fast-evolving sector, to say the least, and you’ve had to pivot a few times along the way. Can you talk about those pivots, and why they were necessary, and how they worked out?

Boris Renski: We’re kind of an atypical startup, I would say, because most startups that you would see coming out of the Valley is a couple of smart guys that built up cool open source software that has become popular. They’ve gotten some VC funding and off they go. And hopefully, they’d built a company out of that or maybe exited it or maybe not.

Our story is a bit different than that. We’ve actually been around for a while, we’ve been around for over 10 years. And the story of Mirantis is that of a continuous evolution and continuous pivoting.

So I started, I think it was a 2002-time frame, shortly after I moved here from Moscow. I started doing something that I would argue every other Russian of IT background tends to do, and that is sell Russian engineering talents to Silicon Valley-based companies.

I guess not so much through my personal talents but through some degree of luck and the fact that I was able to find a very talented group of engineers, I was able to scale that company to about 50 people. And in 2006, merge it with another company that was doing pretty much the same thing – and this is how Mirantis was formed back in 2006.

It was myself, my partner at the time, Alex Friedland, and this company of about 100 people altogether, that was just kind of a generic software outsourcing.

Shortly after the merger, I would argue this was the first pivot to your question, because it was clear that just doing generic selling of engineering talent that the scale of a hundred people is not something that you can build a huge company out of. It was clear that we needed to specialize.

And we had at the time already a bunch of customers that we were doing some infrastructure stuff for. For example, Cisco was a customer for whom we were doing some hardcore networking stuff at the time. And this was 2006, time of cloud and kind of this infrastructure cloud revolution.

So, we started moving in the direction of just cloud infrastructure, and we started playing with everything that’s hot out there – big data, all the different open source cloud technologies. But in general, we moved from being completely generic to be more specialized, but we stayed, as far as our value proposition, focused on just services.

And then, we, I think, spend probably 4 years or so in this configuration, slowly growing the business. And then, when the cloud became mainstream, again, we were doing a whole bunch of stuff, so we figured we need to kind of specialize further. And we need to just take one area, we can just be doing cloud and big data and everything that one can find.

So, we decided to focus on cloud and specifically on the technology that was kind of up and coming and cool at the time, called OpenStack, which I’m sure you’ve heard of. And at the same time, still stick to the kind of value proposition around services – no products, just selling services. So, this was I guess the second pivot.

The first pivot was from kind of a generic software to cloud infrastructure. Second pivot from kind of generic cloud infrastructure systems integration, to focusing on a specific layer, kind of OpenStack and OpenStack adjacent open source projects.

I think it was probably a year or two years in that mode that we ramped, that we were actually able to ramp quite a bit. I would say that the reason for that ramp is because unlike anybody else in the space, who was trying to immediately build a leverage business model around OpenStack at a time, we were just selling people.

We were just selling services, and we were the only guys that were in town doing OpenStack services and doing it in a very competent fashion. And, of course, most of the large companies adopting new open source technology, they tend to shy away from start up some products in the early days until the winner emerges.

So, they came to us to actually build some bespoke solution, using either OpenStack or some OpenStack adjacent technology, like, for example SAF or OpenContrail, because there’s a lot of open source projects you need to stitch together whenever you build infrastructure.

There was another next wave of growth, so to speak, that took us to the next level. The third pivot was actually trying to introduce elements of a leveraged business model. So, this happened already I think in maybe 2012/2013-time frame, when we were already pretty popular open source infrastructure and OpenStack specifically at a time.

And what we did is, we basically started trying to look for patterns of commonalities between all of the different projects that we would implement. A lot of them were very different, but some of them had a lot in common.

We’ve basically built this kind of a library that gathered a list of the different configurations, the common configurations for deploying on-premise cloud infrastructure. In plain words, it was just a bunch of puppet libraries at the same time, like puppet scripts.

We started collecting it internally at first for just being able to deliver services more effectively to our customers, and then, I think 2014-time frame, we actually open sourced it and made it publicly available.

We said, okay, we now have this set of a puppet script effectively for deploying OpenStack, and OpenStack adjacent projects that everybody can use, and if you’re within those configurations, if you’re deploying using the scripts, these specific configurations will be able to actually go ahead and provide some sort of SLA support for you. That was a third pivot. From just pure-focused OpenStack services to monetizing support SLA around it.

The fourth pivot was kind of both from the process and I will say technology-focused standpoint. So, between I think 2013/2014-time frame, where we emerged as this OpenStack implementation and support vendor, up until I would say 2017/18-time frame, we’ve been focusing on first of all evolving this leveraged business model.

So, basically, moving our support from just providing kind of like initial response and ongoing SLA, to more of, like, an uptime SLA. So, moving up the value stack and adjusting our business processes accordingly. We are therefore being able to extract more margin from the customers we already have.

And the second vector of evolution was around the technology itself because obviously the world has kind of moved on to containers and Kubernetes. VMs, on-prem VM orchestration has become more of a commodity.

We started building more and more competence around that, and moving our product from being exclusively focused on just VM orchestration on-prem to basically a container orchestration on-prem and hybrid cloud using containers and Kubernetes.

I would say that, probably, we are 80% of the way through our fourth big evolution at this point, and looking forward to the fifth one. That’s kind of been the long and winding journey for us, evolving the business model.

Most Important Projects

Michael Schwartz: So, there are 200+ repositories in the Mirantis GitHub. Are there any themes in the software, and which are the most important software projects for your business model?

Boris Renski: It’s a good question. I think out of 200, only a fraction of them is active and alive, because 200 – this is like from when we started. And then, the repos, we tend to commit more to, and then do kind of spikes, and then it goes into the maintenance mode or just goes away.

I wouldn’t say there’s just like one repo that’s the most important one, but there’s a collection of repos. But all of them are around a theme of lifecycle management of the software. So, we have this component tool product Mirantis cloud platform, called DriveTrain.

Back in the day it was extremely unique, but now it’s more kind of more mainstream. It’s a system for managing the lifecycle of a distributed system, using continuous delivery approach.
What that means is that for the private cloud, or the hybrid cloud that we have deployed for the customer, every single service, every single component, we treat as an atomic element.

And we separate the binaries and configuration, and we codify workflow for updating each one of these components, using a continuous delivery pipeline. And DriveTrain is a system that makes basically all this magic happen.

The core problem that this ultimately solves is basically keeping the main components of a distributed system up-to-date for the customer in a very seamless and non-disruptive fashion. Because in our view, the biggest disruption that cloud brings to the table, is the fact that you don’t really need to care about the lifecycle of the infrastructure software anymore.

So, if you get it from AWS, it’s just there, and they release new versions seamlessly, and new services, and then you can just start using them – you don’t need to go for the upgrade cycle.

The whole big problem that we were focused on solving back from the OpenStack days is how do we do that same thing, only not for the public cloud environment but for the hybrid cloud, and specifically for the on-premise piece of it.

And all of that, relay it, aggregate it under this project called DriveTrain, which consists of probably several dozens repos. And this is where we probably do most of our R&D and hard work. So, hopefully that answers it.

Contributions

Michael Schwartz: Are Mirantis’ engineers the majority of contributors to these projects?

Boris Renski: The short answer is yes, but I want to qualify that a little bit. So, when we build a hybrid cloud environment for the customer, typically, there are kind of common upstream components like Kubernetes, like Ironic for bare metal management, like OpenContrail, or Calico for networking, Ceph for storage, etc.

Those are really what I would call pure open source projects with large community around them, where Mirantis is just one of the contributors, and we package them, and we deliver them.

And then, there is a number of components like, for instance, DriveTrain that glue these things together. And when it comes to the glue part, it’s mostly Mirantis contributors with some of outside community consisting of our customers or maybe just users outside of Mirantis.

Material Contribution From Open Source

Michael Schwartz: Do you think that open source software development has materially contributed to the business model?

Boris Renski: The whole company, the entire business model revolves around delivering open source infrastructure software to customers in cost-efficient, and simple to consume fashion.

So, the answer is absolutely yes. Our entire business model is predicated on being part of the open source community and taking the software that we helped build in the open to all customers.

Michael Schwartz: It sounds like some of those components, if you change the license on them, would customers really care? And if they’re mostly Mirantis’ engineers working on them… So I guess I’m wondering, yes, sure, you are deploying a whole stack of open source, and that’s mutually valuable. But I’m wondering about for the software development activity at Mirantis – do you think it being open source really makes a difference?

Boris Renski: It’s a good question. I think the answer to that question is still yes to a large extent. It has to do with the fact that one of the big advantages that we bring to the table, and one of the big things that we do that a lot of the competitors don’t do, is that we allow our customers to take complete control over the infrastructure that we deliver for them as an option, through what we refer to as a build-operate-transfer model.

And because our customers are large telcos and large Enterprise, being able to have that option and being able to actually operate the infrastructure that we’ve delivered for them independently, at some point in time down the road, is very important.

And having an Apache 2 permissive software license is instrumental for that happening. Because if we have some sort of license that requires them to pay fees or limits them from doing whatever they want to do with the software weakens the value proposition behind the build-operate-transfer model.

Build Operate Transfer

Michael Schwartz: Part of this process is used in complex systems, like Toshiba built the subway system for some country, they operated for a period of time and then they handed it over. But I’ve never actually heard this used in IT, build-operate-transfer. I’m wondering, has this approach been successful, and what did you learn along the way when you delivered that?

Boris Renski: Yes. It definitely has been working for us.

One thing that we have learned is that I guess the promise of the transfer is probably more important than actually doing the transfer. I would say that less than 20% of the customers that we do actually go through with the transfer. Most of them just prefer to a kind of have that as an option in the contract, should the situation change.

It is common in the pockets of the IT industry. And the reason actually, again, why we are able to do it, and why we’ve been offering it is because one of the pockets of the IT industry works common as exactly like IT staff outsourcing.

So, back in the day, during this pre-first pivot story of Mirantis that I told you, what we do, I just mentioned, would sell talented engineers to the Silicon Valley companies. But the way we do it is, we proposed the same exact build-operate-transfer model in that we would staff an R&D center that is offshore for the customer.

We would basically implement customer’s business process and culture in the offshore center. We would run it for them, and then we’d give them an option to actually buy it out and take over. And what they’ll have is their own offshore center.

And that’s extremely common in that segment. And when it comes to building hybrid cloud infrastructure, it’s kind of not that different, because it is a bit of a complicated thing. A lot of it is about actually implementing the process and not just the software.

So, you need to have the people that know their organization, that know the change management process for updating the software, that know the existing systems that the customer has. So, it’s not just like, “Here is a piece of software – go use it.”

It’s a big kind of a cultural transformation in a lot of cases. We have the roots of doing that back in the IT staffing industry, and we’re basically been able to transfer some of that to actually the notion of building hybrid clouds and implementing all the necessary kind of a cultural process associated with that.

Transfer People

Michael Schwartz: When you transfer the, let’s say, the operation to the customer, do you still offer to transfer some of the resources?

Boris Renski: Some yes, but it’s a little bit different from the previous example, where I’ve told you it’s just primarily the people that your transfer. Here, it’s a little bit more software and process biased, so typically you made a transfer of a few people, but most of the time it’s the people that the customer already has.

It’s kind of like, when we start this process typically, we would require that a customer would dedicate a number of people that would be effectively integrated into our Ops team, and will help run that hybrid environment that we are to leave behind.

So, in a way, you could say that with transfer people, it is just that they were all on the customer’s payroll day one. For a period of about six months, they are effectively operating as an integrated part of our team. But then they get transferred back onto the customer’s operational management.

Transfer People

Michael Schwartz: For customers who have transferred off, do they continue to renew their software subscription? And I’m wondering about how your renewal rate is for those customers?

Boris Renski: It’s a good question. The renewal rate is pretty good. We look at the software subscription as kind of like a spectrum. If you look at our subscription business, we have three offerings within the portfolio: OpsCare, ProdCare and LabCare we call them.

The OpsCare is typically the tier that the customers start with before they have transferred annual operations in-house. And at that level, we give the customer an uptime SLA on the environment. And it’s our team in collaboration with the customer’s team that is following a process that is actually delivering on that SLA.

And then, the one down from that, ProdCare is more kind of resembling of a typical software subscription that you get from somebody like Red Hat or Canonical, where we’re basically giving SLA on the initial and ongoing response time, and provide customer to the continued access to like bug fixes, patches and things like that.

LabCare is the lowest level, where basically it’s kind of like 8 by 5, you just get barely any access to the support line but you still get access to the software updates. If there’s any severity, one issue that you encounter, we are responsible for producing a patch within a certain given time and giving of the update.

Most of the customers that we see go for the build-operate-transfer cycle, they would start on OpsCare, and then, they would downgrade to ProdCare, and then eventually LabCare.

But, I think it’s only been a couple of instances where they went ahead and just completely disconnected, and did not even do LabCare at all. I would argue that probably both of instances where they just decided to discontinue the cloud, or they just did the different direction, or something like this.

So, most of the time, they downgrade a subscription, but they don’t move away from subscription all together.

Team

Michael Schwartz: Obviously you have been used to building some of the team offshore – I’m wondering about what’s current strategy for building the team? Do you have a sort of central headquarters, and do you look to hire regionally? Is it very global, like, how do you meet the new demand?

Boris Renski: This is, again, one of the things that it’s kind of like it’s been hidden strength of the company, given our history that I’ve described, back in the day, core value proposition being building these distributive teams.

The area that we focused on kind of a building up is continuously changing, depending on the opportunity and market conditions. One of the big value propositions is cost-efficiency. We are able to deliver that cost-efficiency in part through having access to the global talent pool.

We have a tad over 500 people in the company, and most people are distributed across about 7 locations. Our HQ is in Bay Area in the Silicon Valley, but we have an office in Austin, where we do a lot of support.

We have an office in Poland, we have an office in China, we have an office in Ukraine, we have an office in Germany – basically all over the place.

The way we figure out where our staff is kind of continuously revalued. I’ll just give you an example. For instance, one of our competitors back in the day was Rackspace. And Rackspace is known to have a lot of good support people because their core value prop was fanatical support.

They’ve gone for some private equity acquisitions and restructurings and things like that, and they reprioritized some of the business directions, which, making a long story short, made it possible for us to go ahead and hire a lot of the people that were kind of like a fallout of this reorganization in Austin, Texas area, because this is where a lot of their support people were. We did this kind of a blitz campaign, and we built up a bunch of people in Austin to do the operations and support.

With these kind of opportunities, they continuously come around, and we tried to kind of recalibrate, and we tried to put emphasis on hiring in one area versus the other, depending on the situation.

Biggest Challenge For Company

Michael Schwartz: What do you think are the biggest challenges for open source software startups today?

Boris Renski: I can only competently speak to the challenges in the infrastructure space, which is where we’re focused on. And I think that the biggest challenge is figuring out the monetization strategy.

By that I mean, because the software is free, open source in the infrastructure space can be one of two things. It can be either a way to decrease your spent on R&D and leverage in ecosystem, that you can basically deliver particular platform more cost-effectively than proprietary alternatives because other people are building that software that you’re going to be reselling.

Or, even more commonly, it’s kind of like a marketing vehicle that will pull through some other value propositions. So, back in the OpenStack days, OpenStack was super hot – everybody wanted it. So, it was your way to get into an account and see if you can spread your wings there.

Now, it’s more like Kubernetes and solderless and things like that. So, you can grab onto Knative, or Kubernetes, or some of ours hot projects, and pick the interests of the Enterprise and then get in there. It’s a way to decrease your marketing and sales costs.

The software itself is free. You can use it to do one of those two things, but you can’t really make money on the software itself. There has to be something else that you’re selling. And that something else can be a datacenter space or hardware, which is what basically public cloud providers do.

People say that AWS is the most successful open source company out there because they built a 25-billion-dollar business by taking open source components and layering them as a way to sell commodity, datacenter, and hardware at the high margin.

In the case of Red Hat for instance, they sell support SLA, which is a more common approach, but that kind of boils down to selling people to a large extent.

There’s other more where you can sell, hardware appliances. Like a good example of that I think is Nutanix, where they’ve used a lot of the open source components to build their solution, but ultimately they are kind of pushing appliances as their main thing when they’re starting out.

Figuring out what that thing is, and understanding why you’re better at actually being able to deliver on that other thing than others, use core. For us at Mirantis, we were able to get some degree of success because we were always very good at selling people.

And when we layered things like OpenStack and Kubernetes on top of that, that made up easier for us and more cost-effective to sell these people because we were kind of like getting pulled through by what’s project being hot. And we were able to monetize this people thing. For public cloud, it’s hardware and datacenter.

So, the question is, what is it going to be for you that you’re going to be selling, because, for sure, it’s not going to be the software itself.

Advice For Entrepreneurs

Michael Schwartz: Any advice for the people, the entrepreneurs, who are starting these companies? Because you’ve had a couple of entrepreneurial experiences, so, just wondering if you have any closing advice for those poor souls?

Boris Renski: If you are starting a new company in the open source infrastructure space, I think you have to make a decision early on as to what your play is. And there’s generally two types of plays.

You can either focus on something important, industry-focused or vertically-focused value proposition, and build up a long-lasting business around it. And you can make that decision like Day 1, in which case, you should not tie yourself to any particular open source project or wave, but just focus on open source as a potential way of decreasing your expenditures on R&D and just stick to that strategy.

Or, alternatively, you can say that it’s going to be a two or three-year play, and I’m going to ride a wave, I’m going to ride like a Kubernetes wave, like what Heptio did.

The latter is actually, I would say, the play of the 80% of the VC-backed startups today. And I think that you need to be very conscious of what your play is and stick to it. What you don’t want to do is kind of try and mix between the two.

I would argue that we at Mirantis, for a period of time, were a little bit confused about “Are we like an OpenStack company, or are we an on-premise infrastructure company?” I think being very crisp on what you are out to accomplish, Day 1 and sticking to it, is key.

It’s easier to say, but it’s very hard to do when you’re actually trying to do it.

Michael Schwartz: Awesome! Lots of really, really good content and thoughts there. Boris, thank you so much for spending time with us today.

Boris Renski: Of course, my pleasure. Thank you, Mike.

Credits

Michael Schwartz: Thanks to the Mirantis team for helping to organize the interview.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke from Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

If you have feedback or comments, tweet at us. Our Twitter handle is @fosspodcast.

If you’re a fan of the show, and you listen on iTunes, please leave us five stars in a comment. That helps us get the words out to others.

Next week, we interview Peter Mattis, one of the founders of CockroachDB.

Until then, thanks for listening.