Name: Building a multi-platform data strategy with Cloudflare R2
Uploaded: 2025-08-20T17:17:57.370Z
Duration: 38 min 36 s
Description: Building a multi-platform data strategy with Cloudflare R2

Transcript for "Building a multi-platform data strategy with Cloudflare R2": Philip, are you talking? Because I don't think we can hear you. So they're backstage. So if you put the backstage microphone up, we can hear them. Got it. Okay. We're seasoned pros at this. So we are fully public. Just me and you. Hey, everyone. Welcome to our new podcast. It's the Hamza j Cloudflare botflare podcast. Exactly. In addition to being an amazing engineer, Hamza has the greatest voice I've ever heard in technology, so I'm just gonna let him present all of this. I'll just I'll just read out an architectural diagram book. The Morgan Freeman of data infrastructure. It's it's on it's on the mic. It's on the mic. Hey, everyone. What's up, Philip? Doing well. We'll give it, like, another, like, thirty seconds or so before, for folks to join, and then we'll get started. Hope everyone's having a good day so far. Cool. Well, I think we I think we're good to get started. First of all, thank you everyone for joining. You you we we we appreciate you being here. You know, we're we're gonna have a a few different people speaking today, and then we'll we'll also have a q and a. So you you all should be able to type in questions. And then, after, after we're done talking, you know, we'll we'll be able to answer them. So, I guess before we get started, the people that'll be speaking today I mean, I'll I'll be one of them. So my name is Philip. I'm a product manager at Cloudflare. I work on some of the, some of our data and storage products on the developer platform. And then we're also so excited to have, Jake and Hamza from Bobsled. So Jake is cofounder and CEO of Bobsled. We've, worked together now for, I don't know, at least at least a year or so. So, excited to have you have you here to present. Then Hamza as well, who's a a senior engineer. Thanks so much for having us, Chris. Appreciate you all for being here. And so, you know you know, we have a we have a, you know, a a a, you know, kind of a basic agenda here. So, I'm gonna be talking about the first couple things. So we're gonna talk about, you know, why why multicloud, why Multi Engine Now, some of the things that we've been seeing from our customers and kind of just general trends in the industry. We're gonna talk about a little bit about Cloudflare's data primitives, you know, for this multi cloud, multi engine world, some of the products that we've been building and some of the things we've been, seeing from from companies out there and customers. And then, bobsled folks will jump in, talk a little bit about, you know, what bobsled is, what kind of problems that they're solving for customers. They'll talk a little bit about some of the key challenges in building an interoperable data, data platform. And then, you know, we'll talk they'll talk a little bit about how, you know, how they're using, some of the Cloudflare products to kind of, make that a reality. And then at the end, I mentioned earlier, we'll have a q and a. So if you have questions, you know, feel free to post them. So, first thing is why multi platform now? So, you know, I think a long time ago, when I would when, you know, I think multi the general kind of concept of multi cloud, seemed like it was, you know, only for kind of a select few companies who would be doing it to sort of, you know, derisk work certain workloads, things like that. But increasingly over the last few years, we're seeing, you know, a lot of companies that are are going multi cloud. So these could be even like a you know, you know, on on one extreme, single person startups all the way to, you know, who are going multi cloud to get access to, you know, GPU computes, you know, because of availability shortage over the last couple of years. Or it could even be, you know, you know, up to larger companies who are doing it, to gain access to best of breed services on different clouds, and also just to avoid, lock in generally from a strategic perspective. And then, you know, kind of adjacent to this multi cloud, you know, you know, wave that we've seen, we also see more and more data teams that are going multi engine. So, we we, you know, we talk to many companies who either themselves or have customers who are using, you know, Snowflake and Databricks, right, and Spark, Trino, you know, etcetera, BigQuery for different workloads. And and and some of this, you know, multi engine trend that we're seeing is, you know, is really being enabled by some of these open table formats like Apache Iceberg, for example, Delta Lake, and and and there are others. But, you know, going multi cloud, you know, multi engine, doesn't come without challenges. Moving data across clouds can be expensive, and there's a lot of complexities there, which I think that Cloudflare does a lot to address, but also Bobsled, really handles some of these problems, you know, for data teams. So just to give a brief overview, of some of the things that Cloudflare is doing in the data space and and some of the primitives and services that we have that address some of these, you know, you know, address some of these multi cloud and multi engine, you know, challenges. So I think I think first, a lot of this stuff is built on a product that we have called r two, which, you know, we're gonna talk about a little bit later, but it's an object storage product. A lot of these open table formats like Apache Iceberg, etcetera, they're really built with object storage in mind, and that's kind of one of the key components here. But, you know, it's not all about storage. There's also questions of, hey. How do you know, I have storage, you know, and and that but how do I actually get my data into storage, into a format that's, you know, that I can actually do something with? So we're building a product, called pipelines, which is out today. But, essentially, the, you know, the goal there and and and and what you'll be able to do is, ingest data in directly into iceberg, directly into some columnar formats. And then, you know, once you have data, you know, on the platform, you you know, then you have to query it. Right? So, you know, I think I think that's where some of the zero egress stuff comes into play and some of these interoperable formats you can use, any engine you want. So I'll just briefly talk about some of the services that we have before handing it off to the the Bobsled, team. But, you know, like I said, r two object storage, it's a object storage product, zero egress fees. And it's really the foundation, for a lot of our customers building, you know, multi cloud or multi, engine, products, whether that's, data teams, you know, with analytics tables or whether it's, teams who are training AI models and need to access that data, you know, around the world in any cloud and region. And one of the great things about it is, you know, it supports a common object storage API, which is the s three API. So a lot of times, it's just as easy as changing an endpoint, and and and you'll have things working just like, you expect. And briefly, a little bit, I think, one of the cool things is, you know, I'll talk about this is how r two works. So traditionally, when you're using, you know, an object storage provider, you'll see there's an endpoint. It's a regional endpoint in Cloudflare, and and that means, you know, your data might be stored in Eastern North America, but and and, you know, whenever wherever your users are, which may be around the world, they're talking directly, you you know, to data in North America, and that can cause issues in terms of latency, performance, things like that. Just a little bit about how r two works. There's kind of three components. We have a API layer, which is a Cloudflare worker. We have a metadata layer and then object, the underlying object store layer. And one of the cool things, leveraging Cloudflare network is because our API layer is a Cloudflare worker and those Cloudflare workers run close to users and clients no matter where they are. If you have, if you have data stored in Eastern North America, like in our previous example, but you have customers or clients in Asia or Europe, etcetera, we're able to leverage Cloudflare network to do a lot of really intelligent caching, to improve performance both on the read side and on the write side. So that's that's one one little difference about how r two works, but, you know, it kinda ties into things here. Briefly, r two data catalog. So, not only do we have object storage, but we've been leaning more into the Iceberg community. So you you know, if you if you're familiar with Iceberg, you can't just, set it and forget it. You know, there there is a catalog component there. And, you know, one of the things that you have to do, with with large scale, iceberg tables is you act actually have to compact data. So, you know, if you're writing iceberg, sometimes you can end up with many small files which are less efficient to query. One of the things that we're building into, our data catalog, which we're shipping very soon, is the ability to compact data files, and do further table optimizations to make sure that you could always get the same, you know, to get to get the best performance. And since this works directly with r two, there's still zero egress fees. And since it's, you know, built on an iceberg standard, you can use any, you know, engine that you you already use, whether it's Snowflake, Spark, PySpark, etcetera. And then on the ingest side, one of the things that we we have out in beta but we're continuing to ship updates to is something called pipelines. And, essentially, this is a product that allows you to ingest streams of data either through Cloudflow workers or HTTP, API. And you could write SQL pipeline transformations on these streams of data and then ultimately write it to, our data catalog, and and or other columnar formats like, you know, parquet, etcetera. And and, ultimately, you know, some you know, what the goal of these pieces is, you know, to make, having these data lakes and data warehouses as easy as possible for customers. You don't have to worry about things like iceberg and the maintenance, that you have to do. So yeah. With that, I you know, I'd like to hand it off to the Bobsled team to talk a little bit more about Bobsled and how how they're using, you know, how how they're thinking about this. Fantastic. Thank you very much, Philip. I really appreciate the time and and all of the partnership over the past year. It's been, it's been great. Looking forward to continuing it. So as mentioned, I am cofounder and CEO of Bobsled, which is the world's most adopted data sharing platform. Today, Bobsled is used by many of the largest producers of the world's most valuable data products, right, across just about every major industry you can think of. So those are the companies like ZoomInfo and Dun and Bradstreet and GlobalData and Deutsche Borse and Kotality or three of the five largest stock exchanges in the world or other leaders in technology and health care. Many companies really produce the data that that power, you know, so much of the analytical and intelligence workflows, across the tech the the market rely on us to build, share, and govern their data products. I think I can slide to you myself. Right? Fantastic. And the reason that they choose to work with Bobsled to manage this critical infrastructure is because we enable true interoperability across the full stack of data infrastructure. Right? So our customers don't just need to make their data available everywhere their customers work, which is a major problem in and of itself, but they need to do it with granular entitlements. They need to do it with rich semantics and data models, and they need to do it with enterprise grade observability and governance. So to deliver that, we've had to really build in this idea of interoperability across multiple layers in the stack. So if you look at the diagram here on the bottom, and we had to start with interoperability at the data structure level. Right? So if you just think about how data models and data types and update patterns and optimizations work across Snowflake and Databricks and open source formats like Iceberg and others, there's an enormous amount of complexity in making sure things that seem as simple as, you know, geography being represented across multiple platforms actually take a lot of work to build and manage, and that's something that we've been working on for the last several years. Something that we're hard at work on right now where the market is going is an interoperable context layer. Right? So as more and more enterprises look to have AI native access to their data, bringing semantics and business meeting, from where data lives to where it's actually going to be accessed, it's kind of the next frontier in this interoperability and in a place where we're investing enormous amount of our time. Next, creating a data product catalog. So, really, a catalog experience that's really focused on this idea of creating data products that are consumed outside of your organization and to do that in a way in which they can be discovered, understood, and governed across all of the different platforms for their access. We really had to build from the ground up. And then you get to, you know, what is really the the most basic aspect of this and what I think will just continue to take engineering focus and time is what we consider to be a global sharing network. Right? So that's supporting all of the sharing and access mechanisms across every major cloud and data platform today and very soon, across the most adopted AI platforms in the world as well as we go through this platform shift of really people looking to bring, you know, prompt to SQL and direct insights as a service as opposed to pure data as a service, this will continue to evolve, I think, in perpetuity. But in order to solve these problems, we have multiple categories of technical and infrastructure issues that we've had to solve in order to do that. So moving from the top, we actually have to enable provisioning and management of infrastructure of every single region of every cloud and every data platform. Because if you think a little bit about how daring mechanisms and kind of best in class access works, really, what you're generally doing is pushing the permissioning and access to the platform where that data is going to be accessed and creating a really seamless experience for whoever is going to consume that data. But the flip side of that is that the data actually does have to be represented in accounts within these platforms, which means we need the ability to spin up and manage infrastructure across, again, every region of every cloud, every data platform. But it's not just accounts. It's the right storage and elastic compute and permissions and all of those things within data platforms as well, and they need to be able to be scaled up and down dynamically. Next, we had to move towards the translation and interoperability of those data products. Right? So whether that's data types, whether that's update patterns and CDC, how it's moving into semantics, we have to act as this translation layer so our customers can build and manage their data products once and have them move seamlessly across all of the platforms in which they they their consumers interact with them. Then we had to move into entitlements and access. So in addition to supporting the multiple different flavors of sharing mechanisms that exist within Snowflake and Databricks and s three and Azure Blob Storage, etcetera, our customers actually need to be able to define interoperable views across these platforms. Right? Because, generally, data products are not everyone accesses the same data. Right? You need to be able to control who accesses what data, where they can access, and to do that in a way in which you have consistency and reliability. And then from there, governance and observability became critically important for Bobsled, especially as we began to power a lot of the most mission critical workloads for, you know, the world's largest enterprises. Right? So to do that, we have to provide telemetry and controls to monitor usage. We have to ensure data quality. We have to maintain compliance across this, you know, pretty complex footprint across all of these different networks. And, increasingly, our customers move petabytes of data They're driving billions of dollars in revenue. So knowing who has that data, where and when, and really guaranteeing the consistency and quality of it, it's not a nice to have. It's it's a core requirement for what we do. And then we moved into a challenge that, frankly, I I just don't think we could really solve on our own, which is doing this, in a way in which it's it's not just cost efficient, but I'd say that the economics work really at scale. Right? So, you know, we can and do invest a lot of engineering effort in making sure that our compute is efficient, and we size warehouse and serverless compute correctly and and, you know, make sure that's dynamic. But the issue of really the tax of egress, but also the requirement to replicate data so many times across all of these different platforms, it it really isn't something that we as sitting into this layer over the infrastructure itself could really solve. And, I mean, one of the things that we've seen is that for many of the world's largest data products, it actually made interoperability entirely unviable. Right? And you really you couldn't make this data more easily accessible. And I have to say, I think that Cloudflare has really changed the economics of the Internet in many ways, and now I think data infrastructure in a really meaningful way. Right? So, Cloudflare and r two, it really is the only zero egress network that works. And I don't think anyone should underestimate the challenge of actually delivering that. Right? The only way that CloudFlare can do that without having dug in you know, fill up too much with the the teams that have built that is you have to run your own fiber between all of these hyperscalers backbones. Right? And not only do you need to go through all of the investment to to do all of that actual, you know, physical engineering and work, you then need to be willing to not charge for it in the way that it just become the standard tax of egress for all data that moves between platforms that I've really never been able to wrap my mind around even when I was working at some of these hyperscalers myself. So, yeah, I don't this isn't a problem that we or anyone else could fix without CloudFlare. I know that's only one bullet on this larger list, but it's one that I think they're, you know, not only uniquely suited to solve, but I think in general, just is an example of, one example of kinda one of the many reasons I think Cloudflare is such an impressive organization, and that it really is reducing these taxes and these friction points and these inefficiencies for running the Internet. So I'm really, really excited to have been able to partner with them around solving, you know, what seems like one bullet, but is really just like a like a structural problem with how the cloud is scaled, which is really cool. So for that, I am going to hand it over to Hamza, who is one of our lead engineers on our, r two implementation. Thank you, Josh. Cool. So, everyone will have their eyes blasted with a beautifully presented high level architecture diagram. I'm basically going to go through our Sled House project, and this project is essentially the interoperable data lake that, you know, Jake's been describing in the previous slides. How does it work and, like, where does r two fit in and, like, how like, what what are the core parts of this? So roughly starting I'll just, like, gesticulate wildly at the screen with no pointer, but on the left, we have provider infrastructure in that red, font. That's, like, obviously, the provider data. On the on the far right is the customer. So that's where people that consume the data, they wanna make their queries on the data, and they wanna, yeah, make use of it. Essentially, in the middle there, so bang in the middle, interoperable data lake. So what we've basically built is an iceberg based data lake, and the goal really is to bring the provider's data and into this data lake with these golden copy tables. And these are already the source tables that kind of drive everything else. And, well, this is kinda where our two fits in because it's egress three, because it's s three compliant. It allows us to do that in a way that we can then have that data. And then whenever we need to query that it's, which I'll come to in a second, it will all read from that single source of data. So we have, like, ingestion engine towards the left a little bit, which we use Spark to pull the data from, you know, anyone's source into Bobsled in the middle. And then we also have a tail maintenance service, and this does things like compaction, like rewriting, also handles things like, partitioning, using icebergs, hidden hidden partitioning, etcetera, etcetera. So these are all the bits that kind of make up that golden copy source of data that we keep in the data lake. Now the exciting bit is when you go a little bit more towards the right. So we have the global fulfillments engine. This is where we provide, like basically, the goal is to have a single interface that providers can use to define their fulfillments, to define the data products, any row filtering column because they have but in a single way. So it doesn't matter if you're doing it for Snowflake, for Databricks, or any other destination. You define it once in in kind of this this global single format. You decide who you want to share it to, how you want to share it, and everything else is handled internally. Now how do we handle it internally? This is where the magic happens. So I'll kind of mention the Snowflake bit in a bit more detail because that's kind of, my area of expertise. Snowflake allows you to define external tables, like ice pack tables. And once you've defined them, you define external volume, you define external tables, you can then create standard Snowflake secure views over those tables. And you can share those views in listings, you know, using the the standard Snowflake sharing protocols. What that means is that for consumers of the data, so the customers all the way on the right, when they actually query these views so they get these views shared with them. They can use that in the the native way that they interact with Snowflake. When they query those views, essentially, Snowflake will read the data directly from r two, from a golden source copy of the data. So data is not being copied and replicated into Snowflake. It's living just in one copy in r two. And as queries are made, the data that's necessary for the query is then being pulled out. Obviously, iceberg's metadata is incredibly impressive in how it kind of does that efficiently. But so the minimal amount of data that's needed is then read and pulled out and presented to the consumer of that data. And this all happens again without copying data. So it all happens on this kind of view based read only approach that we've devised. So that's really the core kind of, like, a very high level overview, but really the core of how it works. In copy of data, we have no egress fees on that data, so we're not copying the data, you know, set like, separate times into all of these different destination, all the different regions. It just lives where it is. When it's queried, that's when it's read. And, obviously, it's being cached by, you know, artist's built in caching. And, yeah, zero egress, s three compliant, and that kind of allows us to build this entire solution. So, moving on then, just to focus in, hone in on a little bit I can't move. Cool. Next slide. Fantastic. Yeah. Just to hone in a little bit how it came to Cloudflare R2. So, obviously, when we were looking at how we're going to build this, how we go to architect it, we chose Iceberg as kind of the right format for our data lake, for our data lake. And R2 stood out, as as mentioned, zero egress. That's a massive bonus. It really sidesteps a huge problem that our customers were facing in terms of these egress charges, whether you, like, send data to new destinations, to new regions. And it's s three compliant, which means that we can use a wide variety of tools. Anything that supports s three would pretty much work with R2. We found that to be the case. We've made use of that. We've used different catalog different aspects, to make all of this work. So next slide. Fabulous. But, yeah, once we kind of started using R2, it became apparent that there are other benefits. As we mentioned, I think Cloudflare is working on essentially an Iceberg API, the R2 data catalog. So that's something we're very excited about using. We're talking to them about it and hopefully looking to make use of that so we can have, like, compaction maintenance operations, and also just using, you know, a catalog in the same ecosystem as Cloudflare. We use the same access credentials. It simplifies a lot of things in our architecture. And then, obviously, the global caching, the fact that not only is the data being queried from a single source of truth, you don't need to replicate it, but it's also being cached intelligently. So where it's being queried, which regions it's being queried, they always have performant access to that data. Yes. So I'll hand it back over to Jake. Thank you, Hamza. Yeah. So just to talk a little bit about where we're going as we continue to build, one, for our mission to make data products accessible and interoperable across wherever the the customers work, and then also to continue to build, this kind of interoperable infrastructure that that, you know, Cloudflare provides for us is we're really starting to focus. As we've gotten to very strong coverage across all of the different cloud object stores and all of the different data platforms is really how is data sharing going to shift as we move towards this new platform shift towards AI. Right? And as our we work with many of the world's largest data businesses. I think we've seen that many of them view this AI shift as both a massive risk and opportunity. Right? And I don't think anyone has really gotten to a a strong position on what it means to be an AI native data business, which is, I think, where we're really pushing for. So where some shifts that we're seeing is just an enormous increase in the number of business users that are actually able to interact directly with data. Right? So you're getting to a place where the the idea of an insight being able to answer questions against data is becoming commoditized, which theoretically should incredibly increase the value of the data itself. Right? So as that insight ability becomes really easy, what becomes really challenging is access to unique and more and more valuable data. But one of the challenges we're seeing in actually making that shift become real is the accuracy in prompts to really SQL. Right? Because we're not talking about just hitting a data API. We're talking about really being able to answer complex and arbitrary questions against data. They require constantly evolving context engineering. Right? Because in between a business user and the ability to write a prompt, there's not a data person who can actually deeply understand each all of the data available at the, you know, at the column level and to be able to understand and translate that business context and to iteratively build a query, someone's really just looking for an answer. So as we're seeing our customers in the market start to solve this idea of how do you bring business context and understanding to the actual data that is available, our customers also need to understand from a business perspective, how do they make their data actually usable within these platforms that their customers are are now leveraging at just an unbelievable speed of adoption? And then really importantly is how do they do that in a way that actually entitles and protects the data assets? Right? Because if you think of, again, some of our customers who, you know, have billions of dollars worth of incredibly valuable data, leakage and accidentally exposing these to really the wider Internet and to to annoying models themselves are really an existential risk. So how do you do this in a way that actually respects your data ownership and your and your your governance and, and licensing models? And then really a big part of this is how do you actually shift your business model to go from data as a service to insights as a service? So I think we're really early into this shift, but I wanted to at least just show a little bit around what we are working on, which is really the idea of being able to deploy AI analytics agents as a service in addition to really data shares as a service. So just kind of walking through left to right, this is really taking our existing infrastructure. So today, you plug bobsled in to wherever you store your data, which for pretty much all of our customers is generally multiple different source locations, and you create these interoperable tables that we create in Iceberg over Cloudflare r two and that we have lovingly named Sledhouse tables. From there, you create data products over the top of them, which for us are views built over these tables, and those views can be, you know, created really in any SQL expression. And then from there, you are able to actually apply context and semantics to them. So that's plugging in to wherever you have those things now, but it's also creating the interface in which that context can consistently grow as you interact and have your customers work more directly with that data. These are it's an evolving, really, context engineering that that you can apply against this data to start to build out really what in essence is a knowledge graph over your data products. And then differently from a traditional data share where you're allowing your customers to bring their own compute and query your data, actually, what you're able to provide is a text to SQL agent, and the ability for to create an interface via MCP directly either with the LLMs that your customers are already using or to deploy a wrapper over those LLMs so that the consumers of your data can interact via prompts, you can interact via questions, and that you are able to parse those questions, translate them into accurate SQL, and return answers as opposed to exposing raw data. And I think this is still pretty early days, but we are working with many of our largest customers to launch this feature actually over the coming weeks, and would be very excited to speak with anyone who is also working on the idea of how do you provide insights as a service over data as a purest to pure data as a service, and, you know, how can you do that in a way that leverages the only zero egress network that, again, exists in the world, which, we built, everything on top of Cloudflare two. So with that, I'll turn it back over to you, Phil. Great. Thank thank you, Jake and Hamza, for, for going over Bob's, bobsled, and talking more about your your future plan there and how with what you're already doing today. With that, I mean, you know, there there's there's one thing, there's one thing I'd like to do, which is give a shout out to, Cloudflare Connect, which is our upcoming, customer conference, that'll be in in Vegas from, October. If you're interested in attending, there'll be a lot of, interesting speakers, sessions, things like that. So if you're interested in checking out and getting more information, you can, you know, scan that QR code there to learn more about signing up and, you know, and then and getting involved. And then outside of outside of this, we can go over a few of the questions that folks had, during this, during this conversation. So if you have any, please, use the q and a feature to drop the questions. In the meantime, I could, you know, I I could I could start by answering a couple of them. So we had one question. You know, is is pipelines gonna support, both batch and streaming? That's a great question. So, right now, the focus of pipelines is on the streaming side. So, we we we recently made an acquisition of a company called Arroyo, which is powering a lot of what pipelines does under the scenes, or, you know, behind the scenes from infrastructure perspective. And and what we're focusing on is primarily this, streaming, ingestion, and transformation. So right now, we support, you know, ingesting data, and doing these transformations via HCP API and also our workers API. But soon, we'll be supporting more sources and destinations. So think, you know, we'll be able to soon, read off, you know, your your Kafka topics and and and bring those into pipelines and and and start doing transformations and and then either writing that data or, you know, publishing that data back to your Kafka topics, for example. But more so focused on the streaming side, versus batch at at this time. Another question that I'm seeing in the q and a is, for the Bobsled team. So, what were some of the, you know, significant compounding complexities Bobsled encountered when managing data infrastructure, you know, with managing infrastructure orchestration and data interoperability before using Cloudflare? Jake or Hamza, do you wanna take that? I think you maybe already touched on that a little bit. But Yeah. I'll just hit it really quickly. I mean, in order to actually make data available in directly in platforms, you actually have to manage the accounts and infrastructure in each of them. So Cloudflare helps enormously because it's interoperable and and has integrations with these platforms. But if you wanna make data available within Snowflake or Databricks or on-site desk three or Azure, you actually have to manage accounts in the regions where that data is gonna be consumed. So the ability to scale up then scale down and provision that infrastructure is probably the first problem we had to solve. Data interoperability, no data platform, but there's no universal standard for how data structures are managed. Right? Whether that's data types, whether that's things like clustering and partitioning and optimization, whether that's how updates and metadata are managed, they differ across all platforms. And the idea of standardizing around something like Iceberg eventually would be amazing, but it would absolutely shock me if the, like, the percentage of analytical data today that is used in the world, like, it it's not even 1% that is an iceberg. Right? I mean, like, the idea that that's gonna actually solve all these interpretive problems by itself, I just don't I don't think anyone who works in data really believes. And then sharing and entitlements. I mean, not take a platform like Snowflake, which has been just the absolute leader in sharing and yet the top one I have an enormous amount of respect for. There are their sharing mechanisms themselves continue to evolve, and there are, you know, many of them. And then if you move to platforms that are much more open like AWS, there is, you know, close to an infinite number of ways in which data can be changed. So managing that complexity, observability, I mean, being able to understand what is happening across this gigantic data sharing network that you have from an infrastructure perspective, from a pipeline perspective, from an access perspective is kind of a blooming complexity. So, I mean, I I think, you know, a lot of what Bobsled and really any infrastructure tool is is a complexity management abstraction. What Cloudflare has done is be able to really remove that requirement to work on the backbone of all of these clouds and kind of interact in a in an economic model that didn't really benefit the use case that we're we're solving for. And I think where a lot of the road map is going is getting into that, you know, as we move towards the the iceberg APIs and just the ability to actually abstract even further away the data management, I think, is gonna continue to pay dividends for us. Great. Thank you for answering that, Jake. I think, I think that's all for questions today. A lot of them, that were asked during this, during this, conversation have already been answered. So if you have any, I think with that, we'll wrap up. If you have any further questions or things that come up, you know, sort of later in the day as you're thinking about it, feel free to reach out to myself, anyone on the Cloudflare team, and I'm sure I'm sure Jake and and Hamza would be happy to have anyone reach out with further questions as well. So, with that, I think we're good to wrap up. Thank you so much, for everyone for attending and for the questions. And, thank you to Jake and Hamza from Bobsled for sharing your story. You know, and so with that, I guess, hope everyone has a good day. Thank you.