Voices in Data Storage – Episode 24: A Conversation with Sirish Raghuram of Platform9

Guest

Having experienced virtualization, IaaS and cloud-native industry transitions first hand, Sirish believes that open-source represents the future of enterprise hybrid clouds.

Sirish is passionate about enabling IT Ops in large enterprises to be successful with their cloud initiatives — being able to easily adopt and manage VMs, Kubernetes and Serverless at scale, across ANY infrastructure, with minimum management overhead and without breaking the bank.

In addition, Sirish is focused on building Platform9 – across customers, employees and partners – as the industry leader in hybrid and multi cloud.

Prior to founding Platform9, Sirish was an early engineer at VMware who went on to technical and management roles. His work at VMware led to several products, features and patents.

Outside Platform9, Sirish follows cricket, makes his kids laugh, and builds his collection of fast lenses and unprocessed photos. His favourite books include the Harry Potter series, Blue Ocean Strategy, Inbound Marketing and Innovator’s Dilemma.

Transcript

Enrico Signoretti: Ciao, everybody, and welcome to a new episode of Voices in Data Storage brought to you by GigaOm. I am Enrico Signoretti, and today we will talk about Kubernetes. Last week, I was at VMWorld, and I met a lot of people. We had a lot of conversations around Kubernetes. VMware was presenting Project Pacific, which is somehow the integration between Kubernetes and VMware. Maybe this time they will finally get it right. A lot of sessions were about Kubernetes. This was the topic of the show from my point of view. To discuss about this and all the implications that this will bring to enterprises, I invited today, Sirish Raghuram, CEO of Platform9. Hi, Sirish, how are you?

Sirish Raghuram: I'm really good. Thank you for having me, Enrico.

Thank you for the time. Sirish, maybe we can start to introduce you and your company first.

Yeah, absolutely, Enrico. My name is Sirish Raghuram. I am co-founder and CEO at Platform9. Platform9 was founded by myself and three other engineers from VMware. We were there for a long time. We built a lot of the products, like vSphere and others.

We started the company to make it easy for enterprises to run hybrid cloud environments. We do that by providing a SaaS control plane, a cloud control plane, that is very simple and easy to get started with. You go to sign up, and you can get up and running very quickly, and then you can integrate that with any infrastructure you have, whether that's on-premises infrastructure or public cloud environments.

The control plane takes care of providing services like Kubernetes. You can think of it, in a way, as Kubernetes as a service company. The underlying technology is really this cloud control plane that makes it easy to run hybrid cloud environments.

Yeah, so from your perspective, you have a lot of customers using your platform at the moment. What is your opinion about Kubernetes adoption in the enterprise? How do we seal it in an evaluation phase for most of them? Are they really putting their mission critical application? Is something still in the middle?

I feel like maybe I could present a broader perspective, Enrico. Two years ago, we used to have to explain to customers why Kubernetes makes sense. I think they were generally interested in containers. We started explaining to them why Kubernetes was the right choice, versus something like a Docker Swarm or an Apache Mesos.

Last year, we used to have to talk about, okay, now people had agreed on Kubernetes, and now they were saying, "Okay, we're just about getting started with Kubernetes. What are some of the problems we should be aware of?" Today, especially, I think, companies that are more advanced with their digital technologies, are already, I think, well on their way in terms of their Kubernetes journey. The reason for that is containers as a platform are so attractive. They are much more resource efficient. They are truly portable across cloud environments.

From a developer and dev ops team perspective, containers are a significant improvement versus trying to use virtual machines and packaging applications using all the config management tools. For all these reasons, I think this is really happening. It's happening now. It's actually a really interesting time in the market where enterprises, I think, are relatively early in the journey. They're not running more than 10, 20% of their workloads on containers and Kubernetes, but they are directionally committed to going down that path. Five years from now, a lot of them want to be running a significant portion of their workloads on Kubernetes.

The preview of Project Pacific that we saw at VMware is trying to bring in together legacy – if I can call them legacy – I mean, VMware machines and containers in the same environment. You are able to manage them as single applications. Do you think this is the right way to manage Kubernetes in that enterprise, or do you think that the enterprises wanted to do this in this way?

Yeah, so great question, Enrico. The first thing I want to point out is that this is not a new capability. In the open source Kubernetes world, there have been projects like KubeVirt that have effectively allowed you to do this for over a year now. This is not necessarily a new innovation. What is new is that I think VMware has tried to retrofit Kubernetes onto the vSphere platform. Why does this make sense?

The theory is that look, it will be much easier for companies that have existing workloads to be able to start to experience the Kubernetes API, and the Kubernetes workflow using those existing vApps. I think that for certain types of applications, that may be true. Given that this has already been out there in the open source community, we have some experience of seeing customers actually trying to use this.

What we've seen is that fundamentally, Kubernetes is a pretty different way of thinking about packaging your applications. The idea of taking existing applications, not really modifying them, and just overlaying Kubernetes on top of them, it sounds appealing in theory, but in practice you run into a number of limitations where you wonder at the end of it, is it really worth it? Should Kubernetes really be adopted by using, adopting the true microservices cloud native design practices?

I think it will have limited real-world usage. I think most companies that are serious about Kubernetes are actually looking to use Kubernetes in its native manner. By that I mean truly using microservices, and truly using the application partitioning concepts that microservices entail.

Do you also think that this kind of approach could be sort of lock in? I mean, you lose some of the application portability that Kubernetes promises if you mix virtual machines with containers. Somehow you limit your options.

You absolutely limit your options. There's only going to be one company, which is supporting Pacific. It's going to be VMware. There isn't going to be innovations or contributions from the rest of the community. Yes, without question, there's going to be lock in. I think, Enrico, [there are] a few more challenges with this approach.

I think one of the challenges VMware sees is if companies adopt containers and Kubernetes – I saw this post on Twitter, recently, from a gentleman at Nike who said, "Hey, if you're using containers and Kubernetes, and our unit of abstraction of cloud is a commodities structure, then tell me why can't I run a commodities structure on bare metal," by that he means a standard Linux environment, "and get more performance efficiency, but also simplify the stack? I don't need to run VMs, and then run containers on top of VMs. I now need to have the operational complexity of supporting both the VM stack and the container stack."

There’s a cost aspect, there's a complexity aspect, and then there's an innovation aspect. Let's talk about all three. From a cost point of view, clearly, you're going to be further ahead if you can just run containers on bare metal. We have a lot of our customers who sometimes start with VMs, but eventually they want to go and just run containers on their hardware, or in the public cloud – on the public cloud bare metal environments. Cost-wise, that's clearly the cheapest option.

Let's talk about operational complexity. In operational complexity, now we are talking about training your operational team to support VMware and all of the set of tools that that entails, like vSphere, there's maybe vRealize, maybe NSX for networking. There's SRM for VR. There's always old-world way of doing infrastructure and support and operations that are on infrastructure.

Now, in addition to that, because there's some portion of your applications that are also running on Kubernetes, you also have to learn to support all of these things in the cloud native way. You need to figure out how to support backup NDR for containerized workloads, which are running on these native pods.

I think the operational complexity, the range of technologies that operators need to learn, and support goes up significantly. The kinds of integrations… just imagine the complexity of trying to integrate networking. Now you bring in the public cloud. Most enterprises are going to be hybrid. They're going to have at least two or three environments. The combined complexity, I think, goes up significantly. It makes no sense to be using Pacific on the public cloud.

I mean, if you think about using some Amazon, and some Azure, and some on prem with VMware, you're not going to run Pacific on Amazon. You're not going to run Pacific on Azure for cost reasons and complexity reasons. You can just run containers on those platforms natively and manage it with Kubernetes. Cost-wise, it's much higher. Operational complexity-wise, I think it's significantly higher.

Then you think about the innovation. When a new version of Kubernetes comes out, in the open source community, how long will it be before VMware supports that version of Kubernetes on vSphere? I think the challenge is new patches come out all the time. New security vulnerabilities come out all the time. Also, new versions of Kubernetes come out every three months. VMware, historically, has not updated ESXI at that kind of velocity. A portion of the specific stack runs on the ESXI. I think there's a lot of complexity to this model.

I think at the end of it, when you consider all of this, I think a customer who probably looked back and [said], "Is it really worth it? Should I just simplify my stack and have a legacy environment, which is running VMs?" I use the word legacy badly. It can be a well-designed application. What I mean is a traditional monolithic architecture, which is running in VMs, and a next generation microservices architecture, which is running on containers. They just think of these as two different things.

What are the advantages that VMware – [what] I like about Project Pacific is the fact that you can improve the collaboration between infrastructure teams and dev ops teams? This is one of the hardest things that you can add in every organization now, putting together these two teams. What's your opinion on this?

I think the gap that VMware talks about is very real. There is definitely a divide between operators and developers. I think that they – in particular, in the VMware world, that gap is pretty pronounced. If you think about most organizations [that] are running VMware, and you think about the vSphere operations team, their world, and their challenges, and their concerns look very different than I think the world of the dev ops team or developer team in their organization.

Gartner, for example, talks about this new, emerging world where we've seen this as well. There's sometimes new operations teams that development teams spin out from the development organization or from the dev ops organization to become the new cloud ops layer because of how different the developer mindset today is versus the VMware operator mindset. I think that anything that VMware is trying to do to bridge that divide is a good thing. That gap is real, and I think it's holding enterprises back in terms of being able to be more efficient and more agile.

However, the question is: is Pacific the right way to address that gap? For the reasons that I outlined before, the costs, the operation complexity, and the innovation aspect, while the effort is – the pain point is real. The question that arises is: is this the right approach to address that problem? I think the jury's out on that because I think a lot of these organizations that are really serious about containers will want a more pure, non-locked in, not VMware specific version of Kubernetes.

The other one, Enrico, that's worth talking about is if you think about what developers want – they want, not just Kubernetes, but they want this broader range of application services, like Prometheus for monitoring, Istio as a service mesh, and Jeager for tracing, Harbor for the highly available container registry. Kubernetes is like a new operating system kernel for the cloud data world. You need these surrounding services to really make that a friendly operating system to build applications on top of.

For example, in VMware's announcements, there was no mention of these things. The focus is all on trying to retrofit Kubernetes into vSphere. Again, you go look at it from a developer point of view, compared to what they can get from open source or alternatives like Platform9, they don't really get these broader range of services that I think they all cared about. Ultimately, to be able to build modern, containerized applications, you need Kubernetes, but you need these additional services as well. That seems to be lacking in VMware solutions. I think for all those reasons, they're definitely trying to solve the right problem. The approach is questionable.

I see. Again, you are probably right. I mean, trying to mix all these things, and somehow reinventing the wheel could be very dangerous because as you said, there are several tools. These guys coming from the open source world, they are so used to them. Then if they start to work with this VMware environment, it becomes very hard for them to enjoy the platform and be very productive with it. To your point, probably, it will increase the costs, sometimes, dramatically.

From another perspective, you have a totally different approach to this kind of problem. I know your history. I know how you deploy your product. How can an enterprise take advantage of Platform9 services – including these kind of issues?

Yeah, I think it would be interesting to talk about maybe two kinds of customers. Both are VMware customers and are using Platform9. They have been in production for more than a year now. The first one is S&P Global, which is the world's leading financial technology ratings and intelligence company. They're a pretty large VMware customer. They're a Fortune 500 based in New York City in Manhattan. Their CIO had a vision of saying, "I want to modernize my organization's digital platform capabilities. I want to delight my development teams with a modern development experience and giving them the latest and greatest capabilities." But they had an existing VMware investment. They chose not to disturb that. They said, "Look, the VMware environments work. We've been quite happy with VMware as a virtualization technology. Let's talk about how we're going to deliver a great development experience on top of that."

What we've done there is – S&P Global has essentially done both an IaaS stack, Infrastructure as Service stack, using our managed open stack product, which runs on top of VMware. Existing applications that are running using VMs are available in a catalog, with self-service, with a fully automated experience. They've also rolled out managed Kubernetes. By rolling out an integrated cloud control plane, which includes both VM-based IaaS, and container-based Kubernetes as a Service, and a rich catalog of applications like Prometheus, and Istio, and Jeager, and Harbor, and Cassandra, and Kafka, and Hadoop, and Spark. The list goes on and on.

They've enabled the full catalog of development capabilities that their development teams are hungry for. That works both on prem and VMware and across hybrid clouds like Amazon and other clouds that they may use in the future. That's, I think, one classic example of how I think a large enterprise organization that has an existing investment in VMware can leverage that while still driving value to the business.

Another example, and I'm not going to name this customer because of what they did. They actually deployed our Kubernetes as a Service solution completely independent of their existing VMware environment. They also had an existing open stack environment. They said, "Look, this is a critical piece for us. We've had a lot of challenges with our open stack layer. Historically, it's been too complex to run. Our VMware stack is interesting, but we don't really realize [value]. We want to be delivering a new stack. We want to build a whole new stack and see if we can standardize on that, but we want to prove it out first."

They actually went and deployed a brand-new Kubernetes as a Service stack just on standard Linux, so on bare metal, effectively. Containers are running not on VMs, but containers are running on Linux, on physical hardware. That was about a year ago. Now they've been very happy with the experience. The fact that we delivered this as a SaaS service means our Software as a Service platform is taking care of the deployment and monitoring and troubleshooting of Kubernetes.

In addition to Kubernetes, now they're starting to consume capabilities like Prometheus, capabilities like Istio. They've now chosen that this stack will be standardized. They're moving everything from the VMware environments and the open stack environments, actually transforming them into containers, and then moving them into this whole new Kubernetes as a Service platform. So they're taking a more aggressive approach, where they're forcing modernization by keeping the Kubernetes stack very clean and very aligned with upstream Kubernetes. They're not running Kubernetes on VMs. They're not running Kubernetes in any kind of proprietary manner. They're using upstream Kubernetes that we support and all the surrounding services. They're forcing a migration of all the existing workloads. They are pretty aggressive.

We have seen other companies that have done this successfully where they have been able to modernize those application stacks and bring them into the containerized world. Two different approaches, I would generally say that it comes under the nature of applications. If you have very long-lived applications, 30, 40 years old, then you may want to take the S&P Global approach where you keep some layers unchanged. But if you're willing to modernize more aggressively, then I would highly recommend the second approach. It really is a choice that customers have in terms of how we choose to deploy and use Kubernetes.

I have a couple of questions, then. One is you talked about very large companies in the end with very complex environments, open stack, VMware, and now Kubernetes. Is this solution good only for these very large organizations, or do you also serve small organizations as well?

We have a number of customers who are much smaller than that, Enrico, as you know. One company that comes to mind is a European company called EZ Flex, which is much smaller but wanted to be able to run infrastructure within Europe. They’re using our Kubernetes as a Service platform on top of their existing environment.

In fact, in many ways you could say that the fact that our service is available as a SaaS service means that smaller organizations, they're more resource constrained. Often, the operations teams have more to do, and they don't have a large team. We can help augment them effectively by bringing our management control plane effectively serves as a way of augmenting the capabilities of the operations team in small organizations. It's not necessarily just for large organizations.

Yes, I totally understand. You solve all the issues that come with Kubernetes around Kubernetes’ first deployment and management. It is the same problem for a small and large organization at the end of the day. Actually, now, it's becoming pretty common. Also large service providers like Google offer a suite of services. What kind of differentiator is Platform9 when I compare it with the Googles of this world?

The predominant differentiators are Google's Kubernetes service, GKE, runs in the Google cloud platform. Many companies don't want to be locked into a single cloud provider. They may have existing on prem environments that they also want to use, or they may want to have a hybrid strategy, or a multi-cloud strategy across Amazon Web Services, Google Cloud, and Azure. Those companies, what they end up having to do today is they end up having to run Kubernetes by themselves. They end up trying to hire an in-house team, a platform team, to deploy and run Kubernetes.

Now the challenge is that Kubernetes is pretty complex. You need very specialized talent to be able to run Kubernetes. Also, deploying Kubernetes is actually the easy part. It's the ongoing troubleshooting, and monitoring, and upgrades, and resolving cluster downtime when its v-clusters fail. Those are where you end up really having problems.

Most organizations, they either don't want to deal with that, or they have engineers that can deal with that, but those engineers are their most valuable engineers. They want to let them do higher order work that is unique to their business. They want something like a Google Cloud service, they want something like a GKE, but they want it to be able to run on prem, or across hybrid and multi-cloud environments. That is what we do. In fact, there's nobody else that does what we do in terms of providing a service, Kubernetes as a service platform, that runs in a hybrid and multi-cloud manner.

At the end of the day, you provide on prem plus multi-cloud kind of environment. You can deploy your solution on different environments. This makes life easier for your customers. This is the real differentiator, right?

That's correct.

Sirish, I think we got a nice overview about what is happening right now in the Kubernetes infrastructure and what your company does. Actually, I'm pretty curious to know if you have an idea on where Kubernetes is heading. I mean, the development, what we can expect from this huge community in the next, I don't know, one year, two years?

It's an exciting time in the space, Enrico, because I felt like in the early years, a lot of time was actually spent in talking about Swarm versus Mesos versus Kubernetes. Now, I think all of that is behind us. It's remarkable that this open source project has gotten to be so powerful, and has so much mindshare, that VMware had to pretty much make it center stage in their annual conference. I mean, that speaks volumes about the traction that I think Kubernetes is having.

I think it's exciting because what's happening now is we're going to a world where – historically people used to talk about the move to the cloud, as in lifting and shifting workloads, and thinking of the cloud as a destination. I think Kubernetes has been the key technology that has really changed that, and where we're not talking about move to the cloud as much as if you're using cloud native. If you're running on Kubernetes clusters, and you're using the Kubernetes API, it really does not matter whether you're using on prem environments, or public, or hybrid, or multi-cloud environments.

I think the future of Kubernetes is going to be – I think there's two really big areas of innovation. The first one we've talked about already in terms of this range of services around Kubernetes. Today, I think companies that are trying to run Kubernetes end up becoming the systems integrators of all these technologies. I think there needs to be a way by which it's easier for them. The cloud providers aren't going to do that because the cloud providers all have their own proprietary version of these technologies. I think that's an area where the community's investing in.

The second one, I think, is Kubernetes is now effectively leveling the playing field between on prem, and hybrid, and public cloud, and multi-cloud environments. I think we're finally getting into – I don't know, Enrico, if you remember the words, grid computing, many years ago.

Yeah, I remember that.

Kubernetes was actually going to enable a computing grid where people could consume cloud capacity with the same consistent experience, and being able to build applications to that world, while actually being able to consume capacity more dynamically and as a commodity. I think this is not going to happen in a year, but I think in the next three to five years, Kubernetes is absolutely going to help deliver a cloud computing grid. I think that is really powerful because it's going to significantly make organizations much more efficient, and lower the cost of computing, and therefore help bring more innovation using computing to the world.

I see your point. My only concern is about data storage. It is much easier to move computer resources and applications, but data will be always the difficult part. We will see what happens. I think it's time to wrap up this episode. It was a very nice conversation. I would like to give our listeners a couple of links. Where can we find you on Twitter if they want to keep the conversation going, for example, and the website for Platform9?

Yes, so Platform9 is at Platform9.com. We're on Twitter at @Platform9sys. Tweet to us there, or you can tweet to me personally @SirishRaghuram on Twitter. I read both, so I'm happy to continue the conversation there. Enrico, thank you for having me.

Thank you for spending the time and talking about this very interesting topic. Bye-bye.