 Okay, welcome back everyone to SuperCloud 22 here in our live studio performance that you're on stage in Palo Alto I'm Sean Furrier, host with the queue with Dave Vellante. My co-host got a great industry ecosystem panel to discuss whether it's real or hype David Mcjennan, CEO of AshiCorp, hugely successful company as Will LaForest, field CTO at Confluent and Victoria over here and go from VMWare Guys, thanks for coming on the queue. Appreciate it. Thanks for having us. So real or hype, SuperCloud, David. Well, I think it depends on the definition. Okay, how do you define SuperCloud? Start there. I think we have like an inherently pragmatic view of SuperCloud or the idea of SuperCloud as you talk about it, which is, you know, for those of us that have been in the infrastructure world for a long time, we know there are really only six or seven categories of infrastructure. There's sort of the infrastructure, security, networking, databases, middleware and really the message queuing aspects. And I think our view is that if the steady state of the world is multi-cloud, what you've seen is sort of some modicum of standardization across those different elements, you know, take, you know, take Confluent. You know, I worked in the middleware world years ago, MQ series and typical multicast was how you did message queuing. Well, you don't do that anymore. All the different cloud providers have their own message queuing tech. There's Google Pub sub and the equivalence across the different different clouds. Kafka has provided a consistent way to do that. And they're not trying to project that you can run everything connected. They're saying, hey, you should standardize on Kafka for message queuing because that way you can have operational consistency. So I think to me, that's more how we think about it is sort of there is sort of layer by layer sort of de facto standardization for the lingua franca. So a streaming super cloud is how you would think of it or a component of that could be a super cloud. I just I just think that there are like if I'm going to build an application message queuing is going to be an unnecessary element of it. I'm going to use Kafka, not, you know, a native Pub sub engine on one of the clouds because operationally that's just the only way I can do it. So I think that's more our view is much more pragmatic rather than trying to create like a single platform that you can run everywhere and deal with the networking realities of like network, you know, hops missing across those different worlds and have that be our responsibility. It's much more around, hey, let's standardize each layer operational. Standardized layer that you can use to build a super cloud if that's your intent. Yeah, yeah. And it reminds me of the web services days you kind of throw back there. And we're kind of living the next gen of web services. The dream of that next level because dev ops dev sec ops now is now gone mainstream. That's the big challenge we're hearing devs are doing great. But the ops teams and they got to go faster. This seems to be a core, I won't say blocker, but more of a drag to the innovation. Well, I'll just get off it. I'll hand it off to you guys. But I think the idea that like, you know, if I'm going to have an app that's running on Amazon that needs to connect to a database that's running on private data center. That's essentially the SOA notion, you know, writ large. They were all trying to solve 20 years ago, but it's much more complicated because you're brokering different identity models, different networking models. It's just much more complex. So that's where the ops bit is the constraint. You know, for me to build that app is not that complicated for the ops person to let it see traffic is another thing altogether. I think that's that's the break point for so much of what looks easier to a developer is the operational reality of how you do that. And the good news is those are actually really well solved problems. They're just not broadly understood. Well, what's your take? You talk to customers all the time. Field CTO, Confluent really doing well streaming data. I mean, everyone's doing it now. They have to know these are new things that pop up that need solutions. You guys step up and doing more. What's your take on super cloud? Well, I mean, the way we address it, honestly, is we don't going to be honest. We don't think about super cloud much less is the fact that SAS is really being pushed down. Like we rely on seven years ago and you took a look at SAS like it was obvious if you were going to build a product for an end consumer or business user. You'd do SAS. You'd be crazy not to. Right. But seven years ago, if you look at your average software company producing something for a developer, the people building those apps, chances are you had an open source model or, you know, self managed. I think with the success of a lot of the companies are here today, you know, Snowflake, Databricks, Confluent, it's obvious that SAS is the way to deliver software to the developers as well. And as such, because our product is provided that way to the developers across the clouds, that's that's how they have a unifying data layer. Right. They don't necessarily, you know, developers like many people don't necessarily want to deal with the infrastructure. They just want to consume cloud data services. Right. So that's how we help our customers span cloud. So we had that SAS was going to be either built on a single cloud or in the case of service. Now they built their own cloud. Right. So increasingly we're seeing opportunities to build a sales force as well across clouds, tap different different different services. So so how does that evolve? Do some clouds have, you know, better capabilities than other clouds? How does that all get sort of adjudicated? Do you do you devolve to the lowest common denominator? Or can you take the best of all of each? The whole point of that, I think, is that when you move from the business user and the personal consumer to the developer, you can no longer be on a cloud. Right. There has to be locality to where applications are being developed. So we can't just deploy on a single cloud and have people send their data to that cloud. We have to be where the developer is. And our job is to make the most of each individual cloud to provide the same experience to them. Right. So yes, we're using the capabilities of each cloud, but we're hiding that to the developer. They don't shouldn't need to know or care. Right. Again, you're hiding that with the subtraction layer. We talked about this before. And that layer has, what, some intelligence that has metadata knowledge that can adjudicate where the best service is or a function of latency or data sovereignty? How do you see that? Well, I think you need to instrument these applications so that you can get that data and then make the intelligent decision of where this deployed application. I think what Dave said is right. The level of super cloud that they're talking about is the standardization across messaging and what's happening within the application. Right. So you are not too dependent on the underlying. But then the applications say they take the form of a microservice. Right. And you deploy. There has to be a way for operators to say, okay, I see all these microservices running across clouds and I can factor out how they're performing. How I cycle manage and all that. And so I think there is, to me, there's the next level of the super cloud is how you factor this out so an operator can actually keep up with the developers and make sense of all that and manage it. Yeah. We say that all the time. It's also like, that's what Datadog does. So Datadog basically allows you to instrument all those services on-prem private data center, you know, all the different clouds to have a consistent view. I think that's another good example of a vendor that's created a sort of level of standardization across a layer. And I think that's more how we think about it. I think the notion of like a developer building an application they can deploy and not have to worry where it exists is more of a PAS kind of construct. You know, things like Cloud Foundry have done a great job of doing that. But underneath that, there's still infrastructure. There's still security. There's still networking underneath it. And I think that's where, you know, things like Confluent and perhaps at the infrastructure layer have standardized. Off-the-shelf PAS, if I can call it that. Yeah. And then you have PAS. And I think about, you mentioned Snowflake. Snowflake is what Snowpark seems to be developing a PAS layer that's purpose-built for their specific purpose of sharing data and governing data across multiple clouds called SuperPAS. Is that a prerequisite of a SuperCloud? You're building blocks, I'm hearing, for SuperCloud. Yeah. Is that a prerequisite for SuperCloud that's different than PAS of 10 years ago? No. I think they're just different layers. So it's like, I don't know how the Snowflake offering is built, but I would guess it's probably built on Terraform and Vault and Console underneath it. Because those are the ingredients with respect to how you would build a composite application that runs across multiple clouds. And that's how Oracle, the Microsoft announcement they just made, if you saw that, that was built on Terraform. But they would claim that they did some special things within their past that were purpose-built for low latency, for example. They're not going to build that an open shift as an example. They're going to do their own little mechanics. For sure. So I think what you're pointing out and what Victoria was talking about is, hey, can a vendor provide a consistent experience across the application layer across these multiple clouds? And I would say, sure, just like you might build a mobile banking application that has a front end on Amazon and the back end running on vSphere on your private data center, sure. But the ingredients used to do that have to be, they can't be the cloud-native aspects for how you do that. How do you think about the connectivity of networking between that thing to this thing? Is it different on Amazon? Is it different on Azure? Is it different on Google? And so the companies that we all serve, that's what they're building, they're building composite applications. Snowflake is just an example of a company that we serve that's building composite applications. But don't you have to hide the complexity of those cloud-native primitives? That's your job, right? Is to actually create simplicity across clouds, is it not? Yeah, absolutely. I mean, that, in fact, is what we're doing for developers that need to do event streaming, right? That need to process this data in real time. Now, we're doing the sort of things that Victoria was just talking about. Like, underneath the covers, of course, you know, we're using Kubernetes and we're managing the differences between the clouds. But we're hiding that, and we've become sort of a de facto standard across the cloud. So if I'm developing an app in any of this cloud... I think we all know, and you was mentioning earlier, every significant company is multi-cloud now, all the large enterprises. I just got back from Brazil and, like, every single one of them have multiple clouds and on-prem, right? So they need something that can span those. What's the challenge there if you talk to those customers? Because we're seeing the same thing. They have multiple clouds, but it was kind of by default, or they had some use case, either .NET developers there with Azure, they'll do whatever cloud. And it's kind of seemed specialty relative to the cloud native that they're on. What problems do they have? Because the complexity to run infrastructure as code across clouds is hard, right? So the trade-up between native cloud and have better integration to complexity of multiple clouds seems to be a topic around super cloud. What are you seeing for issues that they might have or concerns? Yeah, I mean, honestly, it is hard to actually... So here's the thing that I think is kind of interesting, though, by the way, is that... I think we tend to, you know, if you're from a technical background, you tend to think of multi-cloud as a problem for the IT organization. Like, how do we solve this? How do we save money? But actually, it's a business problem now, too. Because every single one of these companies that have multiple clouds, they want to integrate their data, their products across these, and it's inhibiting their innovation. It's hard to do, but that's where something like HashiCorp comes in, right? Is to help solve that so you can instrument it. It has to happen at each of these layers. And I suppose, if it does happen at every single layer, then voila, we organically have something that amounts to super cloud, right? I love how you guys are representing each other's firms. But they also, correct me if I'm wrong, but your customers want to monetize, right? They want to bring their tools, their software, their particular IP and their data and create, you know, every company is a software company. As you know, Andreessen says, every company is becoming a cloud company to monetize in the future. Is that a reasonable premise of super cloud? Yeah, I think everyone is trying to build composite applications to generate revenue. Like, that's why they're building applications. So, yeah, 100%. I was just going to make a point, because we see it as well. Like, it's actually quite different by geography, weirdly. So, if you go to, like, different geographies, you see actually different cloud providers more represented than others. So, like, in North America, Amazon's pretty dominant. Japan, Amazon's pretty dominant. You go to Southeast Asia, actually, it's not necessarily that way. Like, it might be Google for whatever reason, more early, Bob. So, this notion of multi is just the reality of what everybody's dealing with. But, yeah, I think everyone goes through the same process, what we've observed. They kind of go, there's Cloud V1 and there's Cloud V2. Cloud V1 is sort of the very tactical, let's go build something on cloud. Cloud V2 is like, whoa, whoa, whoa, whoa. I now have some stuff on Amazon, some stuff on Azure, some stuff on vSphere. And I need some operational consistency. How do I think about zero trust across that way in a consistent way? And that's where this conversation comes into being. It's not like the first version of cloud. It's actually when people step back and say, hey, I want to build composite applications to monetize. How am I going to do that in an industrialized way? And that's the problem that you were sure about. It's not a no-brainer like it was with cloud. Go to the cloud, write an app, you're good. Here, it's architectural systems thinking. You've got to think about regions. What's the latency? It's the step back and go, like, how are we going to do this exactly? Like, it's fine to do one app, but how do this scale? Zero trust is a great example. I mean, Amazon kind of had it. It was forced to get into the zero trust discussion. That wasn't even a term that they used. And now they're starting to talk about it, but within their domain. And so how do you do zero trust across cloud to your point? I wonder if we're limiting our conversation too much to the very technical set of developers. Because I'm thinking back at, again, my example of C++ libraries, C++ libraries that makes it easier and then visual basic, right? And right now, we don't have enough developers to build the software that we want to build. And so we are now debating, oh, can we hide that AI API from Google versus that SQL server API from Microsoft? I wonder at some point, who cares, right? I think if we want to get really economy of scale, we need to get to a level of abstraction for developers that really allows them to say, I don't really, for most of the procedural application that I need to build as a developer, as a procedural developer, I don't care about this. Some propeller head has done that for me. I just like plug it in my IDE and I use it. And so I don't know how far we are from that, but if we don't get to that level, it feels to me that we're never going to get really the economy or the cost of building application to the level. I was going to ask you in the previous segment about low code, no code, expanding the number of developers out there. And you talked about propeller heads, that's what you guys all do. You're the technical geniuses to solve that problem. So you can have low code development. I don't think we have the right people here because we're still trying to solve that problem at that level. But that problem has to be solved first right before we can address what you're talking about. Yeah, I worked very closely with one of my biggest mentors was Adam Bosworth who built all the APIs for Visual Basics and the SQL API to Visual Basic and all that stuff. And he always was on that front. In fact, his last job was at AWS, building that no code environment. So I'm a little detached from that. It just hit me as we were discussing this. It's like, maybe we're just like creating... I would argue that you kind of got to separate the two layers. So you think about the application platform layer that a developer interfaces to. Victoria and I worked together years ago and one of the products we created was Cloud Foundry. So this is the idea of like just CF push, just push this app artifact. I don't care. That's how you get the developer community writ large to adopt something complicated by hiding all the complexity. And I think that is one model. Turns out Kubernetes has actually become a peer to that and perhaps become more popular. And that's what folks like Tanzia are trying to do. But there's another layer underneath that, which is the infrastructure that supports it. Because that still needs to run on something. And I think that's the separation we have to do. Yes, we're talking a little bit about the plumbing, but we just need to be talking about the app layer. You need both of them. Our point of view is you need to standardize at this layer, just like you need to standardize at this layer. Well, this is infrastructure. This is DevOps v2. DevOps. Yeah. And this is where I think the ops piece with open source, I would argue that open source is booming more than ever. So I think there's plenty of developers coming. The automation question becomes interesting because I think what we're seeing is shift left is proving that there's app developers out there that want to stay in their pipelining. They don't want to get under the hood. They just want infrastructure as code. But then you got supply chain software issues there. We talked about that DockerCon big time. So developers at the top, I think are going to be fine. The question is what's the blocker? What's holding them back? And I don't see the devs piece, Vittorio, as much. What do you guys think? Is it the blocker ops or is it the developer experience that's the blocker? It's both. There aren't enough people, truthfully. That's true. Yeah. I mean, I think I sort of view the developer as sort of the engine of the digital innovation. So, you know, if you talk about creative destruction, that was the economic equivalent of softwares eating the world. The developers are the ones that are doing that innovation. It's absolutely essential that you make it super easy for them to consume, right? So I think, you know, they're nerds. They want to deal with infrastructure to some degree. But I think they understand the value of getting a bag of Legos that they can construct something new around. And I think that's the key because honestly, I mean, no code may help for some things. Maybe I'm just old school, but I went through this before with like Delphi and there were some other ones and I hated it. Like I just wanted a code, right? So I think making them more efficient is absolutely key. But I think what you're going with that question is that the developers, they tend to stay ahead. They just get wired that way, right? So I think right now, there is a big bottleneck in developers. I think the operation team needs to catch up because I talk to these people, like our customers all the time and I see them still stuck in the old world. They give me a bunch of VMs and I know how to manage that world. You know, although as Legos is going to be there forever, they'll manage your main train. The world is all about microservices and containers and if the operation team doesn't get on top of it and the security team, then they're going to be a bottleneck. Okay, I want to ask you guys, if the companies can get through that knot hole of having their ops teams and the dev teams work well together, what's the benefits of a super cloud? How do you see the outcome? If you kind of architect it right, you think the big picture, you zoom out and say, what's the end game look like for super cloud? What's the nirvana? To me, nirvana is that you don't care. You just don't care. When you're running a building application, let's go back to the on-prem days. You don't care if it runs on HPE or Dell or I'm going to make some an animes here with my old family. But you don't really care, right? What you want is the application is up and running and people can use it, right? And so I think that nirvana is that there is some computing power out there, some past layer that allows me to deploy and build application. And I just build code and I deploy it and I get value at the reasonable cost. I think one of the things that the super cloud, as far as we're concerned, is cost. How do you manage and monitor the cost across all this cloud and make sure that the economics don't get out of whack, right? How many companies we know that have gone to the cloud only to realize, holy crap now, I got the bill. And as a vendor, when I was in my previous company, we had a whole team figuring out how to lower our cost on the one hyperscaler that we were using. So these are the ones you have in the super cloud, you don't care. You go with the path of least the best economics is. So what about the open versus closed debate? Will, you were mentioning that we had snowflake here and Databricks is both ends of the spectrum. You guys are building open standards across clouds. Clearly even the walled gardens are using open standards. But historically de facto standards have emerged and solved these problems. So the super cloud as a de facto standard versus Databricks is trying to do a super cloud kind of as an open platform. What are your thoughts on that? Can you actually have an open set of standards that can be a super cloud for a specific purpose? Or will it just be built on open source technologies? Well, I mean, I mean, I think open source continues to be an important part of innovation. But I will say from a business model perspective, like the days like when we started off, we were an open source company. I think that's really done in my opinion. Because if you want to be successful nowadays, you need to provide a cloud native SAS oriented product. It doesn't matter what's running underneath the covers could be commercial, closed source, open source. They just want a service and they want to use it quite frankly. Now it's nice to have open source because developers can download it and run on their laptop. But I can imagine in 10 years time actually, and you see most companies that are in the cloud providing SAS free $500 credit. They may not even be doing that. They'll just go whatever cloud provider that their company is telling them to use. They'll spin up their SAS product. They'll start playing with it. And that's how adoption will grow. My personal view is that its infrastructure is pervasive enough. It exists at the bottom of everything that the standards emerge out of open source in my view. And you think about how something like Terraform is built. Just pick one of the layers. There's Terraform core and then there's a plug-in for everything you integrate with. All of those are open source. There are over 2,000 of these. We don't build them. It's the same way that drove Linux standardization years ago. Someone had to build the drivers for every piece of hardware in the world. The market does not do that twice. The market does that once. So I'm deeply convicted that open source is the only way that this works at the infrastructure layer because everybody relies on it. At the application layer, you may have different kinds of databases. You may have different kind of runtime environments, and that's just the nature of it. You can't have two different ways of doing network. Because the stakes are so high, basically. Yeah, because there's an infinite number of... The surface area is just so large. So I actually worked in product development years ago for middleware. And the biggest challenge was how do you keep the adapter ecosystem up to date to integrate with everything in the world? And the only way to do it in our view is through open source. And I think that's a fundamental philosophical view that we're just grounded in. I think when people are making infrastructure decisions that span 20 years at the customer base, this is what they think about. They go, which standard it will emerge based on the model of the vendor? And I don't think my personal view is it's not possible to do it in a product way. Do you think that's a de facto standard kind of psychological perspective? Or is there actual material work being done or both in there? It's a network effect thing, right? So before Google releases a new service on Google Cloud, as part of the release checklist, does it support Terraform? They do that work, not us. Why? Because every one of their customers uses Terraform to interface with them. And that's how it works. So the philosophical view of the customers, okay, what am I going to standardize on for this layer for the next 30 years? It's kind of a no-brainer philosophically. I think the standards are organically created. Based upon adoption. I mean, for instance, Terraform. We have a provider where, again, we're at the data layer that we created for you. So I don't think there's a board out there. I mean, there are. They're creating standards. I think those days are kind of done, to be honest. The Terraform provider for vSphere has been downloaded five and a half million times this year. Right? I mean, these are unifying moments. The de facto standards are a really important process in these structural changes. I think that's something that we're looking at here with SuperCloud is, what's next? What has to unify? Look what Kubernetes has done. I mean, that's essentially the easy thing to work with, but people get behind it. So I see this as a big part of this next v2. What do you guys see that's needed? What's the rallying unification point? Is it the past layer? Is it more infrastructure? I guess that's the question we're trying to... I think every layer will need that open source or a major traction from one of the proprietary vendor. But I agree with David. It's going to be open source for the most part. But going back to the original question of the whole panel, if I may, if this is reality of hype, look at the roster of companies that are presenting or participating today. These are all companies that have some sort of multi-cloud, cross-cloud, SuperCloud play. They're either public, have real revenue, are about to go public. So the answer to the question, yeah, it's real. Yeah, and there's more too. We had good fit of men, but... We chose SuperCloud on purpose because it was kind of fun. John and I kind of came up with it. But do you think it hurts the industry to have this, try to put forth this new term? Or is it helpful to actually try to push the industry to define this new term? Or should it just be multi-cloud 2.0? I mean, conceptually, it's different than multi-cloud, right? I mean, in my opinion, right? So in that respect, it has value, right? Because it's talking about something greater than just multi-cloud. Everyone's got multi-cloud. Well, to me, multi-cloud is the problem, I should say, the opportunity. SuperCloud, or we call it cross-cloud, is the solution to that challenge. And we're debating that in our Clouderati panel we were talking about. Is multi-cloud a problem yet that needs to get solved? Or is it not yet ready for a market, to your point? Are we in the front end of coming into the true problem set? I can give you a definite answer to that. The answer is yes. If you look at the customers that are there, that have gone through the euphoria phase, they're all like, holy, something, what are we going to do about this, right? But they don't know what to do. And the more advanced ones, as the vendor. Look, at the end of the day, markets are created by vendors that build software that customers want to buy. Because they get value. And it's nuanced. David, we were sort of talking about before, but Goldman Sachs is now a software vendor, right? Capital One is a software vendor. I'd be really interested to see what Cerner does, what Oracle does with Cerner, in terms of them becoming super cloud vendors and monetizing. That to me is, that is their digital transformation. Do you guys see that in the customer base? Am I way too far out of my skis there? I think it's two different things. I think basically it's the idea of building applications that they monetize. Yeah, and Cerner's going to build those. And if you think about IOT companies that sell, or you think people that sell thermostats, they sell an application that monetizes those thermostats. Some of that runs on Amazon, some runs on the private data center. So they're basically going to composite applications and monetize them for the particular vertical. I think that's what we see each and every day. Yeah, you can argue that's not anything new, but what's new is they're doing that on the cloud. Exactly, that's what makes it super cloud. And I think what we all participate in is, hey, in order to do that, you need to drive standardization of how you do provisioning, how you do networking, how you do security, to underpin those applications. I think that's what we're all talking about. Guys, this is great stuff. I really appreciate you taking the time out of your day to help us continue the conversation, to put out in the open. We want to keep it out in the open. So in the last minute we have left, let's go down the line from a HashiCorp perspective, Confluent and VMware. What's your position on super cloud? What's the outcome that you would like to see from your standpoint going out five years? What's it look like? We'll start with you. I just think people are understanding that there is a layer by layer view of how to interact across clouds to provide operational consistency and decomposing it that way, thinking about that way is the best way to enable people to build and run apps. We want to help our customers work with their data in real time, regardless of where they are on-prem or in the cloud. And super cloud can enable them to build applications that do that more effectively. That's great for us. Antonio? My advantage for us is customers don't care. Just that's computing out there. And it's a tool that allows me to grow my business. And we make it all the differences and all the challenges disappear. Dial up compute, utility, infrastructure as code. I open up the thoughts of water coming out. Yeah, I don't care how he got here. I don't want to care. Well, thank you guys so much. And congratulations on all your success in the marketplace, both you guys and VMware, and your new journey. And it's going to be great to watch. Thanks for participating. I really appreciate it. Thank you. Okay, this is super cloud 20. Our inaugural event is a pilot. We're going to get it out there in the open. We're going to get the data. We're going to share with everyone out in the open on siliconangle.com and thecube.net. We'll be back with more live coverage here in Palo Alto after this short break.