Data Mess to Data Mesh | Jay Kreps, CEO, Confluent | Kafka Summit Americas 2021 Keynote

Hi everyone. I'm really excited to be here. This is my first time doing a live talk in a couple of years, and I think it's a lot better than just talking to a video recording. So I'm really excited. I'm gonna be talking today about this idea of a data mesh, and this is something that's gotten a lot of traction. This may be something that you're thinking about or reading about. I'm gonna talk about how this relates to the world of Kafka and event streaming and this larger project of connecting a company around data in motion. Before I get into that though, I always like to start with any new trend and try and talk about, you know, what's the underlying thing that drives it? What's the root cause? And I think that there's a big idea that kind of pushes a lot of these things in our world which is that in some sense companies are becoming software. And this is something that sounds a little funny when you say it. You know, what does it mean if a company is becoming software? But what I mean by this is that companies are in some sense becoming software-defined. You know, the core aspects of how companies interact with their customers, how the goods and services are produced, how it all stitches together the activity of the business is just increasingly defined end-to-end in software. And this is actually a pretty significant change. If you kind of think back to how software, you know, came into organizations, it was a bit at a time. You know, an organization was ultimately a group of people that talked to each other to get the job done. And, you know, applications were added here and there, really disconnected from each other. And still the integration was among the people and the applications kind of stood alone. You might have some systems helping the HR team, some systems helping the sales team, systems helping marketing, some custom software of your own creation, but ultimately, you know, a company was about the org chart, the people, and I think this is something that's significantly changed, and it's easy to miss what's changed, but if you look at the architecture of a modern company, there's just a huge amount of software. There are more applications by hundreds or thousands of times. There's more databases and data systems and data warehouses and analytics platforms platforms and SaaS layers. And more than anything, it all needs to connect. It all needs to work together. And the result done poorly is really a big mess. It is this giant spaghetti picture that we've always talked a lot about. And I think that that is more than anything a big change in the world that we're all trying to cope with. And I think it's worth asking the question, what What's driving this? Why all this integration? Why does everything have to connect now? You know, what causes it? And I think the answer is really simple. You know, this is something that customers demand. You know, customers expect to have rich experiences where the bar is really set by the best of breed tech companies, and they expect this now from every company that they interact with. And for a lot of companies, maybe the digital side of the business was a bit of a sidecar that didn't get as much attention. You know, I think during the pandemic, it's highlighted just how important that is to a first-class customer interaction. And it's not really just the front end. It's also, you know, all the internal operations of a company, how goods and services are produced, manufactured, distributed around the world, delivered to customers. All that logistics and operations is increasingly driven end-to-end in software. And, you know, companies are really competing on this dimension. And this is a big change in how we think about software architecture. If we think back some decades ago, software architecture was really about what was inside an application. How many tiers should it have and how should we organize the code? How should we structure things internally? But if we think about what software architecture is increasingly about, obviously the internals of an organization matter, but increasingly it's about how do you build a company in software? How do all these applications come together? How do they communicate? How do they key off of each other? How can we do that in a way that's scalable, you know, both in systems terms but also in organizational terms. And at the heart of this, this problem and this movement is really the rise of a new set of concepts around events and event data and event streams. And this is a key aspect of how companies connect, how you can decouple systems, and a key part of, you know, the emerging architecture for companies. One of the things that's so interesting about events is they kind of have a dual way of being. They're both a notification of something that happened as well as data about what happened. If we think about maybe the stream of sales, maybe in a retailer that are happening all around the world, each of these sales events, it's both a notification that might trigger some action, some restocking, changes in order systems, etc. but it's also data that might flow into some system to be stored, the record of sales that needs to be analyzed or persisted. And so it both acts as something that drives applications as well as something that flows as data. And these two use cases, these two uses of events are actually interrelated and right at the heart of what I'm gonna be talking about. So there's really two movements that are arising, and I think that they have, certain analogy between each other. So microservices, this is something that's been around that's ultimately asking a question of, hey, how can we decouple and structure the communication between our applications? And data mesh, this is something that's really about how can we decouple the movement of data and integrate around that. And both are trends towards decentralization. Both of these are asking the question of how we can structure this in the large in a way that all the parts of the company can kind of move independently. And I think it's interesting to actually see some of the similarities between these two movements. In many ways, it kind of represents a little bit of this duality of events. And so I'll start with microservices. Most people are familiar with this idea. The bane of the classical software engineering world is the big bad monolith, where you have— the jumping ground of all code that's continually metastasizing and adding new modules and bits. And like a lot of monolithic centralized processes, any kind of big application starts to get slow as you add more people who need to actually accomplish new objectives, and they're all trying to do it in one big code base that has to all work together and be qualified together and ship together. It always gets slower. You can do it better and you can do it worse, but it, it simply doesn't scale. And you know, one of the few ways that we've come up with to cope with this is to try and split this up, try and turn it into independent services or applications that can communicate together. And this can actually reach a larger scale. This can connect more than what you could have in the one monolith. And events and event streams are, are really an important aspect of this. There's obviously, synchronous communication between services, but a lot of what happens in a company is fundamentally asynchronous. It's not happening, you know, while your customer waits, it's happening in the background. And this event-driven microservices has been a key aspect of actually being able to do this in the large across a company without the level of coupling. And now if we turn to the data side of events, the data world, there's actually a, a similar monolith. And to look at this, it makes sense to go back a decade or so and look at kind of the classic data integration architecture. And the idea here is we have a few independent applications. They have their own relational database. They don't really need to interoperate or relate to each other. Data flows really in one direction from left to right where we might scrape data data out of these relational databases. We might load it into a monolithic data warehouse perhaps at the end of the day, and there's usually a single team that would be responsible for that load and they would gather all the requirements for the use of data around the company and they would structure the data in a way that's usable. And to some extent, this works, right? Like this is a monolith, but in a simple enough world, it's actually quite functional. You can get the needs that you have at least to serve the kind of reports and analytics that were the concern of this architecture. But if we look at the world today, it's actually quite different, right? I showed this picture there, there isn't just one destination for data. It isn't the case that individual applications stand alone. Increasingly there's vastly more data, vastly more systems and teams and all of it has to integrate. And if you try and approach this with the same organizational approach, the same technological approach, where there's kind of a monolithic data team that gathers all the requirements for everything in the organization and tries to prioritize who gets help with their data needs each quarter, it's gonna be a huge bottleneck. And it is, and this is something a lot of companies suffer with. And you know, it's just a bad experience. In some part of a company, you have a team that is resourced to go do something important, but they need data or they need to integrate with something else. And that creates this dependency on another team and you have to argue about the prioritization and it gets bumped out till next quarter and you can't really make progress and it's frustrating and it's slow. And so this kind of centralized monolithic approach to data, we're really just past the point where that's workable. We have to come up with something which scales better. And actually, like in the microservices world, I think event streams have a really important role to play here in the flow of data across a company. You know, this is not just about triggering applications. This is also about the flow of changes that can come to different data systems and how that flows out to other use cases for data into analytics systems, search systems, caches, all the different consumers of data that may store it and ingest it and index it for their use cases. These two kind of roles of data kind of corresponds to the two kind of dual nature of events that I pointed out, that the events are both being used as data, which flows into storage systems, and it's being used as a kind of trigger, which actually activates some activity from an application. Very often the same event stream is being used for both. The sales are both triggering restocking and they're also being loaded into your data warehouse, for example. And this is a really important component of how you can start to decouple the flow of data, how you can start to decentralize the flow of data. You want to have something where it's much more of a publish-subscribe mechanism. Different parts of the company can publish out what's happening in their area. Consumers can tap into that and read it. This is obviously a key foundational element of how you're gonna be able to scale across a company, We've talked about the idea of really having a kind of central nervous system that allows the different parts of a company to connect and come together. And so obviously event streams are a key part of this, but it really raises the question of how do you actually do this, right? How do you actually make this work in the large? And this is something we spend a lot of time with our customers. I'm always reminded a little bit of this internet meme, which is how to draw an owl. And there's just two simple steps. First, you draw some circles, and then step two is you draw the rest of the effing owl, right? And the joke, of course, is that that second bit hides a few key steps that you have to get right to have a proper owl here. And it's actually similar, I think, in the microservices world, where really getting the principles, practices, and tooling right to do this in the large is critical to success. I think it's equally true in the world of data flow where you have to really get both the principles and the practices right to be able to scale. And this is something that we see when we interact with our customers at Confluent. We find that as companies implement event streaming and Kafka, there's kind of a couple different stages. There's kind of early decentralized interest. At some point maybe there's production systems in different parts of the company, probably disconnected, that are using event streaming teams. And at some point, it really does become part of the architecture. It becomes a connective layer across teams. And to really get to that state where you're getting leverage out of data, where it's connecting across the organization, it's actually not just a matter of technology. You really have to have both technology and people and practices working together in the same way. And I think these kind of good systems are ultimately a function of both. And so in this talk, I'm gonna talk a little bit about both the people and principles aspect of this, how should you think about and organize around data, as well as some of the software tools, including some exciting stuff that we've built at Confluent to try and help support this. And to do this, I'm gonna use the kind of key principles of the idea of a data mesh. And data mesh, this is a concept that was popularized by Jamak Dagani, and we had a whole set of thought leadership around it. And I think it really provides some key principles that you can start to organize your thinking around as you try and scale the use of data. And I think this is really key. Whenever you need to get a large group of people to think and act the same way, it's really helpful if you can boil it down. And so there's 4 key principles: domain ownership, data as a product, self-service data, and federated governance. And I'm gonna divide these up a little bit and kind of talk about, you know, the first two as being about how data is produced. How can we scale the production of data and how can we do that in a way that's effective? And then the second two are kind of about how data is consumed, what makes it possible to easily consume data in this new decentralized world. And so I'll start with the first, how data is produced. And the idea here is really simple and in a way kind of obvious. If we want to scale, we have to decentralize ownership. We can't have a monolithic team that's required to know everything about all of the data everywhere in the organization and every change that's happening as every little bit of software evolves and moves. It's just not scalable. It has to be the case that people who are domain experts in an area who own the, production systems there, who are responsible for the creation of that data, that they're responsible for how that data gets out to the rest of the organization. And it has to be that, that mechanism by which they give data out to the rest of the organization, that that's actually treated as a kind of product or API which gets the same level of product thinking and product management to actually make it good. And make sure it meets the needs that other teams have and make sure that it's simple and easy to use. And if this is done well, then suddenly each area, you know, you don't need to worry so much about the details of what happens in it. You just need to worry about what they provide out, you know, their data deliverables, their data products, their kind of data API. And if we can get this right, we can actually start to, you know, decentralize the production of data The key question that this raises is, what is that interface? What's an API for data? How can we deliver this? And, and this is what ultimately companies have to agree on. The same as if you're gonna have microservices, you have to agree about how do, how do services communicate? How can I call your service? How can you call my service? In this world, it's about how can I deliver data to you in a way that you can depend on, that can evolve, that can change, that meets the requirements that you have in your part of the organization. And you know, kind of the simplest thing that might work is, well, you know, why not just dump out some CSV files at the end of the day and you know, we can put 'em all in S3 or some data lake and people can pick up what they need when they need it. And you know, to some extent this can work, but, but it actually has a, a pretty key problem, which is if we want to support the operational uses for data, the production systems that run the business that face customers, we can't be dumping out data at the end of the day. It just doesn't make any sense. We're gonna have something that's out of date. And it's gonna look wrong to customers. It's gonna cause all kinds of bugs and confusion. We can't really have out-of-date data flowing around the organization. You need something real-time. And that's really what's driven the rise, I think, of Kafka in this role. This idea of, you know, creating, using event streams as a feed to connect things. And this has a set of key advantages, right? First, as I said, it's real-time, right? This can support both operational use cases as well as deliver it to offline systems, to data lakes and data warehouses and analytics platforms that may or may not need to be real-time. You know, secondly, it's scalable. You can actually go from the very large volume operational data, the stuff that is being generated by machines, and you can take all of that, but you can also take the very high value transactional data and have strong guarantees across all of this. And this is really critical to support the variety of different data types that companies have to deal with. And then obviously it's multi-subscriber. Consumers can come and go. You don't need to pay attention to every single consumer. There's not a, you know, a high interlock between the producer and the consumer. This makes it actually truly decoupled. And finally, it's a kind of universal mechanism. You know, Kafka can, you know, be public, can be, take, you know, streams of data that are published that can be loaded into search systems, can be loaded into caches, can be loaded into data warehouses, can trigger applications. It kind of connects to everything. It, you know, it's a universal exchange. Typically if you're exposing a database table, it has certain query capabilities, but it may or may not be the ones that your users need. By providing a kind of change log or stream, you can cover the broad set of different data types. And this works both across, you know, pure events, you know, what happened, the sales that may be occurring at a point in time, the, you know, the things that in a data warehouse would be, in the fact tables, but it also actually works just as well for mutable data, right? You can provide change data capture streams, the streams of what changed in a database, and this can be replicated in real time or offline periodically into caches, into derived data stores, into data lakes, into data warehouses. This actually covers both these types of data. And so if we actually make this our kind of API between teams, then we have a mechanism by which we can kind of give ownership of data in each domain to a particular team. We can start to treat that output as a key product, just like their UI or their APIs would be. Their data streams need to be thought of as being as important, having structured schemas that represent the data. This is a key part of that contract. To the rest of the organization. So that's a little bit about scaling and decentralizing the production of data. But if we do this, we actually raise a couple problems which are around the consumption of data. If there's no longer one team that can do it all, how are we gonna actually truly make this self-service? How are we gonna allow people to act independently if there's a ton of infrastructure difficulties and technical overhead to accomplishing this? We can't really push it out to every team. And if it isn't safe to do this, how, you know, we have to figure out how we govern data, how we discover it. These are the problems that start to arise. So I'll start by talking about self-service data. You know, how can we make this something that, you know, for each of these teams where producing data is just one of the things that they're responsible for, how can we make it easy enough that there's no real burden for them to produce and there's very little burden to support the different consumers? How can we decentralize the infrastructure component in such a way that self-service is really possible. And why would this be better if we did it? Well, you know, first of all, we've solved a couple problems here. You know, we've gotten rid of the kind of monolithic data warehouse that has to solve all the needs. We've actually allowed data modeling to scale out to all these different teams. The team that is responsible for the structure of data is the same team that's responsible for the creation of data. And if they do this well, they can reason about how it's gonna change. They know when it's gonna change. They can think about their consumers and produce the right thing for them. And by doing this, by decentralizing, we can actually move at the pace that the business is investing in different areas. We no longer have this central team that may be misaligned with everyone else. That's a bottleneck for the rest of the organization. We no longer have the long line of people waiting. So that's why we wanna do it. Let's talk now about how to do it. How can we actually make data self-service? Well, I think the key to making infrastructure for data really self-service is cloud. You can always try to do this internally in a company. I ran chunks of a data infrastructure team at LinkedIn, and our job was to provide data capabilities internally. But it's really, really hard to make it truly self-service, to make it kind of no touch, everybody gets what they want. Ultimately, you end up trying to build the completeness of a full cloud product. If you have a real cloud product, it makes it really easy. A lot of the infrastructure can go into the background. To do this, you need to have something that's truly cloud native. And this has been a focus for us at Confluent with Confluent Cloud. How can we actually make something that is a true cloud native product that's actually self-service where you don't have to be in the operational details? How can we do that in a way that teams could start to just use it independently without having to get deeply into the operational aspects of it. And there's a number of things you have to do to get this right. First, you have to actually just make it really easy to create clusters. You need to provide access to the broader ecosystem around Kafka. So we also make KSQL self-service. We provide access to all the different connectors so you can hook up to different systems. Obviously you need that full set of things. So that kind of self-service ability to opt in, create a cluster, work with that cluster, That's key. But it's not just that. You also have to handle the operational side of this. If it turns out that each team in your company that wants to produce data has to build a mini Kafka operations organization, it's just not gonna be feasible. They're not gonna have that expertise. And so we've put really deep investments into tiering out storage so that we can support unbounded storage. You don't have to preallocate some amount of capacity. You're not gonna run out if you end up producing too much data. We support elastic expansion and automatic rebalancing so that load is always well balanced. This takes away a lot of the more complex operational details of Kafka so that teams can just use it and not have to invest heavily in the operational components. And so this, this is another key thing we've done with Confluent Cloud to try and make this just really easy to use. But I'm gonna talk about one, more feature that's really important that we just released. And what makes this so important is it's not enough to just get the operational details right in one location. You know, companies are ultimately these big, complicated, geographically distributed beasts. You know, they have parts that are in the cloud, parts that are in different cloud regions, parts that may be in different clouds or parts that may be on-premise. It can't be the case that everybody who, you know, works and produces data and wants to provide that out to the organization, it can't be the case that they have to get a PhD in cloud networking and failover architectures to be able to actually provide that to all the locations and systems and environments that need it. We have to somehow solve the problem of managing the replication of data geographically across all the different complicated parts of an organization. We have to make it easy to fail over and fail back. And this is something we've worked on for a long time. We've had a series of different tools that help with this. But now at Confluent, we've actually created a really exciting feature called cluster linking that we think that makes this incredibly easy and declarative. And Addison, a product manager at Confluent, is going to run us through a demo of what this is and how it works. It's something we're really excited to show. So Addison.

Thanks, Jay, and hello Kafka Summit. When we were building Confluent Cloud, we knew that we needed to abstract away a lot of the complexity that comes with using Kafka to make sure you could focus on your business. We needed to make it self-service via a UI, a CLI, and a RESTful HTTP interface. We needed to take care of all the upgrades, patches, and data balancing. Make it elastic, make scaling storage a thing of the past with a new storage engine. The provisioning of connectors and the scaling of tasks needed to be point-and-click. We also needed to add stream processing with KSQLDB. When it came time to tackle geo-replication, we knew we couldn't take the same connect-based approach that is used today. We needed to make a more intuitive way to handle cluster-to-cluster geo-replication that doesn't require a PhD in networking. We asked the question, can geo-replication be as easy as creating a topic? Turns out it can. Let me show you with a quick inventory management demo. I have a dedicated cluster running in GCP in US East 1. This will act as our centralized inventory cluster. I have two other clusters, one in Azure in Europe, and another in AWS running on US West 2. We need to share inventory data with the centralized cluster on GCP. Now we could set up a Connect cluster, manage the tasks, and manage the offsets as the data gets replicated from one cluster to another. But that is too complex and not as performant as it could be. Let's see how cluster linking makes this easier by mirroring data from one cluster to another, byte for byte, with no extra moving parts. I'm going to use the Confluent Cloud CLI cluster linking command to create two links between our two warehouse clusters in our centralized cluster in GCP. The first link we'll create is from our US warehouse cluster to the logistics cluster. Now let's run that command again, but from Europe to our centralized logistics cluster. That's it, all linked up. Now I just have to choose what topics I want to mirror from one cluster to another over these links. To mirror over the data from the two clusters, all we have to do is create a special kind of topic called a mirror topic. This topic is a byte-for-byte mirror of the data in our source topic. That means offsets are mirrored perfectly, byte for byte, as I move the data from one cluster to another. And I don't have to worry about creating a second source of truth. All the offsets are the same. Creating a mirrored topic is easy using the Confluent Cloud CLI or REST API. Create it with the confluent-cloud-kafka-mirror-create command. Now that those mirrored topics are created, the data is flowing over the links. Now all we have to do is consume these mirrored topics like we would any other topic. We can see all the data flowing from our warehouse clusters on Azure and AWS to our centralized cluster on GCP. That's it! Cloud-native, offset-preserving, global geo-replication across environments, all in about 60 seconds. Cluster Linking is generally available in Confluent Cloud, so go check it out. Thanks, and back to you, Jay.

So I think that these, you know, self-service features are key to actually decentralizing, to allow teams to produce data without having to worry about all the operational aspects. But now that we've done that, we have a new problem, which is where is my data? Data is all over the place. We have to reason about how you find the right thing, how you ensure that it's high quality. Ultimately, is, how do we federate the governance of data? When there was one monolithic team that did everything and there was one place where everything was in our data warehouse, the world was actually a little simpler, right? How can we get back that simplicity without slowing everybody down, without having kind of the monolithic tool that has to be integrated with every other system in the organization, without having the monolithic team that does all the work? What's the solution to federate governance and scale this out across an organization, this is something that we've thought a lot about at Confluent and something where we have some pretty exciting product announcements to talk about. So these are the problems I need to solve. Where do I find data about a customer? What's the right ID for a payment? What does that ID mean? Who's responsible for this? This data looks out of date. Is it right? How can I actually check that? How can I tell where it comes from? How can I tell how up to date it is? How can I discover all this about what I've got? And how can I do this with this real-time streaming data that's changing all the time? And so we're introducing a new set of features called stream governance. And this takes the best practices for decentralized federated governance and applies it automatically with, uh, Confluent. And this really has 3 components. The first is around stream quality. How do I avoid bad data? How can I enforce schemas? How can I check that? How can I ensure compatibility? What's the contract between Team A and Team B? How can you evolve that contract? This takes a lot of what we've done with our schema registry and helps really enforce it across the full set of tools. You know, next is our, our stream catalog. How can I actually discover data? How can I tag what it means? How can I find the right thing and figure out who owns what? This is a critical question that you have to answer about data. And finally, stream lineage. This is incredibly cool. This is like Google Maps for all your data flow created in real time off of the actual flow of data. There's no extra work you have to do to instrument anything. It's just created as data flows and as those flows change. So it's an always up-to-date version of what got where, when it got there, how much of it there was. It's incredibly powerful. And to talk about these features, David, the product manager for stream governance, is gonna give us a demo of some of this functionality. David.

Thank you, Jay. Hi everyone. My name is David and I'm one of the product managers here at Confluent. Today, I'm super excited to show you what we've been up to when it comes to governing and discovering data in motion. So let's say you wanna build a new streaming application and you're trying to search across hundreds of event streams on Confluent. Or you want to make some changes on a pipeline and need to understand all the downstream dependencies from a particular topic. Or say you have this auditor on your back asking you where on Confluent you store personal identifiable information. Well, these are all great questions, but today you're left with asking around the office, setting endless meetings to chase people, or keeping some of this information documented in medieval things like spreadsheets, and intranet pages. As you might imagine, this is not productive or scalable, and we've seen this firsthand with some of our customers. As you grow your investments in event-driven architectures, you need a platform that can support you with data knowledge sharing, collaboration amongst teams, implementation of governance processes, and full visibility into what's happening at any time. In summary, you need something that can govern and democratize your data in motion, to unlock its expansion. What I'm about to show you and what we are releasing today in Confluent Cloud is the beginning of this journey, a truly self-service data-in-motion platform that has governance embedded by design. We call it stream governance, and we build it because we believe this is very important for your success as you move towards being an event-centric enterprise. So for this demo, we're going to put ourselves in the shoes of Francisco, Francisco is an engineer on the data team of the United States Aviation Monitoring Department, also known as FlyWatch. So you, Francisco, and your team, you have a very important job, taking care of the data that keeps us all safe in the skies. So this is fast and furious, real-time sensitive data that informs the position of every aircraft in the US airspace. And naturally, Kafka is this data backbone. Now, it's a Friday night and you're on call as you normally are every month. It's late and you just had a crazy work week. So you're just chilling, watching a nice movie while cuddling your chihuahua named Strims. Now, as the movie gets into its climax, you get a call. And on the other side is your boss yelling about some aircraft data not showing up for the LaGuardia Airport monitoring. So what do you do? What do you say? Maybe say it's the wrong number and hang up? Or pass the phone to Strims the chihuahua? Well, no need for that. Lucky for you, you have Confluent Cloud, and just in time with the new stream governance capabilities that we are releasing today that can help you get back to your movie in no time. All right, so let's do this. Great, so we are now online and looking at the FlyWatch monitoring control center. On the screen are all the airport applications consuming from their respective topics in Confluent Cloud. As we can see, the LGA, LaGuardia, application screen is blank. So let's quickly jump to Confluent Cloud to investigate more. First thing I'll do is use the new stream lineage tool to visualize and understand how event streams are flowing through Confluent. For the first time, I can follow the lineage of my data and stop by anywhere along the way to get more information. Each node on the graph represents a topic or an application that is producing or consuming from a topic, like a connector, a KSQLDB query, or your own coded application. and the edges represent the data flowing between them. Note that this graph is built automatically from the activity of producers and consumers of data, with no additional work or instrumentation needed from my side. Confluent is connecting the dots for me. So, starting from the left, I can see all the aircrafts publishing their own location to a topic named aircraft. These are Java applications configured with the Kafka client ID as the actual aircraft ID. Then subscribing from this topic, I have a Kafka Streams application that is filtering out any PII data like the pilot name. In fact, this application is using the new tagging feature for schema fields to determine which values should be masked. Next, I have a series of KSQLDB queries routing these events to the respective airport topics. Finally, I can see all the FlyWatch applications I showed on the initial control center screen consuming from these topics. One thing I notice immediately is that the LaGuardia topic is not showing up on my lineage. Something must be off with this KSQLDB query. So let me go ahead and inspect this node. Going to the query clause, I can see we are using a field called True Track to filter events. This seems like a good follow-up for me. Using the new Stream Catalog functionalities, I can now search and discover what True Track is. The catalog takes me to the schema of this field, where I can learn more about this data definition. Schemas are incredibly powerful for governing data in motion. They don't just make explicit the data contracts between producers and consumers, but also power data discoverability since they are a primary source of data information. I found that TrueTrack is tagged as deprecated, and now I have context for why the KSQLDB query is failing. Let me also add the tag do not use to make it super clear for other users to come. Great, so now I can ping the owner of this KSQLDB query to take it from here. This is the end of the story. I used the new self-service governance tools on the platform to successfully help me out this Friday night. I'm super happy, Streams the Chihuahua is barking in happiness, my boss is happy, everyone is happy. All of this is now live in your Confluent Cloud, so please go and check it out. If you want to learn more about stream governance, please join me today at 11:00 AM Pacific time for the session, Navigating Your Data in Motion. Thank you all, and back to you, Jay.

Great. So we're really excited about this functionality. It's probably the most requested set of features from our customers of all time. Ultimately, how you govern data is on everyone's mind. I think there's kind of dual pressures to both unlock the data and make it accessible, as well as actually keep it locked up and keep it safe. And, you know, I really think that with the right governance tools and the right stream processing and streaming infrastructure, you can kind of start to do both at the same time. And I think these 4 principles of data meshes are actually a few key things to get right as you think about how you democratize data, how you start to decentralize it across an organization. And I think ultimately these, these decentralized approaches, they are a little bit of work to get right, but I think that they're necessary to scale as an organization gets bigger. It invariably just gets slower and slower if you have monolithic systems, monolithic processes, technology built around monolithic principles. And, you know, this, this problem of decentralizing and scaling the use of data is ultimately right at the heart of this overall project of helping companies become more software-defined, helping them actually interconnect all the parts to really deliver first-rate services to their customers. And I think this is an incredibly important project and right at the heart of what we're trying to help make possible in the larger Kafka community. So it's something I'm really excited about. And with that, I thank you very much and hope you enjoy the rest of the conference.