 Welcome back everyone to the SuperCloud 22. I'm John Furrier, host of theCUBE. This is the Clouderati panel. The distinguished experts who have been there from day one watching the cloud grow up and building clouds and all open source stuff as well. Just great stuff, good friends of theCUBE and great to introduce back on theCUBE, Adrienne Cockroft, formerly with Netflix, formerly AWS retired, now commentating here in theCUBE as well as other events. Great to see you back out there, Adrienne. Lori McVidi, Cloud Evangelist with F5, also wrote a great blog post on SuperCloud as well as Dave Vellante as well. Kind of setting up the SuperCloud conversation which we're going to get into. And Chris Hoff, who's the CTO and CSO of LastPass who's been building clouds and we know him from theCUBE before with security and Cloud commentary. Welcome all back to theCUBE and SuperCloud. Thanks John. All right. Lori, we'll start with you to get things going. I want to try to sit back as you guys are awesome experts and involved from building and in the trenches on the front lines and Adrienne's coming out of retirement. But Lori, you wrote the post kind of setting the table on SuperCloud. Let's start with you. What is SuperCloud? What is evolving into? What is the North Star from your perspective? Well, I don't think there's a North Star yet. I think that's one of the reasons I wrote it because I had a clear picture of this in my mind. But over the past, I don't know, three, four years, I keep seeing in research my own and others, right? Complexity, multi-cloud, we can't manage it. They're all different. We have trouble, what's going on? We can't do anything, right? And so digging into it, you know, you start looking into, well, what do you mean by complexity? Well, security, right? Migration, visibility, performance, right? The same old problems we've always had. And so SuperCloud is a concept that is supposed to overlay all of the clouds and normalize it, right? That's really what we're talking about is yet another abstraction layer that would provide some consistency that would allow you to do the same security and monitor things correctly, right? Cornell University actually put out a definition way back in 2016. And they said it's an architecture, right? That enables migration across different zones or providers. And I think that's important and provides interfaces to everything, makes it consistent and normalizes the network, basically brings it all together but it also extends to private clouds. Sometimes we forget about that piece of it and I think that's important in this so that all your clouds look the same. So SuperCloud, big layer on top makes everything wonderful, it's unicorns again. It's interesting, we had multiple perspectives. C comes like Snowflake who built on top of AWS. Jerry Chen who we heard from earlier today, Greylock Penn, this castle's on the cloud saying, hey, you know, you can have a moat, you can build an advantage and have differentiation. So startups are starting to build on clouds. That's kind of the native cloud view. And then of course they get success and they go to all the other clouds because they got customers in the ecosystem. But it seems that all the cloud players, Chris, you kind of commented before we came on today is that they're all fighting for the customer's workloads on their infrastructure, you know. Come bring your stuff over to here and we'll make it run better. And all your developers are going to be good. Is there a problem? I mean, or is this something else happening here? Is there a real problem? Well, I think the North Star's over there, by the way, Lori. Oh, there it is. The SuperCloud North Star. So indeed, I think there are opportunities whether you call them problems or not, John, I think it's to be determined. Most companies have, especially if they're a large enterprise, whether or not they've got an investment in private cloud or not, have spent time really trying to optimize their engineering and workload placement on a single cloud. And that regardless of your choice, as we take the big three, whether it's Amazon, Google or Microsoft, each of them have their pros and cons for various types of workloads. And so you'll see a lot of folks optimizing for a particular cloud. And it takes a huge effort up and down the stack to just get a single cloud right. That doesn't take into consideration integrations with software as a service instantiated, oftentimes on top of infrastructure service that you need to sort of supplement where the abstraction layer ends in infrastructure as a service, right? I'm providing, you've seen most IAS players starting to now move up chain as we sort of predicted years ago. To platform as a service, but platforms of various types. So I definitely see it as an opportunity. Previous employers have had multiple clouds, but they were very specifically optimized for the types of workloads. For example, in let's say AWS versus GCP based on the need for different types and optimized compute platforms that each of those providers ran. We never in that particular case thought about actually running the same workloads across both clouds because they had different pricing models, different security models, et cetera. And so the challenge is really coming down to the fact that what is the cost benefit analysis of thinking about multi-cloud when you can potentially engineer the resiliency redundancy all the in season illities that you might need to factor into your deployments on a single cloud if they are investing at the pace of which they are. So I think it's an opportunity and it's one that continues to evolve. But this just reminds me, your comments remind me of when we were talking about OpenStack versus AWS. Oh, if there were only APIs that existed that everybody could use and you saw how that went, right? So I think that the challenge there is what is the impetus for a singular cloud provider any of the big three deciding that they're going to abstract to a single abstraction layer and not be able to differentiate from the competitors. Yeah, that differentiation is going to be big. I mean, assume that the clouds aren't going to stay still like AWS and just not start innovating. We see the devs are doing great, Adrian. Open source is bigger and better than ever. But now that's been commercialized into enterprise it's an ops problem. So to Chris's point, the cost benefit analysis is interesting because do companies have to spin up multiple operations teams each with specialized training and tooling for the clouds that they're using and does that open up a can of worms? Or is that a good thing? I mean, can you design for this? I mean, is there an architecture or taxonomy that makes it work? Or is it just the cart before the horse, the solution before the problem? Yeah, well, I think that if you look at any large vendor sorry, large customer, they've got a bit of everything already, right? If you're big enough, you've bought something from everybody at some point. So then you're trying to rationalize that trying to make it make sense. And I think there's two ways of looking at what multicloud or super cloud. And one is that impractically people go best of breed. They buy, they say, okay, I'm gonna get my email from Google or Microsoft. I'm gonna run my applications on AWS. Maybe I'm gonna do some AI machine learning on Google because those are the strengths of the platforms. So people tend to go where the strength is. So that's multicloud because you're using multiple clouds and you still have to move data and make sure they're all working together. But then what Lori's talking about is trying to make them all look the same and trying to get all the security architectures to be the same and put this magical layer, this unicorn magical layer that let's make them all look the same. And this is something that the CIOs have wanted for years and they keep trying to buy it and you can sell it but the trouble is it's really hard to deliver. And I think I want to go back to some old friends of ours at Instradius who had, and they were back in the early days of clouds, well, we'll just do an API that abstracts all the cloud APIs into one layer. And Stradius ended up being sold to Dell a few years ago. And the problem they had was that they didn't have any problem selling it. The problem they had was a year later when it came up for renewal, the developers all done end runs around it were ignoring it and the CIOs weren't seeing usage. So you can sell it, but can you actually implement it and make it work well enough that it actually becomes part of your core architecture without, you know, from an operations point of view without having the developers going directly to their favorite APIs around it. And I'm not sure that you can really lock an organization down enough to get them onto a layer like that. So that's the way I say it. You just defined shadow, shadow IT. That's pretty good. Yeah, shadow IT, yeah, yeah. I mean, this brings up the question. I mean, is there a real problem? I mean, I guess we'll just jump to it. What is super cloud? If you can have the magic outcome, what is, what is it? Stradius kind of rendered in with automation, the security issues, Kubernetes is hot. What is the super cloud dream? I guess that's the question. I think it's got easier than it was, you know, five, 10 years ago. One, Kubernetes gives you a bunch of APIs that are common across lots of different areas, things like Snowflake or MongoDB Atlas. There are SaaS-based services which are across multiple clouds from vendors that you've kind of picked. So it's easier to build things which are more portable, but I still don't think it's easy to build this sort of magic API that makes them all look the same. And I think that you're going to have sort of leaky abstractions and security being, getting the security right, it's going to be really much more complex than people think. What about specialty super clouds? Chris, what's your view on that? Yeah, I think what Adrian was alluding to, those leaky abstractions are interesting, especially from the security perspective. Because I think what you see is if you were to happen to be able to thin slice across a set of specific types of workloads, there was a high probability given today that at least on two of the three major clouds, you could get SaaS providers that sit on those same infrastructure, the service clouds for you, string them together and have a service that technically is abstracted enough from the things you care about to work on one, two, or three. Maybe not all of them, right? But most SaaS providers in the security space are identity space, data space, for example, co-exist on at least Microsoft and AWS, if not all three with Google. And so you could technically abstract a service to the point that you let that level of abstract, like Lori said, no computer science problem could not be, you can't, so no computer science problem can't be so more layers of abstraction or misdirection, right? So the redirection. And in that particular case, if you happen to pick the right vendors that run on all three clouds, you can possibly get close. But then what that really talks about is then, if you built your seven layer dip model, then you really have specialty super clouds spanning across infrastructure service clouds, right? One for, you know, your identity apps, one for data and data layers to normalize that, one for security. But at what cost? Because you're going to be charged not for that service as a whole, but based on sort of compute resources based on how these vendors charge across each cloud. So again, that cost-benefit ratio might start being something that is rather imposing from a budgetary perspective. Lori, weigh in on this because, you know, the enterprise people love to solve complexity with more complexity. Here, we need to go the other way, right? It's a commodity. So, you know, it has to be a better way. I think I'm hearing two fundamental assumptions. One, that a super cloud would force the existing big three to implement some sort of equal API. Don't agree with that. There's no business case for that. There's no reason that could compel them to do that. Otherwise, we would have convinced them to do that, what, 10, 15 years ago, and we said we need to be interoperable. So it's not going to happen there. They don't have a good reason to do that. There's no business justification for that. The other presumption, I think, is that it's more about the services, the differentiated services, right? That are offered by all of these particular providers as opposed to treating the core IAS as the commodity it is. It's compute, it's some storage, it's some networking. Look at that piece. Now, pull those together and it's not open stack. That's not the answer. It wasn't the answer. It's not the answer now. But something that can actually pull those together and abstract it at a different layer. So five providers don't have to change because they're not going to change. But if someone else were to build that architecture to say, all right, I'm going to treat all of this compute so you can run your workloads, as Chris pointed out, in the best place possible. And we'll help you do that by being able to provide those kind of cost benefit analysis. What's the best performance? What are you doing? And then provide that as a layer. So I think that's really where SuperCloud is going because I think that's what a lot of the market actually wants in terms of where they want to run their workloads because we're seeing that they want to run workloads at the edge, right? A lot closer to me, which is yet another factor that we have to consider. And how are you going to be moving individual workloads around, right? That's the holy grail. Let's move individual workloads to where they're the best performance, the security, cost optimized, and then one layer up. Yeah, I think so. John Considine, who ultimately ran CloudSwitch that sold to Verizon, as well as Tom Gillis who built Bracket, right? Are both rolling in their graves because what you just described was exactly that. Well, they're not even dead yet. So I can't say they're rolling in their graves. Sorry, Tom. Sorry, Jim. Well, how do hyperscale keep their advantage with all this? I mean, to that point. Native services and managed services on top of it. Look how many flavors of managed Kubernetes you have, right? So you have a choice, roll your own or go with a managed service and then differentiate based on the ability take away and simplify some of that complexity. Doesn't mean it's more secure necessarily, but I do think we're seeing opportunities where those guys are fighting tooth and nail to keep you on a singular cloud, even though to Lori's point, I agree. I don't think it's about standardized APIs because I think that's never going to happen. I do think though that sort of sassy super cloud model that we were talking about. Layering SaaS that happens to span all the three infrastructure services are probably more in line with what Lori was talking about. But I do think that portability of workload is given to you today within lots of ways. But again, how much do you manage and how much performance do you give up by running additional extraction layers? How much security do you give up by having to roll your own and manage that? Because the whole point was in many cases, right? We are cloud is using other people's computers. So in many cases, I want to manage as little of it as I possibly can. I like this whole SaaS angle because if you had the old days, you know, you're on Amazon web services, hey, you build a SaaS application and runs on Amazon, you're all great. You're born in the cloud, just like that's generation of startups. Great. Now when you have this super pass layer as Dave Vellante was riffing on his analysis and Lori, you were getting into this kind of pass layer that's kind of like sassy. What's the SaaS equation looked like? Because that to me sounds like a super cloud versus saying, I have a workload that runs on all the clouds equally. I just don't think that's ever going to happen. I agree with you, Chris, on that one. But I do see that, you know, you can have an abstraction that says, hey, I don't really want to get in the weeds and I want to spend a lot of ops time on this. I just want it to run effectively and magic happens, or as you said, some layer there. How does that work? How did you see this super pass layer, if anything, enabling a different SaaS game? I think you kind of hit on it there, right? The last like 10 or so years, we've been all focused on developers and developer productivity and it's all about the developer experience and it's got to be good for them because they're the kings. And I think the next 10 years are going to be very focused on operations because once you start scaling out, it's not about developers. They can deliver fast or slow. It doesn't matter, but if you can't scale it out, then you've got a real problem, right? So I think that's an important part of it is really, now what is the ops experience and what is the best way to get those costs down? And this would serve that purpose if it was done right, which we can argue about whether that's possible or not, but I don't have to implement it, so I can say it's possible. Well, are we going to be getting into infrastructure as code moves into everything as code, security, data, applications as code? I mean, blank as code, fill in the blank. Yeah, we're seeing more of that with things like CDK and Pulumi, where you're actually coding up using a real language rather than the death by YAML or whatever you... How much YAML can you take, right? But actually having a real language so you're not trying to do things in parsing languages, right? So I think that's an interesting trend. You're getting some interesting templates and I like what... I mean, the sort of the counter example is that if you just go deep on one vendor, then maybe you can go faster and it is simpler. And one of my favorite vendor, favorite customers right now that I've been talking to is Liberty Mutual. Very deep, serverless first on AWS, they're just doing everything there and they're using CDK patterns to do it and they're going extremely fast. There's a book coming out called the Value Flywheel by Dave Anderson, it's coming out in a few months to sort of just detail what they're doing. But that's sort of the counter argument. If you can pick one vendor, you can go faster, you can get that vendor to do more for you and maybe you get a bigger discount. So you're not splitting your discounts across vendors. So that's one aspect of it. But I think fundamentally you're going to find that the CIOs and the ops people generally don't like sitting on one vendor. And if that vendor, if that single vendor is a horizontal platform that's trying to make all the clouds look the same, now you're locked into whatever that platform was, right? You've still got a platform there, there's still something. So I think there's, that's always going to be something that the CIOs want, but the developers are always going to just pick whatever the best tool for building the thing is. And a sort of analogy here is that the developers are sort of dating and getting married and then the operations people are running the family and getting divorced, right? And all the bad parts of that cycle are in the divorce end of it, right? You're trying to get out of a vendor, there's lawyers, it's just a big mess, right? It's all about yourself. Well, you know, that's why ops people don't like locking because they're the ones trying to unlock, right? They aren't the ones doing the lock-in, they're the ones unlocking when developers, if you separate the two, they're the ones who are going picking, having the fun part of it, going trying a new thing, right? So they're chasing a shiny object and then the ops people are trying to untangle themselves from that remains of that shiny object a few years later. So one way of fixing that is to push it all together and make it more DevOps-y, right? But that's sort of trying to put all the responsibilities in one place, like more continuous improvement. Chris, what's your reaction to that? Because you're- No, I was, that's exactly what I was going to bring up. Yeah, John, and because we keep saying devs, dev and ops and I've heard somewhere you can glue those two things together. Heck, you can even include sec in the middle of it and dev sec ops. So what's interesting about what Adrienne's saying though too is I think this has a lot to do with how you structure your engineering teams and how you think about development versus operations and security. So I'm building out a team now that very much makes use of thanks to my brilliant VP of engineering, a team topologies approach, which is very streamlined and product oriented way of thinking about, for example, an engineering, if you think about team structures you might have people that build the front end with the middle tier in the back end and then you have a product that needs to make use of all three components in some form. So just from getting stuff done, their ability then has to tie to three different groups versus building a team that's streamlined that ends up having front end, middleware, and back end folks that understand and share standards but are able to uncork the velocity that's required to do that. So if you think about that not just from an engineering development perspective, but then you couple in operations as a foundational layer that services them with embedded capabilities, we're putting engineers and operations teams embedded in those streamlined teams so that they can run at the velocity that they need to. They can do continuous integration. They can do continuous deployment. And then we added CS, which is continuously secure and continuous security. So instead of having giant centralized teams, we're thinking there's a core team, for example, a foundational team that services platform make sure all the trains are running on time that we're doing what we need to do foundationally to make the environment for the dev and operator and security people functional. But then ultimately, we don't have these big monolithic teams that get into turf war. So the Adrian's point about the operators don't like to be panned in. Well, they actually have a say ultimately in how they architect, deploy, manage, plan to operate those systems. But at the same point in time, we're all looking at that problem across those teams and go like, if one streamlined team says, I really want to go run on Azure because I like their services better. The reality is the foundational team has a larger vote versus opinion on whether or not functionally we can, we can satisfy all of the requirements of the other team. Now they may make a fantastic business case when we play rock, paper, scissors and we do that. Right now that hasn't really happened, right? We look at the balance of AWS. We are picking sassy super cloud vendors that will by the way happen to run on three platforms if we so choose to expand there. So we have a similar interface, similar capability, similar processes, but we've made the choice at last best to go all in on AWS currently with respect to how we deliver our products for all the reasons we just talked about. But I do think that operations model and how you build your teams is extremely important. Yeah, and to that point, the vendors themselves need optionality to the customer, what you're saying. So I'm going to go fast, but I need to have that optionality. I guess the question I have for you guys is what is today's trade off? So if the decision point today is first of all, I love to go fast model on one cloud. I think that's my favorite when I look at all this. And then with the option knowing that I'm going to have the option to go multiple clouds, but everybody wants to lock in on the vendor side. Is that scale? Is that data advantage? I mean, so the lock in is a good question. And then also the trade offs. What do people have to do today to go on a super cloud journey to have an ideal architecture and taxonomy? And what's the right trade offs today? I think that there's, sorry, just to put a comment and then that Laurie get a word in, but there's a lot of the market here is you're building a product and that product is a SaaS product and it needs to run somewhere, right? And the customers that you're going to, if to get the full market, you need to go across multiple suppliers. Most people doing AWS and Azure and then Google occasionally for some people, but that I think has become kind of the pattern that most of the large SaaS platforms that you'd want to build out of, because that's the fast way of getting something that's going to be stable at scale. It's got functionality. You don't have to go invest in building it and running it. Those platforms are just multi cloud platforms. They're running across them. So Snowflake, for example, has to figure out how to make their stuff work on more than one cloud. I mean, they started on one, but they're going across clouds. And I think that that is, that's just the way it's going to be because you're not going to get a broad enough view into the market because there isn't a single, you know, AWS doesn't have 100% of the market, right? It's maybe a bit more than then, but Azure has got a pretty solid set of markets where it is strong and it's sort of market by market, right? So in some areas, different people, some part places in the world and different vertical markets, you'll find different preferences. And if you want to be across all of them with your data product or whatever, whatever your SaaS product is, you're just going to have to figure this out. So in some sense, the super cloud story plays best with those SaaS providers, like there's no flakes of this world, I think. Lori? Yeah, I think the SaaS, right? The SaaS product, right? Kind of identity, you know, whatever, right? You're going to have specialized, right? SaaS, super cloud, we already see that emerging, right? Identity is kind of becoming like this big SaaS play that crosses all clouds, right? It's not just for one. So you get that kind of an evolution going on where, yes, I mean, every vendor who provides some kind of specific functionality is going to have to build out and be multi-cloud as it were. It's got to work equally across them. And the challenge then for them is to make it simple for both operators and if required, right, dev. And maybe that's the other lesson moving forward, right? You can build something that is heaven for ops, but if the developers won't use it, well, then you're not going to get it adopted. But if you make it heaven for the developers, right? The Hops team may not be able to keep it secure or keep everything. So, right, maybe we have to start focusing on both. Make it friendly for both at least. Maybe it won't be the perfect experience, but gee, at least make it usable for both sides of the equation so that everyone can actually work in concert, like Chris was saying, right? A more comprehensive, cohesive approach to delivery and deployment, so. All right, well, wrapping up here, I want to just get one final comment from you guys, if you don't mind. What does SuperCloud look like in five years? Is it, what's the Nirvana? What's the state? What's the steady state of SuperCloud in five to 10 years? Or say 10 years, make it easier. What's the process? Five to 10 years. Chris, we'll start with you. Wow. SuperCloud, what's it look like? A magic plain, a single pane of glass? Yeah, I think. Single glass of pain. Yeah, a single glass of pain, thank you. You stole my line. Well, not mine, but that's the one I was going to use. Yeah, I think what is really fascinating is ultimately, to answer that question, I would reflect on market consolidation and market dynamics that happens even in the SaaS space. So we will see SaaS companies combining in focal areas to be able to leverage the positions that, let's say, in the identity space that somebody has built to provide a set of compelling services that help abstract that identity problem or that security problem or that instrumentation and observability problem. So take your favorite vendors today. I think what we'll end up seeing is more consolidation in SaaS offerings that run on top of infrastructure to service offerings to where a SuperCloud might look like something I described before. You have the combination of your favorite interoperable identity, observability, security, orchestration platforms that run across them and they're sold as a stack, whether it be co-branded by another, by an enterprise vendor that sells all of that and manages it for you or not. But I do think that, you talked about is this, I think you said, is this an innovator's dilemma? No, I think it's an integrator's dilemma as it has always ultimately been. As soon as you get from sort of, genesis to bespoke build to product to then commoditization, the cycle starts anew. And I think we've gotten past commoditization and we're looking at niche areas. So I see just the evolution, not necessarily a revolution of what we're dealing with today as we see more consolidation in the marketplace. Laurie, what's your take? Five years, 10 years. What does SuperCloud look like? Part of me wants to take the high in the sky unicorn approach. No, it will be beautiful and one button and things will happen. But seen this cycle many times before and that's not going to happen. And I think Chris has got it pretty close to what I see already evolving, right? Those different kinds of, you know, super, you know, services basically. And that's really what we're talking about. We call them SaaS, but they're, right? X as a service, everything is a service. And it's really a SuperCloud that can run anywhere, but it presents a different interface because well, it's easier. And I think that's where we're going to go and that's just going to get more refined. And yes, a lot of consolidation, especially on the observability side, but that's also starting to consume the security side, which is really interesting to watch. So that could be a little different SuperCloud coming out in there that's really focused on specific types of security, at least, that we'll layer across and then we'll just hook them all together. It's an API-first world. And it seems like that's going to be our standard for the next while of how we integrate everything. So SuperClouds are APIs. Adrienne, take us home. Yeah. What's your- Sure, I think, and just picking up on Lori's point there, these are web services, meaning that you can just call them from anyway, that you don't have to run everything in one place. You can stitch it together. And that's really meant it's somewhat composable. So I mean, practice, people are going to be composable. Kind of compose their applications on multiple platforms. But I think the interesting thing here is what the vendors do. And what I'm seeing is vendors running software on other vendors. So you have Google building platforms that then they will support on AWS and Azure and vice versa. You've got AWS's distro of Kubernetes, which they now give you as a distro so you can run it on another platform. So I think that trend's going to continue and it's going to be possibly pick, say, an AWS or a Google software stack, but you don't run it all on AWS. You run it in multiple places. Yeah. And then the other thing is the sort of third tier, second, third tier vendors like, I mean, what's IBM doing? I think in five years time, IBM is going to be a SaaS vendor running on the other clouds. I mean, they're already sort of halfway there to be a bit more controversial. It's always fun to kick like, I don't work for corporate entity now. No one tells me what I can say. Bring it on. How long can Google keep losing a billion dollars a quarter? Right? They've either got to figure out how to make money out of this thing or they'll end up basically being a software stack on another cloud platform. Is there like the actual way they can make money on it? Because you've got to, and maybe Oracle, is that a viable cloud platform that you've got to get to some level of viability and I think the second, third tier vendors are going in five, 10 years are going to be running on the primary platform. And I think just the other final sort of thing that's really driving this right now, if you try and place an order right now for a piece of equipment for your data center, key pieces of equipment are a year out. Right? It's like trying to buy a new fridge from like Sub-Zero or something like that. And it's like, it's a year. You got to wait for these things. Right? Any high quality piece of equipment. So you go to deploy in your data center and it's like, I can't get stuff in my data center. Like the key pieces I need, I can't deploy a whole system, we can get bits and pieces of it. So people are going to be cobbling together. This is going to cloud because the cloud vendors have a much stronger supply chain to just be able to give you the system you need, right? They've got the capacity. So I think we're going to see some sort of pandemic and supply chain induced sort of forced cloud migrations just because you can't build stuff anymore outside the cloud because they have the supply. They are the chain. That's super smart. That's what, that's the benefit of going last. So I'm going to scoop and real quick. I can't believe we didn't call this web three super cloud because none of us said web three. Don't forget DAO, blockchain, blockchain super clouds. We have, I mean, there's, there's, there's a very interesting distributed computing stuff here, but we'll call that the cube version. The cube version. The cube version. All right. In the metaverse, cube verse soon. Super cloud, perhaps. But anyway, three points, Adrienne and Laurie. Chris, great to see you, Adrienne and Laurie. Thanks for coming on. We've known each other for a long time. You guys are part of the Cloud Erotic, the group that has been in there from day one and, and watch it evolve and you get the scar tissue to prove it and the experience. So thank you so much for sharing your commentary. We'll roll this up and make it open to everybody. And as additional content, we'll call this the outtakes, the longer version, but really appreciate your time. Thank you. Thank you. Thanks so much. Okay. We'll be back with more super cloud 22 right after this.