This week the OpenStack Podcast's guest rockstar was Sirish Raghuram. He's the co-founder and CEO of Platform9 (www.platform9.com), and he's also a former long-term VMware employee. From that unique vantage point, he was able to contribute terrific insights about why enterprises haven't fully embraced the cloud yet and why VMware Integrated OpenStack is probably a net win for the OpenStack community. He also spoke about:

• Why he founded Platform9
• What Platform9 provides
• How containers may change the meaning of PaaS
• Why 2015 & 2016 will be the turning point for enterprise cloud adoption
• Why his team uses Ansible for configuration management
• Who he thinks has done mind-blowing work in the tech world
• What the current monthly Amazon spending break point is, and how we might bring it down

For a full transcript of the  interview, click read more below.

Jeff:                 Hi, everyone. I'm Jeff Dickey from Redapt.

Niki:                I am Niki Acosta from Cisco, and we are super, super, super stoked today to have a very special guest from Platform9, Sirish Raghuram. Did I say that right?

Sirish:             Yeah, you got it Niki. Thank you for having me and it's great to be here today.

Niki:                Awesome. Sirish, we are really excited. The impetus behind Sirish joining the show today is, I don't know about rest of the OpenStack community, but I've been hearing a lot about Platform9. They are getting a lot of attention. What they are doing is incredibly cool. We wanted to bring Sirish on today to talk about it, because they haven't been part of the OpenStack community for long, but as we discussed prior to the show, they actually have good timing in what they are trying to accomplish.

Sirish, before we get into all of that, we usually like to start the show by asking how you got started in tech. Tell us about your roots, your interesting time with VMware and now leading up to, of course, Platform9.

Sirish:             Sure, absolutely. I grew up in India. I was studying engineering, and that's when I got my first PC. I discovered the whole World of Warcraft and Age of Empires. Multiplayer real time strategy games are where it's at, if you ask me. In the middle I would write some code as well. I really took to it. Programming, technology, computer science, it felt like home for me. I graduated. After graduating from Pune I was fortunate to get connected with VMware, and that's how I got started at VMware.

My first assignment at VMware was making Windows XP Boot, our workstation, VMware Workstation 3, because they changed the SCSI style. Microsoft changed the SCSI style. One thing led to another, and I spend 13 years in VMware engineering across many different groups and functions. [inaudible 00:01:58] engineering get a hands on technical leadership or engineering management. Now, here we are with OpenStack and Platform9. The key insight was that, for all of virtualizations success and dominance in the enterprise, the enterprise customer still is struggling to put it all together as a private cloud. The answer has obviously got something to do with OpenStack. We started with Platform9 to make it really simple and easy for anyone at any scale run their own private cloud.

Niki:                Jeff, you look like you want to ask something.

Jeff:                 When did you decide that you are going to build this OpenStack-based company? What was that? What was happening? What was going on?

Sirish:             Yeah. I get asked about OpenStack a lot, especially given my background at VMware. If you think about it, the way we thought about it is, there needs to be a cloud platform. We didn't feel like VMware's in-house cloud platform solutions were the answer. Then when we thought about solving that problem, we could have gone and written something entirely our own or use something like OpenStack, and we also looked at CloudStack. The answer was very easy that it had to be OpenStack, because of, think about it from a customer's point of view. There is this enormous ecosystem of leverage. Their API endpoints are standardized; there is tools that work with them; the storage and network systems that integrate with them. You get the standard API.

OpenStack has become a, or has become a standard for the data center. It's something that the customer wins if you do it. Architecturally, OpenStack doesn't get the credit that it deserves. It's actually a very reasonable loosely coupled service-oriented architecture. Why wouldn't we use OpenStack as opposed to rolling something entirely our own? We're trying to solve a problem, and OpenStack is a part of that solution.

Niki:                VMware launched their OpenStack services distro or whatever. Assumingly, from what I read on ESX, is that posing a threat you think to other players in the OpenStack space given their market dominance over the last ten years?

Sirish:             It's a great thing for OpenStack and the space in general, because if you look at what's happened, and I've had the opportunity to talk to two or three really large VMware accounts that either participated in the VIO Beta or were the kind of customer that VMware was trying to retain by launching VMware Integrated OpenStack. The answer was that these customers had come to the conclusion that VMware's existing cloud platform solutions weren't going to cut it. They needed something which is more like Amazon. The natural answer was to look at something like OpenStack. OpenStack has this fantastic benefit of saying that here is an API that a number of different vendors can potentially implement for you. Be that Metacloud or be that Platform9 or VMware or any of the other OpenStack vendors.

For a customer, it puts them in a position where they have more leverage as opposed to if they were using the proprietary vCloud API, they're completely beholden to VMware. Not just that, the design was something that's a lot more modern. OpenStack's design is a lot more familiar to a world which is using a lot more Amazon Web Services. VMware did a very good thing in realizing that they needed to have an OpenStack solution. Now, for the OpenStack market it suddenly makes brings on ... expands the addressable markets 5X. Eighty percent of an enterprise or seventy percent of the enterprise is still running a lot of VMware. All of those people previously weren't really addressable to the OpenStack community.

Now, suddenly that community is realizing that OpenStack is actually a vCloud platform that they need to be thinking about as well. It expands the addressable market so much. It more than offsets the competition from VMware, and now it's up to the individual vendors to add on their own value adds and differentiation and compete with VMware. It's a great thing for everyone.

Niki:                Do you think that people who are using VMware Integrated OpenStack are going to use it to do a kick the tires kind of environment, and then potentially choose another route for OpenStack? Or do you think, for those particular users that they are going to do VMware Integrated OpenStack, and over time it will get better and will stick with it?

Sirish:             It'll be like predicting which way the future ... which way it works out. It's a little hard to do. I do think that the people who are looking at OpenStack are also realizing that there are other hypervisors out there. There is this newfangled technology called containers, which is very interesting as well. They are looking to achieve greater infrastructure automation. They look at VMware integrated OpenStack as a path, as a stepping stone in the path for their internal infrastructure and that path is going to take them down a path where there is more automation, multiple hypervisors, more loosely coupled distributed Linux-oriented services.

For some, it's a stepping stone that's comfortable. It comes from a trusted brand, VMware that they trust. For others, it's a way to test the waters in OpenStack, while actually looking to make a bigger jump into the OpenStack community.

Niki:                That's interesting that you say that. In a lot of ways, I see that a lot of people are now seeing VMware as a direct threat. The same people have to be very careful because they have these historical strong relationships and partnerships with VMware. It will be interesting to see how all that shakes out, which brings me to the whole reason we had you here. It sounds like from Platform9's perspective that you guys are actually trying to help these types of customers who are dealing with multi hypervisors, multi target clouds. Can you tell us a little bit about the impetus behind finding Platform9, and what you guys do to help solve these challenges?

Sirish:             Sure, absolutely. I'd say, I was at VMware for 12 years. When you are in a company as successful as VMware was, it was a fantastic culture there. It's very easy to get locked into your own cocoon and that certainly happened with us. There was a conversation I got pulled into with a San Francisco based startup in 2013 where they were having a massive spend on Amazon Web Services. They had grown from being a 20-person company to a 600-person company. They wanted now to move off of Amazon and run their own infrastructure. I was brought into help answer their questions and to show them how they could do it with VMware's solutions.

When we actually started having the conversation with them, I realized that they didn't think it was easy or viable for them to build a private cloud. I was like, look, there are all these solutions. There is VMware, there is OpenStack... all these things. They said, "Look, our operational team is eight people; we will need to get to 20 people in order to pull this off." I realized that ... if you think about it, the cost for the company was such that they couldn't do it. They continued using Amazon for far longer than they wanted to, because they felt there was no other solution that they could really implement successfully. That was a shock to the system, to me when I realized that for all of virtualization's success...virtualization is really the underpinning of cloud infrastructure...on the private cloud side people struggle with it so much. This is a very sophisticated team I am talking about. These people were, I'd say, power users to put it mildly, and they weren't confident of pulling off a private cloud. That's when I realized that there is a problem that needs to be solved, and we said we are going to go solve it. We started Platform9 with a goal to make it ... We asked ourselves, why is it so hard? When people can rack and stack hardware and put Linux on it very easily, Why is it so hard to go from racks of Linux or racks of VMware vSphere into your own mini Amazon? There is no good reason for that to be the case.

We started Platform9 with a goal. We asked ourselves, if someone has racks of Linux or racks of VMware, can we get that private cloud operational in five minutes? That's a goal we have for ourselves. We do that by hosting OpenStack as a web service. It's a cloud service, which means that customers sign up at Platform9 and they get a fully tuned production-ready OpenStack control plane that they can plug in their infrastructure with it, which means that suddenly they don't need to spend any time in that complex management layer which they struggle to develop. They have the hardware, that's not the hard part for them. For them, it's a management fabric that pools that hardware together into a private cloud, and we took all that pain away by saying, "You don't need to install it; you don't need to configure it; you don't need to monitor anything; you don't need to troubleshoot anything, and you don't need to have ways and means by which you can resolve issues and roll out actions in your advantage."

We take all of the responsibility of delivering the control plane to you with an SLA that you can rely on. You can actually focus on using your private cloud and going on to achieve greater infrastructure agility and automation as opposed to trying to get it up and running.

Niki:                Are you operating the cloud long term? I am assuming you guys are handling upgrades and all that good stuff too.

Sirish:             Yeah. That's actually the most important thing. If you look at getting an OpenStack control plane up, there are many different ways of doing it today. There is Pathstack, RDO, Mirantis, DevStack. There is many different ways by which you can get an OpenStack instance up and running. That's not the hard part. The hard part is keeping it running, in production, at scale while you have users using it. That's where you need to have the full loop between ... You need to have telemetry that monitors your OpenStack services for health and detects issues that are happening, that are going around. You need to have telemetry that then goes and has the ability to alert the concerned engineers, and then they have the ability to roll in and resolve issues proactively. Especially a lot of the automation that Amazon Web Services has in their management fabric in terms of keeping it running at production at scale. That's what's needed in the private cloud. That's why we deliver Platform9 as a service with an SLA saying that, "Look, your control plane is our responsibility; you don't have to miss a beat. You can use it and we will take complete responsibility for its availability, its scalability, its performance and its upgrade SLAs and so forth. All of that goes out of the window; we take care of them freely."

Niki:                I read on your website, one of the goals or the intentions of Platform9, I'm not sure if this is something that exists today or something that's on your roadmap. Your intent is to have multi hypervisor support, is that correct?

Sirish:             That is correct. We declared general availability for KVM and [inaudible 00:13:00]; that's about six weeks ago. We are actually now in beta with VMware vSphere. We have some really large customers who have massive VMware deployments who are very excited about what we are doing. After we are done with VMware, we will be announcing updates on Docker as well. Essentially, ESX is still the world's best hypervisor, but you don't need it for every workload that you run. If all you are trying to do is CI and CD and test and dev automation, you don't need a lot of the features that VMware ESX has. You may legitimately choose to use KVM, or maybe you will start to move to micro services architecture and maybe use more containers.

We think that the private cloud has to be decoupled from your choice of virtualization platform and customers should be free to choose any mix of virtualization technologies that works for them. They may now ... the production workloads that need higher SLA and a very resilient underlying infrastructure on VMware or they may run newer applications and containers and test and dev work that will ...

Niki:                I think we lost Sirish. Sirish, can you hear us?

Sirish:             Platforms that work for them, and we want to enable them to use that in the private cloud seamlessly.

Niki:                Looks like we lost you there for a second, but I think I got the basic gist of what you were saying. How do you ... Let's say, hypothetically you got your OpenStack [inaudible 00:14:35] Platform9; you've got workload and you want that workload to target a VMware hypervisor. Are you handling that through the OpenStack layer to the scheduler, or is that happening on some other component that might be ... Platform9's kind of secret sauce?

Sirish:             We are all based on OpenStack. Let me actually walk over to a location where I probably have better wireless range. It's all based on OpenStack. Yeah, we are an OpenStack based company, and we will continue to remain on OpenStack. What we do is have the scheduling logic to integrate with OpenStack, the KVM based resources that an organization might have as well as any VMware resources. Both of these resources can be pulled into one private cloud. What that means is that you can then deploy your virtual machines regardless of whether that image is a VMware image or a KVM image. The scheduler has the ability to look at based on the image type that you are trying to deploy from; if it will have the ability to actually pick the right underlying infrastructure.

Niki:                Very cool. Then to the user, those are all going to appear in the OpenStack dashboard, right?

Sirish:             It looks exactly the same. OpenStack Glance image library represents all of the images that you have. It looks exactly the same. The user doesn't even see the differences between VMware underneath or KVM underneath.

Niki:                How are you handling storage? That's always the big one. It sounds like everyone that we've talked to on the show has a different spin on block storage, volumes, and object storage.

Sirish:             A lot of the challenge with OpenStack is in actually ... It's like a framework. It's like a kernel that you can use to do many different things. I think the challenge is in putting it together in a way by which you eliminate, subdue that complexity that arises from the million different ways of doing things. With Platform9 the philosophy is as simple as, if you deploying a block storage device today, you have a server, let's say, that's hooked up with storage. It could be direct attached storage or it could be network attached storage. When you import that server into Platform9, the way you do it is you sign up for your Platform9 control plane and you download an agent and drop it on to that server, and that enables the trust and management relationship between your server and your Platform9 control plane.

When you do that that agent introspects any storage that's available on that server, be it direct attached storage or network attached storage, and seamlessly imports that via the nova and the Glance and the Cinder APIs in OpenStack. Likewise on network as well, on storage and the network, the key achievement is in eliminating the complexity that people face when interfacing OpenStack with the storage and network subsystems that they may have.

Niki:                Are you using Neutron currently?

Sirish:             We are moving to Neutron. We were based on Nova network. We've only recently upgraded from OpenStack Havana to OpenStack Juno. By the way that's a story in itself, because our customers next week are ... As of now many of customers are still on OpenStack Havana, we are actually rolling out this upgrade next week. They are going to get an email. Their upgrade process looks like this. They get an email saying, hey, there is a 15 minute downtime scheduled for this time, next week; let us know if you want to reschedule it. They don't lift a finger, right? At the end of that downtime period they get an OpenStack Juno enrollment completely up and running. They don't need to lift a finger, it all works for them. It's completely touchless from their point of view.

As part of the Juno upgrade, a key driver to upgrade to Juno was to move to the more stable Neutron implementation in Juno, because we did look at Neutron in Havana, but we decided to stick with nova network for its stability there. In Juno we are actually making greater use of Cinder and Neutron.

Niki:                Very cool. Jeff, I feel like I've asked a barrage of questions, and I think it's your turn.

Jeff:                 You've asked some great questions. It has been good. What does size and scale look like for you guys? What's the ideal customer and how large do you guys go?

Sirish:             We actually have a lot of inbound interest from very small customers. It's a lot of the fact that small customers who may previously have said, "OpenStack; no way; that's too complex for me." We are making it accessible, so easy for them that many people sign up and get up and running very quickly. The sweet spot, is I think, that OpenStack solves problems at scale. You have a certain minimum scale at which the value proposition for OpenStack in infrastructure automation and resource pooling really becomes very high. We think that that scale is somewhere between 50 servers and on up. Fifty physical servers and on up.

Our largest customer plans to reply us on a couple of thousand servers by 2017. They are starting small with a 50 server deployment right now, but they are licensing Platform9 statewide. We have, I'd say, five customers that plan to get to the thousands of physical server scale, but they are not there yet today. The way infrastructure software works is they tend to test at first at 20 server scale, then 50 server, 100 server and they scale very simply. Very few of them flip a switch and say, "We are going to run this in 2000 servers tomorrow."

Niki:                Are you deploying this in a hosted model, or is this a customer premise implementation?

Sirish:             The infrastructure, the actual resources, the compute and the storage and the network resources that they are using always tends to be within the customers' premises. The control plane for all of these customers is hosted by Platform9. Now, we do have, I'd say, there is ten percent of our customer inbound that wants a purely on-premises solution. We don't have that today. It is something we are architecturally designed to do. We could make it up available relatively quickly. It's a matter of prioritizing our backlog and getting first things done first.

Niki:                Very cool. That's a great model. If you can centralize the control plane and then still give the customers the warm and fuzzies knowing that their VMs are still within their four walls. I think that's pretty brilliant.

Sirish:             The insight there was, today there are so many customers that are distributed themselves. For example, our biggest customer has five different geographies. They have data centers in San Francisco, New York, Amsterdam, Japan, and India. What is on premises anymore? They don't want to have five different management systems for each data center. They want to have a single pane of glass, and they want to use these data centers with regions a lot like the public cloud. The realization we had was as you get to ... as the world gets increasingly decentralized, people are coming to realize that you need a management fabric for the private cloud that spans the globe regardless of where your actual infrastructure is. Then you are free to plug and play with infrastructure in different geographies.

Niki:                I did see too... I think it was on your supported platform page, maybe it was a different page. It looked like there was going to be or there is some integration to some of the more popular public cloud platforms as well. Is that right?

Sirish:             That is something we get asked for. We do get asked in particular about Amazon, and whether customers could bring in the single pane across their internal infrastructure and the public infrastructure. Again, this is something that's maybe applicable to OpenStack in general. OpenStack should become ... It's a standard. It is a de facto standard for how to consume infrastructure in the enterprise context. OpenStack itself should have a provider, a driver that can let it use Amazon capacity or Google compute capacity in the backend. Stuff that we want to do, again, there is a lot of interesting things you do, and you have to choose first things first.

Niki:                Go ahead, Jeff.

Jeff:                 Can you hear me? I'm curious about the multi-tenant, what you guys are doing around that, and then the collaboration.

Sirish:             Multi tenancy in the context of our customer accounts themselves and how we... ...

Jeff:                 How do you solve that problem that seems to be a big issue?

Sirish:             There is two handles to multi tenancy with Platform9, because we are a SaaS based management fabric. We do not share customer data. For every customer account, we bring up a dedicated control plane instance as opposed to maybe letting multiple accounts share the same control plane. That was a factor ... It comes out of the fact that even though it's only hosting metadata, the control plane only has access to metadata. It does not really have any VM images or VM instances. It still is sensitive data that we did not want to risk any compromises around.

Every control plane has its own dedicated root certificate authority and all of the metadata communication that happens between the data plane software, the software that's running on the hardware that is being managed by that OpenStack instance, is encrypted, strongly encrypted with certificates that are dedicated to that root certificate authority. Even we don't have access to the metadata that's stored by the control plane for our servers, for our customers I mean. Nor do customers share anything. They share nothing other than the fact that it is the same company that's servicing them, but their control plane is entirely isolated. It can be locked down to their network range.

If you sign up as a customer to Platform9, you can configure your Platform9 control plane to be accessible only from your networks. That's on the multi tenancy on our end. It's a model that works very, very simply, and addresses most of these info side questions that customers tend to have.

Niki:                One thing that seems to be challenging too, at least from the operator perspective is being able to monitor the entire stack all the way from the bare-mental instance all the way up through the OpenStack layer and potentially beyond. How are you guys handling telemetry and monitoring? Why did you make the decision that you made? There is a lot of choices out there obviously.

Sirish:             There is a lot of choices. Look, I wouldn't claim that this is the only way to do it. What we do have is something that's working very well. Let me explain what we do. Our architecture, again, has the control plane and it has a data plane. What we have is the control plane itself aggregates key logs and monitors statistics and API calls from the data plane. The data plane actually rose itself and exposed it to the control plane where we have collectors. We have collectors in the control plane as well, which are internally piped into our own centralized log monitoring infrastructure.

We monitor not just logs for possible error traces, but also API traces, and performance latency. All of that is then hooked into ... we use paper trail internally. We could be using the ELK framework; we actually then pipe that into our alerting system, which is VictorOps. When a customer runs into an error, literally my cell phone goes off, the VictorOps app on my cell phone goes off. For those who are not familiar with VictorOps, VictorOps is a lot like page equity. They are conceptually very similar.

The net result is, when our customers are using Platform9, when something fails we see it sometimes before they even realize something failed. We can then jump on it and resolve it. We have actually fixed issues without customers ever telling us there was a problem.

Niki:                Were you guys out with Ceilometer? Is there any component of Ceilometer that you are using now, and in full disclosure that there is plenty of people who don't much like those people who are not yet on Neutron. How are you handling that?

Sirish:             We are not on Ceilometer yet. We started OpenStack now has 15 different services. It's a matter of prioritizing the ones that we are doing first before the others. Ceilometer gets ... it does come up. Service providers in particular look at Ceilometer as a way for them to enable billing. Now, there are dedicated solutions that they could be using. They could also be running Ceilometer themselves and integrating that with their Platform9 endpoint. There are solutions that we offer to these customers today, but it's not something that's included in the Platform9 core distribution today.

Niki:                I'm assuming, along the way, you guys are doing bug fixes in contributing stuff back up to OpenStack. How do you determine what tries to go back to OpenStack and what doesn't?

Sirish:             We do make a lot of bug fixes. I did some queries last year. At some point we've made 400 bug fixes in six months. Look, a lot of those are probably specific to the way in which we package and deliver our software. It's how much of those are core bugs was a matter of packaging. The line is sometimes fuzzy. We are not yet in a position where we