 Super metafragilistic expialidocious. What's in a name? In an homage to the inimitable Charles Fitzgerald, we've chosen this title for today's session because of all the buzz surrounding SuperCloud, a term that we introduced last year to signify a major architectural trend and shift that's occurring in the technology industry. Since that time, we've published numerous videos and articles on the topic and on August 9th kicked off SuperCloud 22, an open industry event designed to advance the SuperCloud conversation, gathering input from more than 30 experienced technologists and business leaders in theCUBE and broader technology community. We're talking about individuals like Benoit Dajaville, Kit Colbert, Ali Goetze, Mohit Aron, David McJanet and dozens of other experts. And today we're pleased to welcome David Lenthicum who's a Chief Strategy Officer at Cloud Services at Deloitte Consulting. David is a technology visionary, a technical CTO, he's an author and a frequently sought after keynote speaker at high profile conferences. Like VMware, explore next week. David Lenthicum, welcome back to theCUBE. Good to see you again. Oh, it's great to be here. Thanks for the invitation. Thanks for having me. Yeah, you're very welcome. Okay, so there's topic of SuperCloud, what you call MetaCloud has created a lot of interest. You know, VMware calls it cross cloud services, Snowflake calls it their data cloud and a lot of different names. But recently you published a piece in Info World where you said the following, I really don't care what we call it and I really don't care if I put my own buzzword into the mix. However, this does not change the fact that MetaCloud is perhaps the most important architectural evolution occurring right now and we need to get this right out of the gate. If we do that, who cares what it's named? So very cool. And you also mentioned in a recent article that you don't like to put out new terms in the wild without defining them. So what is a MetaCloud or what we call SuperCloud? What's your definition? Yeah, and again, I don't care what people call it. The reality is it's the ability to have a layer of cross cloud services that sits above existing public cloud providers. So the idea here is that instead of building different security systems, different governance systems, different operational systems and each specific cloud provider using whatever native features they provide, we're trying to do that in a cross cloud way. So in other words, we're pushing update integration security. You know, all these other things that we have to take care of as part of deploying a particular cloud provider and in a multi cloud scenario we're building those in and between the clouds. And so we've been tracking this for about five years. We kind of understood that multi cloud is not necessarily about particular public cloud providers. It's about things that you built in and between the clouds. Got it, okay. So I want to come back to that kind of definition but I want to tie us to the so-called multi cloud. You guys did a survey recently. We've said that multi cloud was mostly a symptom of multi vendor shadow cloud, you know, M&A and only recently has become a strategic imperative. Now Deloitte published a survey recently entitled Closing the Cloud Strategy Technology Innovation Gap and I'd like to explore that a little bit. So in that survey you showed data. What I liked about it is you went beyond what we all know, right? The old, our research shows that on average, you know, X number of clouds are used at an individual company. I mean, you had that too, but you really went deeper. You identified why companies are using multiple clouds and you developed different categories of practitioners across 500 survey respondents. But the reasons were very clear for why multi cloud as this becomes more strategic. Service choice scale, negotiating leverage, improve business resiliency, minimizing lock in, interoperability of data, et cetera. So my question to you, David, is what's the problem super cloud or meta cloud solves and what's different from multi cloud? It's a great question. The reality is that if we're super cloud or meta cloud, whatever is really something that exists above a multi cloud. I kind of view them as, you know, the same thing. It's an architectural pattern. We can name it anything. But the reality is that if we're moving to these multi cloud environments, we're doing so to leverage best of breed things. In other words, best of breed technology to provide the innovators within the company to kind of take the business to the next level and we determine that in the survey. And so if we're looking at what a multi cloud provides, it's the ability to provide different choices of different services or piece parts that allows us to build anything that we need to do. And so what we found in the survey and what we found in just practice in dealing with our clients is that ultimately the value of cloud computing is going to be the innovation aspects. In other words, the ability to kind of take the company to the next level from being more innovative and more disruptive in the marketplace that they're in. And the only way to do that instead of basically leveraging the services when that a particular walled garden of a single public cloud provider is to cast a wider net and get out and leverage all kinds of services to make these happen. So if you think about that, that's basically how multi cloud has evolved. In other words, it wasn't planned. They didn't say, we're gonna go do a multi cloud. It was different developers and innovators in the company that went off and leveraged these cloud services sometimes with the with the consent of IT leadership sometimes not. And now we have these multitudes of different services that we're leveraging. So many of these enterprises are going from a thousand to say 3,000 services under management. That creates a complexity problem. We have a problem of heterogeneity, different platforms, different tools, different services, different AI technology, database technology, things like that. So the metacloud or the super cloud or wherever you want to call it is the ability to kind of deal with that complexity and the complexities terms. And so instead of building all these various things that we have to do individually in each of the cloud providers, we're trying to do so within a cross cloud service layer. We're trying to create this layer of technology which removes us from dealing with the complexity of underlying multi-cloud services and makes it manageable. Because right now, I think we're getting to a point of complexity. We just can't operate it at the budgetary limits that we're at right now. We can't keep the number of skills around and the number of operators around to keep these things going. We're going to have to get creative in terms of how we manage these things, how we manage a multi-cloud. And that's kind of where the super cloud, metacloud, whatever they want to call it comes in. Yeah. And as John Furrier likes to say that in IT we tend to solve complexity with more complexity and that's not what we're talking about here. We're talking about simplifying and you talked about the abstraction layer and then it sounds like I'm inferring more. There's value that's added on top of that. And then you also said the hyperscalers are going to walled gardens. So I've been asked why aren't the hyperscalers super clouds? And I've said essentially they want to put your data into their cloud and keep it there. Now that doesn't mean they won't eventually get into that. We've seen examples in a little bit outposts, Anthos, Azure Arc, but the hyperscalers really aren't building super clouds or metaclouds at least today, are they? No, they're not. And I always had the predictions for every kind of major cloud conference that this is the conference that the hyperscaler is going to figure out some sort of a multi-cloud across cloud strategy. In other words, building services that are able to operate across clouds. That really kind of has never happened. It has happened in dribs and drabs and you just mentioned a few examples of that. But the ability to kind of on the space understand that we're not going to be the center of the universe and how people are going to leverage it. It's going to be multiple things, including legacy systems and other cloud providers and even industry clouds that are starting emerging these days and SaaS providers and all these things. So we're going to assist you in dealing with complexity and we're going to provide the core services of being there. That hasn't happened yet. And they may be worried about conflicting their market and the messaging is a bit different. Even actively pushing back on the concept of multi-cloud. But the reality is the market's going to take them there. So in other words, if enough of their customers are asking for this and asking that they take the lead in building these cross-cloud technologies, even if they're participating in the stack and not being the stack, it's too compelling in the market that it's not going to drag a lot of the existing public cloud providers there. Well, it's going to be interesting to see how that plays out, David, because I never say never when it comes to a company like AWS and we've seen how fast they move in the same time, they don't want to be commoditized. There's the layer underneath, all this infrastructure, and they get this ecosystem that's adding all this tremendous value. But I want to ask you, what are the essential elements of super cloud coming back to the definition, if you will, and what's different about meta cloud, as you call it, from plain old SaaS or past? What are the key elements there? Well, the key elements would be holistic management of all of the IT infrastructure. So even though it's sitting above a multi-cloud, I kind of view meta cloud, super cloud is the ability to also manage your existing legacy systems, your existing security stack, your existing network operations, basically everything that exists under the purview of IT. If you think about it, we're moving our infrastructure into the clouds and we're probably going to hit a saturation point of about 70%. And really, if the super cloud meta cloud, which is going to be expensive to build for most of the enterprises, it needs to support these things holistically. So it needs to have all the services that is going to be shareable across the different providers and also existing legacy systems and also edge computing and IoT and all these very diverse systems that we're building there right now. So if complexity is a core challenge to operate these things at scale and the ability to secure these things at scale, we have to have commonality in terms of security architecture and technology, commonality in terms of our directory services, commonality in terms of network operations, commonality in terms of cloud operations, commonality in terms of FinOps, all these things should exist in some holistic cross-call layer that sits above all this complexity. And you pointed out something very profound. In other words, that is going to mean that we're hiding a lot of the existing cloud providers in terms of their interfaces and dashboards and things like that that we're dealing with today, their APIs. But the reality is that if we're able to manage these things at scale, the public cloud providers are going to benefit greatly from that. They're going to sell more services because people are going to find they're able to leverage them easier. And so in other words, if we're moving the complexity wall, which is many in the industry are calling it right now, then suddenly we're moving from, say, the 25 to 30% migrated in the cloud, which most of the enterprises are today, to 50, 60, 70%. And we're able to do this at scale and we're doing it at scale because we're providing some architectural optimization to the super cloud meta cloud layer. Okay, thanks for that. David, I just want to tap your CTO brain for a minute at super cloud 22. We came up with these kind of three deployment models. Kit Colbert put forth the idea that one model would be your control planes running in one cloud, let's say AWS, but it interacts with and can manage and deploy on other clouds at Kubernetes cluster management system. The second one, Mohit Aaron from Cohesity kind of laid out where you instantiate the stack on different clouds and different cloud regions. And then you create a layer, a common interface across those. And then Snowflake was the third deployment model where it's a single global instance. It's a one instantiation basically building out their own cloud across these regions. Help us parse through that. Do those seem like reasonable deployment models to you? Do you have any thoughts on that? Yeah, I mean, that's kind of a distributed computing trick we've been doing, which is in essence an agent of the super cloud that's carrying out some of the cloud native functions on that particular cloud, but is in essence a slave to the meta cloud or the super cloud, whatever, that's able to run across the various cloud providers. In other words, when it wants to access a service, it may not go directly to that service. It goes directly to the control plane and that control plane is responsible very much like Kubernetes and Docker works. That control plane is responsible for reaching out and leveraging those native services. I think that that's thinking that's a step in the right direction. I think these things into themselves, at least initially are going to be a very complex array of technology. Even though we're trying to remove complexity, the super cloud into itself in terms of the ability to build this thing is able to operate at scale across cloud is going to be a collection of many different technologies that are interfacing with the public cloud providers in different ways. And so we can start putting these meta architectures together and I certainly written and spoke about this for years, but initially this is going to be something that may kind of escape the detail or the holistic nature of these meta architectures that people are floating around right now. Yeah, so I want to stay on this because anytime I get a CTO brain, I like to, I'm not an engineer, but I've been around a long time. So I know a lot of buzzwords and have absorbed a lot over the years. But so you take those, the second two models, the Mohit instantiate on each cloud and each cloud region versus the snowflake approach. I asked Ben Wilde, does that mean if I'm in an AWS East region and I want to do a query on Azure West, I can do that without moving data. He said, yes and no. And the answer was really no. We actually take a subset of that data and so there's the latency problem. From those deployment model standpoints, what are the trade-offs that you see in terms of instantiating the stack on each individual cloud versus that single instance? Is there a benefit of the single instance for governance and security and simplicity and but a trade-off on latency or am I overthinking this? Yeah, you hit it on the nose. The reality is that the trade-off is going to be latency and performance. If we get wiggy with the distributed nature like distributed data example you just provided, we have to basically separate the queries and communicate with the databases on each instance and then reassemble the result set that goes back to the people who are recording it. And so we can do caching systems and things like that. But the reality is if it's a distributed system, we're gonna have latency and bandwidth issues that are gonna be limiting us. And also security issues because if we're moving lots of information over the open internet or even private circuits, those are gonna be attack vectors that hackers can leverage. You kind of have to keep that in mind when we're trying to reduce those attack vectors. So it would be in many instances, and I think we have to think about this, that we're going to keep the data in the same visible region for just that. So in other words, it's gonna provide the best performance and also the most simplistic access to dealing with security. And so we're not in essence thinking about where the data is going, how it's moving across things like that. So the challenge is gonna be is when you're dealing with a super cloud or meta cloud is when do you make those decisions? And I think in many instances, even though we're leveraging multiple databases across multiple regions and multiple public cloud providers and kind of that's the idea of it, we're still gonna localize the data for performance reasons. I mean, I just wrote a blog in Info World a couple of months ago and talked about people who are trying to distribute data across different public cloud providers for different reasons, distributed application development system, things like that, you can do it with enough time and money, you can do anything. I think the challenge is gonna be operating that thing and also providing a viable business return based on the application. And so why it may look like a good science experiment and it's kind of cool into itself as an architect. The reality is the more pragmatic and approach is going to be elated in a single region, not a single cloud. Very interesting. The other reason I like to talk to companies like Deloitte and experienced people like you is because I can get, you're agnostic, right? I mean, your technology agnostic, vendor agnostic. So I want to come back with another question which is how do you deal with what I call the lowest common denominator problem? What I mean by that is if one cloud has let's say a superior service, let's take an example of, you know, Nitro and Graviton, you know, AWS seems to be ahead on that, but let's say some other cloud isn't quite there yet and you're building a super cloud or a meta cloud, how do you rationalize that? Does it have to be like a caravan in the army where you slow down? So all those, you know, the slowest trucks can keep up or are there ways to adjudicate that that are advantageous to hide that deficiency? Yeah, and that's a great thing about leveraging a super cloud or a meta cloud is we're putting that management in a single layer. So as far as a user or even a developer on those systems, they shouldn't worry about the performance that may come back because we're dealing with, you hit the nail on the head with that one. The slowest component is the one that dictates performance. And so we have to have some sort of a performance management layer. We're also making dynamic decisions to move data, to move processing in one server to the other to try to minimize the amount of latency that's coming from a single component. So the great thing about that is we're putting that volatility into a single domain and it's making architectural decisions in terms of where something will run and where it's getting its data from, things are stored, things like that, based on the performance feedback that's coming back from the various cloud services that are under management. And so if you're running across clouds, it becomes even more interesting because ultimately you're gonna make some architectural choices on the fly in terms of where that stuff runs based on the active dynamic performance that that public cloud provider is providing. So in other words, we may find that it automatically shut down a database service, say MySQL on one cloud instance and move it to a MySQL instance on another public cloud provider because there was some sort of performance issue that it couldn't work around. And by the way, it does so dynamically away from you making that decision, it's making that decision on your behalf. Again, this is a matter of abstraction removing complexity and dealing with complexity through abstraction and automation. This is an example, that would be an example of fixing something with automation, self healing. When you meet with some of the public cloud providers and they talk about on-prem, you know, private cloud, the general narrative from the hyperscalers is, well, that's not cloud. Should on-prem be inclusive of super cloud, meta cloud? Absolutely. I mean, and they're selling private cloud instances with the edge clouds that they're selling. So the reality is that we're gonna have to keep a certain amount of our infrastructure, including private clouds on-premise. It's something that's shrinking as a market share and it's gonna be tougher and tougher to justify as the public cloud providers become, you know, better and better at what they do. But we certainly have edge clouds now and there's the hyperscalers have examples of that where they run instance of their public cloud infrastructure on-premise on physical hardware and software. And the reality is too, we have data centers and we have systems that just won't go away for another 20 or 30 years or just too sticky. They're uneconomically viable to move into the cloud. That's the core thing. It's not that we can't do it. It's the fact the matter is we shouldn't do it because there's not gonna be an economic, there's not gonna be an economic incentive of making that happen. So if we're going to create this meta layer of this infrastructure, which is gonna run across clouds and everybody agrees and that's what the super cloud is, we have to include the on-premise systems, including private clouds, including legacy systems. And by the way, include the rising number of IoT systems that are out there and edge-based systems out there. So we're managing it using the same infrastructure into cloud services. So they have metadata systems and they have specialized services at service finance and retail and things like doing risk analytics. So it gets them further down that path but not necessarily giving them a SaaS application where they're forced into all of the business processes. We're giving you peace parts. So we'll give you a thousand different parts that are related to the finance industry. You can assemble anything you need but the thing is it's not gonna be like building it from scratch. We're gonna give you risk analytics, we're gonna give you financial analytics, all these things that you can leverage within your applications, how you want to leverage them will maintain them. So in other words, you don't have to maintain them just like the cloud service. And suddenly we can build applications in a couple of weeks that used to take a couple of months in some cases a couple of years. So that seems to be a large take of it moving forward. So get it up in the super cloud. Those become just other services that are under managed, that are under management on the super cloud, they're at a cloud. So we're able to take those services, abstract them, assemble them, use them in different applications and the ability to manage where those services are originated versus where they're consumed is gonna be managed by the super cloud layer where it's dealing with the governance, the service governance, the security systems, the directory systems, identity access, management, things like that. They're gonna get you further along down the pike and that comes back as real value. If I'm able to build something in two weeks it used to take me two months and I'm able to give my creators in the organization the ability to move faster, that's a real advantage. And suddenly we are gonna be valued by our digital footprint, our ability to do things in a creative and innovative way. And so organizations are able to move that fast, leveraging cloud computing for what it should be leveraged as a true force multiplier for the business, they're gonna win the game. They're gonna get the most value. They're gonna be around in 20 years, the others won't. David Lentic, I've always loved talking to you. I have a dangerous combination of business and technology expertise. Let's tease VMware Explorer next week. You're given a keynote if you're gonna be there. Which day are you? Tuesday, Tuesday 11 o'clock. All right, the big day. Tuesday 11 o'clock and David please do stop by the Cube. We're in Moscone West. Love to get you on and continue this conversation. I got a hundred more questions for you. We really appreciate your time. I always love talking to people at theCUBE. Thank you very much. All right, and thanks for watching our ongoing coverage of SuperCloud 22 on theCUBE. You're leader in enterprise tech and emerging tech coverage.