رونوشت کامل AEMCS Chief Solutions Officer Todd Miller on the 6 Cloud Mistakes Driving Up Your Costs

they're very good at managing the infrastructure. 00:05:06.240 --> 00:05:13.759 But really, the infrastructure is essentially um a response to what an application or workload needs. 00:05:13.839 --> 00:05:22.319 And without that understanding, especially when you factor in multi-cloud, it's easy to understand why cloud waste is once again on the rise. 00:05:22.480 --> 00:05:31.120 Um 29%, 30%, I think is what's being forecasted this year, uh, with 70% of that being driven by the application layer. 00:05:31.279 --> 00:05:40.800 So essentially, uh the old approach worked right for a while, uh, but a new approach is needed, what we call an application-centric playbook for cloud management. 00:05:41.360 --> 00:05:53.439 People moved so quickly to the cloud that um maybe they didn't do it in a pragmatic way, in the sense of making sure that they had change management processes and proceed procedures. 00:05:53.600 --> 00:05:58.319 Uh, would you agree that that's part of the problem that's created that complexity and that waste? 00:05:58.800 --> 00:05:59.439 Well, sure. 00:05:59.600 --> 00:06:12.319 I mean, uh I think that along with just perhaps a fundamental lack of understanding about what applic how applications should be uh even coded, developed uh you know, in the first place to run effectively in the cloud. 00:06:12.480 --> 00:06:20.800 Uh I think what happens is you have uh you have organizations that are driven uh to continue to innovate, right? 00:06:20.879 --> 00:06:21.839 And what does that do? 00:06:22.000 --> 00:06:35.040 That places kind of the incentive on new features, capability that places less uh emphasis on how do we make this application run most cost-effectively, most securely, with the greatest availability and uptime. 00:06:35.120 --> 00:06:45.199 And unfortunately, then what happens is is those people who are responsible for those functions, they fall into that reactive mode because they lack the understanding of the application or the workload. 00:06:45.279 --> 00:06:50.560 Uh, and so they're merely functioning in response to what they're seeing at the infrastructure layer. 00:06:50.720 --> 00:07:00.399 Because again, when you lack that insight at the workload, at the application, you're merely pulling levers in response to what you're seeing at an infrastructure or platform as a service layer, right? 00:07:00.560 --> 00:07:08.399 What we're talking about is needing to change the fundamental lens through which you're viewing your cloud and managing your cloud environment. 00:07:08.720 --> 00:07:10.639 All right, great segue for us to get into it. 00:07:10.720 --> 00:07:16.000 So the conceit of the podcast this time, uh, we we don't usually do themes here, but we've got a theme. 00:07:16.160 --> 00:07:19.759 We want to do the top mistakes that people make with their cloud infrastructure. 00:07:19.920 --> 00:07:29.279 So you make it sound easy to manage your cloud infrastructure, but uh I think you see quite a few mistakes that

are repeatedly made by enterprises over and over again. 00:07:29.360 --> 00:07:32.399 And so um we're gonna start off with the first one. 00:07:32.560 --> 00:07:36.480 And the first one you told me you wanted to touch on was infrastructure first management. 00:07:36.560 --> 00:07:37.920 What does that mean? 00:07:38.720 --> 00:07:45.759 So, what that means is that uh, you know, again, organizations back from the AWS launch, kind of going back to what we chatted about there, right? 00:07:45.839 --> 00:07:52.560 Which is outsource your infrastructure, use the public cloud, let AWS provide you the infrastructure, it simplifies it, et cetera. 00:07:52.720 --> 00:08:02.160 And what that did was did was create a whole uh perspective within organizations, but a whole industry of managed service providers focusing on the infrastructure, right? 00:08:02.240 --> 00:08:03.120 And that was great. 00:08:03.199 --> 00:08:04.800 Uh organizations embraced it. 00:08:04.879 --> 00:08:07.600 They found it was simpler, it was certainly quicker and faster. 00:08:07.680 --> 00:08:30.160 Uh it created a niche market, if you will, not so niche now, but but essentially an MSP, uh, uh an opportunity in the market for someone else, which made it even easier for organizations uh to say, hey, great, so now only am I not um leveraging the public cloud to simplify infrastructure, make it more of an on-demand capability, but I can actually hand that to someone else to manage. 00:08:30.319 --> 00:08:39.360 Well, what the net result of that was is that is that organizations uh by and large and these MSPs, they got really good at managing the infrastructure. 00:08:39.679 --> 00:08:48.399 But the challenge, right, is that what we're seeing now is is that the infrastructure is merely uh the reactive response, if you will. 00:08:48.559 --> 00:08:50.000 I'll give you a couple examples. 00:08:50.240 --> 00:09:00.000 So uh everyone's probably um you know basically joked about the story about the IT guy who gets the phone call from the end user saying that they're having problems with the application. 00:09:00.159 --> 00:09:04.159 And the IT guy says, well, looks just fine to me from my dashboard. 00:09:04.240 --> 00:09:10.559 And the reality is that uh the applications and workloads can be suffering while the infrastructure looks just fine. 00:09:10.720 --> 00:09:17.120 And again, that's that's really the net result of what happens when you're managing from the infrastructure. 00:09:17.279 --> 00:09:36.080 Uh another really good example is that uh the reality is that infrastructure tools they show you where cloud spend is happening, but they don't tell you why, they don't tell you from where, and they don't give you the root cause uh ability, the insight to address those things at their source, right? 00:09:36.240 --> 00:09:41.600 All they do is uh allow you to simply pull levers and see what the net result is. 00:09:41.679 --> 00:09:47.279 So you're gonna, you know, looks like this VM

may be over um provision from a core standpoint. 00:09:47.360 --> 00:09:48.639 So you remove a core and what happens? 00:09:48.720 --> 00:09:53.519 You wait and see what happens, but you really have no clue as to whether you help things or hurt things, right? 00:09:53.600 --> 00:09:57.039 You're just kind of reacting responsibly and you're playing sort of a guessing game. 00:09:57.200 --> 00:10:08.480 But when you have that application-centric approach and that fundamental understanding of the application and workload, then again, you're managing from what we call the application layer down. 00:10:08.639 --> 00:10:19.279 So that lens, that application-centric lens you're using, and it's focusing your purview and your insights, your management downward, starting at the application and filtering back down. 00:10:19.360 --> 00:10:33.120 So everything below that, if you will, is being managed, it's being secured, it's being sure it's compliant, all from the perspective of what that application needs to be managed, optimized, secured, and be compliant. 00:10:33.279 --> 00:10:41.039 So that's really one of the primary mistakes we've made is organizations managing from the infrastructure layer instead of understanding and managing from the application layer. 00:10:41.440 --> 00:10:52.720 Is it a bit like the tailwagging the dog in the sense that you're you're making infrastructure decisions first, and then you're adding the applications, and so there might not be a good fit, right? 00:10:52.799 --> 00:11:01.039 There might be some discrepancy between the needs and requirements or what it's going to take to get that application running optimally from a performance and a security perspective. 00:11:01.360 --> 00:11:01.600 Absolutely. 00:11:01.679 --> 00:11:07.759 And when you factor in the uh that, you know, again, I mentioned like not over 92% of enterprises are multi-cloud. 00:11:07.840 --> 00:11:16.559 When you factor in that uh over 80% of organizations are relying on custom applications now for mission critical services, right? 00:11:16.720 --> 00:11:22.480 You can see why the cloud waste and complexity is growing at the application layer. 00:11:22.559 --> 00:11:30.000 And when you're ill-equipped to be able to uh meet that challenge, that's where you get into the inability, right? 00:11:30.159 --> 00:11:35.919 We see a lot of um a lot of buzz these days, frankly, about spiking cloud costs, right? 00:11:36.080 --> 00:11:49.120 Because the complexity has moved to the application layer, and that's where the a new playbook is needed to manage, and effectively from that perspective, the old playbook of managing from the infrastructure simply doesn't work in today's world. 00:11:49.440 --> 00:11:50.399 I found a stat. 00:11:50.480 --> 00:11:55.200 I forgot to cite it, so I have no idea where it came from, uh, but I I swear it's real. 00:11:55.279 --> 00:12:00.720 Uh over 80% of organizations run mission critical services on custom applications. 00:12:00.960 --> 00:12:02.720 Um, does that resonate with you? 00:12:02.799 --> 00:12:06.480 And what does that mean for this infrastructure first approach? 00:12:06.799 --> 00:12:07.360 Yeah, absolutely. 00:12:07.440 --> 00:12:12.559 And I think that was either a Forbes or a Forrester um uh particular statistic. 00:12:12.799 --> 00:12:26.320 But what it does, again, is it it really highlights um again one of the underlying reasons why the complexity has shifted, because now it's not just simply shrink wrapped apps, but now it's custom developed applications, right? 00:12:26.480 --> 00:12:34.159 80%, I think you mentioned, of organizations, right, relying on custom software to run their mission critical applications. 00:12:34.320 --> 00:12:37.440 So that points to that ever increasing complexity. 00:12:37.519 --> 00:12:51.519 Um and the reality is not, and certainly not to sound like I'm disparaging developers or IT guys, right, having having been the latter for many years, but the reality is that application developers often have very little understanding of what resources their application needs, right? 00:12:51.679 --> 00:12:58.559 And if you think about how these individuals are motivated, it's a little understand how we arrive at the situation that we're in. 00:12:58.720 --> 00:13:02.320 So the application developer, he needs his application to run. 00:13:02.480 --> 00:13:05.919 He needs it to run as as high performing as possible, right? 00:13:06.240 --> 00:13:13.840 Responsive, uh quick, uh, you know, satisfying the expectations of executive management and users, customers, right? 00:13:14.000 --> 00:13:21.440 At the same time, he needs it to uh to not have tickets for him because he's already got to go on to the next application or the next feature for that application. 00:13:21.600 --> 00:13:23.519 He's done, he's got to move on, right? 00:13:23.679 --> 00:13:27.279 So he asks the IT guy for everything he can get. 00:13:27.519 --> 00:13:31.600 I need eight cores, I need 64 gigabytes of RAM, whatever it might be. 00:13:31.759 --> 00:13:37.600 Well, the IT guy, he has no real understanding of the application, how it runs and what resources it needs. 00:13:37.679 --> 00:13:38.480 And what does he want? 00:13:38.639 --> 00:13:40.480 Well, he doesn't want tickets either, right? 00:13:40.639 --> 00:13:43.279 He's already got too much to do and not enough time to do it. 00:13:43.360 --> 00:13:48.080 And so he just wants it to work and not result in any tickets for him. 00:13:48.159 --> 00:13:51.519 So he tends to give the application developer what it is he wants. 00:13:51.679 --> 00:13:54.879 And so what we have is the genesis of cloud waste. 00:13:55.039 --> 00:14:06.720 And when you multiply that by uh the number of workloads, again, the the uh the scale of which organizations have embraced the cloud, the year-over-year cloud spend increase is indicating mass adoption. 00:14:06.960 --> 00:14:15.360 92% of enterprises leveraging multi-cloud,

but you can see how cloud waste can be can grow to become uh the issue that it is. 00:14:16.000 --> 00:14:30.000 Before you ask the next question, I want to ask we would you say that you're advocating for a cloud-centric or I'm sorry, a uh application-centric approach, or is it an application-first approach? 00:14:30.159 --> 00:14:32.559 And is there a difference between those two? 00:14:32.960 --> 00:14:34.320 Well, and that's a great question. 00:14:34.399 --> 00:14:36.559 Uh, and I think they're more or less the same thing. 00:14:36.720 --> 00:14:43.279 So for us, application-centric, I'll kind of use that example I gave before, which is kind of like think about it as a lens, right? 00:14:43.519 --> 00:14:49.919 So I'm gonna use this application lens and I'm gonna view and manage my cloud environment through that lens. 00:14:50.000 --> 00:14:58.720 And basically what that means is that I'm gonna take an application-first approach to the actions I take, the strategies I develop, right? 00:14:58.799 --> 00:15:07.519 And I'm gonna think about all those things, not in terms of VMs or cores or memory or platform as a service, but with regards to what that application needs. 00:15:07.679 --> 00:15:29.600 But, but the key factor here that that is the challenge for most organizations is they lack the fundamental knowledge of those applications and that down to a code level, not just of the application of code itself, but what it takes to run that application effectively within a cloud environment. 00:15:29.759 --> 00:15:30.000 Right? 00:15:30.159 --> 00:15:36.639 So you're not developing for a fat client, you're not developing for uh something that's got tremendous amounts of bandwidth, right? 00:15:36.720 --> 00:15:43.360 You're not developing for something uh that is using um local dedicated hardware infrastructure architecture, right? 00:15:43.519 --> 00:15:57.279 Um there's all sorts of factors that go into understanding how an application should be developed in the first place, or what shrink wrapped application is going to function well, given the specifics, even to take it further, of the cloud environment you're in. 00:15:57.519 --> 00:16:05.679 AWS has strengths versus Azure, vice versa, you know, Azure SQL, Azure Um App Insights, et cetera, versus AWS capabilities, right? 00:16:05.919 --> 00:16:17.120 So it's also about understanding what is the right cloud for that application or workload, as well as how to fundamentally um uh write or configure that application. 00:16:17.279 --> 00:16:29.679 But yes, if you have that knowledge, then you take that application-centric or application first approach in order to guide your decision making around how you manage, secure, uh, and optimize that application. 00:16:30.080 --> 00:16:47.519 I guess in my mind, the distinction was application first means that the application requirements are strictly driving the infrastructure decisions, whereas application-centric might take more of uh the bigger picture of the business needs into consideration uh as a decision point, right? 00:16:47.679 --> 00:16:52.799 So if you say that you're uh customer first, then that means you're putting the customer above everything. 00:16:52.960 --> 00:17:04.799 If you say that you're customer-centric, it means in my mind, um you're you're thinking about what are the right things for the customer, what are all the moving parts, and how do we kind of orchestrate to get this to get the outcome that you want. 00:17:05.440 --> 00:17:06.079 I agree. 00:17:06.240 --> 00:17:09.519 And I I guess I what I would say is our perspective is all those things, right? 00:17:09.759 --> 00:17:16.720 So let's say application-centric, it's essentially the cumulative of both application first and application-centric. 00:17:17.039 --> 00:17:20.559 So, what does it mean practically when you're making architecture decisions? 00:17:20.640 --> 00:17:26.559 Like, can you walk through a decision-making process for both and kind of compare and contrast? 00:17:27.119 --> 00:17:27.440 Sure. 00:17:27.599 --> 00:17:37.440 So uh, you know, again, taking an application-centric approach would first and foremost go all the way back to your application selection. 00:17:37.599 --> 00:17:41.759 So let's take the business all the way back to we define a business need, right? 00:17:41.920 --> 00:17:52.000 We decided we need an application or a piece of service to either be developed or we're going to launch some type of uh initiative to identify if a shrink wrap uh solution will get us there, et cetera. 00:17:52.160 --> 00:17:59.920 But your first uh you know, your first um uh part of that process should be your application selector, uh selection, excuse me. 00:18:00.079 --> 00:18:02.960 And that's where you bring in, of course, your requirements, right? 00:18:03.039 --> 00:18:04.559 What does the application need to do? 00:18:04.720 --> 00:18:14.960 And that's where you have your first opportunity to make smart decisions or to make application-centric decisions around, well, what what cloud shop are we? 00:18:15.119 --> 00:18:16.240 Are we an Azure environment? 00:18:16.319 --> 00:18:16.880 Are we Amazon? 00:18:16.960 --> 00:18:17.519 Are we Google? 00:18:17.599 --> 00:18:18.720 Are we Oracle, right? 00:18:18.960 --> 00:18:25.680 And basically factor that in at that very early step in terms of the application selection selection. 00:18:25.759 --> 00:18:43.440 If we know that we're uh an Azure uh shop, then we want to ensure that we're looking at or ensuring that any application that we might select adheres to the capabilities, uh, maybe some limitations, or certainly place to the strengths of that particular cloud environment. 00:18:43.759 --> 00:18:58.880 Um following that, then it gets, of course, into, and let's just say it's maybe a custom developed application, it's understanding, again, back to that understanding that that deep application understanding of how to code develop, et cetera, an

application for a particular cloud environment. 00:18:59.039 --> 00:19:06.079 That's when you're starting to plug in the requirements definition and you're going through your application development process from a strategy perspective. 00:19:06.240 --> 00:19:21.359 And then, of course, it's having the right people to code or develop that application, and then having an eye towards what the an understanding of what those resources are going to be engaged and it's gonna require to uh support that application workload. 00:19:21.519 --> 00:19:47.599 And here's also an opportunity to get your cloud uh engineers and your cloud architects involved in that process if they aren't already, and probably should have been, uh, is to ensure that they're part of that ongoing conversation where they're having the ability to input uh not only things about certain performance and cost, but also from a security perspective, uh, rather than identify these things later and have to try and approach them as bolt-ons. 00:19:48.000 --> 00:19:53.680 And that's kind of more or less the process through to deployment and ultimately management. 00:19:53.839 --> 00:20:15.119 But it starts really early on, uh, all the way back in the application selection, uh, where you have the ability to influence your decision making based upon uh the cloud environment that you where your strengths lie, your support capabilities, your current investment, whatever that might be, to ensure that you're making decisions that are aligned with who you are as an organization? 00:20:15.519 --> 00:20:24.880 So our next mistake is about using infrastructure for AI that wasn't built for AI? 00:20:25.039 --> 00:20:30.000 I think these are kind of closely related, maybe just a different uh you know, side of the coin. 00:20:30.160 --> 00:20:38.880 But before I I have you touch on that, I want to ask specifically, has AI and and vibe coding changed mistake number one? 00:20:39.039 --> 00:20:50.400 And how do you how do you put application um, you know, an application-centric approach into place when line of business users are now building their own applications? 00:20:51.839 --> 00:20:52.720 Well, uh yes. 00:20:52.880 --> 00:21:10.960 I mean the short answer is is I think most people would assume is yes, that presents challenges as it relates to um, you know, having a solid understanding of what environment you're developing to and making uh aligned decisions around what and how you're developing. 00:21:11.039 --> 00:21:41.839 Um and it plays into some of the mistakes that organizations make uh as it relates to AI, which uh you kind of touched on it, which is just having uh you know, having your your rank and file employee non-developer employees who may be in your accounting department off utilizing AI to create some some uh application that fills some gap or need that they have that ultimately then needs to run an environment for which uh it might be suited, but it was certainly never designed for from a

technical perspective. 00:21:42.240 --> 00:21:42.720 Yeah. 00:21:43.119 --> 00:21:47.759 So why can't you just bolt AI workloads onto your existing cloud infrastructure? 00:21:48.079 --> 00:21:49.200 Sounds easy to me. 00:21:51.359 --> 00:21:59.599 Well, the the the biggest challenge there again is um the lack of understanding around the environment that. 00:22:00.079 --> 00:22:01.519 You're intending to use those for. 00:22:01.680 --> 00:22:11.920 But it really goes even farther back into what we see is really an absence of clarity around not only purpose, but of organizational strategy. 00:22:12.720 --> 00:22:36.480 Some of the major mistakes that we see as it relates to that is organizations trying to utilize AI to deliver on something when they they lack the technical and business understanding of the digital environment that they intend to have that capability operate within. 00:22:36.640 --> 00:22:44.000 And that leads to all sorts of gaps and missed expectations down the road. 00:22:44.400 --> 00:22:51.920 But there are there are a number of very um uh easily categorized mistakes that organizations make. 00:22:52.319 --> 00:22:55.359 A lot of them aren't even technical or um business sense. 00:22:55.519 --> 00:23:08.559 They're just you know um responding, feel feeling unnecessary, pressure to respond to uh to hype or to move quickly, uh expectations that are unreasonable, not founded in reality, et cetera. 00:23:08.720 --> 00:23:12.559 Those are that's one of the first and easiest mistakes that organizations make. 00:23:13.920 --> 00:23:21.039 So what does cloud architecture actually need to look like when AI is the primary workload? 00:23:23.599 --> 00:23:26.640 Well, frankly, it doesn't it doesn't look a whole lot different. 00:23:26.799 --> 00:23:40.640 I mean, certainly it all depends on what your AI architecture is going to look like, uh how it's gonna function, and what technology uh needs uh in terms of um, you know, what if it is a core dependent, core heavy, et cetera, uh, as opposed to things like GPU. 00:23:40.799 --> 00:23:45.920 Um, and certainly different cloud environments have different strengths in terms of satisfying those requirements. 00:23:46.160 --> 00:23:51.119 But there's not there's not a real fundamental difference from our perspective. 00:23:51.359 --> 00:24:03.440 It really goes back to um uh uh understanding exactly what it is we're trying to accomplish, what it is we're trying to achieve, um, how are we going to do that most effectively within this particular cloud environment? 00:24:03.599 --> 00:24:11.039 I mean, there's no shortage of entities out there uh that will uh sell you uh AI infrastructure, right? 00:24:11.119 --> 00:24:16.960 They're more or less the same organizations who are selling you compute, storage, and network today. 00:24:17.279 --> 00:24:34.559 Um but again, the mistakes that they're make uh in going wrong is is really driven more around um basic fundamental stuff, less about the cloud,

less about the the technology within the cloud, really, uh, but more really about um you know, their data is not AI ready. 00:24:34.640 --> 00:24:40.240 Um maybe believing somehow for some reason that that every challenge requires AI. 00:24:40.319 --> 00:24:56.240 That's a real common one, which is we're we're so we're so saturated with AI today that I think people have started to believe or started to have their very first reaction that any type of time a problem is presented to them, how can I use AI to solve this? 00:24:56.559 --> 00:25:00.000 The reality is AI is not the right solution in every case. 00:25:00.240 --> 00:25:08.240 Um so it's really less from our perspective about technology than it is about more just um uh a consistent strategic approach. 00:25:08.960 --> 00:25:09.599 Got it. 00:25:09.759 --> 00:25:17.759 Um would you say that people are uh investing uh in AI infrastructure the right way? 00:25:17.920 --> 00:25:35.519 In other words, how how do you I don't get into many infrastructure conversations, but when I talk about you know AI deployments in the enterprise, what I find is that uh people are vastly underestimating what the ultimate costs are going to be, right? 00:25:35.680 --> 00:25:42.880 And uh a lot of that has to do with um, you know, infrastructure costs and token usage obviously is being the other one. 00:25:43.519 --> 00:26:05.440 Um, you know, when when you're looking at AI deployments and you're looking at the infrastructure that you're going to need for it, how can you um do it in a cost-effective and right-sized way now, but also be able to scale and also understand what the costs of scale are going to look like? 00:26:06.720 --> 00:26:14.480 So along those lines, the the challenges that we see today are uh um somewhat the same, somewhat a little different. 00:26:14.640 --> 00:26:19.039 So many organizations, frankly, they're struggling with exactly what to do with AI. 00:26:19.200 --> 00:26:25.839 And so in the absence, they're not they're not doing much from an organized organizational perspective at all. 00:26:26.000 --> 00:26:41.440 Uh and so what's happening instead is that you have, as we kind of just were talking about, you have your your rank and file employees in your in your work groups and departments, they're all running around doing their own thing with AI, right, in a non-organizational, sanctioned, or controlled manner. 00:26:41.599 --> 00:26:54.400 And ultimately, um, this is where we see a lot of the spike, unplanned, unforeseen costs with AI, et cetera, uh, is because of the lack of centralized oversight, governance, control, if you will. 00:26:54.480 --> 00:27:03.200 Um, the easy solution to that, of course, is to, even if you don't necessarily know what the right AI technology is for you, what the right platform, et cetera, right? 00:27:03.279 --> 00:27:26.480 It's a clause, a chat GPT, what have you, um, is to at least um put enough parameters or formalize enough around the use of AI to uh

to settle on, even if it's two or three different approaches, um, adopt organizational level accounts and onboard the organization that way. 00:27:26.559 --> 00:27:30.240 Because what that does is that gives you control over things like you mentioned token use, right? 00:27:30.480 --> 00:27:40.400 Gives you control over exactly how much cost you're going to incur, and maybe more importantly, or just so importantly, at what rate you're going to incur that cost, right? 00:27:40.480 --> 00:27:47.279 So it allows you some uh budgetability around that cost, right, that you didn't have before. 00:27:47.440 --> 00:28:10.319 And this what this does is essentially buys you time to more formalize exactly what your intentions are to use AI, which then leads us into uh another sort of challenges and just touching a little bit on the infrastructure side, I think what happens again is there's a there's a lack of a more clearly or clearly enough defined um initiative and purpose around the use of AI. 00:28:10.400 --> 00:28:16.160 There's a lack of real understanding at the at the business exactly what is the outcome we're trying to achieve. 00:28:16.400 --> 00:28:40.559 And so there's there's not enough, there's not a narrow enough focus on that business outcome, which leads to sprawl, which leads to the need to uh uh you know adopt greater and greater quantities of infrastructure than they might have normally needed, ultimately, which then leads to those spiking costs from an infrastructure, infrastructure perspective. 00:28:40.720 --> 00:28:58.799 So again, the goal there would be to um be very much aligned on what the initiative and the business outcome is and identify the requirements to satisfy that, which which which is really no different than launching into in almost any software development project. 00:28:59.279 --> 00:29:02.079 How do you decide where your workload should live? 00:29:02.240 --> 00:29:05.279 I mean, public cloud versus private cloud. 00:29:05.519 --> 00:29:06.960 I mean, how do you know? 00:29:07.359 --> 00:29:09.440 Well, that that comes down to a number of things. 00:29:09.519 --> 00:29:12.720 Uh it can depending upon what the that workload is, right? 00:29:12.799 --> 00:29:14.960 So if it's a database, depends on what database. 00:29:15.039 --> 00:29:18.480 So if you're today running it on a physical machine, probably not. 00:29:18.559 --> 00:29:24.720 But let's say you're using Microsoft SQL or you're running it on a VM in a private cloud environment and Microsoft SQL. 00:29:24.880 --> 00:29:29.119 Uh some of the, you know, an easy first answer may not be the right answer, right? 00:29:29.200 --> 00:29:32.240 There's more thought that goes into it, but an easy first answer would be Azure, right? 00:29:32.319 --> 00:29:34.160 Because it's on Microsoft SQL today. 00:29:34.319 --> 00:29:47.279 Um what we see as a mistake then, which again goes back to that real understanding of the cloud, is organizations will then deploy that as a VM

with Microsoft SQL on it, which is not the most cost-effective, best performing way, right? 00:29:47.359 --> 00:29:53.279 You utilize something like Azure SQL, uh, more of the platform as a service capabilities. 00:29:53.440 --> 00:29:54.559 Um, so that's one thing, right? 00:29:54.640 --> 00:29:57.519 So if it's a database, what database is it? 00:29:57.599 --> 00:29:59.279 Uh what type of requirements do we have? 00:29:59.440 --> 00:30:13.279 Do we have need for uh uh clustering or um uh you know failover, always online stuff, um, all sorts of technical aspects may come into ultimately what the right cloud is for that, but that's a place to start. 00:30:13.440 --> 00:30:14.880 What language it was developed on? 00:30:15.039 --> 00:30:16.480 It was developed on.NET, right? 00:30:16.640 --> 00:30:19.920 Of course, that comment might lend you toward Microsoft Azure as well. 00:30:20.079 --> 00:30:26.160 Uh if it was developed on some other platforms, or if it's more of a Google ecosystem. 00:30:26.319 --> 00:30:42.000 Um so really it's like platform, um, technical requirements of that platform, feature and functionality set of that platform, and ultimately um not to not to forget, you know, where what is the core strength cloud-wise of the organization? 00:30:42.400 --> 00:31:06.960 Uh, and and if if there are no clear-cut advantages uh or requirements for that workload to exist somewhere else, then of course you'd always like to try and stay within your um within your core competency, unless, of course, the goal is to provide this as a a redundant type of capability to something else, in which case you may want to look at a different cloud simply to provide you cloud redundancy. 00:31:07.440 --> 00:31:11.519 I had a conversation the other day with a guy that we've had on as a guest. 00:31:11.599 --> 00:31:13.359 We're gonna have him on again soon. 00:31:13.599 --> 00:31:24.640 And he was talking about uh the conversation kind of went towards the Chinese open weight models and what role they may have in in your AI infrastructure and how you might leverage them safely. 00:31:24.799 --> 00:31:27.599 And he was talking about the importance of running them locally. 00:31:27.759 --> 00:31:34.160 And um, you know, I'm wondering like how how do you decide where your AI should live then? 00:31:34.240 --> 00:31:40.000 Like, is there a heuristic that's simple or is it highly dependent on you know the the specific use case? 00:31:40.799 --> 00:31:49.519 Yeah, Sean, to be very candid with you there, that's uh that would be a subject matter I would have to defer to someone who has more expertise in that space. 00:31:49.680 --> 00:31:52.799 Um, probably not the best question for me to answer. 00:31:53.119 --> 00:31:53.839 No worries. 00:31:54.000 --> 00:31:59.759 Uh we'll we'll ask him on the podcast and then I'll I'll show you the clip. 00:32:00.079 --> 00:32:06.160 Um all right, so you had talked about sprawl, and that leads us to the next mistake. 00:32:06.319 --> 00:32:10.160 So mistake number three is letting your cloud costs run away. 00:32:10.319 --> 00:32:13.359 And uh I think sprawl is probably one of those reasons. 00:32:13.440 --> 00:32:21.119 Uh FinOps is becoming, I shouldn't even say becoming, it's been a board-level conversation because cloud costs have been so high. 00:32:21.359 --> 00:32:28.880 Um so it's drawing a lot of attention, especially now when there's a need to fund all this token usage and these AI projects, right? 00:32:29.039 --> 00:32:36.240 So uh how do you go about um you know approaching FinOps to clean up the mess that you have? 00:32:36.400 --> 00:32:41.680 And and maybe also how do you keep from creating that mess to begin with? 00:32:43.039 --> 00:32:45.200 So there's a number of ways to come at that. 00:32:45.359 --> 00:32:54.799 So let me let me start with um again going back to that application-centric playbook that you need to have, right? 00:32:54.880 --> 00:32:58.720 It's no longer focused on starting and stopping at the infrastructure, right? 00:32:58.799 --> 00:33:05.839 That's not the way that you're gonna be successful managing cloud environments, especially from a cost perspective. 00:33:05.920 --> 00:33:10.799 Uh, and there's a number of areas that comprise that um that playbook, right? 00:33:11.039 --> 00:33:20.079 Application performance, uh, database efficiency, cloud resources, DevOps, security, resilience, observability, and finally cost management. 00:33:20.240 --> 00:33:34.319 So it can range everything from understanding how the application performs, making sure that my caching and my caching ratios are successful or are hitting the appropriate targets, uh, query optimization, index tuning. 00:33:34.400 --> 00:33:41.759 Um, but talk speaking more specifically around the FinEps aspect, um, governance is a real big one. 00:33:41.839 --> 00:33:51.279 Um and one of the first things, I guess, what I would start with and answering your question more specifically is controlling costs starts first with understanding your costs. 00:33:51.599 --> 00:33:57.359 And so the first step towards that is to ensure that you're doing the appropriate things around governance. 00:33:57.440 --> 00:34:10.719 Uh, it's surprising how many organizations don't utilize things like tagging to tag resources within the cloud to understand who owns it, what cost center or department does it go to, is it production or development, right? 00:34:10.880 --> 00:34:22.159 Understanding many, a number of at least eight to ten different business aspects of every asset and resource within your cloud environment, in order to first understand what's driving the cost of bill. 00:34:22.239 --> 00:34:31.679 You get a bill from your cloud provider and it shows you compute, and it shows you different VMs or what have you, platform as a service capability, it shows you things like e-gress charges. 00:34:31.840 --> 00:34:41.760 Um, but it doesn't necessarily help you paint a picture of

a specific area of cost or even a specific application workload or workload group, right? 00:34:41.920 --> 00:34:48.000 Which allows you to drive further into the next phase, which of course is uh right-sizing that cost. 00:34:48.079 --> 00:34:49.039 Is this cost legitimate? 00:34:49.119 --> 00:34:50.320 Is it not legitimate? 00:34:50.480 --> 00:35:00.719 Um, that's the next step in the process and helping to understand what things are production, development, et cetera, helps you understand why this development resource needs to be on 24 by 7 by 365. 00:35:00.880 --> 00:35:03.840 We only do development on that three months a year or something like that, right? 00:35:04.000 --> 00:35:06.480 So then it's legitimizing the cost. 00:35:06.559 --> 00:35:14.239 And then ultimately the third step is leveraging that playbook, uh that full playbook to manage that cost, right? 00:35:14.400 --> 00:35:40.960 So again, optimizing your applications and workables, optimizing your database, optimizing your development operations and your pipelines, uh infrastructure as code, leveraging things, uh smart resilience, um, factoring in and building out observability, you know, logs, metrics, um, alert attuning, and then lastly, cost management, which sounds like, well, isn't shouldn't that just be enough by itself? 00:35:41.119 --> 00:35:53.679 But cost management is is kind of a it's both a specific need uh and area of focus, but also like an umbrella, because all those other areas I talked about all filter back into cost. 00:35:54.239 --> 00:36:05.599 Cost management, though, uh uh looking at it with a specific focus is comprised of what I just talked about, those various areas and driving efficiencies, that falls under usage optimization, right? 00:36:05.760 --> 00:36:12.000 But then there is also rate optimization, which is how I buy my cloud resources, right? 00:36:12.159 --> 00:36:34.079 Leveraging things like savings plans, leveraging smart usage of reserved instances is part of uh specifically looking at, well, I know now that I've gone through that process I just laid out about identifying, legitimizing, and managing, now I say, well, okay, so so this dollar, this cloud spends, multi-cloud spend is what I've identified and legitimized, I have to have. 00:36:34.239 --> 00:36:37.840 Now, how can I how can I purchase that most efficiently? 00:36:38.079 --> 00:36:45.360 And that's where you get into the specifics uh from a cost optimization, specifically a rate uh optimization. 00:36:45.920 --> 00:36:48.239 I come from the telecom side of this business. 00:36:48.400 --> 00:36:55.679 I've got some experience with uh what at the time we would call telecom expense management, today we'd call it technology expense management. 00:36:55.840 --> 00:37:00.400 But you know, there's there's a very simple methodology for it, which is start with an inventory. 00:37:00.480 --> 00:37:01.840 So that's your observability. 00:37:02.000 --> 00:37:07.519 You need to understand exactly what you have and then uh start to pressure test those things, right? 00:37:07.599 --> 00:37:08.639 So should we have this? 00:37:08.800 --> 00:37:09.519 Do we need this? 00:37:09.679 --> 00:37:10.800 Are we using this? 00:37:10.960 --> 00:37:12.800 Um, and then you stop that bleeding. 00:37:12.880 --> 00:37:15.920 So anything that you don't need, you you cut that, right? 00:37:16.159 --> 00:37:27.119 Um, and then you can go into your cost optimization, which is now I've got the opportunity to take this network that I know that I do need and that I know that I do have and go ahead and shop that out for better pricing, right? 00:37:27.519 --> 00:37:34.800 Um but all of this, it's it's one point in time, right? 00:37:34.880 --> 00:37:39.920 It's a single moment in time that you're gonna get your your hands around that cost. 00:37:40.079 --> 00:37:52.559 If you don't have a tool and discipline and governance around how you're buying network in the future, um, then you're just gonna end up in the same position. 00:37:52.719 --> 00:37:54.159 It's just a matter of time, right? 00:37:54.239 --> 00:37:58.239 So uh is it similar with uh FinOps and cloud? 00:37:58.480 --> 00:37:58.960 Oh, absolutely. 00:37:59.119 --> 00:38:03.920 I mean, the biggest mistake we make is we're engaging with the customer. 00:38:04.079 --> 00:38:10.000 Uh, we provide them, we offer a complimentary up to 40 hour assessment of their public cloud environment, right? 00:38:10.079 --> 00:38:23.440 So it identifies uh that whole playbook that I just outlined, the the application performance and security and compliance and cost, uh, et cetera, is all part of that uh that those observations that we take within their cloud environment. 00:38:23.679 --> 00:38:41.199 Um and in many cases, um, I mean, the goal for us is obviously to do exactly what you said, is to manage that customer's environment ongoing, to keep it optimized, to keep it secure, to keep it lean, right, and functioning and be something that is delivering on the promise of why they embrace the public cloud in the first place. 00:38:41.360 --> 00:38:49.440 Um, what we see sometimes is organizations that say, great, thank you for these insights, we'll go off and do that on our own. 00:38:49.599 --> 00:39:01.199 Uh and the mistake that we see, to go back to uh your your specific question is um the customer's cloud environment, the way it was when we found it, was that way for a reason, right? 00:39:01.360 --> 00:39:04.800 Because for any number of reasons, that's what they know, right? 00:39:04.960 --> 00:39:15.119 Many other organizations, right, when they when they architected their cloud environment and and built it out, they essentially built it the same way they did on-prem. 00:39:15.280 --> 00:39:17.119 Because again, that's what they know. 00:39:17.280 --> 00:39:27.920 And so even though you may give them a blueprint to go and drive efficiencies and optimizations, ultimately over time, they slowly regress back

to where they were because that's what they know. 00:39:28.320 --> 00:39:44.400 And so the challenge there, of course, is to provide um uh a means, a way, right, um, for organizations to not only achieve optimization from, again, not just cost, but performance, security, et cetera, but to stay that way. 00:39:44.559 --> 00:39:50.639 Uh, and that's where, frankly, um, that's one of the capabilities we provide as part of our ongoing managed services. 00:39:50.719 --> 00:40:00.239 But but Marcel, what I really want to draw out is that's probably the number one failing of uh cost um optimization, right, as a service. 00:40:00.320 --> 00:40:02.079 And we provide that as a capability, right? 00:40:02.239 --> 00:40:05.360 CCMO, um cost management optimization, right? 00:40:05.599 --> 00:40:11.679 Provide reporting on a regular basis to the customer identifying areas where we've seen spikes in cost and increase. 00:40:11.840 --> 00:40:23.199 The challenge with that though is that um it's to your point simply a point in time and it's not um proactive. 00:40:23.840 --> 00:40:30.960 So, in other words, I'm gonna send you a report at the end of the month, it tells you three weeks ago, I noticed you had a cost spike in this area. 00:40:31.119 --> 00:40:34.239 So if this was three weeks ago, you could have done something about it. 00:40:34.400 --> 00:40:39.519 But since it's not, right, I'm telling you that you spent money three weeks ago that you didn't need to be spending. 00:40:39.840 --> 00:40:43.199 So you have one half of the equation, but not the other, right? 00:40:43.360 --> 00:40:46.320 You need the ability to react and take action. 00:40:46.480 --> 00:41:03.360 And that's where that full stack approach to include the cost optimization really sells itself in terms of we're not just going to identify areas where your security maybe have gone lapse or but you know, or or your uh cost is spiking or overrun. 00:41:03.440 --> 00:41:11.440 Um, but it's also about taking action to correct those things, as well as the governance aspects, again, back to that tagging, right? 00:41:11.519 --> 00:41:29.199 Which is once you've tagged things and you've identified what's appropriate, what's not, you can exert locks and controls to prevent individuals from being able to unreasonably consume resources and uh spike costs unanticipated, unbudgeted. 00:41:29.440 --> 00:41:44.480 Uh so yes, it exists as a service, uh, there is value in it, but customers should understand going into it that it's extremely reactionary and can be information that is too late for them to act upon. 00:41:44.719 --> 00:41:52.400 Um and so you know, understand what it is that you that you may be purchasing uh both strengths and weaknesses. 00:41:53.519 --> 00:42:13.360 In the telecom expense management analogy, one of the things that we would recommend is that they get a TEM software to manage this because it will ingest your bills electronically and it will flag any variances and it can set off notifications. 00:42:13.440 --> 00:42:27.760 And even some um some platforms that say have mobile expense management, they can tell you real time, and actually you can even do it for you, just kind of optimize your mobility plans, for example, real time based off of usage patterns. 00:42:27.840 --> 00:42:34.480 So that's that proactive approach that you're talking about, as opposed to, hey, sorry, you spent too much money last month, too late. 00:42:34.880 --> 00:42:37.920 Um, so like is there a tool like that in this space? 00:42:38.239 --> 00:42:38.480 Yes. 00:42:38.639 --> 00:42:50.239 The challenge though, unlike the telecom expense management, is this and this the answer to this question kind of takes us all the way back to the beginning of this conversation, which is you're taking a purely infrastructure level approach. 00:42:50.880 --> 00:42:55.920 So this software, let's just say we've could you've got a uh a FinUps type tool, right? 00:42:56.079 --> 00:43:04.079 And it's identifying that this core on this VM uh is is not utilized sufficiently and could be removed. 00:43:04.159 --> 00:43:10.239 And you've got it set to actually take action when it feels that that you know, that that it has reasonable action to do so. 00:43:10.480 --> 00:43:21.119 But that takes us back to kind of the your typical MSP who only has an understanding of the infrastructure layer, and that they are taking actions without truly understanding what is using those compute resources. 00:43:21.280 --> 00:43:23.599 How are those compute resources being used? 00:43:23.760 --> 00:43:27.199 Are there cyclical, seasonal, are there types of development? 00:43:27.280 --> 00:43:43.199 We have one customer, for instance, that has to overprovision their VMs because when they run updates to their environment, right, code updates, it maxes out all CPUs, but simply the way the application was written, right? 00:43:43.280 --> 00:43:46.960 And that's not persistent, it's only during their development updates. 00:43:47.199 --> 00:43:49.679 But the rest of the time, they're over provisioned. 00:43:49.760 --> 00:44:05.519 So, in your scenario about the software that's automatically going to remove CPUs, that's where you, you know, if you don't understand the picture from an application perspective, you run the risk of actually hurting uh the cloud environment as opposed to helping the cloud environment. 00:44:05.920 --> 00:44:11.119 How often do you see people actually tying these costs directly to business outcomes or value? 00:44:11.360 --> 00:44:13.840 Because it seems like that's part of this picture as well, right? 00:44:13.920 --> 00:44:26.079 Like you you might you might look at the costs purely just from that perspective in a vacuum and think, well, costs are going up or we're spending so much money, but um value could be increasing in a nonlinear way, right? 00:44:26.159 --> 00:44:28.159 So how do you actually make that connection? 00:44:28.960 --> 00:44:31.840 So to

answer your first question, not as often as we'd like. 00:44:32.079 --> 00:44:39.440 So organizations rarely tie back um uh expenses to value. 00:44:39.599 --> 00:46:05.920 So you know right we spent an extra$20,000 a month in our cloud environment but we generated you know an extra$1 million in in retail value as a result of that right that doesn't happen as often as you'd like um the it seems like the two sides of the ledger don't talk to each other uh enough uh from an expense uh and revenue standpoint um what we like to do is we like to present um the recommendations in terms of a business value so if we're again even back to that complimentary up to 40 hour um assessment right is we're not just gonna tell you that we think you should do something right because that's insufficient information we need to explain to you not only why you should do it but ultimately what is the return to the business as a result of doing that and sometimes it's to spend more money right and so I think that's again where having individuals having the right level of governance right so that the costs are accurately understood in terms of where, what and why helps provide that insight into uh when a bill is higher, um is there a a corresponding increase in value that was realized by the organization uh as a result of that yeah so uh mistake number four is the organizational problem. 00:46:06.239 --> 00:47:44.000 Okay so um these mistakes seem to be occurring because silos exist uh within the organization within the the people that are using the cloud infrastructure um so what uh number one do you agree and number two uh what is uh best practice look like to break down these silos and ensure that there's better communication yeah absolutely I mean the reality is that silos create gaps right I mean gaps in between those eight different pillars I talked about application performance database optimization right when you have uh individual in separate individuals or individual groups owning them and the reality is is that that's probably always going to be the case because your DBAs your database experts probably aren't your cloud engineers and vice versa right um the fact that they are not um that those gaps exist because those those um functions are siloed the functions being siloed is is understandable and and reasonable and realistic um the lack of unified ownership of them is really the challenge and so the gap is is that you don't have that single um point of unification that ensures that all of these teams are working effectively towards the same goal right all pulling in the same direction and each team is not essentially focused on a very narrow perspective of what's the right answer for my particular responsibility without regard for what it might do to the other areas of that. 00:47:44.159 --> 00:47:57.440 So we absolutely believe and that's frankly one advantage of leveraging the right managed services provider, managed cloud service providers is to achieve that unified ownership across those areas. 00:47:59.119 --> 00:48:25.039 Yeah there there's a new title uh that's in the industry that's really sexy right now which is chief AI officer I interviewed one on the podcast um a guy named Ed Kiesling from Progress Software and he's their CAIO and I asked him what a CAIO does and why does a business need one and he said uh just that right that AI exists in silos across the organization. 00:48:25.119 --> 00:48:54.559 The silo can be as big as a business unit or a line of business can be a department it could be as small as a single user and uh shadow AI somebody needs to be the connective tissue between all of these different departments within the organization and have ownership of AI, have ownership of cost, have ownership of um outcomes and putting governance in place and ensuring communication. 00:48:54.800 --> 00:49:10.320 So um I've not heard of a chief infrastructure officer I don't know if a chief cloud officer is something that exists uh but how how should a business actually uh you know define ownership of this and and manage this across those silos? 00:49:10.880 --> 00:52:23.360 So from our perspective we normally see that falling under say your chief information officer or chief technology officer um some organizations may even have a uh more of a a chief cloud uh or some type similar type role um and more or less um again you're not necessarily you're not necessarily falling application development software development et cetera under there you're you're you're you're building out capabilities across very specific needs um in order to address these requirements across various cloud environments so you don't you're not necessarily um having database expertise for instance in order to be able to um create uh be part of a software development effort but essentially that have the purview of databases as it relates to optimization securing et cetera within a cloud environment so the the focus is different the depth in some areas is is certainly probably different um so it's very it it's still easier to to centralize those under one of those technology uh roles that exist today got it um mistake number five last mistake that we want to talk about this is something that is very specific very actionable something we've heard a lot about in the headlines for over the past couple of years now and that's the VMware trap um so if you don't mind I I'm sure that everybody understands what the issue is uh just kind of touch on it and explain the current state of the uh VMware Broadcom drama sure so yeah um basically in a nutshell um you know VMware was acquired uh the goal has been and to some extent uh the you know the the the the the drive or the the the goals or objectives are understandable right which is to like any business uh focus on the areas of their business that are the most revenue producing uh and eliminate the ones that are not producing enough revenue but are producing uh more of the issues

kind of the old 80-20 sure right and so uh Broadcom has been reducing partners uh they've also been increasing pricing they want a smaller number of bigger deals instead of a a huge amount of lower revenue deals uh they also don't want to work with as many partners right so they're reducing the partner count uh in order to be able to spend more time with less partners so you know to some extent like I said all understand some of the challenges though that those changes are creating are pain points for customers unfortunately which is um increasing licensing of course that's a pain for any uh any customer uh at the same time uh reducing their support footprint so as I mentioned they you know they don't want to focus on as many platforms as many release versions so they're upping hardware requirements they want everyone to get to uh you know version nine so you got to get to version nine many customers' hardware won't support version nine so what's happening is kind of a perfect storm frankly of of organizations who are finding themselves on the cusp of a VMware renewal that they may or may not be able to work with the same partner they worked with before. 00:52:23.599 --> 00:52:36.320 The renewal they're getting can be anywhere from uh 50, 100 to 1200 times more than what their current cost is, the elimination of perpetual licensing and the narrowing of hardware compatibility. 00:52:36.719 --> 00:52:57.360 So you're looking at customers facing um increased cost on a licensing and maybe having to do an unplanned, unbudgeted CapEx refresh across their entire environment and not this particular moment in time equipment is particularly expensive and and the other the other part of that perfect storm is it's an incredibly bad time to have to purchase hardware. 00:52:57.519 --> 00:52:57.840 Yeah. 00:52:58.000 --> 00:53:03.199 So uh last guy I talked to about this said there's about a six month lead time on equipment right now. 00:53:03.679 --> 00:53:09.840 What we were talking about he mentioned that there's this um what do you call it a compliance cliff in 2027. 00:53:09.920 --> 00:53:28.800 So October of 2027 I guess is when these upgrades need to be done uh and that's I guess when support is over and if you haven't made that upgrade because you didn't get the equipment that you needed uh you're gonna fall out of compliance for things like HIPAA, PCI, whatever regulations that you might fall under. 00:53:29.679 --> 00:53:39.440 And I think people don't really understand the timeline of this which is it's going to take you a little time to figure out what the right move is here and what direction you want to go. 00:53:39.599 --> 00:53:43.119 And then you're gonna have to source all this stuff and find support. 00:53:43.280 --> 00:53:54.559 So that's going to take time procurement process is usually 60 days at least right then you've got six months of lead time to get your equipment and then you've got a couple of months to get it deployed. 00:53:54.719

--> 00:54:12.079 So that's basically the year timeline that you've got right now year plus um but we're also going into budgeting season right now so like you need to have that conversation today so that you can budget appropriately because this is going to cost you a bunch more money. 00:54:12.639 --> 00:54:23.840 So maybe just kind of talk us through recommendations for this and I I think the first thing that you said to me was um don't make the knee jerk reaction to just go to the next platform like Nutanix. 00:54:23.920 --> 00:54:26.960 So uh what what is the right way to approach this? 00:54:27.519 --> 00:54:33.280 So the first thing I would tell customers or organizations is that understand that there are options out there, right? 00:54:33.360 --> 00:54:48.480 And you're best served to your point of of tackling this even though it's daunting, challenging um and nobody you know likes to necessarily tackle these things head on or change there's going to be pain involved the reality is that there are options out there. 00:54:48.639 --> 00:54:56.559 The first step is to educate yourself on what those options are and you can do that with any number of various organizations included. 00:54:56.800 --> 00:55:04.800 And the goal isn't really in that particular point is to sell anything or buy anything it's to understand what options exist out there. 00:55:04.880 --> 00:55:39.599 And there are more than organizations might think I mean Nutanix certainly mentions one of them HP has a solution we leverage a Proxmox based approach but there are also um uh exit strategies of which again I mentioned a proxmox based approach but really ours is more of a an initiative solution uh within which there are multiple exit paths and those are kind of some of the other alternatives so the public cloud is another exit strategy right so you can exit some or all of your workloads to AWS or Azure or in many cases what we see is a hybrid combination. 00:55:39.840 --> 00:56:06.800 So um in essence shrinking down your private cloud moving workloads that will function properly in the public cloud which allows you to shrink down which allows you to maintain only the applications and workloads in your private cloud that need to be which reduces your cores which reduces your potential license renewal which may be an appropriate solution for you a gap solution for you to get you to a longer term one. 00:56:06.960 --> 00:56:33.599 There are also other solutions out there uh like for instance Expedient offers what they call a bridge solution which is essentially you get out of the VMware licensing business and you utilize their VMware licensing we like that uh it offers value as a bridge solution because what it does is um it allows organizations who who maybe waited a little too long to be able to buy themselves more time to be able to figure out what the right long-term answer is. 00:56:33.920 --> 00:56:41.440 So what would you say is more dangerous reacting too fast not reacting at all reacting too slow? 00:56:41.599 --> 00:56:44.719 I mean where are mistakes being made in this process? 00:56:45.199 --> 00:56:46.880 Well that's an interesting question. 00:56:47.760 --> 00:56:56.000 And you might get different answers depending upon who in the engagement you talk to right versus the vendor versus the customer. 00:56:56.159 --> 00:57:02.800 So from a customer's perspective there's really never a downside to engaging too soon. 00:57:03.280 --> 00:57:39.679 You're better off engaging earlier than later simply because depending upon the size of your environment if you were to work backwards from um you know end of term right end of your your license current licensing term if you basically back two months out of that just to give yourself some risk uh mitigation room right your migration based upon maintenance windows cape you know availability of groups people et cetera whatever requirements dependencies might take you anywhere from six to eight to twelve months so now you basically need 12 months right is is eaten up just to get there. 00:57:39.760 --> 00:57:45.199 But first you have to figure out what the plan is right and then you come into what is my migration strategy, right? 00:57:45.360 --> 00:57:59.119 This is where you need an organization to come in and essentially perform an assessment deep dive to say here's what you got here's the different workloads dependencies capabilities here because each one of them may have different requirements in terms of getting them from A to Z, right? 00:57:59.199 --> 00:58:15.920 Some of them are going to migrate nice and easy using a de uh readily available migration tools others might need a replatforming others might need a modernization effort because they're running on an operating system that's no longer supported so you need to figure out what that plan is first and then of course it's got to be tested and validated. 00:58:16.079 --> 00:58:26.800 So that assessment could be another you know six weeks to three months right so now you see now we're at we're at two months plus 12 months 14 we're at three we're at 17 we're almost at two years. 00:58:27.119 --> 00:58:29.760 So there's never a problem to starting too soon. 00:58:29.920 --> 00:58:32.079 So that's never a mistake. 00:58:32.880 --> 00:58:46.239 What we probably see as the biggest mistake is that customers pick something like Nutanix and they say well Nutanix has got a solution I'm saved right we're all good. 00:58:47.440 --> 00:59:05.119 And then oftentimes they find out in the long run that it's going to be just as expensive as what they're trying to get away from and they haven't really solved the whole vendor lock in aspect which is that they more or less put themselves in a position to find themselves right back into the in the same place when it's time to renew those licenses again. 00:59:05.280 --> 00:59:05.519 Right? 00:59:05.679 --> 00:59:10.320 Another captive audience right that has faces a lot of

pain to go in a different direction. 00:59:10.559 --> 01:02:12.960 So certainly um the knee jerk is a problem uh and the not waiting we have one customer talking to that's um their terms already expired right they're basically have no support and that's not a good place to be so really the two mistakes that customers can make are you know knee jerk doesn't always turn out the way you think it's going to be and waiting too long and not leaving yourself enough time to to uh properly and safely get to where you need to be so to bring this all home just the whole discussion here um what would you leave as advice for the technology leaders that are concerned about their cloud spend concerned about their infrastructure application performance what are the things that they should do after listening to this podcast let's say the top three things where they could focus their attention that would be the highest leverage items that they could tackle well the easy answer would be to would be to say to to engage somebody but let's talk about this purely from a um something that would be useful information for for an executive or a manager to to take away um the first thing of course would be to understand this kind of goes back to our conversation around TEM right so specifically from a cost perspective right first thing is to understand where your costs are coming from so governance leveraging the capabilities of your current cloud environment to be able to identify your your assets your inventory so that you can have a more insightful reporting about where your cost is coming, where your costs lie, where those percentages are then you can move on to that whole legit uh legitimacy uh phase we talked about right which in your world was you know identify um uh manage in terms of this is this cost acceptable or not right we call it legitimize right legitimize the cost and then ultimately manage the costs that need to remain right legitimize allows you to turn off things you don't need scale back things you didn't need right from a cost perspective um that would be the really the three places I would start starting with that with the whole governance aspect um the second thing I would uh encourage organizations to do is really think long and hard about the application-centric playbook because as we've talked about here and hopefully impressed upon people managing from the infrastructure is not going to suffice in this new world right more and more workloads complexity workloads has gone up cloud waste is on the rise being driven by the application layer you need to manage things from the perspective of the application layer and the last thing I'll kind of go back to the whole private cloud VMware Broadcom which is saying um ask the right questions now right don't be afraid to ask questions educate yourself there are alternatives don't wait to move right the right solution for you is is out there uh and there are also solutions to help you to bridge that gap to get there even if you're uh you find yourself short on time. 01:02:13.440 --> 01:02:19.199 Sounds like the common theme out of all three of those is uh take action and take action soon. 01:02:19.360 --> 01:02:24.880 Uh fastest way to take action is to partner up with someone like Amplix with your company. 01:02:25.119 --> 01:02:30.639 So uh if people wanted to ask you questions, get in touch with you, whatever, how can they find you? 01:02:31.280 --> 01:02:35.039 Easiest way is uh Todd Dobb Miller at aemcs.com. 01:02:35.599 --> 01:02:36.000 Awesome. 01:02:36.159 --> 01:02:38.880 Todd Miller, thank you so much for your time and expertise. 01:02:39.119 --> 01:02:39.840 Thank you, Sean. 01:02:39.920 --> 01:02:40.320 Appreciate it. 01:02:40.400 --> 01:02:41.360 Thanks for having me on here. 01:02:41.519 --> 01:02:42.639 My pleasure