 Welcome back to our studios in Palo Alto, California. My name is Dave Vellante. I'm here with John Furrier, who was taking a quick break. You know, one of the early examples that we used of so-called super cloud was Snowflake. We called it a super data cloud. We had really a lot of fun with that. And we've started to evolve our thinking years ago. We said that data was going to form in the cloud around industries and ecosystems. And Benoit Dajaville is a many time guest of theCUBE, he's the co-founder and president of products at Snowflake. Benoit, thanks for spending some time with us at Super Cloud 22, good to see you. Thank you, thank you, Dave. So, you know, we, like I said, we've had some fun with this meme, but it really is, we heard on the previous panel, everybody's using Snowflake as an example. Somebody who builds on top of hyper scale infrastructure. You're not building your own data centers. And so, are you building a super data cloud? We don't call it exactly that way. We don't like the super, you know, world. It's dismissive about our, you know, friends at cloud provider friends. So, but we call it the data cloud. And the vision really for the data cloud is indeed, it's a cloud which overlays, you know, the hyperscaler, you know, cloud. And, but there is a big difference, right? There are several ways to do this, you know, super cloud as you name them. The way we picked is to create, you know, one single system and that's very important, right? The, there are several ways, right? You can instantiate, you know, your solution in every region of the cloud and, you know, potentially that region could be AWS, that region could be GCP. So you are indeed a multi-cloud solution. But Snowflake, we did it differently. We are really creating cloud regions which are superposed on top of the cloud provider, you know, region, infrastructure region. So we are building our regions. But where it's very different is that each region of Snowflake is not one instantiation of our service. Our service is global by nature. We can move data from one region to the other. When you land in Snowflake, you land into one region, but you can grow from there and you can, you know, exist in multiple cloud at the same time. And that's very important, right? It's not one single, I mean, different instantiation of a system is one single instantiation which covers many cloud regions and many cloud providers. So we use Snowflake as an example, and we're trying to understand what the salient aspects are of, you know, your data cloud, what we call super cloud. In fact, you know, you use the word instantiate. Kit Colbert just earlier today laid out, he said there's sort of three levels. You can run it on one cloud and communicate with the other cloud, you can instantiate on the clouds or you can have the same service running 24 seven across clouds. That's the hardest example. The most mature. You just described essentially doing that. How do you enable that? What are the technical enablers? Yeah, so as I said, you know, first we start by building, you know, Snowflake regions. We have today three regions that spawn, you know, the world. So it's a worldwide system with many regions, but all these regions are connected together. They are, you know, mesh together with our technology. We name it Snowgrid. And that makes it hard because, you know, regions, you know, Azure region can talk to AWS region or GCP regions. And as a user of our cloud, you don't see really this regional differences that, you know, regions are in different, you know, potentially cloud. When you use Snowflake, you can exist. Your presence as an organization can be in several regions, several clouds if you want, geographic and both geographic and cloud provider. So I can share data irrespective of the cloud and I'm in the Snowflake data cloud. Is that correct? I can do that today. Exactly. And that's very critical, right? What we wanted is to remove data silos. And when you associate a system in one single region and that system is locked in that region, you cannot communicate with other parts of the world. You are looking data in one region, right? And we didn't want to do that. We wanted, you know, data to be distributed the way customer wants it to be distributed across the world and potentially sharing data at world scale. So does that mean if I'm in one region and I want to run a query that's right? I'm in AWS in one region. I want to run a query when data that happens to be in an Azure cloud. I can actually execute that. So yes and no, the way we do it is very expensive to do that because generally if you want to join, you know, data which is in, which are in different region and different cloud is going to be very expensive because you need to move, you know, data every time you join it. So the way we do it is that you replicate the subset of data that you want to access from one region from other regions. So you can create this data mesh, but data is replicated to make it very cheap and very performant too. And is the snow grid, does that have the metadata intelligence to actually perform? Can you describe that a little bit? Yes, snow grid is both a way to exchange, you know, metadata about, so each region of Snowflake knows about all the other regions of Snowflake. Every time we create a new region, that, you know, the metadata is distributed of our data cloud, not only, you know, region knows all the region, but knows, you know, every organization that exists in our clouds where this organization is, where data can be replicated by this organization. And then of course it's also used as a way to exchange data, right? So you can exchange, you know, four petabytes scale of data size. And we just had, I was just receiving an email from one of our customer who moved more than four petabytes of data cross region, cross, you know, cloud providers in, you know, few days. And, you know, it's a lot of data. So it takes, you know, some time to move, but they were able to do that online, completely online and switch over, you know, to the other region, which is failover is very important also. So one of the hardest parts about SuperCloud that I'm still trying to struggling through is the security model, because you've got the cloud as your sort of first line of defense. And now we've got multiple clouds with multiple first lines of defense. I've got a shared responsibility model across those clouds. I've got different tools in each of those clouds. Do you take care of that? Where do you pick up from the cloud providers? Do you abstract that security layer? Do you, you know, bring in partners? It's a very complicated. No, this is like, this is a great question. Security has always been the most important aspect of Snowflake since day one, right? This is the question that every customer of ours has, you know, how can you guarantee the security of my data? And so we secure data really tightly in region. We have several layers of security. It starts by creating every data at rest. And that's very important. A lot of customers are not doing that, right? You hear these attacks, for example, on cloud, you know, where someone left, you know, their buckets open and then, you know, you can access the data because it's a non-encrypted. So we are encrypting everything at rest. We are encrypting everything in transit. So a region is very secure. Now, you know, you never, from one region, you never access data from another region in Snowflake. That's why also we replicate data. Now the replication of that data across region or the metadata for that matter is really highly secure. So Snowgreets ensures that everything is encrypted. Everything is, you know, we have multiple, you know, encryption keys and it's, you know, stored in hardware, you know, secure modules. So we beat, you know, Snowgreets such that it's secure and it allows very secure movement of data. Okay, so I know we kind of, getting into the technology here a lot today, but because SuperCloud is the future, we actually have to have an architectural foundation on which to build. So you mentioned like a bucket, like an S3 bucket. Okay, that's storage. But you also, for instance, taking advantage of new semiconductor technology. So my quite, like Graviton as an example that drives efficiency. You guys talk about how you pass that on to your customers, even if it means less revenue for you. So awesome. We love that. You make it up in volume. And so, but how do you deal with the lowest common denominator problem? I was talking to somebody the other day and this individual brought up what I thought was a really good point. What if we, let's say AWS, have the best, you know, silicon, okay? And we can run the fastest and the least expensive and the lowest power. But another cloud provider hasn't caught up yet. How do you deal with that delta? Do you just take the best of and try to extract that? No, it's a great question. I mean, of course our software is abstracting, you know, all the cloud providers, you know, infrastructure, such that when you run in one region, let's say AWS or Azure, it doesn't make any difference as far as the applications are concerned. And this abstraction, of course, is a lot of work. I mean, really, really a lot of work because it needs to be secure, it needs to be performance and, you know, every cloud and it has, you know, to expose APIs which are uniform and, you know, cloud providers, even though they have potentially the same concept, let's say blob storage, APIs are completely different. The way, you know, these systems are secure is completely different. The errors that you can get and the retry, you know, mechanism is very different from one cloud to the other, the performance is also different. We discovered that when we were starting to port our software and, you know, we had to completely rethink how to leverage blob storage in that cloud versus that cloud because just of performance too. And so we had, you know, for example, to, you know, Stripe data, so all this work is work that, you know, you don't need as an application because our vision really is that application which are running in our data cloud can, you know, be abstracted off all these difference and we provide all the services, all the workload that this application need, whether it's transactional access to data, analytical access to data, you know, managing, you know, logs, managing, you know, metrics, all of this is abstracted too such that they are not, you know, tied to one, you know, particular service of one cloud and distributing this application across, you know, many regions, many cloud is very seamless. So Snowflake has built, your team has built that true abstraction layer across those clouds. That's available today. It's actually shipping. Yes. I can use it. And we are still developing it, you know, transactional, you know, Unistore, as we call it, was announced in last summit. So they are still, you know, work in progress. But that's the vision, right? And that's important because we talk about the infrastructure, right? You mentioned a lot about storage and compute, but it's not only that, right? When you think about application, they need to use the transactional database. They need to use an analytical system. They need to use, you know, machine learning. So you need to provide also all these services which are consistent across all the cloud providers. So let's talk developers because, you know, you think Snowpark, you guys announced the big application development push, the Snowflake summit recently. And we have said that a criterion of SuperCloud is a SuperPaz layer. People love they wince when I say that. But okay, we're just going to go with it. And, but the point is, it's a purpose-built application development layer specific to your particular agenda that supports your vision. Have you essentially built a purpose-built Paz layer? Or do you just take kind of off-the-shelf standard Paz and cobble it together? No, we build it, you know, a custom build because as you said, you know, what exists in one cloud might not exist in another cloud provider, right? So we have to build, you know, all these components that's a modern application, more than that application need. And that, you know, goes to machine learning, as I said, transactional analytical system and the entire thing, such that it can run in isolation, basically. And the objective is the developer experience will be identical across those clouds, is that right? Yes, the developers doesn't need to worry about cloud provider. And actually our system, we didn't talk about it, but the marketplace that we have, which allows actually to deliver. We're getting there. Yeah. Okay. No, no, let's go there because the other aspect of SuperCloud that we've talked about is the ecosystem. You have to enable an ecosystem to add incremental value. It's not, you know, the power of many versus the capabilities of one. So talk about the challenges of doing that, not just the business challenges, but again, I'm interested in the technical and architectural challenges. Yeah, yeah, so it's really about, I mean, Snowflake has the way we enable our, you know, ecosystem and, you know, our partners, you know, to create value on top of our data cloud is via the marketplace where you can, you know, put, you know, share data in the marketplace, put, you know, provide listing on this marketplace, which are data sets, but it goes way beyond data. It's all, go all the way to application. So you can develop, think of it as the iPhone, a little bit more, all right? Your iPhone is great, not so much because the hardware is great, or because, you know, of the iOS, but because of all the application that you have and all these applications are not necessarily developed by the, you know, Apple, basically. So we are, you know, it's the same model with our marketplace. We foresee an environment where, you know, customers, I mean, providers and partners are going to build these applications. We call it native application and we are going to help them distribute these applications cross cloud, you know, everywhere in the world potentially and they don't need to worry about that. They don't need to worry about how these applications are going to be insensiated or we are going to help them to monetize these applications. So that unlocks, you know, really all the partner ecosystem that you have seen, you know, with something like the iPhone, right? It has created, you know, so many new companies that have developed, you know, these applications. You're detractors of criticizing you for being a walled garden. I've actually used that term. I use terms like de facto standard, which are maybe, you know, less sensitive to you. But nonetheless, you know, we've seen de facto standards actually deliver value. I've talked to Frank Slutman about this and he said, Dave, we deliver value. That's what we're all about. At the same time, you know, he even said to me, you know, your thoughts on this is, look, we have to embrace open source where it makes sense. You guys announced the pastry, iceberg. So what are your thoughts on that? Is that to enable a developer ecosystem? Why? Why did you do iceberg? Yeah, yeah, I mean iceberg is very important. So just to give some context, iceberg is an open, you know, table format, which was, you know, first, you know, developed by Netflix and Netflix, you know, put its open source in the Apache community. So we embrace that open source standard because it's widely used by many, many, you know, companies and also many companies have, you know, really invested a lot of effort in building, you know, big data adobe solution or data like solution and they want to use Snowflake and they couldn't really use Snowflake because all their data were in open, you know, format. So we are embracing iceberg to help these companies move to the cloud. But why we have been reliantence with direct access to data? Direct access to data is a little bit of a problem for us. And the reason is when you direct access to data, now you have direct access to storage. Now you have to understand, for example, the specificity of one cloud versus the other. So as soon as you start to have direct access to data, you lose your, you know, your cloud diagnostic layer. You don't access data with API. When you have direct access to data, it's very hard to secure data because you need to grant access, direct access to tools which are not, you know, protected and you see a lot of, you know, hacking of data, you know, because of that. So that was not, you know, direct access to data is not serving well our customers. And that's why we have been reliant to do that because it's not cloud diagnostic. It's, you have to code that. You have to, you need a lot of intelligence while API is accessed. So we want open APIs that that's, I guess the way we embrace, you know, openness is by open API versus, you know, you access directly data. iPhone. Yeah, yeah, iPhone, API, you know, we define the set of APIs because APIs, you know, the implementation of the APIs can change, can improve. You can improve compression of data. For example, if you open direct access to data now, you know, you cannot evolve. My point is you made a promise for, you know, governed security, data sharing, ecosystem. It works the same way. So that's the path that you've chosen. Ben-Waad Dajaville, thank you so much for coming on theCUBE and participating in SuperCloud 22. Really appreciate it. Thank you, Dave. It was a great pleasure. Right there, right back with our next segment, right after this short break.