Screaming in the Cloud - Flow Architectures & the Future of Streaming Data with James Urquhart

Episode Date: February 16, 2021

About JamesJames Urquhart is a Strategic Executive Advisor for VMware Tanzu customers. Mr. Urquhart brings almost 30 years of experience in distributed applications development, deployment, and operations, focusing on software as a complex adaptive system, cloud native applications and platforms, and automation. Prior to joining VMware, via Pivotal, Mr. Urquhart ran product and engineering teams for AWS, SOASTA, and Dell (via Enstratius). Mr. Urquhart has also written and spoken extensively about cloud computing, software agility and the business opportunities they afford.Mr. Urquhart was named one of the ten most influential people in cloud computing by both the MIT Technology Review and the Huffington Post, and is a former contributing author to GigaOm and CNET. He recently completed a book on event-driven integration for O'Reilly Publishing titled "Flow Architectures: The Future of Event-Driven Integration".Mr. Urquhart graduated from Macalester College with a Bachelor of Arts in Mathematics and Physics.Links:VMWare: https://www.vmware.com/Book: Flow Architectures: The Future of Streaming and Event-Driven integration: https://www.amazon.com/Flow-Architectures-Streaming-Event-Driven-Integration/dp/1492075892Twitter: https://twitter.com/jamesurquhart

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. they needed, so they built one. Sounds easy enough. No one's ever tried that before, except they're good at it. Their platform allows teams to create consistency for the entire incident response lifecycle so that your team can focus on fighting fires faster, from alert handoff to retrospectives and everything in between. Things like, you know, tracking, communicating, reporting,

all the stuff no one cares about. FireHydrant will automate processes for you so you can focus on resolution. Visit firehydrant.io to get your team started today and tell them I sent you because I love watching people wince in pain. This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy?

What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit LaunchDarkly.com and tell them Corey sent you and watch for the wince. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by James Urquhart, who is currently a strategic executive advisor at VMware Tanzu. James, welcome to the show. Thanks, Corey. I've been looking forward to this for a really long time. So there's a few things I want to talk to the show. Thanks, Corey. I've been looking forward to this for a really long time.

There's a few things I want to talk to you about, but first I'm going to indulge myself and have a little bit of a diversion. I was at VMworld, I want to say 2019, but don't quote me on that, where there was a keynote that I was live tweeting and they talked about VMware Tanzu in the context of a made-up company called Tanzu Tees, a t-shirt company. Now, I'm a jerk on Twitter, in case you didn't realize that. And I immediately went after making fun of the overwrought insanity of building a company to do t-shirts on all of these different technology stacks. And as a result of that, I sort of lost the plot of what Tanzu actually is. So, as a personal favor, can you set me straight on that, please?

Yeah, happy to do so. It is, in fact, not a t-shirt vertical offering. And you don't even sell the shirts is the worst part. No, not even the decals that you iron on like we used to do back in the 70s. No, none of that stuff. Tanzu is a brand, but it's a brand that is focused on essentially how people run modern applications anywhere, pretty much, in public cloud and in their data center portfolio. A number of technologies that are required in that way. I think probably the demo you saw back then, if they had a do-over, they would do sort of the way we talk about things now. So there's sort of three main buckets to it. There's build, run, and manage.

And so the build components are things like Tanzu Application Service, which is the old Pivotal Application Service, Tanzu Build Service, which is cloud-native build packs, and then a number of technologies related to everything from CICD kind of capabilities, the Harbor Repository, all that kind of stuff that's about how do you build and then deploy software in a way that it can then be automated by operations downstream. And then the operations downstream piece is the run piece. And that'll be things like our Kubernetes offerings, Tanzu Kubernetes Grid, the Tanzu Mission Control, which is a multi-cloud, multi-cluster management and operations environment for Kubernetes. And then Service Mesh, Tansu Service Mesh, and other products that allow you then to basically get the capacity and the connectivity that you need simply and easily from both your existing on-premises VMware estate,

and we actually have TKG embedded in vSphere, and also from your public clouds as well. And then the final piece with the managed piece is, you know, probably the highlight in that bucket is Tanzu Observability by Wavefront, the old Wavefront application monitoring and observability environment. Wavefront's amazing. It's probably one of my biggest surprises when I joined the company and got to see the demos the first time. It's a really solid product to be able to see full stack. If you're a SRE, if you're in security, a number of different ways that you want to be able to kind of see how all the components are working together to deliver the service that you need to deliver

and to be able to debug those things. So that's kind of the heart and soul of what it is. It's sort of that kind of level of environment sitting on top of things like VMware Cloud Foundation and vSphere and things like that. Which does a lot to explain the challenge that I had, because I'm trying to imagine, wow, this product sounds kind of like it's trying to do all things at once. What the hell kind of multifunction printer is this? Understanding that it's a brand takes me one step further. And oh, it's a label over a whole bunch of different things that suddenly the wool falls away from my eyes. Thank you. That is helpful. Well, I appreciate that.

So I didn't bring you here to talk about VMware, surprisingly. Instead, I wanted to talk about a few other things. First and most notably, you have a new book out from O'Reilly called Flow Architectures with a subtitle that involves a whole bunch of words that I'll mess up, so I'll let you state it. Yeah, the title is Flow Architectures, the Future of Streaming and Event-Driven Integration. What all that boils down to is it's a book that makes a prediction. It's a book that makes a prediction that we are moving over a period of maybe five to ten years, but we're moving towards a world in which connecting to a stream of events

will be done through very standard interfaces, much like we connect information with HTTP today in very, very standard ways. And then that movement towards that standardization and the arrival of those standard interfaces and protocols that enable that are going to reduce the cost of integration of real-time data to such an extent that cross-organizational integration will be

significantly easier and cheaper to do. And that will lead to an explosion of new applications that are able to respond in near real-time, close to real-time to things you do in your everyday life, right? Or to weather changes or to a number of other things. So you can imagine having a trucking company that might connect to the National Weather Service to get weather data and might connect to a broker for loads for partial truck loads or whatever it might be, might connect to traffic systems, but be able to do that without having to custom write an API call for several different APIs to do that. Just a simple... So this is more of an integration approach to architecture?

I'm trying to distill this down to something, I guess, more fundamental, where it's like, is there a simple, I guess, skeleton case you can wind up giving as an example of this? I mean, sure, it can be ridiculous. Obviously, it goes far beyond this, but give me the t-shirt company style example. Yeah. Well, I think the big thing that you look for is where are the places today where either it would make sense for two organizations to share data about what's happening, but they don't because the use case doesn't quite generate the value to justify the work to get there. So this might be, for instance, Walmart has a phenomenal real-time inventory program with their suppliers, but a lot of other

online shops don't because to do the work to make that really easy to do is a fair investment. The other areas is that you can imagine that there are a lot of combinations of data that if it was cheap enough to experiment, you might find a really powerful way of correlating pieces of data that weren't easy to do before. So there's efforts underway in the scientific community to look at having sort of sensors all over the place and that those sensors collect everything from weather information and temperature and the movement of currents and the vibrations that are being detected in the ground and so on. And that you might be able to find really interesting ways of doing things like everything

from earthquake prediction to understanding where economies might be the strongest at any given time. Being able to get really easy and cheap access to data that can help you do these amazing things, and also the ability then to not have to write a ton of code to take advantage of that, to be able to just say, hey, I want my library or my application to just point this URI to this stream, and I'm now connected, and I'm now receiving data that quickly. Gotcha. So on some level, I've had customers who have talked to me

about replacing a data lake model with a stream processing model. Is that directionally aligned with the idea of flow architectures, or is that a dramatic misunderstanding slash oversimplification? Because you say flow, I hear stream, and I think, ah, those two words mean the same thing in the laypeople language. So I tend to take shortcuts and be extremely lazy, and people call me a thought leader for it.

Yeah, well, you know, there you go. And that's probably, to a certain extent, how I started the research on this as well, is just kind of going, aha, well, this is all like data moving through our economies, a lot like water running downhill through a sand dune, right? It picks its paths, but as it reinforces certain paths and as it determines there's the equivalent of values, it determines that there's a way downhill towards sea level. Then it takes that and it reinforces

that further. So yes, you're right, Corey. It's very much about as you move towards stream processing, the question becomes, what if I need streams from external organizations? or personal relationship with the other party. I just want to be able to go on the internet and say, oh, here's a stream and I want to connect to it. What would it take to get to a world where that is just everyday and commonplace? A lot is the short answer. It's pretty clear that requires a basic, a complete re-imagining of how systems interact with one another. Absolutely.

And I go through where the current technology state is, and I also talk a little bit about how it might move in the future. That gets very speculative, and I'm very clear about that. But with the worldly mapping and promise theory that I do as a part of this, they are modeling techniques that let me be a little bit more clear about where the likely kind of large grain movements are going to be. And I use that then to sort of make arguments about what are the kind of the key areas that we're going to have to solve in order to get to that state. And to your point, you know, a lot of the integration technologies you hear about today are really sort of advanced versions of enterprise service buses and those kinds of, you know, old core Q ways of doing things.

And those are useful, except they're very focused on sort of having adapters to all the different things and then having adapters in the middle to translate data from one format to another. Flow gets to the point where we've agreed upon the protocols

and the interfaces to allow us to already understand how metadata is going to be communicated no matter where it's coming from, where it's going to, and to already understand what are the interfaces to subscribe to a stream, to signal, hey, I'm getting overwhelmed, hold off for a second for me, or whatever it might be. And that eliminates a lot of having to custom code for all the different players' pieces.

There's more to it than that. But the fundamental change I see is moving from a highly contextual environment where you have to predefine all these things and you have predefined places you can plug things into to a composable environment, much more like the Linux command line and the pipe command in Linux command lines, where you can just string a bunch of commands together and the data passes between those. In this case, it would be services and you string a bunch of services together and the data just passes between. In this case, it would be services and you string a bunch of services together and the data just passes between services without a lot of additional work on your part

to make it work. It sounds like it's one of those things where it's easy to wind up waxing poetic or snarky, depending on how it works. Sometimes I rhyme and make snarky poetry in a tweet, but it sounds like this is a deep field that as soon as you scratch beneath the surface, it becomes geometrically more complex. Help me envision the book since I don't have a copy of it yet. I accidentally knock it off a table. How dangerous is it to a dog if

it hits the dog, if the dog is small, medium, or large? No, no, no. It's a book, but it's not a thick book. It's definitely, you know, an animal cover or a Riley book, but it's towards the thin side of one of those. Not as thin as the, I love logging book, but not as thick as most of the programming manuals you're going to come across. It's six chapters and six chapters that are all within a reasonable number of 25 to 40 pages or something along those lines. I hope I wrote it as something that's a pretty easy read, that it steps you through from base principles and core principles through the modeling techniques, and then what fits into the models, and then how you use the model to kind of predict the future and what you can do today. And do that in a way that I take you from point to point to point where I don't lose you by sort of jumping to a new term or a new technology or a new something without having given some context first. A skill I would definitely benefit from with most of my tweeting and almost psychotic

shifting gears without a clutch. It's always fun trying to see how you take something that would fit in either a tweet or a tweet thread or a blog post, but then taking that idea of flow, if you'll pardon me overloading the term, and turning that into a narrative that makes sense with a start, middle, and an end for something as long form as a book. I'm always in awe of people who have basically a tension span to wind up writing books. I do not have that skill. That's a great term for it, too, because it took a little over a year to really write this. And there are parts of this, there's a whole big, large appendix that's sort of an inventory of the technologies that I came across that helped inform all of this and some explanations about their import. And, man, it is an attention span thing. It is definitely something where you're constantly going back and rereading

the previous section to make sure you're flowing into the current section. So yeah, the writing of it was a labor of love. And I'm really glad I got it out there because it certainly has been a topic that I think it's underappreciated for the impact it's going to have on the way we economically connect with each other, you know, maybe 10, 15, 20 years in the future. Is this your first book? It is my first book. Oh, so every time I wind up talking to someone who has been down this path and I suggest, hey, should I write a book? They get this haunted thousand yard stare in their eyes before they begin screaming, no! My working theory is that no one actually wants to write a book. They want to have written the book. Well, at the risk of maybe offending some of your

listeners, it was explained to me in a really good way, which is like, look, have you ever been curious what it's like to give birth? Yeah, it feels like that's the equivalent. It's one of those, oh, kids are great. You should have kids. You know who says that? That's right, parents, because we want non-parents to be just as miserable as we are from time to time. Yeah, no, and it's a hard, laborious process to go through. But if you're like me, and I always say my motto for the last 15, 20 years has been, I write to learn. I write to learn things. And it absolutely did that. So to go through the process and come out the other side with something I'm holding in my hands, the satisfaction from that is immense.

And just the feedback I will get, whether it's positive or negative, the feedback I get from this point on will only help inform and enrich my understanding of the technology world we live in today. And I'm grateful for that. I'm grateful for every reader that provides any form of feedback, regardless of what it is. Yeah, it's one of those massive undertakings that someday I'd like to do it. I just, again, I lie. I just contradicted myself.

Someday I would like to have written a book. And at some point it's like, can you just give me a shot in the arm? And it's a year later and I've written it. And wow, it's great. And how come I'm malnourished and I have these scars all over myself and that and we'll know why. Okay. Let me real quick. I just want to say, man, I blogged for a long time, right? And with the beginning of the cloud era,

I wrote a blog called the wisdom of clouds that was considered one of sort of a very influenced set of blogs that were out there. And for all that writing and all that attention that I got and all of the key points I made that entrepreneurs later told me, like, that was the key that got me on the right track with my product. And OK, that's great, except it does not have the retention. It's not something you can point to as easily out there and say, look at this body of work I did. At this point in time, it's been probably approaching eight years, nine years since I last wrote that blog. And people who knew it well know that I wrote it, but people who don't know me very well, I say I wrote The Wisdom of

Clouds and they're like, what? Okay. I have no idea what that is. Right. And so a book is a little bit more something that you can go back and say, well, it may be out of date now. It might be something you're using to prop up a monitor somewhere, but I wrote it, and it's there. I remember this. I'm going to go ahead and admit to my own secret shame, because I remember citing parts of what you wrote many years ago. So I have an almost perfect track record of being completely wrong on foundational shifts. I thought virtualization early on was going to be a niche thing, sure, for edge stuff, but most workloads are not going to

wind up working there. Yeah, we can safely say I was wrong. Cloud, I was very against it early on, in part because my identity at the time was around running systems manually in data centers, and it was hard for me to accept that they might have to change that. But there were arguments against it. And some of the economic stuff that you wound up talking about in the early example was a great way that this was demonstrated. And then I was down in containers for a while. I made fun of Kubernetes a fair bit

because it's easy to do. And then I figured just for fun right now, I'm taking the opposite approach of I'm going to be a big fan and champion of the idea of serverless computing, which based upon my track record, all but guarantees it'll be a flop. Yeah, I got to say, I mean, I have a great history of making these predictions about, well, it's really obvious to me that this is going to work or this isn't. I think the one I

always laugh at as I go back, I have this blog post before I even ended up at CNET on the very earliest version of the blog, where I was absolutely convinced since AWS already had SimpleDB, it was already out there, they had no need for DynamoDB, and it was going to be just this tiny thing that really wasn't going to make a difference. Now, of course, I didn't know anything about the relative architectures of the two. And so that was purely crazy. There are a number of other things about how big and competitive the other two clouds were going to be. I mean, I think we all correctly predicted that Microsoft and Google were going to be the other players in the space. But I don't think we realized how hard it was going to be for them to catch up to AWS in any way, shape, or form. And I think the serverless thing has legs, if that helps, Corey, because it fits into the flow model really well as well. Serverless is generally about consuming events and creating events and building applications by linking these tiny things together with events.

And so I do believe it has legs. I would love to see AWS more involved in some of the standardization efforts. They were involved for a while with the cloud event stuff. I'm sure there are still people that are involved with it in some way. I would love to see the other cloud providers also being aware of the fact that while a nice, profitable system may be running in their environment, there may be people in other environments that need to consume events from that system and facilitating that rather than making it hard to do. It's data egress. So maybe they can even make money off of it,

right? They're so good at that. But that's my thoughts on it. I think serverless is, to me, functions as a service is the lowest granularity you can get to. It's the least interesting part of all of it, too. It's the event model that is truly transformational. And it only really, I guess It's the event model that is truly transformational. And it only really, I guess, now occurs to me that this feels like it is directly in line with a, you guessed it, flow architecture. Yeah, it absolutely is. And it's also when you think about what developers deliver. We used to make them build servers, right?

And they didn't care about servers. So now we got down to the point with containers that we make them build processes and package those processes. That's way closer to what they actually did. They build an executable, they put that in a container, that makes a ton of sense. But when you really look at the unit of work for a developer on a day-by-day basis,

it's likely measured in functions, not executables. If you can successfully break the environment down so that a developer can work in that unit of work and deliver every time they modify a function or a group of functions and solve a problem, they can deploy that really quickly. And the system is instantly updated with its new powers and capabilities. That's awesome. There are challenges here. And that's one of the reasons why I think the major cloud providers in this space are going to end up looking a lot like operating system or compiler companies. They're going to have to figure out ways to have their infrastructure optimize the placement of functions and optimize the technologies that connect and store data and everything else so that they work really efficiently and fast and don't have network latency in every single case. But I believe that it will only get better over time. It'll only be more reasonable for you to say, hey, look,

you know, we don't need to build a full big package service and a single executable and deploy that executable in this case. What we really need to do is just deploy a set of functions that are then optimally working with each other within the cloud because the cloud provider makes it so. And all of that is, again, consuming events and sending events, calling APIs. By the way, APIs don't go away. You absolutely need the call response piece as well, where it makes sense to do so. And so it all kind of fits together to me really nicely. And it is a simpler, lower toil way for developers to work. This episode is sponsored in part by our friends at New Relic. If you're like most environments, you probably have an incredibly complicated architecture,

which means that monitoring it is going to take a dozen different tools, and then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They've designed everything you need in one platform with pricing that's simple and straightforward. And that means no more counting hosts. You also can get one user

and 100 gigabytes per month totally free. To learn more, visit newrelic.com. Observability made simple. It's extremely gracious of you to agree to talk with me on this show. Now, let's see if I can make you regret it. Yeah, right. You did a lot of predictions on this. How would you say that cloud computing evolved differently

than you expected it would a decade ago? Yeah, a myriad of answers to that. I think when you looked at where we were seeing the first work with EC2 and then even, you know, the turn of the last decade was just, you know, an emergence of other patterns besides just compute and the ability to get services that did more higher level things for you, things like step functions and other things coming out at that time. I think we were thinking it was going to remain very sort of infrastructure and maybe data. So the things that were infrastructure components for an application where you might buy it from a vendor, it's now a utility. But I think what's happened is, in fact, the most surprising to me is that the cloud is able to invent new forms of working much more easily and much more cost

effectively than a lot of on-premises or licensed vendors can do. And so I think you're seeing a big explosion in the variety of things that can happen and a slow move towards maybe a little bit more, not so much vertical market focus, but a little bit more kind of niche need focus set of services that are out there. And I don't think we thought the niche need services would come from the major cloud providers back then. The other thing is the growth was unbelievable, right? The growth is consistently been so damn big that you get a sense that they created a Jevons paradox situation where they made computing so accessible and so cost effective for inventing that it didn't mean we spent less

money on inventing. It meant there were just a massive amount more invention going on out there. And that, to me, signals really, really well for the opportunities that remain in the future, the opportunities that will continue to future, the opportunities that will continue to be created, and that this is really sort of a model that there may be business models that change around cloud, but this model of running compute as a utility is here to stay. I think the entire idea of not having to focus on the baseline stuff just to get a rack up and running in order to start experimenting is huge. 10,

15 years ago, I keep reading time is advancing. I really should have framed this as 15 instead of 10 years. But originally it was, well, you better have a very specific niche use case to put something in the cloud. Now it's,

you probably should have a very specific niche use case to justify not putting something in the cloud. I'm not saying those, those use cases don't exist, but it's... Yeah, yeah. I always tell people there is a financial argument to say that if you have giant scale, then maybe you need to build your own cloud data center, right? But the scale that we're talking about is approaching Facebook.

It's not even target retail scale. Yeah, if Google were an AWS customer, I would have some thoughts that maybe they might want to at least run a cost-benefit analysis on running their own gear. So yeah, there are an awful lot of shops out there, but it is not the $100 million a year range, I promise. Yeah. You know, I do believe, though, that that's going to shift and change. It's never going to be, okay, on-prem is dead. For certain companies, that very well may be true. But I do believe that there are... Oh, that's not true at all.

I mean, I've worked at a lot of places where I push the wrong button or trip over the wrong cable, and yep, on-prem is now dead. Well, I've had a couple of situations where I hit the wrong button in the AWS console and the cloud's dead, too. But, yeah, it's an interesting world. It is a shifting world. It is a world where we have the public cloud is fulfilling its promise in a huge way. And the biggest thing that I look for is, you know, when does the international competition start picking up, right? When do the Alibabas and the companies that may come out of even Russia or Europe, when do those companies start finding market needs and market niches in the U.S. where they actually begin to get a footprint?

Because I do believe that the big three, as we know them today, they're not safe if you look at a 20-year time frame. I think there's a lot of opportunity for disruption, but it has to be another major large player that knows how to run many, many large data centers in order to do that. Oh, yeah. The fact that that used to be a skill set that every company needed to have and now does not, that's transformative. I mean, I know that there's a lot of talk about the big companies out there, but I like to focus the other end of the spectrum. The random, ridiculous small business idea today that maybe just maybe not saying this is guaranteed or

even likely but will one day become a component of a large index and they're publicly traded in the rest the barriers to entry are lower and lower because you don't need to raise a bunch of money just to get a computer to run this stuff on it's now free trials or credit cards i can spend six hours in an evening putting together the bones of an idea before discovering that it's invariably a terrible idea. Turn the whole thing off, and my bill is, what, $7 for that? Plus the 22 cents in perpetuity for some weird resource in an AWS thing that I will be paying until I die. Yeah. Yeah, well, that's a number of us that wrote in early on that really the the thing that cloud change was it used to say the cost of experimenting and and then experimenting again went way, way, way down.

And that is ultimately what you want to see as somebody who wants to create a new technology on somebody else's technology. You want to see that your cost of taking a shot at something and it not working out is significantly low. So, you know, I see a myriad of businesses out there that are super cool and even disrupting businesses that were already built on AWS to disrupt their previous market. You're seeing the second generation come along already. And that's because people can keep trying and keep trying until they find a product market fit that gives them a chance. Yeah, there's value to that and validity to it. And it really drives home the unit economics

of doing this at tremendous scale. And not only that, if there's an outage, because surprise, they're computers, they break. When you have a large scale cloud provider, I care not which one, there is a team of some of the best people in the world at that particular subject rushing to fix it. You won't have that to some extent. There's that aspect. There's the business headline story as well, where it's not your site is down today. It's your cloud provider took an outage, and here's a giant list of businesses that are impacted. And if you're lucky, you might make that list.

Yeah. Well, on the operations side of things and the personnel there, I worked at AWS for 18 months. I can tell you, I sat in on those operations calls. There is no enterprise that I am aware of anywhere that runs anything like what the professionalism and the science that they apply to operating their environment. And the incentives they have for people to be on their game are phenomenal. And so, and I know all the cloud providers have their version of that.

That's the one thing that I absolutely agree with is that you're never going to have a organization that's as focused at optimizing exactly what they need to do to have a phenomenally high quality product at a reasonable price with the flexibility they need, you'll never have that in your own environment because there's just too many variables and that you need too many people that are focused on that day by day by day to

really hit a home run with it. Yeah, it's one of those areas where subject expertise really matters and counts for a lot. I want to thank you for taking the time to speak with me today. If people want to learn more about what you're up to, and of course, buy a copy of your book, where can they find you? Yeah, so I'm by far most active on Twitter, where it's just my first and last name. So J-A-M-E-S-U-R-Q-U-H-A-R-T. The book is available on Amazon. Again, it's Flow Architectures, The Future of Streaming,

and Event-Driven Integration. It's available both in Kindle and paperback form. I'm told that it's on Amazon Books already and on a number of other e-book sites, so check your environment. And welcome honest reviews and honest feedback from anybody who reads the book, and I would look forward to that. And certainly reach out to me, anybody who'd like to follow up and have any deeper conversation, either on the event driven stuff or anything else we talked about today. Excellent. We will, of course, throw links to that into the show notes. Thank you so much for taking the time. I really appreciate it. Thank you so much, Corey. Have a good day. James Urquhart, Strategic Executive Advisor at VMware Tanzu. I'm cloud economist Corey Quinn, and this is

Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me that why data lakes are the future and that streaming is a red herring. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold. This has been a humble pod production stay humble