Flow Architectures & the Future of Streaming Data with James Urquhart

James 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.

Announcer: 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.

Corey: 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.

James: Well, thanks, Corey. I’ve been looking forward to this for a really long time. So.

Corey: So 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 tee-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 tee-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?

James: Yeah, happy to do so. It is, in fact, not a tee-shirt vertical offering.

Corey: And you don't even sell the shirts is the worst part.

James: 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 CI/CD kind of capabilities, the Harbor Repository, you know, 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, Tanzu 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—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—the probably the highlight in that bucket is Tanzu Observability by Wavefront, the old Wavefront application monitoring, and observability environment. Wavefront’s amazing, 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 an 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 this thing. So that's kind of the heart and soul of what it is, is sort of that kind of level of environment, sitting on top of things like VMware Cloud Foundation, and vSphere, and things like that.

Corey: 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.

James: Well, I appreciate that.

Corey: 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.

James: 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 the things you do in your everyday life. 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 truckloads or whatever it might be, it might connect to traffic systems, but be able to do that without having to custom write an API call for several different API's to do that. Just a simple—

Corey: 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 goes far beyond this, but give me the tee-shirt company style example.

James: 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 area 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 movements 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 URL right to the stream and I'm now connected, and I'm now receiving data that quickly. 

Corey: Gotcha. So it's 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—

James: No, no, no, it’s—

Corey: —oversimplification? Because you say ‘flow’ I hear ‘stream’ and I think, “Ah, those two words mean the same thing in laypeople language.” So, I tend to take shortcuts and be extremely lazy, and people call me a thought leader for it.

James: Yeah. Well, there you go. And that's probably to a certain extent, how I started the research on this as well as just kind of going, “Aha, well, this is all”—like, data moving through our economy is 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 the equivalent of values that 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? What if I actually want to find streams where I don't even want a deep contractual 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?

Corey: “A lot,” is the short answer. It's pretty clear, that requires a basic—a complete reimagining of how systems interact with one another.

James: Absolutely. And I go through where the current technology status—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 a Wardley 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 brain movements are going to be. And I use that then to, sort of, make arguments about what are kind of the key areas that we're going to have to solve in order to get to that state? And to your point a lot of the integration technologies you hear about today are really sort of advanced versions of enterprise service buses, and those kinds of old core queue, 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 sort of that having to custom code for all the different players’ pieces. And 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 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.

Corey: 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 the table: how dangerous is it to a dog if it hits the dog? If the dog is small, medium or large? 

James: No, no. It's a book, but it's not a thick book. It's definitely an animal cover O'Reilly 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 sort of a reasonable number of, sort 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 for a first.

Corey: 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 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 the, basically, attention span to wind up writing books. I do not have that skill.

James: [laugh]. Dude, 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 in 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 suction. 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 under-appreciated for the impact it's going to have on the way we economically connect with each other maybe 10, 15, 20 years in the future. 

Corey: Is this your first book? 

James: It is my first book.

Corey: 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.

James: But at the risk of maybe offending some of your listeners, it was explained to me in a really good way, which was like, “Look, have you ever been curious what it's like to give birth?” [laugh].

Corey: 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.

James: 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, it 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.

Corey: 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. After some point, it's like, just give me a shot in the arm. It's a year later, and I've written it and, “Wow, that's great. And how come I'm malnourished and I have these scars all over myself?” And that—and we'll know why.

James: Well, Corey, let me real quick, I just want to say, man, I blogged for a long time. And at 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 okay, 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.” 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, might be something you’re using to prop up a monitor somewhere, but I wrote it and it's there.”

Corey: I remember this. But I'm going to go ahead and admit to my own sacred shame because I remember citing parts of what you wrote many years ago. So, I have a 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 it 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 will be a flop.

James: [laugh]. Yeah, I got to say, I mean, I have a great history and 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 this 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—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—

Corey: The least interesting part of all of it, too. 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.

James: 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 do, 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. 

And so 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 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. Or 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 and it’ll only be more reasonable for you to say, “Hey, look we don't need to build a full big package service in 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 API's—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.

Corey: 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 a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.

Corey: 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.

James: [laugh]. Right.

Corey: 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?

James: 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 the turn of the last decade was just 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 lenders 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 focused set of services that are out there. And I don't think we thought the niche needs services would come from the major cloud providers back then. The other thing is, the growth was unbelievable. 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 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 utility is here to stay.

Corey: 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. Ten, fifteen years ago—I keep forgetting time is advancing. I really should have framed this as fifteen instead of ten years—but originally, it was, “Well, you'd better have a very specific niche use case to put something in the cloud.” Now, it's, “You probably should have a very specific nice use case to justify not putting something in the cloud.” I'm not saying those use cases don't exist, but it’s—

James: 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. But the scale that we're talking about is approaching Facebook. It's not even target retail scale.

Corey: 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 dollar a year range, I promise.

James: Yeah. 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—

Corey: Oh, that's not true at all. I mean, I've worked a lot of places where I pushed the wrong button or trip over the wrong cable, and yep, on-prem is now dead.

James: [laugh]. 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 when does the international competition start picking up. When do the Alibabas and the companies that may come out of even Russia or Europe, when did those companies start finding market needs and market niches in the US 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 timeframe. 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.

Corey: 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 and 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 and an AWS thing that I will be paying until I die.

James: Yeah. Well, that's the story, right? You know, there's a number of us that wrote early on that really the thing that cloud change was—it used to say the cost of experimenting, 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, 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.

Corey: Yeah, and 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.

James: Yeah. Well, on the operation 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. And 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.

Corey: 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?

James: 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.

Corey: Excellent. We'll of course throw links to that in the show notes. Thank you so much for taking the time and I really appreciate it.

James: Thank you so much, Corey. Have a good day.

Corey: 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. 

Announcer: 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 HumblePod production. Stay humble.