 I have a little demo, but based on the timing I'm not showing it. I'll be in the booths in S91 over by the cafe tomorrow in the next couple days if you want to see some of this in the real world. Now two different technologies working together in the open source that help out for a lot of different workloads. One of them is Apache NIFI. It is an open source project that I kind of think of it as a Swiss Army knife. Any time you're trying to implement getting data from any type of place and you don't want to write any code, now if I could start off on one pod, scale it up to thousands, and it's very easy to use to get data, whether it's in a batch, whether it's in a stream, just get it started, get it into your data pipeline so you could do things with it, whether that's logs, events, sensors, stuff out of tables, whatever you may have there. And the next project that we work together with is Apache Pulsar. This one has a lot of different use cases. Often people use it for microservices, it's a great way to communicate between processes, whether they're in different clusters, they're in different clouds, different availability zones, lots of different ways to communicate. They run pretty fast, so yeah, we could do real time apps or we could do batch apps. One of the nice features here is no matter how much data you put into the message queue, we could scale to whatever level you need because we could tear out automatically to whatever kind of storage you have, whether that's S3 or some S3-compatible, ADLS, Hadoop file system, whatever it may be. Our infrastructure at the highest level is a couple of different things. What's nice here is this is a real cloud native distribution of concerns. Pulsar does the compute, that's in its own scalable set of brokers. The bookkeeper is storage and that scales separately from the compute and then we have some metadata that we can put into XED or whatever you have there. We're not tied to any specific implementation, makes it pretty easy to run. Cluster is pretty straightforward, got a number of brokers, the bookkeepers for storage and they scale up independently using anything that's standard on Kubernetes or Yarn or wherever you may be running. Again, like I mentioned, this happens automatically, you don't have to know about it. Once you have it configured, it'll just do it when you set points to say, if data is over a certain age, if data is over a certain size, you'd have it automatically go out there but you could still consume it as if it was in the regular local storage. Makes it very easy for you to just have a message system that goes on forever but you need to start back from the beginning, you could do that. We could also run functions within this architecture. Functions are kind of nice, it's kind of like having your own AWS Lambda that you run yourself in Kubernetes. It's cool with this, we support Java, Go and Python, very simple API, just deploy it and we have all the Kubernetes operators and Helm charts you need to do it. The common use case internally, we use this in the open source Apache to do sources and syncs. So, if you don't want to write code to get data from Postgres or Mongo or any kind of storage, you just point to it, pulls it in. We could also run Kafka Connect Connectors. I didn't really tell you what Pulsar is, I think going pretty fast you're trying to get everything in, but it's messaging and streaming and they're not the same thing. Streaming is like Kafka and Kinesis, you want things in order, you're thinking about CDC, event at a time, very fast things like Flink. We operate that way if you want to. If you decide you want to do work queues or messaging and you send a message, don't care order, don't care who gets it. We have that with full acknowledgement, full scalability. There's companies doing petabytes in memory data warehouses with Pulsar. And we have a native connector that my friends and I worked on to make sure we can connect to NIFI, so NIFI get that data started in the system. You do very simple workflows in NIFI, which is nice, no coding. And then you got your data in Pulsar just to show you how we do it. We have the open source operators and we got a couple of managed ones depending on how you want to run it. One of the really cool features I didn't mention is we could talk other messaging protocols. So if you want to talk Kafka, we'll act as if we're Kafka. You want to do MQTT, you want to do RocketMQ, you want to do Rabbit. We can look like all of those and interrupt any kind of messaging at the same time. So send a Pulsar message, pull it out as if it was Kafka and mix and match as many as you want at the same time. If you don't want to run it yourself, you could run it in our cloud. It will do it for you. We have a free tier you want to start off with. And you could run it as if you just want to run it as if you had Kafka that scales infinitely and you could have a million topics without having to worry about brokers or anything like that. Runs all the Kafka stuff if you need to do that. I've got links to all my stuff here. I don't know how much time I have. I know I'm going pretty quick here, but I don't only have a couple of minutes. So I'll just go on through quickly. I'll give all these slides out so you can get to all the links if you want to see demos, examples, different things we work with. I'm in booth S91 next couple of days. I'll show you some different demos, microservices, Spark, Flink. We interrupt with a lot of different things and it's part of the Apache projects. We work well with pretty much all of them, whether it's Kafka, Spark, what have you. Just show you some kind of command line because people like to see that. And a link to our thing, how we can auto scale up our Pulsar functions, which is our microservices. In Kubernetes, just using some custom metrics and it's pretty straightforward. We open up all the APIs. Everything is either command line interface and the REST API. Everything's documented. We don't hide anything. Everything's open source. So you could just take it, start running it yourself. I'm the open source developer advocate. So go out there and use it. It's pretty awesome, pretty easy to do. I think we have a little time for questions, a little time. Anyone has any questions or wants clarifications, wants some details on anything, wants better pictures. I don't know. Want to see Batman and Robin more? I don't know. Yes. The most, like the biggest use case I'm trying to solve here, like with the functions, is each function going to run for hours or seconds or minutes? What is the scale? That is a great question. The functions are event at a time. So what happens is you subscribe to a topic or multiple topics. And when a message or event comes in, you execute and run. And then you're completed. So it's really designed to do something. It could be routing, transformation, machine learning. We've got someone implemented a SQL engine in there. It's really something happens, do something. And what's nice is it's triggered by something going into a pulsar topic, which, like I said, you could have millions of topics broken down with multi-tenancy for tenants and namespaces. A nice feature with that is you got support for three languages. They run, execute, go away. There's managed version of instances so they kept fresh. It's a very simple API. You implement a function and it gives you all the context and features you need. If you needed a longer running one, I'd probably say run Spark or run Flink or run Google Function or something else. You could. I don't really want someone sitting in there for hours in one of these. It doesn't really make sense. Something like one of those other infrastructures would make more sense. This is really, an event comes in. You know, maybe I want to do real-time NLP on it on one piece of data, one event, one log. That sort of thing. We tend to have people, if you want to do joins, do it with Flink SQL. If you want to do ETL, Spark. We don't want to do everything in the world. We do enough with messaging and streaming. But we needed these functions, so we opened it up for all the infrastructure to use it. We might not have more questions. Maybe a long talk is worse because then people fall asleep. No one's asleep. Too hot to fall asleep. Yes. Thanks. You mentioned something about petabyte of data in memory. Can you speak a bit more about that? And how quickly can you process that? Yeah, we have, there's a couple of different cloud companies in China that have created in-memory data warehouses with Flink and Pulsar together. And those are in the 100 petabyte range. And it's fast enough that it's used for, if you know, Singles Day in China. It's part of that infrastructure. So real-time transactions, pretty powerful. I don't know if I'd use it for scientific computing, but, you know, Flink can do a lot in memory. We could run as much as you need in memory. And, you know, what's nice, too, is once it's in Pulsar, you can have it go away if you want. Once a message is acknowledged, it can go away. Or we could keep it forever. Since you can have, you know, especially with the tiered storage, maybe I'll keep 50 terabytes in recent local bookkeeper storage and then do the rest, the other 500 petabytes in S3 storage. You know, and then I can look back and I can rerun everything that's ever happened for topics in order. I don't have to do any special code for that. I could just point to earliest offset and just do that. And I could do that with the native client drivers which support, like, the top 16 languages out there. Or I could do that with Spark or Flink. We're first-class ones for both of those projects. Pretty straightforward to do. This is a typical app that I do. I have some app doing something. It gets data into Pulsar. Have a function do something like, for mine, it's breaking data up. I get data, I pull out of a couple of different rest sources, clean it up based on where it should go, reformat it, put it into a couple of different topics. And then as those events pop up, a Spark ETL is grabbing a batch of them, dropping them into a table. And then I've got Flink SQL running continuously. So as events come in, it's updating its SQL. Results of that SQL can go into another topic. They can go into, you know, a file system. They can go into something like HBase or Kudu or any of the data stores that Flink supports. So it's a nice way that, this is a toy application I wrote. I know there's a lot of different areas, but each section is very simple. The client libraries are pretty straightforward, so you're doing Java, Python, Go, Rust, Kotlin, Scala. Most of the major languages are supported by the clients. We've got a lot of different people using Pulsar. We might be at the end. One more question. I guess there's no one from Kafka in here. The Kafka people always like to throw me a tough one. Very cool to see no Kafka people. Thank you, Tim.