 Welcome back, everyone, to SuperCloud 22. This is theCUBE's live presentation, streaming out virtually our inaugural event, kind of a pilot. I'm John Furrier, host of theCUBE with Dave Vellante. Got a great panel here to discuss the enablers and blockers, question mark for SuperCloud. We got Kit Colbert, CTO of VMware, Baskar Gorty, CEO of Platform 9, and Haseeb Puthani, who is the CEO of RAFE Systems. We got a mix of the big leader, VMware, and the upstart companies growing into the same space, all cloud-native friends of theCUBE. Great to see you guys, thanks for coming on. Thank you for having us. All right, so there's no debate. Cloud-native is booming, we see that clearly. Kubernetes became a unifying force. It's an ops layer, kind of almost like a, kind of a midline between dev and ops. DevSecOps is happening at scale. What are the blockers and what are the enablers for SuperCloud? What do we need? Haseeb, what are your take? Sure, so, you know I spoke about this a little bit at New York Summit. The big trend I'm seeing, and it's a blocker that's being sort of taken care of by enterprises, which is, you know, till very recently, Kubernetes was effectively a project that an app team would take on, they'd try things out, they'd go to the cloud, they'd spin things up, and then the next team would come and they'd do the same things, and there was no consistency, there was no standardization. It's a mess, right? It's all over the place. Some things are moving fast, some things are not moving fast. And this is not how enterprises do business, right? That's not how things work. Traditionally, enterprises have had IT organizations that create standards, right? So those IT organizations now kind of are starting to think like a platform organization. So centrally, come up with the right framework for all application teams to consume infrastructure, modern infrastructure. So I'm not using the word Kubernetes here, because Kubernetes is an enabler. We are a Kubernetes company, obviously, but it's about modern applications, modern infrastructure. So stepping back and thinking about it as to how an enterprise will do this across the board is the right answer. And I'm seeing this happen in a pretty significant way across all the large enterprises I've talked to. That's right, you've had a great career and we talked before you came on, and you did a turnaround there. We even go back to the old days of the web 1.0 and early software, you've seen the movie before. Yes. You know, complexity is not solved by more complexity. This is kind of the old enterprise way. And they don't want that. They've seen the benefits of self-service. They see architecture and standards as being an enabler. Where are we here in the market? Are we positioned, in your opinion, for customers to get the value of a super cloud? Absolutely. So if you think about it, first of all, I think the topic of cloud-native developers and app developers picking containers and Kubernetes, that's a done deal. That has already happened. So every cloud-native developer is already using these tools. Now, I think as has been discussed today in even the earlier sessions, is are the operations and infrastructure catching up or they're lagging behind, right? As more and more developers are using multi-cloud technologies, enterprises are creating a choice, I think operations, and what we also strongly believe, that's actually part of the name of our company, is a platform. The platform of which a company uses to transform itself to be cloud-native is the big opportunity. I don't think it's a blocker, but it's a huge opportunity. And I think this is where, you know, as you can't stop developers from developing on different clouds, private, public, multi-edge, that's going to happen. Innovation is going to continue. But then how does the infrastructure in the platform make it seamless, right? And almost treat all these different clouds as a single-paying super-cloud platform. That's, I think, is the opportunity. Well, we in a platform more than with other companies or with one unified platform called cloud-native, we know customers have been buying tools from security, they got so many tools in their tool shed, so to speak. What is that platform? I mean, is it more unique fragmentation? Is it unified? I mean, if you think about it, a couple of, it's a combination of tools that are stitched together to reach a purpose, right? If you think about, you know, APIs, container APIs that's been discussed earlier today, I think that should be standardized. The other thing is always on monitoring, because I think that's a very key aspect. Once you build it, then, as the enterprises are using it, the always-on monitoring becomes, so I think it's a combination of capabilities that are stitched together to enable the acceleration for companies to become cloud-native. I have a thought on a blocker. None of you guys are going to like it. Maybe you can come. Maybe some of you guys probably won't put comment, but maybe John will. I think AWS is a blocker to super-cloud, because they don't want those cross-cloud services. That's like, for years, they wouldn't even say multi-cloud. The first time I heard it was in Boston three weeks ago, I actually heard it. So, what do you think? You know I'm going to disagree with that. Okay, go ahead. All right, so we'll get their reaction. So, we just heard from the last panel that AWS should be leading the consortium, because they're not the enemy. They're actually the enemy. Maybe they should be. Well, back in the old web days when standards were driving things, you had a common enemy, proprietary NASAs, proprietary networking stacks. So, the evil empire was AT&T that owned UNIX, if you remember. They copyrighted that. So, you think they're greasing the skids for super-cloud? I think the hyperscalers could, because they're driving the CapEx. They're providing the value. So, in my opinion, Amazon and Azure, whoever does the right thing first can win everything. Maybe this is how Google could catch up. It could be a slingshot move. It could boomerang someone to the front of the line or extend Amazon's already huge lead. So, if I'm AWS, if I'm Adam Sileski, and I'm talking to Andy Jassy, he says, how am I going to differentiate myself? I'd say, I'm going to come in and own multi-cloud. I'm going to own super-cloud. We are the super-cloud. And you work with AWS's primitives in a way that makes services work. I would go for that. I'd be like, okay, show me more. What do you think? I don't think any one company is going to be a super-cloud, because I think, yes, there is going to be a lot of workloads on public clouds, but there's a huge amount of workloads at the enterprise, at the edge, at the store. I think those will continue for various reasons, whether it's data sovereignty, regulations. So, I think it's going to be a combination. Everybody's not going to go to one cloud. It's going to be an amalgamation. Okay, but I've argued that Snowflake is a form of a super data cloud in a very specific use case. Aviatrix is trying to be a network layer and a sneak and a security. Let me know on and on. A lot of small, so now you get super-cloud stovepipes, but nonetheless, you're still abstracting. I mean, this industry is abstractions, right? Well, this concept I completely agree with, right? This idea that, so one of the my thesis is that right now enterprises buy 500 different technologies and they have to become PhDs in 500 different things. It's just never going to happen. Skills issue. There's no way, right? So what's going to happen is all of these providers are going to essentially become managed service providers. Cloud is a manifestation of that. Snowflake is a manifestation of that. Databricks is a manifestation of that, right? So in our general industry, there's going to be a handful of platforms, right? And they're going to work across these clouds. Amazon may have one too, right? Look, they for the longest time sort of ignored on-prem, but now they have something called EKSA, which runs on-prem, right? Why? Why would they bother? There's a lot of money to be made in a data center as well. So my sense is they get it, completely understand and appreciate that there's other things outside of Amazon. But in terms of what Bhaskar was talking about, my sense is these multiple platforms will come about. And to the point we were making earlier about standardization, and I mean, is it going to be one company or is it going to be standards that everybody else will adopt? There's a topic that the three of us have talked about before, which is this v-center for Kubernetes, right? And all due respect to Kit, right? My sense is that there's going to be multiple companies that are going to start working towards a v-center for Kubernetes. And it is, right? I mean, that's how I've, I mean, I've been thinking about this for four and a half years. Including VMware. Yeah, you know, and we should compare those, right? But what's going to happen is there was a distinct warrantage VMware had back in the day because ESX was their product, right? And that was a standard. Right now, what's the ESX in the newer? It's sort of Kubernetes, right? I mean, it's on bare metal for the most part or whatever VMs. So that's a standard, that's got standardized APIs. The things around it are standardized APIs. So what is the unfair advantage that any one company has other than execution? Nothing. Well, also composability. If you over-rotate on Kubernetes, for example, and not take advantage of, say, EC2, for instance. Totally, totally. It's a mix and match. Yeah, but I think if you get too focused on Kubernetes, it's a means to an end, right? At the end of the day, it's a mean to an end. And I think all these tools, there's a lot of standardization happening. That's going to happen, right? And no one vendor is going to control that, right? It's going to be, it's going to continue. I think how you bring these together and orchestrate, right, and manage a service, because I think that, if you think about the lack of skills to keep up with the operations and platforms is one of the largest inhibitors right now for enterprises to move as fast as they want to become cloud-native. And you have the shiny new toy problem, can't the people just go out and grab it? You know, Keith Townsend has a quote. He says, look, we essentially move at the speed of the CIO or else we're going too fast or too slow. So to the point about the new toy now, I've got new skills. Yeah, well, so this has been a really good discussion. And I think, so there's a couple of things, right? Going back to the paper that we wrote, right? Now we have these different sort of layers of multi-cloud services or categories of multi-cloud services. And it's exactly the capture of some of the different examples you just mentioned. And yeah, the challenge is that each of them by themselves are a little bit of an island today. Like, you don't have that extra level of integration. And so what the platform teams typically do is try to add that extra glue to make the experience more seamless for the developers at that company. And so like, for instance, things like identity. So the nice thing about going to a single public cloud is that there's usually one identity system for everything. And that's great, all the different services, roles are back, all that stuff's all centralized. But you don't have that when you're going to cross many different multi-cloud services. So what does that look like? So I think there's some of these different cross-cutting concerns that we need to look at how we standardize on as an industry. And that's what, again, one of the bigger problems. And I think also the other key thing is, yes, you can always say, I'll put everything in one wall garden and I'm done. But that's not the reality. Because at some point you need the flexibility and cost comes into play and flexibility to move comes into play. And I think that is a key factor, right? Yeah, and so then the question is, what degrees of freedom do you give yourself there? And I think that's the architectural question, is how do you design it? What sort of abstractions do you leverage? I think that goes back to some of our discussion before, which is, do you directly go on top of a native cloud service or do you use a multi-cloud service? But I think it's a combination of, I don't think it's either or. No, it's not. It's not an either or. You have to have the ability to choose a public cloud or do it private, but at the same time you don't change. It's like a common dictionary, right? You're not going to change every time the accent changes. So here's a question for you guys. So what has to happen for super clouds to be existing? Assume that AWS and Azure and Google aren't going to sit still, assume that maybe they normalize into some sort of swim lane or position that they have to rationalize. What, assuming they're not going to sit still, what has to happen for super clouds to actually work well? Well, I think really quick, going back to the platform team point, I would say that the platform teams at various companies, and we got one at VMware too, they're creating a rudimentary form of a super cloud, right? Because they, you know, like if they are supporting multiple clouds, like all the things they're stitching together and all that work, that is a super cloud. The problem is that there's not really a standard approach or architecture or reusable things to enable that. I think that's really what's missing. Yeah, but I think the key here is standard reusable because for example, we have customers who are on, doesn't matter where they are. Some of their loads are in public cloud, some are in private, some are at the edge, but they're still using the same platform, right? So it is a standard open source-based technology. So it is standard, there's no lock-in for them from an infrastructure point of view. And it gives them the flexibility because certain apps, you want to put it on the public cloud, certain apps, you do not. You need the, I mean, for example, some of the AI, I think earlier discussion that was going on about chips and AI and ML workloads. I mean, think about moving all of that to a public cloud to, and I think there's a lot of machine learning and AI applications are going to happen where the data is getting created. At the edge, that's what's going to happen. It's not going to happen in public cloud. It's going to be real-time inferencing. It's going to be real-time. And so therefore, you have to decide based on your workload, what are you going to move all the way to a public cloud? And what are you going to need to do to make business decisions at the spot where the data is created? That's a huge disruptor, potentially, to super cloud. This is a whole new architecture that emerges at the edge with a whole new set of economics. I think the edge is going to be massively disrupted. And if you think about the edge, go beyond just the classic definition of edge. Think about branches and stores, retail stores, right? I mean, you cannot shut down a retail store because you lost connectivity to the network or something. You still have to serve your customers. Edge is a disruptive enabler. I think it's going to potentially change the position of the players in the business whether it embraces the edge. Yeah, maybe going back to the question that you had asked before, which is what is the framework for a super cloud? So you said something that is important, which is your team's building one. Yeah, I met that team, actually. They seem to be very sharp guys. They're on my order. Great, they're off. We got a deal going on here, I think. We have it. So this is the interesting part, right? So I will posit that the super cloud of the future will be a company that owns zero servers and no network. Okay? That's going to happen, right? So I just kind of negated the point you made that point. That's about the public cloud. Yeah, so, Mr. Yeah, yeah, yeah, yeah, that's really interesting. I've thought about this a long time that in my opinion, and I'm sure I've said this to you, John, that the one company that I've always believed has the best shot at doing this well is actually VMware. Because that's the one company that's, you know, that there's no infrastructure backhaul that you're carrying. But in terms of thinking and getting there, being a company that can do it is not the same as being the company who has done it. There's a distance. But I have to defend that now, because hyperscalers are not going to build the super cloud. They're not. Now, it's hype. See? Agreed, agreed. Public clouds will be part of the super cloud. Yeah, totally. But they will not, the hyperscalers are not building super clouds. Totally. They're blocking it. Yeah. No, they're enabling it. Right, we agree on that. No, they're enabling it. Because it's not to their advantage, right? The snowflake example you gave is the pivotal example in this conversation, right? Why does snowflake exist at all when redshift exists and all the other things exist because they provide value that is beyond a single cloud's purview, right? And at that point, just step back from our platforms and what we say, I'll forget about that for a minute, right? It's about, look, I think this market is early, we're all early, right? 10 years from now, what will a company look like that actually solves the super cloud problem? They're going to solve for, yeah, Kubernetes, whatever, right? But they're going to solve for truly modern applications. Yeah, they're going to refactor an application that has new economics, new value on top of the cloud. At that point, this idea of edge and cloud, forget about it, right? This is all distribution issues, right? It doesn't really matter. Is it retail or not? Yeah, absolutely, these are places. But the way, the right way to think about this is not about edge versus cloud, right? This is about an app. Sometimes it needs to run in one location and it's good enough. Sometimes it needs to run in 10,000 locations and it's a distribution issue. I've always believed that this idea of edge versus cloud, this is BS, right? Because it is a cloud over a different size. Sure, but I'm making a slightly different point, which is it's a distribution problem, right? If you step back and think about distribution, my app could run in Azure or AWS or in a retail store or in a branch or whatever, right? And once that is done, the question is, how am I in making all this happen? There was a point made in the prior conversation, in the prior session about a database kind of popping up in the place where I needed to run. Okay, nobody does that today, by the way, right? At least truly well, right? Okay, we'll put that, sir. That will come, right? But when that comes, my application is a conglomerate of compute, data, I don't know, a service bus and network and all these things and they will all kind of pop together. That company does not exist today. We will be docking. Wish we had more time. We're gonna dock on it and we have to unfortunately stop this panel because it's awesome, we can go for another hour. Let's bring you guys back, but that's it, the super cloud of the future will look like something and we're gonna debate it. And speaking of Snowflake, we have the co-founder Benoit here next to sit down with us to talk about the super cloud. He probably heard the comment. Come back more coverage after this break with the co-founder of Snowflake after the short break. Forget it, thank you.