1 00:00:00,000 --> 00:00:04,740 Welcome to another episode of Cloud and Culture. I'm Danielle Burrow from VMware. 2 00:00:05,140 --> 00:00:10,360 And I'm Derek Harris from VMware. If you're new, this podcast focuses on the process of 3 00:00:10,360 --> 00:00:16,380 application and IT modernization through the lens of Tanzu Labs, previously called Pivotal Labs. 4 00:00:16,860 --> 00:00:21,200 Over the years, Tanzu Labs experts have helped hundreds of companies and organizations, big and 5 00:00:21,200 --> 00:00:26,300 small, build better software and adopt modern development practices. The tradition carries 6 00:00:26,300 --> 00:00:31,140 on today as Tanzu Labs experts help clients get up to speed with cloud-native computing 7 00:00:31,140 --> 00:00:34,240 and the flexibility and resiliency it provides. 8 00:00:35,060 --> 00:00:39,860 Our guests for this episode are Adam Bull and Felicia Schwartz, who explain the idea of 9 00:00:39,860 --> 00:00:45,540 landing zones for application modernization. Essentially, how to decide whether an application 10 00:00:45,540 --> 00:00:49,720 should live on-prem or in which public cloud and on what type of platform. 11 00:00:50,380 --> 00:00:55,480 So stick around and hear how Adam and Felicia help enterprises approach this important decision. 12 00:00:57,040 --> 00:01:01,980 So Adam, Felicia, it's so great to have you here. Adam, why don't you go ahead and introduce 13 00:01:01,980 --> 00:01:05,340 yourself first? And then Felicia, please introduce yourself as well. 14 00:01:06,000 --> 00:01:11,900 Sure. Thank you, Danielle. So my name is Adam Bull. I'm a multi-cloud architect within VMware. So 15 00:01:11,900 --> 00:01:18,100 I work with some of our largest customers. I'm based in the UK, but I cover all of the EMEA region. 16 00:01:18,100 --> 00:01:24,980 And I generally work with customers who are looking to implement multiple cloud solutions into their 17 00:01:24,980 --> 00:01:32,760 overall enterprise architecture and looking to see how VMware technology can enable that from a consistent 18 00:01:32,760 --> 00:01:37,320 infrastructure, consistent operations perspective within their overall IT strategy. 19 00:01:37,560 --> 00:01:44,960 And hi, everybody. I'm Felicia Schwartz. I am a director of application services, and I help clients 20 00:01:44,960 --> 00:01:52,380 take their existing and new applications and help them architect it and use the right tools to maximize 21 00:01:52,380 --> 00:01:58,460 the value of what the cloud can offer them so that they could solve business problems and be responsive 22 00:01:58,460 --> 00:02:00,520 and have the performance they want in their applications. 23 00:02:01,520 --> 00:02:04,860 Great. Well, it's so great to have you both. And Felicia, it's great to have you back. 24 00:02:05,740 --> 00:02:12,320 So when we spoke with you last, Felicia, we were talking a lot about prioritizing application 25 00:02:12,320 --> 00:02:16,960 modernization and how to assess your portfolio and really make those tough decisions around 26 00:02:16,960 --> 00:02:23,060 prioritization. And this is intended to be kind of a follow-on conversation, thinking about 27 00:02:23,060 --> 00:02:30,280 where you're actually going to put those applications. Most enterprises have many different 28 00:02:30,280 --> 00:02:36,540 kind of landing zones, so to speak, of different kinds of infrastructure, different kinds of platforms 29 00:02:36,540 --> 00:02:43,320 where they could put those applications that they're wanting to move into cloud. And so we wanted to 30 00:02:43,320 --> 00:02:49,740 kind of maybe first start off by just defining, like, what do we mean when we talk about a landing 31 00:02:49,740 --> 00:02:54,360 zone for an app? Maybe, Adam, is that something you could help us define? 32 00:02:55,040 --> 00:03:02,180 Yes. I think this is almost sort of multifaceted in most of the customers that I deal with. Obviously, 33 00:03:02,300 --> 00:03:10,620 the large public cloud providers have defined out what they see as a secure landing zone on their 34 00:03:10,620 --> 00:03:16,860 specific platform. And when I spoke to some of my customers about this, it's generally seen as, 35 00:03:16,900 --> 00:03:23,400 you know, public cloud of old was almost like this open playground, right? You know, you've got all the 36 00:03:23,400 --> 00:03:29,140 swings and the slides and you've got all the climbing frames and everything, and it's just let the kids 37 00:03:29,140 --> 00:03:36,200 in and let them go crazy. And then when the kids started to fall over and bang their heads and so forth, 38 00:03:36,200 --> 00:03:42,820 they realized, actually, we need some controls around this, right? We need to, you know, put some safety in place. 39 00:03:42,940 --> 00:03:48,120 We need to put some security in place. Maybe we need some monitoring in place and so forth. 40 00:03:48,480 --> 00:03:53,140 And that's where I think, you know, the major, you know, landing zone terminology has come from. 41 00:03:53,240 --> 00:03:56,840 Let's put some guardrails around these offerings. 42 00:03:57,480 --> 00:04:04,120 But I think, you know, for the majority of the customers that I deal with, they're looking at that as kind of like the baseline. 43 00:04:04,120 --> 00:04:10,600 And then they're trying to apply their security model on top of that in terms of what sits into their 44 00:04:10,600 --> 00:04:17,580 organizational security. And, you know, I'm thinking, you know, sort of financial services who may look at sort of, 45 00:04:17,640 --> 00:04:22,240 you know, what does this mean for their overall enterprise networking architecture? 46 00:04:22,240 --> 00:04:26,120 What does it mean for their operational tooling and so forth? 47 00:04:26,120 --> 00:04:33,700 Do they need to care about the underlying hypervisor technology that's being used in these cloud providers? 48 00:04:33,920 --> 00:04:39,260 Is the application abstracted or away from that in terms of modern application technologies? 49 00:04:40,160 --> 00:04:47,260 What native services in those cloud offerings are they going to allow their internal customers to utilize? 50 00:04:47,840 --> 00:04:56,300 I've worked with one large financial services customer here in Europe who, you know, up until about a year ago, 51 00:04:56,440 --> 00:05:03,880 was only allowing within their landing zones, I think it was about five native cloud services to actually be consumed. 52 00:05:04,240 --> 00:05:07,880 They were looking to open that up to about 50 going forward. 53 00:05:08,340 --> 00:05:10,880 So there's things like that that people are concerned about. 54 00:05:10,880 --> 00:05:17,060 And then there's another element which I think sometimes gets overlooked, but shouldn't be overlooked at all. 55 00:05:17,480 --> 00:05:19,200 And that's where's the data? 56 00:05:19,640 --> 00:05:31,160 Because the old cliche of data has gravity, I think is no more, it's completely apparent now when you start looking at multiple cloud offerings 57 00:05:31,160 --> 00:05:35,300 or you're looking to make a choice around what that landing zone is going to be. 58 00:05:36,300 --> 00:05:41,900 Because there is a, I often refer to it as a land grab of data, right? 59 00:05:41,920 --> 00:05:52,180 To get data to a specific cloud platform, knowing that that data gravity cliche, if you will, will draw in the applications to that particular platform. 60 00:05:52,300 --> 00:05:57,240 So that's kind of how I think about some of the choices around landing zones. 61 00:05:57,300 --> 00:06:02,500 It's almost a separate layers in a cake, if you will, around what your choices are going to be. 62 00:06:02,580 --> 00:06:06,560 Can we dive in around data for a second, data gravity? 63 00:06:06,720 --> 00:06:11,080 Because that is and always has been, I think, a difficult problem to address, right? 64 00:06:11,160 --> 00:06:16,560 Like you mentioned, I mean, there's like data is in a place and it's hard to move, you know, 65 00:06:16,560 --> 00:06:21,000 especially if you have a lot of mountains of data or something, it's hard to make that ship necessarily. 66 00:06:21,360 --> 00:06:26,560 So how do you, or how do clients approach that situation when like they want to go to the public cloud, 67 00:06:26,620 --> 00:06:30,720 but they have, you know, whatever, like, you know, all the data is on-prem, for example, right? 68 00:06:30,720 --> 00:06:33,140 I mean, how do you even begin to make that migration? 69 00:06:33,220 --> 00:06:37,000 Or is it like using that hard drive, like they ship the hard drive to the cloud provider? 70 00:06:37,680 --> 00:06:44,300 Yeah, well, I guess that's sort of like, that's the, you know, one way of moving the data is one part of the conversation. 71 00:06:44,300 --> 00:06:52,140 But then I think there's another piece around that there's a lot of attraction from public cloud providers to, you know, 72 00:06:52,140 --> 00:06:58,080 hey, bring your systems of record, you know, bring your critical business applications, 73 00:06:58,420 --> 00:07:03,620 bring the databases and the data warehouses that are core to running your business, 74 00:07:03,980 --> 00:07:07,600 bring them to our cloud provider or our cloud platform, sorry, 75 00:07:07,600 --> 00:07:13,000 because, you know, we can run it here and we'll make it, you know, cost effective to bring it here 76 00:07:13,000 --> 00:07:18,980 and we'll take away all that, you know, operational concern and maintenance of underlying infrastructure that you have 77 00:07:18,980 --> 00:07:21,300 and, you know, just bring those workloads here. 78 00:07:21,600 --> 00:07:25,500 Oh, and by the way, you know, when you're looking at your, you know, modern applications 79 00:07:25,500 --> 00:07:33,320 or you're looking at implementing IoT solutions, we'll suck all that data into our public cloud solution as well. 80 00:07:33,440 --> 00:07:38,640 And, you know, oh, and by the way, you're using some, some productivity tool in that, that's in our cloud. 81 00:07:38,640 --> 00:07:46,880 And by, by now, you've got kind of like a convergence of, of data, of users, they're all in one place. 82 00:07:46,880 --> 00:07:50,920 It makes sense to bring the applications to that, to that location as well. 83 00:07:50,920 --> 00:07:57,760 And, and yeah, I don't, you know, we can, you know, there's obviously solutions for, for caching certain data workloads and so forth. 84 00:07:57,760 --> 00:08:02,960 But ultimately you're, you're dealing with a, a law of physics issue at the, at the end of the day. 85 00:08:02,960 --> 00:08:12,960 You know, does it make sense to run a certain application workloads, you know, you know, potentially hundreds of miles away from, from another cloud provider that's hosting the data and so forth. 86 00:08:12,960 --> 00:08:28,800 So I think that the, you know, customers need to think just as much, if not more around what is the strategy for their data going forward, because that's ultimately going to pull in their application migration strategy as well, along with it for the ride. 87 00:08:29,680 --> 00:08:40,400 Yes. I'm sorry. And I was taking a very oversimplistic view of gravity. I was like the gravity that makes it hard to move, not the one that attracted force. Right. So yeah, that makes perfect sense as well. 88 00:08:40,400 --> 00:08:49,680 And in addition to what Adam was saying was, we also find that maybe the way the applications are using data today is not the way it should be moving forward. 89 00:08:49,680 --> 00:08:58,640 Like we find a lot of concern or caution about doing a big lift and shift of data because it's, it, then you have to deal with the applications. 90 00:08:58,960 --> 00:09:14,560 So there's also times for specific applications, like maybe we need to think of the data for the application, what it's going to be using and maybe put the data closer to the application that moves to the cloud, keep the big data lake or the data warehouse where it is. 91 00:09:14,560 --> 00:09:25,140 And then you have like continuous, there's replication of data, but more building into a model of domain driven design where you don't necessarily have to keep the data the way it is today. 92 00:09:25,380 --> 00:09:37,900 There's a new way of thinking about architecting your applications to help expedite your mission to move to the cloud for your applications without having to worry that like I've got thousands of applications that use this data. 93 00:09:37,900 --> 00:09:42,180 What's the impact of I move everything over to the cloud from the data side? 94 00:09:43,080 --> 00:09:44,360 Yeah, that makes a lot of sense. 95 00:09:44,580 --> 00:09:49,840 We're actually going to be talking to one of our data transformation experts in an upcoming episode. 96 00:09:49,840 --> 00:09:55,440 So that'll be a really nice follow-on conversation to this because data is such a major consideration. 97 00:09:55,920 --> 00:09:56,460 So great. 98 00:09:56,740 --> 00:10:02,980 Thanks for going over the security and the data piece because those are really significant considerations. 99 00:10:02,980 --> 00:10:12,880 And I'm wondering, you know, what are some of the other considerations that makes choosing a landing zone for your apps so difficult? 100 00:10:13,120 --> 00:10:15,140 I mean, it sounds like there are so many variables. 101 00:10:15,720 --> 00:10:18,100 What are some of the ones that people get really stuck on? 102 00:10:18,640 --> 00:10:33,740 So I think when customers that I work with are looking to move workloads to the cloud, there's usually, you know, it's usually not a technical blocker per se. 103 00:10:34,080 --> 00:10:38,500 There can be elements of commercial agreements in as well. 104 00:10:38,500 --> 00:10:50,880 So, you know, I've worked with customers that will say, you know, look, we've got certain commercial agreements with certain public cloud providers or because of the industry sector that we're in, we get certain discounts. 105 00:10:51,420 --> 00:10:58,140 And basically, it becomes favorable to use a certain solution purely from a commercial reason. 106 00:10:58,660 --> 00:11:02,700 And then it just becomes a case of, well, is this good enough? 107 00:11:02,700 --> 00:11:16,700 You know, is, you know, okay, you've got some fancier things over here, perhaps, or you've got some technology that we'd like to consume, but, you know, this other one is going to be commercially more viable. 108 00:11:17,560 --> 00:11:29,100 I think from a, you know, also from a traditional application perspective as well, with a lot of these workloads being, you know, driven by, you know, licensing constraints and so forth. 109 00:11:29,100 --> 00:11:47,100 And I think we've seen this already within the public cloud providers is, you know, it will be preferential from a licensing perspective to take certain traditional workloads to a particular location because, you know, it's just easier to deal with from a licensing perspective. 110 00:11:47,560 --> 00:11:59,700 So I think some of those are some of the other real concerns that I see customers looking at as it pertains to their traditional workloads at the moment. 111 00:12:00,660 --> 00:12:10,140 Adam, can I ask when, again, like when you're trying to choose, is it, I mean, do you have a sense of like just, you know, percentage of customers or clients who you're working with? 112 00:12:10,140 --> 00:12:20,660 Like, is it automatically a move to the public cloud or, I mean, like, are there still a lot of companies, you know, still deciding that, okay, the landing's over, this still is a private data center? 113 00:12:21,340 --> 00:12:30,360 And it's just a matter of like, what is it, but how do we modernize that, that data center to make it more, you know, more apt host for our applications? 114 00:12:31,240 --> 00:12:43,400 Yeah, I think there's more of a realization now that, you know, it's not just, you know, public cloud is the answer, what is the question, which I think has certainly been the case for a while. 115 00:12:43,400 --> 00:12:49,900 I think there's becoming a more pragmatic view to the overall IT infrastructure estate, right? 116 00:12:49,980 --> 00:12:56,800 People are realizing that, you know, actually it can be cost effective to run workloads on-prem. 117 00:12:57,040 --> 00:13:05,780 You know, there may be compliance reasons, there may be data locality reasons that just make it preferable to run workloads on-prem. 118 00:13:05,780 --> 00:13:29,620 You know, moving everything that you have at the moment that runs in a, you know, quote-unquote monolithic state and moving that and refactoring or even just replatforming what you have to a different infrastructure provider or a different hypervisor provider is fought with all kinds of risk and delays. 119 00:13:29,620 --> 00:13:40,720 And it generally, for the majority of customers that I work with, they can potentially get down into, you know, single-digit application migrations a year. 120 00:13:40,980 --> 00:13:50,980 You know, that can happen, especially in large organizations who are looking to exit out of data centers, hosting, you know, tens of thousands of workloads, potentially. 121 00:13:50,980 --> 00:14:09,560 And then, you know, customers, they will be in situations where, right, we need to close down a data center, you know, we need to get these workloads out of this location, or we need to exit out of a hosting provider for any number of reasons, and we need to do that quickly. 122 00:14:09,560 --> 00:14:38,400 What's the best way to do that, and I think VMware is in sort of a perfect position to be able to offer customers a consistent infrastructure experience for those modern, sorry, for those traditional applications to be able to move quickly, but then also provide options in terms of, right, what do you want to do once you've, you know, got your workloads settled into a location that you're happy to support going forward? 123 00:14:38,400 --> 00:15:04,540 Do you, you know, take that application and, say, modernize certain parts of it that make sense to modernize and perhaps leave other parts of it where, you know, there may not be any business value or justification or, you know, you just can't build the business case around modernizing that part of the application because, you know, the net result out the back of it is it does exactly the same as what it did before. 124 00:15:04,540 --> 00:15:19,220 But, you know, you know, just with, you know, six to 12 months worth of effort and, you know, potentially, you know, a lot of money thrown out at the problem, but, you know, you've now got options in terms of what you want to do, you know, do you want to modernize certain parts of that application? 125 00:15:19,220 --> 00:15:26,800 Or do you want to integrate parts of that application with the native cloud offerings? 126 00:15:26,900 --> 00:15:34,020 And I would refer to that as solutions that are only available from the public cloud in an as-a-service model. 127 00:15:34,360 --> 00:15:46,960 So I think there's a number of different decision points around what customers do with those applications when they're looking to consume public cloud or, you know, run them in their on-premise infrastructure. 128 00:15:49,580 --> 00:16:00,580 Felicia, do you see any patterns around that with those decisions about public cloud and kind of based, you know, the business criteria and the business value piece of the decision? 129 00:16:01,080 --> 00:16:09,600 Absolutely, which is why we work together with, like, the infrastructure, what we're calling the landing zones, with the business value of the applications. 130 00:16:10,260 --> 00:16:19,160 And exactly what Adam said, the more critical an application is to the business, the more frequently it needs to be responsive to business changes. 131 00:16:19,320 --> 00:16:25,000 That's going to be heavy in the decision of what to do with the app when you migrate it. 132 00:16:25,540 --> 00:16:32,820 We found a lot of these legacy applications that have many, many pieces of functionality incorporated in it. 133 00:16:33,180 --> 00:16:38,220 Not all of them are going to be changed and need to be as resilient and need some of the capabilities. 134 00:16:38,880 --> 00:16:48,280 So with the move to it, we also say we need to decompose it a bit or we need to improve the performance on this so that it can, you know, just being in the cloud. 135 00:16:48,560 --> 00:16:59,280 You know, we've said before to a lot of our customers, moving it to the cloud, if it's not properly architected and it takes 10 minutes to start up, that's not going to get better. 136 00:16:59,280 --> 00:17:06,420 You may have infrastructure savings and speed from an infrastructure perspective, but you also need to make sure you can solve your business. 137 00:17:06,780 --> 00:17:19,780 So I think, you know, from Adam's lens and the application lens, we always have to look at business value of our applications when making the decision for what to do with an application and where the application needs to reside. 138 00:17:21,140 --> 00:17:30,380 I want to go back to something too, Adam, that you mentioned a couple of questions ago, just talking about the commercial reasons for maybe moving to a different platform versus necessarily the technical ones. 139 00:17:30,940 --> 00:17:38,900 And I think, I mean, yeah, especially as you've heard that discussion pop up before, like, well, we know this company really well, so this probably, and we have a contract in place, it might make sense. 140 00:17:38,900 --> 00:17:44,740 But, like, how do you overcome, like, I'm curious, like, what does good enough mean, right? 141 00:17:44,780 --> 00:17:52,660 And are there ways that you can overcome some of those technical limitations with clever architecture or third-party tooling or whatever the case might be? 142 00:17:53,420 --> 00:18:01,120 Yeah, I tend to think once we're into that sort of level of conversation, you know, we're not into a technical decision. 143 00:18:01,120 --> 00:18:11,680 We're into a, you know, there is a specific commercial business reason why customers are looking to choose that particular cloud provider, right? 144 00:18:11,760 --> 00:18:24,220 Because, you know, and in my experience, it's quite tricky to overcome that with technology, you know, if there is, you know, a bottom line decision to move to one particular cloud provider, 145 00:18:24,220 --> 00:18:36,140 because there are, you know, credits that have been already purchased and yet to be consumed, or there's a, you know, an ongoing benefit from a discount or from a licensing perspective, 146 00:18:36,740 --> 00:18:47,500 in my experience, that's a tricky one to overcome from a technology-only standpoint, would be my answer there. 147 00:18:48,860 --> 00:18:55,560 Yeah, and I was just thinking, too, I wonder, how much does maturity model factor into some of these decisions? 148 00:18:56,180 --> 00:19:06,260 Like, you know, how skilled a development team is, whether it makes sense for them to have something on a PAS or something on, you know, 149 00:19:06,260 --> 00:19:11,940 something that's a little bit trickier, where they're being asked to, you know, maybe move to the left, so to speak, 150 00:19:11,940 --> 00:19:16,720 and take on some of the more kind of traditional infrastructure responsibilities. 151 00:19:17,040 --> 00:19:21,740 Does that ever come into the conversation when, you know, choosing landing zones? 152 00:19:23,320 --> 00:19:31,800 Yeah, I think from my experience with customers, there's always organic growth somewhere in the infrastructure. 153 00:19:32,160 --> 00:19:39,300 You know, a customer will be, you know, there'll be on-premise infrastructure nine times out of ten, given who we're speaking to. 154 00:19:39,520 --> 00:19:46,000 There will be, you know, something happening in cloud A, but then there's always that conversation, 155 00:19:46,000 --> 00:19:49,120 and this is where sort of my multi-cloud role comes in. 156 00:19:49,340 --> 00:19:56,960 There'll be something that happened over here because of some, you know, some development team that went off and created something. 157 00:19:57,600 --> 00:20:00,180 And, of course, we used to refer to that as shadow IT. 158 00:20:01,040 --> 00:20:05,280 Shadow IT doesn't seem to be, you know, a term that I hear too much anymore. 159 00:20:05,280 --> 00:20:11,520 It just seems to be, well, that's happened, and there's some stuff over there, and that's now running in production, essentially. 160 00:20:11,840 --> 00:20:30,840 So, I think there's an element where just that ease of consumption needs to be there because, in my experience, working with, you know, developers and so forth, you know, the path of least resistance from an infrastructure perspective always takes precedence, right? 161 00:20:30,840 --> 00:20:52,500 You know, if you can just hit the easy button and get what you want, and that's why public clouds, you know, that's why so much money is spent with public clouds because that you can just next, next, finish, and boom, I've got a PaaS solution, boom, I've got, you know, my web hosting platform, I've got everything that I need, and I managed to do it without having to exit my tool chain that I have. 162 00:20:52,500 --> 00:21:20,680 So, I think that that path of least resistance, you know, fits into play, I think from an infrastructure provisioning and operation perspective, you know, we need to, you know, be able to offer solutions to customers that just mean the path of least resistance is utilizing the technology tool chain that ultimately gives them everything they need from a business and IT strategic direction perspective. 163 00:21:22,080 --> 00:21:29,620 All right, yeah, and to your earlier point about security, too, I'm guessing we want the path of least resistance to be, like, secure and all that, too, right? 164 00:21:29,660 --> 00:21:39,640 I think, because, I mean, the shadow IT thing to me sounds, when I think shadow IT, I think path of least resistance, but not necessarily path that has been vetted or approved or otherwise signed off on. 165 00:21:40,060 --> 00:21:51,660 Yeah, and I think that comes back to that sort of point, the analogy I made earlier of the, you know, here's the playground and here's all the toys and, you know, but now, actually, no, we need some security, we need some governance, we need some 166 00:21:51,660 --> 00:21:56,520 operational oversight here because things can get scary very, very quickly. 167 00:21:56,840 --> 00:22:21,240 Do you have a sense of the, do you guys see, like, Felicia and Adam, do you see customers running, I mean, by default, maybe, I mean, you're talking about multi-cloud, and obviously, I think the idea of, like, I mean, applications spanning multiple clouds or bursting or things are kind of weird, you know, maybe, maybe not super realistic in most cases, but, like, I mean, do a lot of companies have, like, you know, private data center, Amazon, Google, Microsoft, like, locations everywhere, just because certain 168 00:22:21,240 --> 00:22:28,680 teams work on certain platforms or prefer to work or need to work on certain platforms, is that a common way of doing multi-cloud? 169 00:22:29,100 --> 00:22:46,280 So, I guess, from my perspective, I tend to see, you know, applications as a whole, as a whole unit staying together, and I tend to see them staying in specific geographical locations for compliance reasons. 170 00:22:46,280 --> 00:22:59,920 I mean, I mean, I'm, that may just be, you know, any mere perspective on things, because, you know, obviously, things need to, need to stay in specific geographical locations from, from a country perspective, but that's really what, what I'm seeing at the moment. 171 00:22:59,920 --> 00:23:12,120 So, people are really looking at, how can I, how can I move these workloads to a specific cloud landing zone, but I don't want to overly create complexity just for the sake of creating complexity. 172 00:23:12,520 --> 00:23:20,560 You know, I could potentially run all these, these component parts in, in different locations, but do I really want to do that from, from a single application perspective? 173 00:23:20,960 --> 00:23:34,580 Chances are, I just want to take that workload to a, you know, a specific location, I want it to run in that particular region, or that, you know, certain, you know, data center infrastructure, call that, you know, full domain, or availability zone, or whatever you will. 174 00:23:34,920 --> 00:23:37,400 But that's, that's really what I'm tending to see at the moment. 175 00:23:39,960 --> 00:23:49,500 From the application, what I found, and I, and I think Adam spends more time with, in those conversations, but what we found is, people will go to the public clouds for the ease. 176 00:23:49,500 --> 00:23:58,820 And I think it's dead on, like, simplicity, easy start, but then, they'll do that, and a developer may start, or a team of developers that, you know, support a couple of applications. 177 00:23:59,360 --> 00:24:04,760 They'll go to a public cloud to do their development work, and we'll see, wow, this was so fast. 178 00:24:05,280 --> 00:24:11,560 And then, it becomes more popular, then the strategy of what should we be doing comes into play. 179 00:24:11,560 --> 00:24:21,660 And I do have, I'm involved in a lot of conversations now, where they're trying to make those decisions, to have multi-cloud, and they want to go with multiple public, as well as some on-prem. 180 00:24:21,980 --> 00:24:28,100 So, I think that, I found that hasn't historically been the first step into the public cloud. 181 00:24:28,300 --> 00:24:31,420 It's more of, a developer wants to go out there and start doing stuff. 182 00:24:31,860 --> 00:24:42,260 But once it becomes, it's become more now, like, standard, you're finding a little bit more strategic, taking into consideration all the things Adam mentioned about where do these apps need to run? 183 00:24:42,380 --> 00:24:47,720 Are there any legal issues about where things are run, data, compliance issues, et cetera, et cetera? 184 00:24:48,940 --> 00:25:04,760 Yeah, and also, to add to that point, I mean, one thing that I see quite common, or becoming more and more common, is, okay, I will consume workloads, or run my workloads in this particular cloud provider, but what's my exit strategy? 185 00:25:05,020 --> 00:25:08,460 What happens if I need to get out of that cloud provider? 186 00:25:08,460 --> 00:25:15,460 Yeah, I may not have a reason at the moment, but who's to say what will happen in 5, 10, 15 years' time? 187 00:25:16,060 --> 00:25:28,000 Do I have a plan to get out of that cloud provider, or am I consuming services, or have my development and infrastructure team consume services that mean that I'm ultimately locked into that location? 188 00:25:28,540 --> 00:25:31,440 And that, as well, comes back to that whole data locality piece, right? 189 00:25:31,440 --> 00:25:36,400 If I've put all of my data in one cloud provider, that's a point of lock-in. 190 00:25:36,400 --> 00:25:41,940 If I've consumed some particular PaaS service that's only native to that cloud provider, I'm locked in there. 191 00:25:42,320 --> 00:25:48,760 If I'm consuming other services that are only available there, that's an anchor point for all of these workloads. 192 00:25:49,020 --> 00:25:55,520 So I think a lot of customers, and perhaps I have a bias to this, because there's a number of financial services customers that I work with. 193 00:25:55,780 --> 00:26:19,400 They're looking at how can I consume this infrastructure, how can I get the best out of this infrastructure, create those paths of least resistance to make sure that I have that agility, and I'm able to get the applications provisioned and running and performing best for my business, but also be able to get out of that cloud provider or move to another cloud provider if I need to. 194 00:26:19,400 --> 00:26:26,840 So for, you know, we've already touched on some commercial reasons, but there may be regulatory reasons. 195 00:26:27,260 --> 00:26:39,020 You know, there's a number of reasons that mean, you know, customers are looking to see, right, where can I just consume all this workload, but still have that mobility going forward if I should need to. 196 00:26:39,100 --> 00:26:49,380 And I have the same thing. Vendor lock-in is a big concern because of the ease to move, and people don't want to necessarily, customers don't want to necessarily be tied just to one vendor. 197 00:26:49,680 --> 00:26:56,600 But I think that's, it's still an issue in a conversation about how do you get the value from a vendor without that lock-in. 198 00:26:57,680 --> 00:27:02,780 And I think there's also another element, I'm just kind of thinking of other things that are coming to mind as we discuss this. 199 00:27:02,780 --> 00:27:11,820 But, you know, operationally, how do you, you know, getting to work close to the cloud is one thing, but how do you operationalize that going forward? 200 00:27:11,940 --> 00:27:25,800 If I've got, you know, if I'm, say, consuming, let's say I'm consuming on-premise infrastructure and two public cloud providers, okay, how do I manage that as a single unit of compute network and storage with additional services on top of it? 201 00:27:25,800 --> 00:27:42,080 You know, am I operating different security models? Do I have, you know, a different compute infrastructure? Do I need different teams skilled with different technologies to maintain and operate this and secure this overall cloud platform, if you will? 202 00:27:42,360 --> 00:27:51,620 There's a number of things that kind of need to be thought about when you're looking to consume all of this different, disparate infrastructure across different providers. 203 00:27:53,620 --> 00:28:06,660 Yeah, and I'm wondering, you know, when you think about all these different considerations, what's your sense of how important the infrastructure piece is compared to, like, the abstraction layer? 204 00:28:07,220 --> 00:28:16,020 So, you know, thinking about an IaaS or using VMs versus containers, and then, you know, all the layers on top of that. 205 00:28:16,020 --> 00:28:27,280 How, it seems like it's just going to add, you know, there's just so many more options, but is there a way you kind of, you know, break these considerations down? 206 00:28:28,640 --> 00:28:39,500 Yeah, I think from my experience, it always makes me laugh because it feels like in IT, we're always searching for that single pane of glass. 207 00:28:39,500 --> 00:28:42,200 Yes, it's like the carrot on the end of the stick, right? 208 00:28:42,200 --> 00:28:43,340 We're always chasing that. 209 00:28:43,340 --> 00:28:50,980 If I could just abstract myself to this point, I would be able to manage everything without having to care about the underlying infrastructure. 210 00:28:51,420 --> 00:29:01,660 But I think that there's elements where, obviously, there's certain workload types that are going to be highly tied to a specific infrastructure point, okay? 211 00:29:01,660 --> 00:29:17,580 And I think that's where, you know, if we take into consideration some of the, you know, the SaaS methodology in terms of, you know, do I sort of re-host or re-platform these workloads, there are things to be considered there and so forth. 212 00:29:17,580 --> 00:29:31,820 And then, you know, as you become more and more abstracted and obviously you're less tied to the underlying infrastructure, then you have that ability to say, you know, decommission that workload there, but spin it up very quickly somewhere else. 213 00:29:31,960 --> 00:29:41,740 But then, you know, I don't think that really gets you away from some of the underlying, you know, infrastructure that is going to be required to host that workload. 214 00:29:41,740 --> 00:29:50,460 So there is going to be, you know, security you're going to have to think about, you're going to have to think about storage and, you know, we've touched on data gravity a number of times. 215 00:29:50,460 --> 00:30:07,120 There's a few things that I think these needs to be thought about, but yeah, as you get more abstracted away, you have a few more choices there, assuming that you're going to, you know, refactor and modernize all of your application estate, which is something from my perspective. 216 00:30:08,120 --> 00:30:15,040 I don't see customers looking wholesale to refactor absolutely everything that they have. 217 00:30:15,040 --> 00:30:33,120 You know, I've quite often said that I don't believe that, you know, containers and Kubernetes as an infrastructure solution is going to fully replace every virtual machine that's out there in the same way that virtual machines have not replaced physical x86 hardware hosted workloads. 218 00:30:33,300 --> 00:30:46,360 I work with them with customers that will never virtualize certain workloads, and there are a lot of customers out there who, you know, are still running workloads on, you know, non x86 hardwares, and there's still plenty of mainframes out there and so forth. 219 00:30:46,360 --> 00:31:07,180 So, I think there's an element of just having a pragmatic view across the entire infrastructure estate and looking at, right, how do I best manage this portfolio of workloads that I have, you know, and some of those older, you know, older architected solutions is what's actually running the business today. 220 00:31:07,280 --> 00:31:29,960 It's not like we can, you know, it's not like we can refactor and change, you know, some of those older workloads there that are extremely important, but how do I host those going forward, and how do I take a more, as I've said, pragmatic, holistic, overall look at everything and manage it as simply as I can utilizing, you know, this disparate infrastructure that's available to me. 221 00:31:32,120 --> 00:31:52,040 Yeah, I was going to, I mean, just on that, following up on that briefly, like, because I know when the, when the pandemic first hit and unemployment systems were backed up across the country, and they were all these old COBOL apps and, and whatnot, like, I mean, is there, is there, are there, are there strategies for, you know, making a migration like that happen, or modernizing an application like that relatively quickly? 222 00:31:52,040 --> 00:32:01,260 Or are you, or is it, I mean, does that really have to be a slow, kind of long, meticulous, especially for a system like unemployment or something kind of kind of critical system like that? 223 00:32:01,300 --> 00:32:06,960 I'm just curious what the process might look like for, for trying to do something like that in a relatively short timeframe. 224 00:32:06,960 --> 00:32:17,600 I guess from the customers that I've worked with, I haven't really been exposed to a huge amount of sort of, you know, COVID related issues around that. 225 00:32:17,880 --> 00:32:20,860 But Felicia, do you have any, any on that at all? 226 00:32:21,360 --> 00:32:28,300 From, from an application perspective, historically, the mainframe COBOL, these old technologies were very hard. 227 00:32:28,300 --> 00:32:36,880 Some of the strategies that can be used, and again, it goes back to everything Adam's been saying, like, it really talks about the relevance of the applications and portfolio. 228 00:32:37,240 --> 00:32:43,880 Sometimes they'll just outsource their, their mainframes, right, to a company, and then they can get rid of that infrastructure. 229 00:32:44,320 --> 00:32:50,680 That tends to be a strategy if these applications need to keep running, but they're not, they're critical to have, 230 00:32:50,680 --> 00:32:59,700 but not necessarily changing and need to be modified similar to what was needed when COVID hit and like the unemployment systems. 231 00:33:00,360 --> 00:33:04,780 There's other approaches that over the past few years, like have come into play. 232 00:33:04,860 --> 00:33:06,580 And I know we've done a lot of work with customers. 233 00:33:06,580 --> 00:33:25,040 How do you know, we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us. 234 00:33:25,040 --> 00:33:43,040 We've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us. 235 00:33:43,040 --> 00:34:13,020 We've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, but we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us, and we've done a lot of work with us. 236 00:34:13,040 --> 00:34:21,960 more over the next few years, because companies that have these just need a quicker path than to say, I need two years or three years to rewrite this in its entirety. 237 00:34:23,680 --> 00:34:39,940 Yeah, that's actually one thing I have seen a little bit of, is customers looking at, right, we've got these mainframes, right, that they're not going anywhere anytime soon, but how do we incorporate that component into our cloud strategy? 238 00:34:39,940 --> 00:34:51,520 Do we look to, you know, host that mainframe, you know, in low, you know, single, millisecond latency distance to what's happening in our public cloud infrastructure? 239 00:34:51,800 --> 00:34:58,620 It really comes back to that option around, you know, creating that hybrid application architecture. 240 00:34:59,100 --> 00:35:07,440 Some parts of my application may be, you know, modern application components, you know, maybe part of it is hosted in containers and so forth, 241 00:35:07,440 --> 00:35:17,920 but can I bring that modern part of my application into conjunction with my, you know, traditionally virtualization hosted parts of the application, 242 00:35:17,920 --> 00:35:24,640 and is there an offload to the mainframes or dedicated physical systems of record solutions as well? 243 00:35:25,000 --> 00:35:31,600 So, again, I think it is, you know, looking at everything, as Felicia said, and, you know, I said before, 244 00:35:31,820 --> 00:35:38,940 and having a more pragmatic view rather than I'm going to, you know, do a massive big bang across my entire enterprise estate 245 00:35:38,940 --> 00:35:45,280 to get to a modern application endpoint, which, you know, may take a long time 246 00:35:45,280 --> 00:35:53,620 and could potentially offer a lower business value to do the whole thing versus, you know, parts, parts of the application 247 00:35:53,620 --> 00:35:59,600 and really modernize where it matters, I guess, is ultimately the way I look at it. 248 00:36:00,080 --> 00:36:08,420 Yeah, I'm wondering, Adam, are there, do you see kind of any common trends around organizations kind of overstating 249 00:36:08,420 --> 00:36:14,060 or maybe ignoring different benefits or even drawbacks to particular landing zones 250 00:36:14,060 --> 00:36:20,200 in a way that kind of gets them into trouble with how they're matching workloads to the landing zone? 251 00:36:20,600 --> 00:36:28,760 Yeah, I think it comes back to that thing around, so a lot of customers, customers I work with, 252 00:36:28,980 --> 00:36:40,980 they sometimes underestimate that level of refactoring or replatforming work that has to happen across their entire estate. 253 00:36:41,320 --> 00:36:50,580 Yeah, there's one customer I worked with in particular who said, you know, well, I'm going to move all my applications. 254 00:36:50,580 --> 00:36:53,560 I've got, you know, quite a few of them. 255 00:36:53,680 --> 00:36:55,260 I can't remember exactly how many there were. 256 00:36:55,740 --> 00:37:02,600 And he said, you know, I've had one of my top people migrate a single application and replatform. 257 00:37:02,720 --> 00:37:08,120 I think it was being replatformed to use some SQL PaaS solutions and some web front ends. 258 00:37:08,640 --> 00:37:15,400 And it wasn't that difficult to move that one application into that cloud-native landing zone. 259 00:37:15,400 --> 00:37:23,440 And it was a question of, you know, just using, again, I use analogies quite often to explain certain things. 260 00:37:23,620 --> 00:37:31,120 But, you know, if we think about that in terms of, you know, migrating a single family from, say, I don't know, 261 00:37:31,280 --> 00:37:36,180 that's London to Cape Town, it's the first city that comes to mind. 262 00:37:36,580 --> 00:37:39,340 Yeah, it's a fairly straightforward process. 263 00:37:39,560 --> 00:37:42,960 You know, there's things to take into consideration and so forth. 264 00:37:43,140 --> 00:37:49,120 You know, there may be things that, you know, you have to work out once you land in that landing zone, if you will. 265 00:37:49,260 --> 00:37:50,860 But it's relatively straightforward. 266 00:37:51,360 --> 00:38:00,500 But if you take an entire town and want to move the entire population of, you know, 10,000 or so to, you know, Cape Town, 267 00:38:00,640 --> 00:38:02,460 then there's a lot of things to take into account. 268 00:38:02,680 --> 00:38:07,040 The burden of administration goes up quite considerably. 269 00:38:07,640 --> 00:38:13,280 So I think that's really that comes back down to that sort of pragmatic view and really thinking about, right, 270 00:38:13,360 --> 00:38:19,060 what is the level of work of moving these workloads to this specific landing zone? 271 00:38:19,060 --> 00:38:27,360 And are there better ways for me to handle this and to handle this migration task, I guess, would be the main thing? 272 00:38:27,480 --> 00:38:36,340 Because I tend to see that a lot of customers start with sort of high hopes of transforming absolutely everything. 273 00:38:37,080 --> 00:38:41,480 And then they go through a process of trying that, realize it's quite difficult. 274 00:38:41,720 --> 00:38:43,800 They speak to application owners. 275 00:38:43,800 --> 00:38:51,380 They realize that if the application owners aren't fully up to speed with modernizing that application, 276 00:38:51,620 --> 00:38:55,580 they go through a lot of hand-holding processes around that. 277 00:38:55,820 --> 00:39:00,600 And if they've got deadlines on migrating these workloads to a specific cloud provider, 278 00:39:01,160 --> 00:39:06,100 then these transformation pieces can sometimes hinder that timeline, if you will, 279 00:39:06,140 --> 00:39:08,000 and potentially put that timeline at jeopardy. 280 00:39:08,000 --> 00:39:12,040 So if we can look at, say, as we mentioned earlier, modernize where it matters, 281 00:39:12,220 --> 00:39:19,440 modernize where the business benefit is, move the workloads as is to solutions such as VMware Cloud on AWS 282 00:39:19,440 --> 00:39:25,520 or Azure VMware Solution, our VMware Engine, and incorporate that into the landing zone strategy, 283 00:39:25,520 --> 00:39:32,680 then we can get customers to the end result that they want to get to. 284 00:39:33,260 --> 00:39:37,680 And then we can think about, right, is there additional modernization that can happen 285 00:39:37,680 --> 00:39:40,440 once we've got over that first phase of the project? 286 00:39:41,440 --> 00:39:42,100 All right. 287 00:39:42,180 --> 00:39:47,280 And I know we need to probably start wrapping up for timing reasons, but I do want to ask, 288 00:39:47,600 --> 00:39:51,240 and this kind of touches on what you just talked about as well as that early discussion about lock-in. 289 00:39:51,340 --> 00:39:58,160 And I'm curious, like, what is, like, how do you see the role or what are the most important factors oftentimes 290 00:39:58,160 --> 00:40:03,460 in determining, you know, or determining portability, I guess, or mitigating lock-in to the degree it's possible? 291 00:40:03,580 --> 00:40:07,700 Like, is it that abstraction layer like, you know, VM or VMware Cloud and AWS? 292 00:40:07,700 --> 00:40:10,560 Is it Kubernetes or some sort of orchestration layer? 293 00:40:10,640 --> 00:40:11,700 Is it using open source? 294 00:40:12,000 --> 00:40:16,240 Because theoretically, right, you can at least be sure that your components are going to run anywhere. 295 00:40:16,480 --> 00:40:24,600 Like, what is, I'm just curious what the, like, how you're seeing or how you're advising clients to take advantage of whatever portability, 296 00:40:25,020 --> 00:40:26,860 you know, options there really are? 297 00:40:27,540 --> 00:40:31,200 Yeah, I think it's, I think it comes down to a number of different cases. 298 00:40:31,500 --> 00:40:39,660 Like, I sometimes snigger a little bit when I hear the term lock-in or we want to avoid lock-in. 299 00:40:39,740 --> 00:40:42,640 And I think it's almost unavoidable to a case. 300 00:40:43,000 --> 00:40:50,660 You're going to make a decision to utilize a specific technology, whether it's proprietary technology or it's a public cloud provider 301 00:40:50,660 --> 00:40:53,800 or it's open source technology, you're locked into something. 302 00:40:53,960 --> 00:40:57,780 You're either locked into that proprietary technology or you're locked into that cloud provider. 303 00:40:57,780 --> 00:41:04,540 Or in the case of many open source solutions, you know, you could be potentially locked into a community 304 00:41:04,540 --> 00:41:10,100 or you're locked into, you know, specific contractors that you may have on-premise that know that technology. 305 00:41:10,600 --> 00:41:14,400 So lock-in, in my opinion, is almost unavoidable. 306 00:41:14,780 --> 00:41:22,340 But I think where customers can really think about this is, right, what is the breadth of where I can run that technology? 307 00:41:22,700 --> 00:41:27,420 Okay, you know, from a virtualization standpoint and those traditional workloads, 308 00:41:27,420 --> 00:41:32,180 I think VMware is in a, you know, a very good place to be able to offer customers, you know, 309 00:41:32,260 --> 00:41:34,080 you want to run your workloads on-premise? 310 00:41:34,620 --> 00:41:35,320 Sure, no problem. 311 00:41:35,500 --> 00:41:39,160 You want to run your workloads in a VMware cloud provider partner? 312 00:41:39,500 --> 00:41:40,340 Sure, no problem. 313 00:41:40,600 --> 00:41:42,620 You want to run in any of the hyperscaler clouds? 314 00:41:42,900 --> 00:41:44,380 Again, it's not a problem. 315 00:41:44,380 --> 00:41:52,040 If you've got modern applications running in containers and orchestrated by Kubernetes, obviously that can run everywhere. 316 00:41:52,280 --> 00:41:58,520 So it's really, I think, a customer needs to really think about their overall IT strategy. 317 00:41:58,780 --> 00:42:17,120 Are any of the technologies that they're looking to consume going to lock them into, you know, a specific dead end or a specific cul-de-sac of, I'm not sure if that's an American term or not, but a specific, you know, area where they're going to have to do some engineering work to back out of that choice and so forth? 318 00:42:17,120 --> 00:42:20,560 So I think it's a question of just having a look. 319 00:42:20,960 --> 00:42:24,740 What are your goals as an organization? 320 00:42:25,000 --> 00:42:28,180 What does the, you know, eventual IT strategy look like? 321 00:42:28,280 --> 00:42:32,900 You know, a few years now, it's obviously very difficult to think of anything beyond that and so forth. 322 00:42:32,900 --> 00:42:37,620 And just thinking what architecture gives you the most choices going forward. 323 00:42:39,580 --> 00:42:46,000 Well, I think that's a really great place to wrap up with those kind of final thoughts on what to think about when you're getting started. 324 00:42:46,380 --> 00:42:48,820 This has been a really great conversation, Adam and Felicia. 325 00:42:48,940 --> 00:42:50,480 Thank you so much for joining us today. 326 00:42:51,280 --> 00:42:51,940 Thank you. 327 00:42:52,360 --> 00:42:52,720 No problem.