1 00:00:00,000 --> 00:00:04,720 Welcome to another episode of Cloud and Culture. I'm Danielle Burrow from VMware. 2 00:00:05,160 --> 00:00:09,780 And I'm Derek Harris from VMware. If you're new, this podcast focuses on the process of 3 00:00:09,780 --> 00:00:15,700 application and IT modernization through the lens of Tanzu Labs, previously called Pivotal Labs. 4 00:00:16,200 --> 00:00:20,400 Over the years, Tanzu Labs experts have helped hundreds of companies and organizations, big and 5 00:00:20,400 --> 00:00:25,280 small, build better software and adopt modern development practices. The tradition carries 6 00:00:25,280 --> 00:00:30,660 on today as Tanzu Labs experts help clients get up to speed with cloud-native computing and the 7 00:00:30,660 --> 00:00:35,920 flexibility and resiliency it provides. Our guest for this episode is Kevin Murley, 8 00:00:36,060 --> 00:00:41,700 who leads the data transformation team in Tanzu Labs. Kevin explains the ins and outs of data 9 00:00:41,700 --> 00:00:46,620 transformation for modern applications. It's a wide-ranging topic that covers new architectural 10 00:00:46,620 --> 00:00:51,920 patterns, data engineering for machine learning workloads, designing for GDPR compliance, and a 11 00:00:51,920 --> 00:00:56,900 lot more. He also shares some anecdotes from his years watching data trends come and go and share 12 00:00:56,900 --> 00:01:02,060 some thoughts on what we can learn from them. So stick around to hear Kevin's insights, as well 13 00:01:02,060 --> 00:01:07,960 as how Tanzu Labs helps enterprises approach data modernization. Hi, Kevin. Thanks so much for 14 00:01:07,960 --> 00:01:12,360 joining us today. Could you just go ahead and give us a quick introduction of who you are and what you 15 00:01:12,360 --> 00:01:18,580 do at VMware? Hi, Danielle. Thanks for having me. Sure. So my name is Kevin Murley, and I am the 16 00:01:18,580 --> 00:01:25,880 director of data transformation services. Data transformation services is the newly combined 17 00:01:25,880 --> 00:01:32,100 services entity that we've put together, which combines a couple of different services teams 18 00:01:32,100 --> 00:01:39,060 focused on helping our customers be successful with data transformation and modernization. So the 19 00:01:39,060 --> 00:01:46,480 over-encompassing title of data transformation services includes data solution architects, data 20 00:01:46,480 --> 00:01:53,220 engineers, data scientists, and data engagement managers. And so we really help customers. You can think of it 21 00:01:53,220 --> 00:02:01,320 in really three different areas. We help customers enabling the success of Tanzu data products. So 22 00:02:01,320 --> 00:02:10,300 Greenplum, Gemfire, RabbitMQ, Postgres, MySQL, upcoming DMS products. So we help customers with 23 00:02:10,300 --> 00:02:16,240 implementation and enablement to achieve their business goals with the Tanzu data products. We'll do health 24 00:02:16,240 --> 00:02:22,840 checks, evaluate how efficiently they're using the data products. We'll do upgrade services, and of course, full 25 00:02:22,840 --> 00:02:32,480 implementations. Then a second area is you can think of it as data modernization, which is often in support of 26 00:02:32,480 --> 00:02:59,100 application modernization. So we'll work with the Tanzu Labs team. And we'll provide data modernization, such as helping customers do data domain-driven design, where they're moving to microservices-based app infrastructure. We'll look at how to optimize their data access. We'll look at breaking apart data monoliths to 27 00:02:59,100 --> 00:03:28,340 provide better access to provide better access to the data for these new app microservices. We'll build API-based layers so that there's nice, clean access. The example I always use is the companies that we deal with are generally very large companies who have done acquisitions. And we'll have, for lack of a better way to put it, they'll have multiple views of what a customer is, because they'll have incorporated multiple customer databases through their acquisitions, for example. 28 00:03:28,340 --> 00:03:51,520 And so what we can help them do is, as they're modernizing their applications and looking for a nice, clean API for a customer, we can take these disparate customer databases and create an operational data layer that gives the API or gives the microservices a nice, clean, single view of what customer looks like across all these disparate customer databases. 29 00:03:51,520 --> 00:03:54,520 So that would be an example of the data modernization activities. 30 00:03:54,520 --> 00:04:14,520 We also optimize legacy data access. So Oracle or DB2 access, we can help optimize that to improve the efficiency and the performance of these modern applications as they're interacting with legacy systems. 31 00:04:14,520 --> 00:04:21,520 Do those legacy systems go away ever? Or are there those things that tend to stick around and stick around and stick around? 32 00:04:21,520 --> 00:04:43,700 Yeah, good question. A little bit of both. So where it's appropriate to fully modernize a legacy system where we can break it apart, break apart this monolith into more distinct components, or change the actual data access mechanism from what might be 33 00:04:43,700 --> 00:04:50,700 what might be very SQL oriented access into something that is more event driven or event based access. 34 00:04:50,700 --> 00:05:19,700 In time, those systems can go away. But quite often, these systems are very tightly ingrained in the corporate infrastructure. So there's audit and compliance activities built around those systems. And so they will, they're going to be there for a while, they're off in the system of record, and they're not going to move in many cases. So we will find ways to interact with those systems, to make it more efficient for the these modern applications that we're helping customers. 35 00:05:19,700 --> 00:05:21,700 So the short answer is both. 36 00:05:21,700 --> 00:05:40,480 So then the third sort of pillar I was mentioning was really helping modernize these customers' data platforms. And so that could be, to your point earlier, is phasing out these data monoliths could be enabling the platform that they're using for analytics or data science. 37 00:05:40,700 --> 00:06:08,700 So we also help operationalize the idea of data science and machine learning and AI by transitioning these old legacy platforms into something that's more agile, that's a more modern data platform, and really helps operationalize these concepts of business value through learning algorithms and data science models. And then, of course, modernizing these old expensive platforms too. So taking advantage of NoSQL platforms, taking advantage of messaging, etc. 38 00:06:08,700 --> 00:06:20,700 So what are some of the things that customers need to consider about data modernization before they get started? I imagine there's a lot of security and compliance issues amongst other things. 39 00:06:20,700 --> 00:06:38,700 Yeah, a lot of the initial areas to consider are around ideas of, to get started, you want to find a nice discrete set of information that aligns with a business goal. 40 00:06:38,700 --> 00:06:54,700 So if you're in the process or if a customer is in the process of doing application modernization, then we want to be able to find discrete pieces of information or discrete data sets or even a discrete domain area that we can help modernize along with that. 41 00:06:54,700 --> 00:07:12,700 And so that might entail taking information from multiple legacy data sources and creating an operational data store that might be a Postgres database or it might be a Gemfire cache and being able to show the value and return business value by doing these activities. 42 00:07:12,700 --> 00:07:34,700 Whether it's performance or cloud, you know, being able to access information more efficiently from cloud based applications or moving these data systems to a Kubernetes based system there, you really want to be able to derive business value and not move data systems for the sake of the next shiny toy. 43 00:07:34,700 --> 00:07:46,700 Let's make sure that there's real business value and then we really try to help other customers do that analysis and we go all the way back to data domain driven design and development. 44 00:07:46,700 --> 00:07:51,700 So we look at the domains that you're working with and what domains make sense. 45 00:07:51,700 --> 00:07:57,700 Do we need to refactor those domains, these data domains to align with the application domains, for example? 46 00:07:57,700 --> 00:08:04,700 So you mentioned like operationalizing AI and ML and data science and that type of workload. 47 00:08:04,700 --> 00:08:09,700 Is that a common, what I guess I'm thinking about is, is that something customers need to think about? 48 00:08:09,700 --> 00:08:15,700 Like, because you, because you want the business value, you want to be able to do a certain thing, but I think the, maybe it's, maybe it's overlooked. 49 00:08:15,700 --> 00:08:21,700 Maybe it's not, but like you actually have to build the infrastructure, the data infrastructure to be able to do that, right? 50 00:08:21,700 --> 00:08:22,700 Like the algorithms are one thing, right? 51 00:08:22,700 --> 00:08:27,700 But I think the data engineering part of it is, it's kind of the foundation. 52 00:08:27,700 --> 00:08:35,700 Yeah, you're, you're spot on the, what we've, what we find is that we don't want to talk about selling data science. 53 00:08:35,700 --> 00:08:47,700 What we want to talk about is the business value of smart applications or smart models or solving a business problem through data science and AI and ML. 54 00:08:47,700 --> 00:08:59,700 And there's a, there's an old saying that, you know, PowerPoint and Excel is where data science goes to die because, you know, once you've built this great model and you've, you've shown the results, that's great. 55 00:08:59,700 --> 00:09:06,700 But if you can't operationalize that, then you're not going to get long lasting consistent value from the work that you've put in. 56 00:09:06,700 --> 00:09:18,700 And data engineering is a huge part of that, making sure that the data that goes into these models is able to be consistently, efficiently and performantly refreshed. 57 00:09:18,700 --> 00:09:23,700 So you're, you're feeding these models with new data and it's continuing to learn. 58 00:09:23,700 --> 00:09:35,700 And these models are being updated and operationalized so that the people who need this information are getting consistently updated and valuable information out of these data science models. 59 00:09:35,700 --> 00:09:49,700 How much would you say, you know, the desire to do more ML or AI is driving data modernization versus just needing to, you know, build applications differently, access data differently? 60 00:09:49,700 --> 00:09:54,700 I think it's, it's, it's a hard to, it's a hard question to answer, Danielle. 61 00:09:54,700 --> 00:09:59,700 It's the, it, a lot depends of course on the customer priorities. 62 00:09:59,700 --> 00:10:20,700 So the, if a customer has an impending business value need, you know, they know that they are losing money because they're losing customers or customers are not buying additional services or products from them. 63 00:10:20,700 --> 00:10:30,700 And they want to have, they want to have, they want to understand how that's, why that's happening and how to make that not happen or how to make customers buy more, you know, you're looking at efficiency. 64 00:10:30,700 --> 00:10:43,700 Those types of things lend themselves toward building a data science model to really understand what the data is, can tell you what the data can tell you where a lot of other customers just have a need to get off. 65 00:10:43,700 --> 00:10:54,700 Old legacy systems because they're paying too much for those systems or they're not able to, to be efficient with those systems or they can't make changes with the systems. 66 00:10:54,700 --> 00:11:00,700 They're, they're, they're dealing with a system that's an anchor to their ability to be agile. 67 00:11:00,700 --> 00:11:17,700 And so by modernizing these, the systems, or at least the data oriented around them, their systems allows them to make changes to the information faster, allows them to gather information faster and allows them to then think about what they can do with this data in the future. 68 00:11:17,700 --> 00:11:20,700 So it really depends on what I, what I call the data journey. 69 00:11:20,700 --> 00:11:29,700 It depends on where they're at in this data journey will really drive their decisions about what they want to do from a data transformation and modernization perspective. 70 00:11:29,700 --> 00:11:36,700 You mentioned, and you mentioned the, like, like cloud and Kubernetes as potential platforms for this. 71 00:11:36,700 --> 00:11:47,700 How do, I know this is probably a broad question and there may be varying answers, but like, I'm going to sort of lump them together for the sake of, for the sake of this, but like, but like, like how do, how does taking advantage of something cloud or Kubernetes? 72 00:11:47,700 --> 00:11:55,700 And when I say cloud, I guess, you know, that could be cloud services or it could be just, you know, the, the infrastructure or, or, you know, whatever the on-demand nature of it. 73 00:11:55,700 --> 00:12:04,700 But how do, how do, how do, how do those kind of shift the, the nature of how, how you're modernizing data systems or how people are, are managing them? 74 00:12:04,700 --> 00:12:05,700 Yeah. 75 00:12:05,700 --> 00:12:06,700 Yeah. 76 00:12:06,700 --> 00:12:22,700 The platform that a customer chooses to go to, as they're transforming and modernizing their data infrastructures or, or even create new ones, honestly, you know, building brand new data systems is often dependent on where their future is headed. 77 00:12:22,700 --> 00:12:33,700 So by moving to a Kubernetes based system, they get a lot of advantages in terms of operational and reliability, operational efficiencies and reliability. 78 00:12:33,700 --> 00:12:42,700 And so they can, they can start to leverage those advantages for those systems, moving to a cloud-based system, same kind of activity. 79 00:12:42,700 --> 00:12:48,700 People are moving to cloud-based systems because they want ubiquitous access. 80 00:12:48,700 --> 00:12:59,700 And so there's still the, the level of security that they need, but that they want to be able to have the, the general access from anywhere and not be bound to a data center. 81 00:12:59,700 --> 00:13:11,700 So we're seeing, you know, people who are moving to cloud-based data systems, whether it's our own Tanzu data products in the cloud or other, because they want to have, they want to get, reduce their dependency on their data center operations. 82 00:13:11,700 --> 00:13:15,700 And have more flexibility and agility in how they're dealing with their data. 83 00:13:15,700 --> 00:13:16,700 Yeah. 84 00:13:16,700 --> 00:13:32,700 And I'd love to get into some of the challenges that, that customers you're working with are facing when they're trying to, you know, be more agile and be able to access data with, you know, along with these applications that they're also trying to modernize and move. 85 00:13:32,700 --> 00:13:37,700 Just wondering like, what are some of the big, the big hurdles that you're seeing when folks are trying to do this? 86 00:13:37,700 --> 00:13:38,700 Sure. 87 00:13:38,700 --> 00:13:41,700 A lot of it is access-based, you know, is there. 88 00:13:41,700 --> 00:13:45,700 Can they just get at the data they need in a timely fashion? 89 00:13:45,700 --> 00:13:49,700 Is the data being brought into one system or multiple systems? 90 00:13:49,700 --> 00:13:55,700 And then do they have to do additional steps to, to make the data available for use? 91 00:13:55,700 --> 00:14:09,700 Whether that's reporting or business intelligence or data science or application access, you know, getting the data to a place or in a state that makes it available can be, can be time consuming and difficult. 92 00:14:09,700 --> 00:14:23,700 So customers are looking at, you know, these are some of the challenges that they're thinking about here is what's, what data is most important to me and how can I get it as fast as I need it? 93 00:14:23,700 --> 00:14:24,700 Yeah. 94 00:14:24,700 --> 00:14:37,700 So if it's a combination of multi-cloud or on-prem and cloud deployments, then, you know, access has a different sort of connotation because now you're looking at where does my data, where's my system of record? 95 00:14:37,700 --> 00:14:38,700 Where does my data live? 96 00:14:38,700 --> 00:14:41,700 Where does my data live and where is my data going to be used? 97 00:14:41,700 --> 00:14:48,700 And how efficiently can I move the data or access the data across these virtual and physical boundaries? 98 00:14:48,700 --> 00:14:56,700 And so that's another aspect of data transformation and modernization is, is making the access to that information efficient. 99 00:14:56,700 --> 00:15:05,700 If the system of record is on-prem because of audit and compliance reasons, but yet I want to have applications based in the cloud, do I have to do that? 100 00:15:05,700 --> 00:15:16,700 Do I have to go from cloud to on-prem for every single piece of data access, or should I create a cache or an operational data store more local to where my applications are going to be running? 101 00:15:16,700 --> 00:15:28,700 Or do I just need an event based system where I'm moving events in a, in a stream to get to those applications or to allow those applications to get at the data they need? 102 00:15:28,700 --> 00:15:42,700 So it's really, you know, we spend a lot of time making sure we understand our, our customers requirements so that we can guide them and help them move to the right direction and use the right technologies to achieve their goals. 103 00:15:42,700 --> 00:15:49,700 All right. Yeah. That's something we, in our last episode, we touched on data gravity a bit in that concept. 104 00:15:49,700 --> 00:15:57,700 And I think that's to some degree what you're talking about here is like the data that the data is in one place, either it's, it makes sense to build other stuff there because you want access to it. 105 00:15:57,700 --> 00:15:59,700 And that's, that's what the system of record is, but also, yeah. 106 00:15:59,700 --> 00:16:09,700 How do you start when you're talking about laws of physics and we start talking about how are you communicating or, you know, sending data across clouds and, and data centers and, and everything. 107 00:16:09,700 --> 00:16:16,700 So yeah, absolutely. And, and the idea of data gravity, as well as, you know, 108 00:16:16,700 --> 00:16:28,700 the idea of data data is going to sit where it lands and trying to reduce that gravity so that data can be used efficiently can be very difficult, 109 00:16:28,700 --> 00:16:35,700 especially when you're looking at the concept of IoT and we're bringing in tons and tons of information. 110 00:16:35,700 --> 00:16:44,700 And are we landing it somewhere to then operate on it? Or are we landing it somewhere to then move it somewhere else because we're augmenting that information? 111 00:16:44,700 --> 00:16:55,700 So the idea of data gravity has a lot of aspects to it. There is data is sitting in one place because it's always been there and, and it's been there for the last 20 years. 112 00:16:55,700 --> 00:16:59,700 So we're just going to keep putting more and more data there. There's that aspect of data gravity. 113 00:16:59,700 --> 00:17:11,700 There's the anchors to the data gravity, as I mentioned, like compliance and audit, for example, where you've got systems and processes and procedures set up for where that data lives today. 114 00:17:11,700 --> 00:17:18,700 And it's very difficult to move that. But then there's the aspect of, of does all that data that's sitting there really need to be there? 115 00:17:18,700 --> 00:17:30,700 We had a customer in the Midwest who had a, had a big system that was a SOX compliant database, the big Oracle system that was a SOX compliance. 116 00:17:30,700 --> 00:17:43,700 And it took them three months to make any changes to the data structure in this giant Oracle database because of all the procedures and policies and compliance they had to go through for SOX compliance. 117 00:17:43,700 --> 00:17:55,700 When we looked inside that database, there was something like 12 out of the nearly 400 schemas inside that database. 118 00:17:55,700 --> 00:18:01,700 Only 12 of them actually were, were any related to finance, any, anything even related to SOX compliance. 119 00:18:01,700 --> 00:18:08,700 So all this data was sitting in this Oracle database due to data gravity, because that's where it was just easy to put. 120 00:18:08,700 --> 00:18:20,700 That did not need to be there and could not have any kind of agile modifications to that data structure because of the compliance of such a tiny percentage of information that was actually in that system. 121 00:18:20,700 --> 00:18:32,700 It's weird. This is kind of off topic, but, but related, I mean, it has, do, do regulations like GDPR or other things start to start to pop up now, especially in terms of we could, we talk about like, does this really need to be there? 122 00:18:32,700 --> 00:18:33,700 How do we access it out? 123 00:18:33,700 --> 00:18:34,700 Cause I mean, that's kind of the gist, right? 124 00:18:34,700 --> 00:18:39,700 Is minimize what you're keeping, make it possible to delete and do whatever on a user by user basis. 125 00:18:39,700 --> 00:18:42,700 Like that's a data engineering problem. 126 00:18:42,700 --> 00:18:43,700 Very much so. 127 00:18:43,700 --> 00:18:43,700 Yeah. 128 00:18:43,700 --> 00:18:55,700 I was, I was literally on a call yesterday talking about GDPR because it's not only, you know, does that data need to be there, but can it legally be there and who can access it? 129 00:18:55,700 --> 00:18:59,700 And what's more interesting these days is how long does that data live? 130 00:18:59,700 --> 00:19:09,700 Because now with, with GDPR data can may only need to live or may only be allowed to live for a certain period of time, then you have to get rid of it. 131 00:19:09,700 --> 00:19:14,700 So now you have policies in place about who can access that data. 132 00:19:14,700 --> 00:19:26,700 Can the data actually leave a particular geographic area and how long should that data live from the time of its, its initial written, being written to a data store. 133 00:19:26,700 --> 00:19:35,700 So yeah, lots of, lots of questions and, and, you know, data governance and, and these lots of different things coming into play these days around data. 134 00:19:35,700 --> 00:19:48,700 Are there kind of a set of best practices emerging on how to deal with that, or is it really on a case by case basis because everyone's setup is so different and unique? 135 00:19:48,700 --> 00:19:59,700 For GDPR, there's a whole, you know, set of regulations and compliance and there's companies popping up every day to, to figure out how to best deal with GDPR. 136 00:19:59,700 --> 00:20:06,700 And so that's, that's not an area that we're as the data transformation team that we're going to own. 137 00:20:06,700 --> 00:20:12,700 We're going to partner with companies who, who do that and have spent the investment to really understand all the regulations. 138 00:20:12,700 --> 00:20:25,700 So there's, there's a couple of companies that we're talking to, to be able to partner with them and be able to then offer our customers some, some more fully thought out solutions than we could do on our own. 139 00:20:25,700 --> 00:20:31,700 You just put that, that warning on the website that says, do you accept our cookies? 140 00:20:32,700 --> 00:20:34,700 Nothing to worry about. 141 00:20:34,700 --> 00:20:35,700 Exactly. 142 00:20:35,700 --> 00:20:36,700 That covers it all. 143 00:20:38,700 --> 00:20:54,700 I think another question, Kevin is like the, the idea of, because I mean, this is something I think where, especially coming back from the old pivotal days, right, where there was so much talk about, you know, 12 factor apps, you know, this is just how, and, and, you know, there's new, new ways of architecting applications. 144 00:20:54,700 --> 00:21:06,700 So I'm curious, I guess, I'm curious, I guess, on how we talk about, or how, how, how it's maybe changed thinking about approaching like stateful versus stateless applications when you're, when you're modernizing and where the data layer works into that as well. 145 00:21:06,700 --> 00:21:10,700 Because I think, you know, like not all modern apps are stateless anymore. 146 00:21:10,700 --> 00:21:11,700 Right. 147 00:21:11,700 --> 00:21:12,700 Oh, very much so. 148 00:21:12,700 --> 00:21:13,700 Yeah. 149 00:21:13,700 --> 00:21:21,700 And, and that's always been, you know, a philosophical challenge because by its nature, data is stateful. 150 00:21:21,700 --> 00:21:28,700 No data has, it has a state and it has a value at that moment in time. 151 00:21:28,700 --> 00:21:38,700 And the idea of a stateless application accessing stateful data can cause some cognitive dissonance. 152 00:21:38,700 --> 00:21:51,700 And so we've, you know, the idea of how often is data refreshed and who gets to refresh it and making sure that we have the right design patterns around accessing data is really important. 153 00:21:51,700 --> 00:22:12,700 The, the idea that, you know, data is critical to the applications is pretty well understood these days, you know, the applications need data and finding out where that boundary is and how to write smart applications and design smart data infrastructures. 154 00:22:12,700 --> 00:22:25,700 So that you can scale out the applications as easy as possible and, and make them as stateless as possible while still having accurate and consistent data is, is part of what we're all about. 155 00:22:25,700 --> 00:22:31,700 And part of the expertise that we bring to these data and app joint modernization projects. 156 00:22:31,700 --> 00:22:54,700 Yeah, I feel like you almost just kind of answered my next question, which was kind of digging into that around how, like how much of the transformation is really going to be focused on the technology, you know, changing the type of database you're using versus kind of focusing more on the process or the architecture or focusing more on that domain driven design approach, et cetera. 157 00:22:55,700 --> 00:23:10,700 Yeah, if we're, if we're, if we're, if we're given the opportunity, we, we spend as much time as possible, making sure that we understand the requirements because that will help guide the technology to deliver the appropriate solution for the customer. 158 00:23:10,700 --> 00:23:21,700 And sometimes it's not as much about the technology as it is understanding the ultimate goals of what the customer is trying to do. 159 00:23:21,700 --> 00:23:44,700 And so by that, I mean, um, just saying they need better performance, you know, a customer saying we need better performance for our customers who are using our mobile app that in and of itself can be solved with technology to a degree, but then there's the aspect of. 160 00:23:44,700 --> 00:23:51,700 And there's, you can, you can only pull so much data through, you know, a certain size pipe at any one period of time. 161 00:23:51,700 --> 00:24:07,700 And is the data that you're pulling through that pipe, the most efficient set of data for those applications to be used the idea of looking at the actual domain design of the data underneath. 162 00:24:07,700 --> 00:24:15,700 And then potentially breaking apart that, that, that design that is potentially monolithic from 20 years of use. 163 00:24:15,700 --> 00:24:30,700 And then moving that in, and creating a, a smart data domain driven design in support of this mobile app can now make the APIs that are accessing that information much more efficient. 164 00:24:30,700 --> 00:24:37,700 So you're putting smaller information through the pipe, which is going to be much faster and more efficient for the application to use. 165 00:24:37,700 --> 00:24:41,700 Kind of a long answer to a short question, but that makes sense. 166 00:24:41,700 --> 00:24:42,700 Yeah. 167 00:24:42,700 --> 00:24:49,700 Cause I think it relates to another thing we, I think we want to touch on was like, how, how new trends in data systems affect. 168 00:24:49,700 --> 00:24:50,700 I know. 169 00:24:50,700 --> 00:24:52,700 Cause you mentioned earlier too, like, you don't just want to chase the shiniest new thing. 170 00:24:52,700 --> 00:24:53,700 Right. 171 00:24:53,700 --> 00:24:56,700 But for a while it was, everyone's moving to no SQL systems. 172 00:24:56,700 --> 00:24:56,700 Right. 173 00:24:56,700 --> 00:24:58,700 And then it was, you got to have a Hadoop data lake. 174 00:24:58,700 --> 00:24:59,700 And then it was, you got to know you got to spark. 175 00:24:59,700 --> 00:25:04,700 And then it was whatever the case was, but then like you started to see eventually companies go, Oh, we're moving back to my SQL. 176 00:25:04,700 --> 00:25:05,700 Postgres is great. 177 00:25:05,700 --> 00:25:07,700 And it was like, so I'm curious. 178 00:25:07,700 --> 00:25:08,700 Yeah. 179 00:25:08,700 --> 00:25:10,700 I think that's, it's like, yeah. 180 00:25:10,700 --> 00:25:22,700 Like, what does that balance or like, or have you seen, frankly, companies chasing these trends because it seems like the right thing to do, but like, you know, it's ultimately maybe it's not, or, you know, you get the point. 181 00:25:22,700 --> 00:25:23,700 Oh, absolutely. 182 00:25:23,700 --> 00:25:24,700 Absolutely. 183 00:25:24,700 --> 00:25:27,700 You know, it's, we certainly have seen that in the Hadoop world. 184 00:25:27,700 --> 00:25:36,700 You know, Hadoop was the shiny toy for years and everyone was talking about, Oh, I'm going to do ELT. 185 00:25:36,700 --> 00:25:38,700 I'm going to extract land and transform. 186 00:25:38,700 --> 00:25:44,700 I'm going to take all of the data that I have, whether it's corporate data systems or IOT data, or where I'm going to put it all in Hadoop. 187 00:25:44,700 --> 00:25:47,700 And then I'm going to transform it and it's going to be magic. 188 00:25:47,700 --> 00:25:52,700 And I'm going to have all of the answers to every business question I ever wanted to ask by, by querying Hadoop. 189 00:25:52,700 --> 00:26:03,700 And that concept was an interesting, you know, it was a good, good concept, but the reality was that was really hard to do. 190 00:26:03,700 --> 00:26:05,700 Hadoop's really hard to manage. 191 00:26:05,700 --> 00:26:08,700 Hadoop's a great place to land information. 192 00:26:08,700 --> 00:26:12,700 It's not necessarily the great place to access information from. 193 00:26:12,700 --> 00:26:22,700 And so customers, you know, and companies learned over time, what you could do with Hadoop, what was, what was efficient with Hadoop and, and then what wasn't so efficient. 194 00:26:22,700 --> 00:26:32,700 And sometimes they learn very painfully because they made a, they jumped, you know, into the pool without really looking first and, or they, they conceptually understood it. 195 00:26:32,700 --> 00:26:43,700 But practically there was issues with how fast they could access small bits of information, for example, or they would be doing big transformations that would slow down other aspects that they needed to be performant. 196 00:26:43,700 --> 00:26:48,700 Or it just wasn't flexible enough to give them the information the way they needed it. 197 00:26:48,700 --> 00:26:57,700 So customers have, have looked at Hadoop and some have moved and backed away from using Hadoop for everything to solve all of their data problems. 198 00:26:57,700 --> 00:27:02,700 No SQL was, it was another great example of, Hey, let's put everything into no SQL. 199 00:27:02,700 --> 00:27:04,700 Cause I'm going to get really fast access. 200 00:27:04,700 --> 00:27:13,700 But then they realized the ad hoc access to a no SQL database is maybe not as robust as they were. 201 00:27:13,700 --> 00:27:31,700 They were used to with their Postgres system or their, my SQL system, or, you know, the, something that has a more fully formed and, and mature SQL interface to connect to Tableau or Cognos or, or your reporting application of choice. 202 00:27:31,700 --> 00:27:36,700 And so there's a, you know, there's the, the old right tool for the right job concept. 203 00:27:36,700 --> 00:27:48,700 You know, let's make sure we understand your requirements and then we can talk about the technology to best fit what you're trying to accomplish for today, as well as try to help you be a little bit future proof for moving forward. 204 00:27:48,700 --> 00:27:57,700 Are you seeing any specific trends now, either in how customers are approaching their data or maybe specific technologies? 205 00:27:57,700 --> 00:28:01,700 Well, the, the shiny toy for the last few years is Kafka. 206 00:28:01,700 --> 00:28:04,700 You know, everybody, everybody wants to use Kafka and talk about Kafka. 207 00:28:04,700 --> 00:28:15,700 And, and, you know, I view that as it's a fantastic tool and let's make sure it is the right tool for the right choice. 208 00:28:15,700 --> 00:28:25,700 The, we have, obviously we have our own RabbitMQ messaging system, which is fantastic and has an incredible value itself. 209 00:28:25,700 --> 00:28:27,700 Kafka brings a different set of value. 210 00:28:27,700 --> 00:28:33,700 And so when our customers are talking about messaging and eventing, you know, we, we go back to what are your requirements? 211 00:28:33,700 --> 00:28:41,700 Not only for the messaging side of it, but your data storage side of it, your data query side of it, your performance side of it, your recovery, your operationalization. 212 00:28:41,700 --> 00:28:51,700 We, you know, we want to make sure we understand the customer's complete requirements before we go recommend, you know, Kafka over Rabbit or vice versa. 213 00:28:51,700 --> 00:29:06,700 And I mean, more generally, how have you seen, I'm curious how you've seen the, the, the, the space evolve over the past, you know, you can maybe, you could even start, maybe, maybe the point is like from when, you know, from the, from, you know, the last decade or so, right. 214 00:29:06,700 --> 00:29:21,700 Cause I think there's been a lot of shifts, especially during that time for, but I'm curious how, you know, like how data systems look, you know, if you're looking at a data system from 20, from 2005 or 2010 versus today, like what generally speaking is, is it, are there, are there, are there shifts that we, that we've seen happen? 215 00:29:21,700 --> 00:29:40,700 I think, you know, some of the big trends and shifts that we're seeing have certainly have to do with, you know, the, the types of technologies and the shiny toy aspect of things. 216 00:29:40,700 --> 00:29:54,700 But they also have to do with, you know, and skipping Hadoop and, and those SQL, which we've kind of already covered, but they also have to do with how data systems are being used and managed. 217 00:29:54,700 --> 00:30:10,700 So I think there is a huge shift away from big, expensive data centers where you put all of your data and your, all of your data is managed locally there in that data center. 218 00:30:10,700 --> 00:30:30,700 And you have lots of DBAs managing those data systems where people are more open to the idea of, I may use smaller purpose built data systems that don't necessarily have to live in the data center today. 219 00:30:30,700 --> 00:30:37,700 Like they might live in the cloud or they might live more locally to where my applications are being used. 220 00:30:37,700 --> 00:30:54,700 So there's the decentralization of data that is pushing the advent of now I need to message between my systems to make sure I move the data to, or I have access to the data across systems. 221 00:30:54,700 --> 00:31:01,700 So there's a, there's an aspect of decentralization, but there's also an aspect of the management of those systems. 222 00:31:01,700 --> 00:31:07,700 There's a big push to go toward lighter weight management of data systems. 223 00:31:07,700 --> 00:31:23,700 And that may be, you know, obviously something, some huge percentage of, of, of all of AWS services are data services and customers are going that direction because they don't want to have to deal with the hardware and the networking. 224 00:31:23,700 --> 00:31:26,700 And the management of those systems. 225 00:31:26,700 --> 00:31:30,700 So it's not just the infrastructure, but it's also the management of the data systems themselves. 226 00:31:30,700 --> 00:31:32,700 They want somebody else to do that for them. 227 00:31:32,700 --> 00:31:50,700 And with, you know, with our own Tanzu data products, we're looking at how we can manage our customers' data systems, whether it's, you know, essentially our Tanzu data, data services, how we can manage that better for them. 228 00:31:50,700 --> 00:32:07,700 So how they can rely on us to, to use, provide them a single system that will deploy, manage and monitor their data systems, whether it's on VMs or on Kubernetes, and whether ultimately that is on-prem or in a cloud-based system. 229 00:32:07,700 --> 00:32:14,700 And that is, that is, that is a huge trend that we're definitely seeing over and over again and that we're actively engaging in. 230 00:32:14,700 --> 00:32:20,700 All right. Well, that seems like a, a good place to, Dan did. Kevin, thank you so much. Really, really insightful discussion. 231 00:32:20,700 --> 00:32:22,700 Thank you very much for having me. I enjoyed it.