Supercloud (Multiple Cloud) vs. Multicloud with Faction Founder Luke Norris
Transcript
(suspenseful music) >> Hey, you're watching the CTO Advisor on the road. The CTO Advisor Road Trip. I'm joined with a CTO Advisor alum, Luke Norris. Founder of Faction. Welcome back to the show. >> Yeah, man, thanks for having me. And thanks for coming to Colorado. >> You know, you don't have to twist my arm, man. This is, as you can see, this is beautiful. We're amongst the clouds. I don't know if I've seen any clouds that were more super- >> Super is a topic.
>> We're amongst the superclouds. So I wanted to talk to you about, the topic is supercloud. Our friends over at theCUBE have coined this term superclouds. 0 is going to be mega supercloud or- >> It's super. >> So for our audience that hasn't been following the conversation, let's recap. What is supercloud, as you understand it? It's a loose definition right now. >> Oh, for sure. Yeah, I think the genie's out of sort of the bottle when it comes to the brand supercloud.
I think it's been in multiple affirmations from cross cloud services at VMware, and it's really this idea of abstracting the individual APIs and functions of each of the public clouds, and making it a combined solution or service. We obviously have our own take on that that still makes it a multiple cloud solution. You're still working unique functions in one cloud, unique functions in another cloud. The apps aren't truly spanning. It's just making it easier to actually operate multiple apps running siloed in multiple clouds.
>> So I think the Wikibon folks would argue that it's the complete opposite. It is abstracting the lower level functions of each cloud to provide kind of a single API. The use case they like to give is Snowflake. Of how Snowflake takes each individual cloud, normalizes it, and then presents their solution via their supercloud. >> I love the Snowflake example. So in that example individually, you need individualized compute in Amazon. You need a separate data store in Amazon to run that Snowflake instance.
And then in Azure, you would have compute in Azure, and a separate distinct data set in Azure that you would then have to replicate and actually keep in synchronized with the Amazon one if you wanted to use the applications and services across them. >> So you're saying that supercloud is just an extension of what we call, you know, and I've had this conversation with you guys before, when we're talking about multiple clouds being able to normalize operation across multiple clouds. This is simply normalizing operations within multiple clouds versus making an application and data available across multiple clouds.
>> That's correct. Now, I think this is absolutely needed. I love the fact that it's actually getting a tremendous upswell and attention, and people are now taking notice of it, but it still doesn't allow for that application or service to span multiple clouds simultaneously. To do that, the first thing is data and data gravity. You have to have a single data set so that you can have an application A in one of the clouds and application B in one of the clouds accessing that same data set in real time.
And that's the only way to actually span those. And then B, you actually have to have Amazon, Microsoft, and Google talk to each other as if they are one cloud. And it's our fixed fabric that actually entangles that allows us to do that. >> So we're going to go into the fabric a little bit, but I want to drill into this use case around using data across clouds. One of the arguments for supercloud is that it's not only a technology innovation, but it's a business enabler.
Like, you can do different things that you can't do with the traditional multiple cloud approach. As we're thinking multicloud, this ability to access data across multiple cloud providers, how is that changing, or give me examples of how that's changed business outcomes? >> So we're seeing some really interesting business outcomes across the spectrum of industries. The one that we always talk about is genomics research. The fact that Amazon and Microsoft and Google have different AIML engines. The fact that they can actually have different trained models that they've spent nearly billions of dollars on.
And if you put all your data in Google, you're using Google's already trained model that they've spent this, you know, enormous amount of money on, but you're also missing that innovation of that model being trained by the enormous innovation of Azure, the enormous innovation of AWS. Or you could copy the petabytes and petabytes of data across all of those to try to achieve that. It's not business feasible. So having that one data set and then taking advantage of all of that, you know, functionality, features, and really innovation that they've built into their already pre-trained classical models, is a massive business outcome.
We're also just seeing really cool use cases. There's a real simple business outcome. " If it's damaged, it'll automatically kick off a ticket. It will actually get a shipment received. They'll actually have the person come back and pick up the box. So you can actually drive full supply chain and other features and functionalities when you start pairing all these cool AIML models together. >> So I get the business outcome part of it. I mean, I can do some amazing things.
I can bring in my Snowflake- >> Absolutely. >> Example to leverage this type of capability. But the first thing that comes to my mind is egress. Like, the reason why we don't do this is because the egress charges. There's providers on a market that give me a single control plane for my data across multiple clouds. But every time I go to implement one of these types of business outcomes, I get killed for egress charges, and it mitigates any business benefit I would've gotten.
>> So what we've seen is the egress is a little FUD in our mind. First off, if you truly do have multiple copies of that data in multiple clouds, then synchronizing that is an egress killer. That's impossible. 'Cause the amount of data that is constantly having to be rewritten across all of them. If you have that one copy of data, it's read into the cloud, and only the output is actually written back to that one copy of data. And that's a fraction.
We're talking one billionth of typically the amount of data that's read in is actually written in these. Any egress, sorry, in any batch process like a AIML, EDM, ADAS systems, the rights, the actual outputs from those models and from those things is a fraction of the actual intake of data. Last, a lot of the providers are starting to just remove egress fees. Azure, with their Express Route Local, completely zero egress. We're also seeing limitations and fixed egress at AWS and Google these days.
>> So we hit on a couple of topics that I want to expand upon on some additional content. One, I want to dive into this AIML use case. So we're going to go to the lightboard and do that. Follow the link in the video to the lightboard to have that conversation, 'cause I want you to draw this out for me. And the other one, I'm actually having a panel at VMware Explore that goes deeper into some of these topics. I'm going to have a VP from AbbVie, genomics research.
And then Rebecca Weekly, a VP from CloudFlare, who runs hardware at Cloudflare. And Cloudflare is pushing the industry to kind of get rid of egress and change these issues. So I want to continue this conversation, but we're going to get a little bit more technical. You're a founder, so I expect you to be able to, you know, geek talk. This has been high level. This has been high level, executive level, but we're going to go one layer deeper in our next conversation.
>> Sounds good. com. If you have questions for me or Luke, @ me on Twitter. DMs are open. We can have an extended conversation. com. Talk to you next CTO Dose video.
