Welcome to another episode of Cloud and Culture. I'm Danielle Burrow from VMware. And I'm Derek Harris from VMware. If you're new, this podcast focuses on the process of application and IT modernization through the lens of Tanzu Labs, previously called Pivotal Labs. Over the years, Tanzu Labs experts have helped hundreds of companies and organizations, big and small, build better software and adopt modern development practices. The tradition carries on today as Tanzu Labs experts help clients get up to speed with cloud-native computing and the flexibility and resiliency it provides. Our guests for this episode are Adam Bull and Felicia Schwartz, who explain the idea of landing zones for application modernization. Essentially, how to decide whether an application should live on-prem or in which public cloud and on what type of platform. So stick around and hear how Adam and Felicia help enterprises approach this important decision. So Adam, Felicia, it's so great to have you here. Adam, why don't you go ahead and introduce yourself first? And then Felicia, please introduce yourself as well. Sure. Thank you, Danielle. So my name is Adam Bull. I'm a multi-cloud architect within VMware. So I work with some of our largest customers. I'm based in the UK, but I cover all of the EMEA region. And I generally work with customers who are looking to implement multiple cloud solutions into their overall enterprise architecture and looking to see how VMware technology can enable that from a consistent infrastructure, consistent operations perspective within their overall IT strategy. And hi, everybody. I'm Felicia Schwartz. I am a director of application services, and I help clients take their existing and new applications and help them architect it and use the right tools to maximize the value of what the cloud can offer them so that they could solve business problems and be responsive and have the performance they want in their applications.
2:01Great. Well, it's so great to have you both. And Felicia, it's great to have you back. So when we spoke with you last, Felicia, we were talking a lot about prioritizing application modernization and how to assess your portfolio and really make those tough decisions around prioritization. And this is intended to be kind of a follow-on conversation, thinking about where you're actually going to put those applications. Most enterprises have many different kind of landing zones, so to speak, of different kinds of infrastructure, different kinds of platforms where they could put those applications that they're wanting to move into cloud. And so we wanted to kind of maybe first start off by just defining, like, what do we mean when we talk about a landing zone for an app? Maybe, Adam, is that something you could help us define? Yes. I think this is almost sort of multifaceted in most of the customers that I deal with. Obviously, the large public cloud providers have defined out what they see as a secure landing zone on their specific platform. And when I spoke to some of my customers about this, it's generally seen as, you know, public cloud of old was almost like this open playground, right? You know, you've got all the swings and the slides and you've got all the climbing frames and everything, and it's just let the kids in and let them go crazy. And then when the kids started to fall over and bang their heads and so forth, they realized, actually, we need some controls around this, right? We need to, you know, put some safety in place. We need to put some security in place. Maybe we need some monitoring in place and so forth. And that's where I think, you know, the major, you know, landing zone terminology has come from. Let's put some guardrails around these offerings. 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.
4:04And then they're trying to apply their security model on top of that in terms of what sits into their organizational security. And, you know, I'm thinking, you know, sort of financial services who may look at sort of, you know, what does this mean for their overall enterprise networking architecture? What does it mean for their operational tooling and so forth? Do they need to care about the underlying hypervisor technology that's being used in these cloud providers? Is the application abstracted or away from that in terms of modern application technologies? What native services in those cloud offerings are they going to allow their internal customers to utilize? I've worked with one large financial services customer here in Europe who, you know, up until about a year ago, was only allowing within their landing zones, I think it was about five native cloud services to actually be consumed. They were looking to open that up to about 50 going forward. So there's things like that that people are concerned about. And then there's another element which I think sometimes gets overlooked, but shouldn't be overlooked at all. And that's where's the data? 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 or you're looking to make a choice around what that landing zone is going to be. Because there is a, I often refer to it as a land grab of data, right? 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. So that's kind of how I think about some of the choices around landing zones. It's almost a separate layers in a cake, if you will, around what your choices are going to be. Can we dive in around data for a second, data gravity?
6:06Because that is and always has been, I think, a difficult problem to address, right? Like you mentioned, I mean, there's like data is in a place and it's hard to move, you know, especially if you have a lot of mountains of data or something, it's hard to make that ship necessarily. So how do you, or how do clients approach that situation when like they want to go to the public cloud, but they have, you know, whatever, like, you know, all the data is on-prem, for example, right? I mean, how do you even begin to make that migration? Or is it like using that hard drive, like they ship the hard drive to the cloud provider? 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. But then I think there's another piece around that there's a lot of attraction from public cloud providers to, you know, hey, bring your systems of record, you know, bring your critical business applications, bring the databases and the data warehouses that are core to running your business, bring them to our cloud provider or our cloud platform, sorry, because, you know, we can run it here and we'll make it, you know, cost effective to bring it here and we'll take away all that, you know, operational concern and maintenance of underlying infrastructure that you have and, you know, just bring those workloads here. Oh, and by the way, you know, when you're looking at your, you know, modern applications or you're looking at implementing IoT solutions, we'll suck all that data into our public cloud solution as well. And, you know, oh, and by the way, you're using some, some productivity tool in that, that's in our cloud. And by, by now, you've got kind of like a convergence of, of data, of users, they're all in one place. It makes sense to bring the applications to that, to that location as well. 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. But ultimately you're, you're dealing with a, a law of physics issue at the, at the end of the day. 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.
8:12So 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. 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. 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. 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. 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. 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. 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. What's the impact of I move everything over to the cloud from the data side? Yeah, that makes a lot of sense. We're actually going to be talking to one of our data transformation experts in an upcoming episode. So that'll be a really nice follow-on conversation to this because data is such a major consideration. So great. Thanks for going over the security and the data piece because those are really significant considerations. And I'm wondering, you know, what are some of the other considerations that makes choosing a landing zone for your apps so difficult?
10:13I mean, it sounds like there are so many variables. What are some of the ones that people get really stuck on? 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. There can be elements of commercial agreements in as well. 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. And basically, it becomes favorable to use a certain solution purely from a commercial reason. And then it just becomes a case of, well, is this good enough? 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. 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. 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. 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. 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? 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?
12:21And 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? 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. I think there's becoming a more pragmatic view to the overall IT infrastructure estate, right? People are realizing that, you know, actually it can be cost effective to run workloads on-prem. You know, there may be compliance reasons, there may be data locality reasons that just make it preferable to run workloads on-prem. 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. 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. 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. 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. 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?
14:38Do 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. 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? Or do you want to integrate parts of that application with the native cloud offerings? And I would refer to that as solutions that are only available from the public cloud in an as-a-service model. 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. 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? 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. 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. That's going to be heavy in the decision of what to do with the app when you migrate it. We found a lot of these legacy applications that have many, many pieces of functionality incorporated in it. Not all of them are going to be changed and need to be as resilient and need some of the capabilities.
16:38So 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. 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. You may have infrastructure savings and speed from an infrastructure perspective, but you also need to make sure you can solve your business. 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. 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. 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. But, like, how do you overcome, like, I'm curious, like, what does good enough mean, right? 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? Yeah, I tend to think once we're into that sort of level of conversation, you know, we're not into a technical decision. We're into a, you know, there is a specific commercial business reason why customers are looking to choose that particular cloud provider, right? 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, 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, in my experience, that's a tricky one to overcome from a technology-only standpoint, would be my answer there.
18:48Yeah, and I was just thinking, too, I wonder, how much does maturity model factor into some of these decisions? 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, something that's a little bit trickier, where they're being asked to, you know, maybe move to the left, so to speak, and take on some of the more kind of traditional infrastructure responsibilities. Does that ever come into the conversation when, you know, choosing landing zones? Yeah, I think from my experience with customers, there's always organic growth somewhere in the infrastructure. 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. There will be, you know, something happening in cloud A, but then there's always that conversation, and this is where sort of my multi-cloud role comes in. There'll be something that happened over here because of some, you know, some development team that went off and created something. And, of course, we used to refer to that as shadow IT. Shadow IT doesn't seem to be, you know, a term that I hear too much anymore. It just seems to be, well, that's happened, and there's some stuff over there, and that's now running in production, essentially. 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? 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.
20:52So, 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. 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? 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. 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 operational oversight here because things can get scary very, very quickly. 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 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? 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. 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.
22:59So, 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. 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? 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. But that's, that's really what I'm tending to see at the moment. 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. 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. They'll go to a public cloud to do their development work, and we'll see, wow, this was so fast. And then, it becomes more popular, then the strategy of what should we be doing comes into play. 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. So, I think that, I found that hasn't historically been the first step into the public cloud. It's more of, a developer wants to go out there and start doing stuff. 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? Are there any legal issues about where things are run, data, compliance issues, et cetera, et cetera? 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?
25:05What happens if I need to get out of that cloud provider? Yeah, I may not have a reason at the moment, but who's to say what will happen in 5, 10, 15 years' time? 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? And that, as well, comes back to that whole data locality piece, right? If I've put all of my data in one cloud provider, that's a point of lock-in. If I've consumed some particular PaaS service that's only native to that cloud provider, I'm locked in there. If I'm consuming other services that are only available there, that's an anchor point for all of these workloads. 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. 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. So for, you know, we've already touched on some commercial reasons, but there may be regulatory reasons. 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. 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. 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. 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. 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?
27:11If 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? 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? 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. 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? So, you know, thinking about an IaaS or using VMs versus containers, and then, you know, all the layers on top of that. 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? 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. Yes, it's like the carrot on the end of the stick, right? We're always chasing that. If I could just abstract myself to this point, I would be able to manage everything without having to care about the underlying infrastructure. 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? 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.
29:17And 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. 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. 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. 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. I don't see customers looking wholesale to refactor absolutely everything that they have. 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. 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. 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. 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.
31:32Yeah, 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? 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? I'm just curious what the process might look like for, for trying to do something like that in a relatively short timeframe. 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. But Felicia, do you have any, any on that at all? From, from an application perspective, historically, the mainframe COBOL, these old technologies were very hard. 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. Sometimes they'll just outsource their, their mainframes, right, to a company, and then they can get rid of that infrastructure. That tends to be a strategy if these applications need to keep running, but they're not, they're critical to have, but not necessarily changing and need to be modified similar to what was needed when COVID hit and like the unemployment systems. There's other approaches that over the past few years, like have come into play. And I know we've done a lot of work with customers. 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. 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.
33:43We'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. 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. 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? 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? It really comes back to that option around, you know, creating that hybrid application architecture. 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, but can I bring that modern part of my application into conjunction with my, you know, traditionally virtualization hosted parts of the application, and is there an offload to the mainframes or dedicated physical systems of record solutions as well? So, again, I think it is, you know, looking at everything, as Felicia said, and, you know, I said before, and having a more pragmatic view rather than I'm going to, you know, do a massive big bang across my entire enterprise estate to get to a modern application endpoint, which, you know, may take a long time
35:45and could potentially offer a lower business value to do the whole thing versus, you know, parts, parts of the application and really modernize where it matters, I guess, is ultimately the way I look at it. Yeah, I'm wondering, Adam, are there, do you see kind of any common trends around organizations kind of overstating or maybe ignoring different benefits or even drawbacks to particular landing zones in a way that kind of gets them into trouble with how they're matching workloads to the landing zone? Yeah, I think it comes back to that thing around, so a lot of customers, customers I work with, they sometimes underestimate that level of refactoring or replatforming work that has to happen across their entire estate. Yeah, there's one customer I worked with in particular who said, you know, well, I'm going to move all my applications. I've got, you know, quite a few of them. I can't remember exactly how many there were. And he said, you know, I've had one of my top people migrate a single application and replatform. I think it was being replatformed to use some SQL PaaS solutions and some web front ends. And it wasn't that difficult to move that one application into that cloud-native landing zone. And it was a question of, you know, just using, again, I use analogies quite often to explain certain things. But, you know, if we think about that in terms of, you know, migrating a single family from, say, I don't know, that's London to Cape Town, it's the first city that comes to mind. Yeah, it's a fairly straightforward process. You know, there's things to take into consideration and so forth. You know, there may be things that, you know, you have to work out once you land in that landing zone, if you will.
37:49But it's relatively straightforward. 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, then there's a lot of things to take into account. The burden of administration goes up quite considerably. So I think that's really that comes back down to that sort of pragmatic view and really thinking about, right, what is the level of work of moving these workloads to this specific landing zone? And are there better ways for me to handle this and to handle this migration task, I guess, would be the main thing? Because I tend to see that a lot of customers start with sort of high hopes of transforming absolutely everything. And then they go through a process of trying that, realize it's quite difficult. They speak to application owners. They realize that if the application owners aren't fully up to speed with modernizing that application, they go through a lot of hand-holding processes around that. And if they've got deadlines on migrating these workloads to a specific cloud provider, then these transformation pieces can sometimes hinder that timeline, if you will, and potentially put that timeline at jeopardy. So if we can look at, say, as we mentioned earlier, modernize where it matters, modernize where the business benefit is, move the workloads as is to solutions such as VMware Cloud on AWS or Azure VMware Solution, our VMware Engine, and incorporate that into the landing zone strategy, then we can get customers to the end result that they want to get to. And then we can think about, right, is there additional modernization that can happen once we've got over that first phase of the project? All right. And I know we need to probably start wrapping up for timing reasons, but I do want to ask, and this kind of touches on what you just talked about as well as that early discussion about lock-in.
39:51And I'm curious, like, what is, like, how do you see the role or what are the most important factors oftentimes in determining, you know, or determining portability, I guess, or mitigating lock-in to the degree it's possible? Like, is it that abstraction layer like, you know, VM or VMware Cloud and AWS? Is it Kubernetes or some sort of orchestration layer? Is it using open source? Because theoretically, right, you can at least be sure that your components are going to run anywhere. 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, you know, options there really are? Yeah, I think it's, I think it comes down to a number of different cases. Like, I sometimes snigger a little bit when I hear the term lock-in or we want to avoid lock-in. And I think it's almost unavoidable to a case. You're going to make a decision to utilize a specific technology, whether it's proprietary technology or it's a public cloud provider or it's open source technology, you're locked into something. You're either locked into that proprietary technology or you're locked into that cloud provider. Or in the case of many open source solutions, you know, you could be potentially locked into a community or you're locked into, you know, specific contractors that you may have on-premise that know that technology. So lock-in, in my opinion, is almost unavoidable. But I think where customers can really think about this is, right, what is the breadth of where I can run that technology? Okay, you know, from a virtualization standpoint and those traditional workloads, I think VMware is in a, you know, a very good place to be able to offer customers, you know, you want to run your workloads on-premise? Sure, no problem. You want to run your workloads in a VMware cloud provider partner? Sure, no problem. You want to run in any of the hyperscaler clouds? Again, it's not a problem. If you've got modern applications running in containers and orchestrated by Kubernetes, obviously that can run everywhere.
41:52So it's really, I think, a customer needs to really think about their overall IT strategy. 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? So I think it's a question of just having a look. What are your goals as an organization? What does the, you know, eventual IT strategy look like? You know, a few years now, it's obviously very difficult to think of anything beyond that and so forth. And just thinking what architecture gives you the most choices going forward. 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. This has been a really great conversation, Adam and Felicia. Thank you so much for joining us today. Thank you. No problem.