DataOps and home haircuts, with Bob Glithero

Episode 172 · 35:42 · SRT · archive.org · all Tanzu Talk

We were talking a little bit before we were starting about haircuts and what goes on with hair. Now, Rita, you always have a haircut. So I want to start with you. What is your operating advice in these trying times for hair management? What do you do? Do you have your kid cut your hair for you? My husband cut it. But this is a fairly, well, new in the past couple of years. I got a really short haircut. Before that, it was meh. And I never really paid. I never liked paying a lot for haircuts. You're a supercuts girl. Yes, I've done supercuts for this haircut for sure. And before that, it was, you know, the woman across the street was an Ethiopian woman. She had a hair salon and she'd cut my hair there or I'd have friends trim it. So I never really had a style or a haircut. It was always pretty, whatever it was. But now I got this thing going on and I do great clips, which is like a supercuts. But I did earlier this year for the first time in many years, went and got a fancy haircut, you know, that cost me more than 20 bucks. And it needed it, right? Because it had a shape, you know, it gave it a shape. And it was definitely a nice haircut. I mean, I feel like living in the Bay Area, your decision was like 20 bucks. Do I get a cup of coffee or a haircut? Exactly. All right, might as well. But this time with the pandemic, I was wondering what to do. And my husband said, let's just use the clippers all over, you know, do a super, no guard on the side and then just do a four. And as he was doing it, actually, this is a funny story, he kept saying, it's doing that thing that dog hair does. I'm like, what thing that dog hair does?

Do not compare my hair to dog hair while you're cutting it. Give me the mirror. And it actually wasn't that bad, but yeah. But what is that, like it gets maybe because the clippers like bite onto the hair too much? I think so. Yeah, I think it just kind of goes in that different direction. You know, like poodle hair sometimes does this thing and I'm like, oh my God, what are you saying? Yeah. No, I think your current hairstyle is very amenable to that approach. Yeah, it is. It's very good. How about, well, why don't you introduce yourself before we discover the mysteries of your hair care? Just why don't you say. Oh, very good. Oh, I never get asked about my hair care anymore. So I'm Bob Glitherow and I lead product marketing at VMware for the Tanzu data services portfolio. And this is a relatively new role for me. And before that, I actually headed up marketing for the Greenplum database at what used to be Pivotal. So it's kind of interesting moving from kind of a very relational centric world to this kind of brave new world of, you know, DevOps and microservices. And whereas before my previous role, I was concerned a lot about kind of model development because Greenplum is very, very well optimized for data science exploration and model training. And now, but, you know, one of the hardest things about data science arguably is getting models into production reliably at scale. And now kind of, I've kind of put a foot in that world and I've kind of seen that the tooling and the process that's geared towards that. It's kind of a very fascinating and eye-opening experience. And it's kind of given me a lens into the relationship between kind of the application teams and the database teams and kind of how they interact together. It's kind of the kind of, you know, let's get it done mentality of the application developer. I've got a ship at a certain time versus the kind of traditionally conservative nature of the DBA, whose primary concern is not having things blow up.

That was exactly the thing you were making me think is an application developer does not care to make time for models, right? Which is not to say they would prefer at most to say there's an emergent model, not an a priori model. But so speaking of emergent models, what has been your way of handling hair? I have taken a very laissez-faire approach to my hair, if that makes any sense. Sure. Yeah, I'm just going back to high school. I'm just like, I'm back to the future. I'm just letting it go wild and it's cooperating. So basically, whatever it wants to do on a particular day, I just let it do. I've given up trying to control it. I think, you know, I'm sort of, I want to say I'm a hybrid of these two responses. I should be better at asking my wife to cut my hair because for many years, so I have a different hangup than not wanting to pay for haircuts. It's like, I just don't want to go somewhere or deal with someone, right? Because, you know, the haircutting people always, like, ask you who you are, how you're doing. And, like, I'm sure long-term listeners, like, you know, you sort of know what I do, but people, then they ask me what I do. And I'm just like, oh, my God, I don't want to go over that, right? Like, I just, my life is very confusing, inexplicable. And so, like, it's a very, like, and then do you, like, here, it's a little easier in Amsterdam. But then back in the States, it's like, do I tip this person? How much do I tip this person? Is this a 10, 15, 25? What am I doing here? Like, it's a very, for someone like me, getting my haircut is a very difficult experience. Traditionally, I would have my wife cut my hair. And I just feel, nowadays, I feel kind of bad asking her to do that. But I should ask her some more. I'm hoping as a result of all this, powdered wigs will come back into fashion. Oh, very nice. Powdered wigs encourage health. And you could, like, you could store stuff in there, too. Exactly. It's handy, right?

So, back to the data topic. So, Rita, you had the idea to throw this together. Why don't you kick us off? So, as Bob mentioned, newly launched Tanzu Data Services kind of forced him to get smart on modern data architectures and practices pretty quickly. And so, I thought, you know, since he had to do all that learning and I'm a little lazy, he could come here and tell us about what he learned. I think it's also kind of, to set this up, it's useful to kind of contrast this with kind of the existing way of provisioning data services, you know, in a monolithic, you know, shared infrastructure kind of way. Because the way it used to be done and the way it still is done for a lot of legacy systems is there's this inordinate change management system that you have to go through. And a lot of coordination between the application teams and the DBAs. I mean, if you think about what you need to do to provision a new database today, absent a platform like Tanzu, for example. So, you start, you know, creating a request in your change control system. You know, the teams have to get together, review the sizing, review the other requirements initially for the change control meeting. You've got to create your diagrams, your data flows, you know, your connectivity between points. The infrastructure team has to look at it and decide who's going to do the work, you know, the change order is approved or not. You create your plans and your tasks. And then the app teams, the security teams, and the DBAs all start working on their piece. You install the database, you create the schemas, you verify the hardware, you create all the backup jobs and your other scripted jobs. You know, we aren't given a talk about, you know, having to deal with things like stored procedures and triggers if you're migrating from one to the other. And then the testing team has to validate everything. You've got to validate the backups and restores, create the credentials, the roles and permissions. And then finally, you've got the final sign-off. And I'll contrast all that with just being able to provision, you know, data services on the fly, you know, via a platform.

And it's just like there's a lot of ways to satisfy the application developers need for velocity and rationalize that and balance that against the DBA's need to kind of create sane policies and configurations and defaults so that you can establish proper governance over the data while still giving the data team, the application teams, the flexibility they need. And so that was kind of like my biggest takeaway is kind of like the way a platform like Tanzu can really impact those workflows. And like, you know, so I have a background as an application developer and I only sparingly worked with data people. And then, in fact, like the main data people I worked for were like developers who were forced to understand databases. Right. So it's a different a different mentality and something that like that like and you touched upon this a little bit that I never I never felt like I understood fully is sort of like I don't even know how to phrase it. But like what is the code of ethics that a data person has? You know what I mean? Like like like as an example, like the code, the code of a the principles that an application developer like operates on is like as you as you're saying is like I need to be able to try out a bunch of stuff without people having me go to a meeting. Right. Like like right since I write like since I move pixels on the screen, the best quality stuff I'm going to get is if I am allowed to tinker and just like move the pixels on the screen and like see if it works. And whereas I feel like so that that's not exactly like the code that a data person has. I feel like there's a completely different just like way of thinking that a data person has. Yet I think you're right about that. And I think the nature of the DBA's job makes them very conservative because your first task is to not lose data above all. All right. And if you have a shared kind of monolithic database, then, you know, there are a lot of different groups that depend on kind of the stability of the underlying infrastructure.

You know, changes to schemas have to be carefully considered and improved. None of this is really aligned to things like release velocity. And so, you know, it's it's nice if you can create a variety of data services that can basically serve the need of data at different points in the life cycle. So, for example, if we want to bring data into for analysis, one of the first things we have to figure out is does the data actually have any value? So we have to do some exploratory analysis. And, you know, as we increase our semantic understanding of the data and as different groups within the enterprise decide whether or not they can use it for their own purposes, it becomes increasingly codified and it becomes increasingly centralized in databases and warehouses. And the more centralized that get, the harder it is to get agility into the use of that data because there are so many different groups that are impacted by change. So it's not like, you know, a data scientist wants to go take a little data, maybe do some exploratory analytics, gather statistics on the data, do a little bit of feature engineering to see which features have explanatory power. And so that's been a primary driver of kind of like why the cloud has become so important in data science, because it gets you going quickly and allows you to do rapid modeling and exploration on smaller data sets. So you can kind of do tests and find out, OK, maybe there's some signal in this data or maybe this group of data is mostly noise. And tell me if I'm wrong, but it seems like there's two major sort of like guiding activities that you do with data. There might be other ones. Like I always forget sort of about like archive and retrieval, which is its own like fun area. But like it's basically like I want to read from this data or I want to like change the data or I want to write. And it seems like reading from the data is a little easier to the point of what you're saying. You have to make sure that it's good, right? Like that you're getting that you're getting not only relevant data, like you don't want to drown in data and you also don't want to like what starved but you die of thirst just to you don't want to like, you know, die of thirst of too much too little data.

But you also want to make sure that you don't get like bunk stuff. I think just like pulling the data and doing something with it is a lot easier and less dangerous than actually writing the data. Or I don't know. Is that the case? Yeah. Although you what you don't want to do is like be running these experiments against the production database system. Right, right, right. I guess there's the performance implication, right? Like that. Yeah, yeah. Yeah. And I remember I remember hearing I forget who it was, but someone going over. It's not really like a data thing, but it's kind of representative like a a case where they were trying to remove. You know, they were going through a bunch of stored up emails that had never been used for anything. And that caused such a huge performance hit that it brought down production. So there are concerns like that. Right. And so, you know, we kind of kicked off this talking a little bit about analytics. And so, you know, one of the your imperatives for data science is getting faster feedback. And so anything you can do that will kind of shrink the communication time between different teams is critical for success. The other thing that's been fascinating talking about my transition into this role is that we've talked about the various flavors of, you know, DevOps, data ops, whatever, ML ops. And it's just it's just interesting to see how broadly applicable some of these practices are across DevOps or data engineering or this emerging practice area. That's ML ops, machine learning ops. You know, you've got like you have a notion of version control. Well, you also have a notion of version control in machine learning as well, because you've got to do code version control as well as data versioning, as well as model versioning. Right. So that you can quickly roll back if there's like a problem. So and of course, one of the one of the key attributes you have to design for is reproducibility of results. Right. You can't have inconsistent results. And so having kind of these DevOps practices that helps kind of standardize all that, I think is going to be an important asset and influencer in kind of how machine learning is approached, you know, in the future.

You said the word consistency and that just reminds me of a conversation I was involved in listening to between a data person and a dev person. And the data person was actually a former dev person who needed to talk to data people. And they were talking about the concept of eventual consistency, which my understanding and Bob, maybe you can tell me a little bit about what it means is the data folks freak out. They don't like this concept. Whereas to move fast, developers need to embrace or are looking for this kind of concept. Well, it's kind of funny. We we had a listening exercise with some of our customers and the context was kind of like moving from kind of moving to a microservices or a cloud native type of patterns. And to a person, they highlighted consistency as the number one thing that they struggle with in this making this move from kind of a monolithic type of architect stacks to the microservices type. Like at the top of the hour, we talked a little bit about things like two phase commit, which is common in the relational world. But it's actually an anti-pattern in the microservices because it inadvertently creates tight coupling between services, which is something you don't want. But this notion of eventual consistency, you know, is definitely a problem. You've got basically three things according to the CAP theorem that you can optimize against, you know, availability, partition tolerance and consistency. And if you look at, for example, something like our in-memory data grid product, Gemfire, which is used also as an application cache, we've chosen to optimize for consistency and for partition tolerance. So, for example, you can avoid split brain effects if you lose part of your network. But, you know, you want to be able to give consistent results to queries. You don't want the inventory system saying something's in stock to one request and saying it's, you know, out of stock to a different request.

And so managing the consistency, you know, is very, very important. Can you talk a little bit to me a little bit about that, right? Is it that, is it the belief or the setup that eventually the data will all be the same? But right now, while you're working on it, all you need is like an, almost like an MVP, like the MVP of data. Like this is just the data that I need right now. It's good enough for now. And eventually it will be. So you're balancing kind of two concepts. So you have this notion of eventual consistency versus strong consistency. And in strong consistency, you've got up-to-date data, but it comes at the cost of high latency. Whereas with eventual consistency, you're willing to tolerate some level of stale data since all the nodes of the database may not have the updated data, but that buys you low latency. So you can have very responsive applications. And so which of these you choose depends on kind of the use case and how much tolerance you have for stale data. Talk to me, like how stale can data be in that kind of eventual consistency model? Well, it depends on how fresh the insight you need. And then again, it's driven by your use case. Like if you're doing like recording financial transactions on behalf of a large bank with many trading desks, you want data to be as consistent as possible, right? And as quickly as possible. If you're talking about maybe an e-commerce application, you know, you may be able to tolerate a little more. So again, it just depends on kind of the situation you find yourself in. Yeah, is there like a, I'm just going to throw out a bunch of words here, like a methodology or a gradient or ironically a model that allows you to figure out when consistency can be more slack than not? Like you cited two things, right? Like I would imagine, I don't really know much about these things, but when you're doing like flash trading where you're profiting off of milliseconds, like that's, it's important to be accurate, right?

With what you're doing, whereas like even in retail, like my experience using retail is like sometimes I get an email, it's like, oh, sorry, that's not available. It's just like, I know, I know I charged your card and I said we were going to ship that, but it turns out you don't get it, right? Like, or, and, and so in that instance, like, especially, I mean, I almost think at almost all of retail, like it's a huge, it's like at least multiple minutes, if not hours and days that the consistency window can just be whatever. Well, I could actually point to an example that we use every single day, right? So the internet's domain name system that we use is a, probably the best known example of a system with eventual consistency, right? So the servers that have, you know, the namespace that don't necessarily reflect the latest values, but they're cached and they're replicated across a lot of different directories. And it takes a certain amount of time for updates to percolate, you know, over the DNS system. And so in that case, you can have some tolerance because what's the risk of loss if there's an error, right? Well, you know, not that great. Yeah, yeah. It's almost like the measure is like, well, I'm being silly about it, but like how many, how many times are you willing to reload the webpage, right? Like, and with the DNS update, it's just like, I don't know, whatever, I'll reload it. It's like, I know it's fine. And, and like with all the, with most experiences people have, like you'll reload the webpage. I mean, the, I, in my, I mean, I'm getting kind of corny and simplistic here, but like the only frustration in a retail thing of losing data is when you've spent like, you know, an hour building up your grocery list and then it just disappears. Right. You know, it's, it's not the end of the world if, you know, your shopping cart dumps, you just reload. Right. Right, right, right. Whereas if you traded on like, you know, a fractional penny price and something and the price was wrong, then there's a bunch of money that you just lost. There's no, there's no, there's no, there's no reload on that. You may have, you know, a bad risk calculation that impacts your investment decisions, things like that.

Yeah. Yeah. And then I guess on the other extreme end would be like, like some, I don't know if people call this anymore, but some like internet of things stuff, like, like autonomous driving. It's important for it to happen. I don't know if I'm confusing quickly with consistently, but like, you want to make sure that the data is good because you're going to be making a lot of decisions quickly. Yeah. So what do you do in that situation where you're like, you need like real time modeling and insights made? How, how's all the cap stuff and everything apply to that? Well, you know, just kind of taking a little different view is it's kind of like, that's why you have the, these so-called no SQL databases or non-relational databases. Because it allows the developer to kind of make a trade-off and choose the optimal balance between strong consistency and eventual consistency and latency. So you can kind of get the best benefits of both worlds. And so that's kind of one of the reasons why our portfolio for Tansu data services is structured the way it is. So you can choose the, the data backing service that's appropriate for whatever use case SQL isn't going to go away anytime soon. You're going to need to have a need for relational data for quick prototyping of your schemas or for transactional workloads or even some OLAP or in the context of analytics, data prep, data cleansing, things like that. Whereas, you know, if you need the ability to kind of independently scale your reads and writes in a particular use case, then you've got Gemfire. And then we also supplement that with our partner ecosystem of various NoSQL and SQL data stores so that, you know, you can kind of choose and mix and match the one that you need for your particular application. Right. But, you know, it's, it just depends on kind of how much tolerance you have for stale data in whatever setting you're in.

Yeah. Yeah. Yeah. I mean, that seems like, that seems like it, that would be a good guidebook for developers. Right. Like, you know, how, how stale do you want your bread? Are you making French toast or like very something that's, that's more fresh? And, and, and so, so we talked about the, I mean, you know, the op side of things. What is, I mean, you've gotten over this a little bit, but like in, in the, in the data world, what is the ops stuff? And so, so what I, what I mean by that question is like in the application world, the ops stuff is largely about what older people like me would call release management and configuration management. Right. Like how do I package up and configure my application to run in production? And then also like, uh, how do I troubleshoot it in production? And so it's kind of like having developers do that is a lot of what the literal DevOps stuff is. You know, there's all the, uh, you know, dogs under desk cultural stuff, which is valid on its own, but it's a different related topic. But anyway, so in the data world, like what are the operations things that I guess you're letting developers or data modelers do? Well, one of the things you're doing is streamlining the provisioning workflows for data services, right? And so for example, I mean, I'm just going to reach back into my own past. I was kind of the accidental DBA earlier in my career. Um, and by that, I mean, so I was in charge of financial reporting at a large media conglomerate and we, you know, their application ship with some anonymous OEM database. And just, I would, that thing we're talking about way back in the days of client server. And, you know, I had to kind of, you know, babysit that thing because if we just looked at it the wrong way, it would go down. And one of the things I learned, you know, fortunately before I had, uh, any kind of severe situation is the importance of like rigorous and regular backups. And restores, especially specifically testing that because the vendor consultants didn't understand anything about the, the underlying OEM database.

They just were experts in their business logic. Yeah. Um, and so, you know, kind of automating a lot of the, the day one and day two stuff, um, is of course really, really valuable because if you're kind of a DVA, the, the, the real thing, the real things that you're focused on solving, uh, is kind of like understanding kind of what's going on with your long running queries, right? Like what's going on, what's, what's, what's, what's blocking their execution, right? How are we balancing, you know, performance amongst the different, you know, execution? How do we make sure resource consumption, uh, isn't getting out of control? Um, you know, how are we isolating workloads? And so, you know, the, the, the data ops quote unquote, uh, practice kind of helps kind of reduce a lot of the busy work, uh, that data teams have to do. Um, the other application you can think of is for more practical, uh, data quality, uh, and data validation, right? So, you know, you, a good data pipeline usually starts by validating, uh, the input data. So it could be for file format and size, you know, or the column types, what you're expecting, how are you handling like null or empty values? What do you do with invalid values so that you can, for example, get this data prepped, uh, for, uh, analytics training and prediction around 45 to 55% of, you know, data scientists time is spent on data prep. So one of the key, uh, what I think one of the areas that's rich for mining, uh, is this notion of kind of using these, these data ops practices to help automate a lot of that work, uh, so that, you know, the data scientists and the data engineers can focus on the things that they'd rather be doing, uh, which is making, you know, kind of the higher level troubleshooting. You want to get as much of the infrastructure and ops out of the way as possible. And, you know, at the top of the hour, I talked a lot about kind of the, the basic, the change management process you have to go through and provisioning a data service.

So, you know, data ops kind of takes away a lot of that and streamlines a lot of that so that the developers can kind of get the velocity they need, um, and, and, and work the way they want to. Whereas, um, the DBAs can set up the, the appropriate defaults, the appropriate policies and controls and governance over the data, um, as well. So it's kind of, it, it brings a lot of benefits, I think, to both the app developers as well as the data teams. You know, it's not just the, the app developers that are having all the fun with DevOps. Now that the data teams can benefit as well. Yeah, that's a good, like, I, I like, I like the way you approach that answer. Cause it is, uh, it's very similar to sort of like the answer to DevOps stuff, which is, which is what does the DBA actually do every day? Right? Like, like what, what, what are the, the activities that they go over just to like keep the thing up and running and not falling apart. And a lot of, a lot of what those are in the operations and infrastructure world is a lot of the technical stuff that like DevOps is trying to do better and, and, and automate. But that, that makes a lot of sense. A lot of what you said just sounds so familiar to me from conversations we've been having for several years now, uh, in the industry, right? And context of DevOps, which is reduction of toil, let the data folks do the thing they, they want to do and need to do, you know, um, more quickly and, uh, and consistently. So that's kind of, well, it helps to align the interests of the application developers and the DBAs. Um, there's kind of a running joke in the industry that DBA stands for don't bother asking, right? Right. Doctor, no, right. You know, you can't have that change. And so when you have a platform that supports these, you know, new types of workflows, I think it's easier to harmonize the culture and organization. It removes, it has a potential to remove a lot of friction between the app development teams and the data teams. It's funny. It made me think about the role of technology in, uh, transforming culture. I can't believe I just said transforming, but you know, uh, influencing culture and how people work.

But I think there's something to be said for that. We, we talk a lot about, uh, the importance of culture for modernization and digital transformation and such. And I'm, I'm seeing that this is a conversation you have, uh, here as well. So, uh, yeah, which is kind of what I wanted to talk about. Have you, have you guys, have you all, uh, started to have conversations with customers or hearing any, uh, anything about the cultural implications of this? Uh, how do you change mindsets between, uh, DBAs and devs and folks to, to make this stuff reality? Well, I'll just say that, um, you know, again, just beating the, uh, reiterating this point, you kind of got two competing interests. The developers kind of want to ship quickly to meet, you know, their, their timeframes, their, their, their deliverable deadlines. And they're focused on the business uners. So they're kind of have a kind of a, I don't want to say a short-term focus, but they're, they're more kind of immediately focused on their goals. Whereas the DBAs are doing everything they can to try to kind of build out and govern the data answer and get the most long-term value out of the data. And these, these two things don't always harmonize. So to the extent that, you know, you have these data ops processes that can automate a lot of these workflows, it just kind of makes it, I think, easier to harmonize the interests of these two groups. Yeah. And I wonder, and we don't have to answer this, but I wonder what, uh, a data, a DBA's concept of an MVP, which is minimal viable product is versus a dev or an ops person's. Like minimal, minimal viable data that, you know, based on, based on what we've been talking about, even that, the way I was just thinking that would be, it's more, it's more like a minimum viable. I've got the right stuff and it's performant, right? Like it's like the data is, is almost a side effect of like the care and feeding and the gardening and the, and the, the way you're operating with it. Right. Like it's a, the data is fine, but it's really all the performance characteristics around it. And it's, it's, it's a consistency and latency and everything. That's the real like challenge to provide. So you sort of need like minimum viable reliability, which that sounds terrible.

No one wants the minimum viable, eventual consistency. Just kidding. My favorite. I just think I like, I like the way eventual consistency sounds, I think. More than anything. Anyway. Yeah. So, uh, I, I mean, I mean, before, before we wrap up here, I, I always like find stories and case studies and stuff pretty illustrative of, of like more, some of the concepts we've talked about. Like, do we have some good ones to refer people to that kind of like hit on how to turn, you know, the, the don't bother asking role into the like, come, please ask. What would that be? CPL. Uh, but like, like what, how, how have people like moved beyond, like, don't ever talk to the DVA and like, let's do something useful here. Like, what are some, some stories you could refer people to? I don't know if we'll ever get to the point where, you know, don't talk to the DVA is, is, is, is part of the vocabulary. Um, at least I hope not because, you know, there, as I say, the DV is like to, I'd like to think that they had some value to add, but yeah, we recently wrote a blog post, uh, introducing kind of the Tanzu data services and what the rationale was. And one of the, we, we, we highlighted a number of case studies. And I, one thing I would refer people to is to look at that blog and look at the case study for MasterCard, which was basically using, um, Gemfire as their backing service for their fraud detection system and scaling that to, you know, billions of transactions a day and making, you know, instant decisions on, you know, whether or not a transaction is fraudulent or not, I think it's a really useful case study to look at just to kind of give you to see how it's possible to scale these things quickly. No, that's, yeah, that makes a lot of sense. I always, retail examples or, or anything involving like, you know, money changing hands is, is always helpful because most everyone understands that. I guess unless, I don't know, I don't know in the hills of Oakland, if there's some barter economies that, uh, you know, I find this case study useful, but yeah, well, great.

Well, I, I, you know, thanks for being on is, it was, uh, it was nice. If people were beyond the case study, if they wanted to see what you were up to in a non-creepy way on the internet, you got a, you got some Twitter thing or a live journal you want to point people to? Yeah, absolutely. So if you want to follow my doings on Twitter, my handle is at BGlithero, B-G-L-I-T-H-E-R-O, um, which by the way is an English name. I'm always asked if it's Italian, but no, I'm from very, very far North of Italy, uh, up by London, um, and then, you know, I do, I do post a lot of readings, uh, on LinkedIn as well. Um, I know it's primarily used for bad recruiters, but actually I try to contribute some value to that platform as well. Uh, again, under the same name, BGlithero. Yeah. LinkedIn has become a strange, crazy, usually useful content stream. I don't know. I think I made some tactical mistake years ago and I just like uploaded my contacts to it and try to connect to everyone. And so I got a bunch of like irrelevant speaking of finding out if the data is valuable stuff in there, but right. And then I would encourage people also to follow, uh, the VMware Tanzu data accounts on both Twitter and LinkedIn, because we're always a highlighting, uh, interesting case studies as well as, uh, tutorials and best practices for things like application caching, uh, as well as for things like messaging, uh, and which is, and streaming, which is something we really didn't get a chance to touch on today. Yeah. Yeah. We should, we should reunite to go over those things. Cause those, yeah, because there's lots of interesting things going on with streaming data and streaming use cases these days. Well, I'll put a link to all of those things at the show notes, which, which you can get at, uh, I remember last time I was not sure what the URL anymore was, but what I should have done is just a simple test of what my assumption was, which turned out to be correct. That if you go to Tanzu.vmware.com slash podcast, you can find the show notes for this and how to subscribe and everything.

Now, also, if you're feeling feisty, you can do the plural podcast. It doesn't have to be singular. I was, I was debating in my head. Do you make this a podcast? Cause then that implies there's only one, but maybe there's not more than, I don't know. It's very confusing what, which way we should, we should handle that. And, uh, maybe if you wanted to wait around for DNS updates, we could add in podcast.tanzu.vmware.com. I don't even know what, what happened, what do they call it when you're three levels up from, from a.com? Is that, uh, just madness? I forget, but, uh, that, that would be fun. Well, thanks for joining, uh, Bob and, uh, sharing your, your, what you've learned. Well, thanks for having me. I mean, this was, this was a treat and I hope to do it again soon. Yeah. All right. Well, we'll see everyone next time. Bye-bye. Bye.

Tanzu Talk · 🍕 Get more pizza.