Hello. I'm Adam Kranitz, and welcome to The Cloud Reset, our latest move faster live show. You know, these move faster shows explore how companies have leveraged technical challenges and data storage and distributed work into a competitive advantage. Each show, we feature an industry expert with today's guest, perhaps the most well known to date. Let's bring in David Linthicum. Hi, Adam. Hello. David is a globally recognized thought leader. You're an innovator and influencer in cloud computing, AI and cybersecurity. And you're the author of seventeen bestselling books, including this one right here. I've read cover to cover, Insider's Guide to Cloud Computing, over seven thousand articles, courses on LinkedIn learning. You're a frequent speaker, podcast host, contributor on topics like digital transformation, cloud architecture, AI and security. And I know most importantly, you're passionate about educating. You serve as an instructor at Louisiana State University, and you're a frequent mentor to the next generation of cloud professionals. I want to welcome to Move Faster, and I'm excited to dig into the Cloud Reset topic. Well, it's great to be here, Adam, and this is absolutely the topic we should be talking about right now. I think it's the hottest topic going even above AI. People are trying to figure out where to platform this stuff correctly. You know, I think what kind of started this conversation, the reason I reached out to you, you know, obviously I'm a subscriber to the Cloud Computing Insider on YouTube. But your recent video on VMware's private cloud outlook, I think that video kind of went viral. And in it, said you mentioned sixty nine percent of enterprises are repatriating workloads. I think that stat caught everyone's attention. Now, don't want to brand you as a cloud contrarian, but let's kind of dig into it. Whatever happened to the cloud first era and what's changed? Well, what changed was is we realized how expensive it was. So in other words, when we started to move to cloud in two thousand and eight, two thousand and nine and kind of did the mass movement through about twenty fifteen and I was right in the middle of that, the cloud was being touted as a superior platform to the on premise systems that we're doing. It's supposed to be cheaper, better, faster, more agile, things like that. And most of that didn't come true. You know, as we moved into, know, twenty twenty and the pandemic and more people were using cloud based resources because of that. And now we're moving into AI based resources as well. You know, suddenly realize that the amount of money that people are paying for the public cloud providers is way more than we thought it was going to be. As I outlined in my book, it's probably two point five times and I stand behind that, no one's pushed back on me yet, two point five times that what we were told it was going to cost back in the day. And certainly what happened in the last ten years is the cost of hardware has come down on a forty five degree angle. Storage is a commodity now. Processing is a commodity now. You know, even some of the AI based processors out there, the older GPUs and TPU chips are a commodity now. It's way less expensive than what we're paying for in the cloud. And also the cloud comes with some junk fees, egress ingress fees, the ability, you know, network utilization fees, the ability to host stuff on particular regions and localizing on a region and the lock in aspect of it. So altogether, around five years ago, I started to notice that many of the enterprises were pushing back on some of the cloud, basically parroting the message I've been, you know, touting for years. Never against the cloud. The public cloud providers have a purpose and they certainly have a place in our modern architectures. My concern was we moved many workloads and many data stores into the cloud that should not have been moved to the cloud. We didn't localize them for the cloud providers, therefore they're not utilizing the cloud providers correctly, and companies are overpaying for the cloud providers. And like I said, they're wasting resources. Two point five times the amount of resources they're paying on their cloud computing or public cloud based systems could have been built, you know, could have been used to use something that was other strategic purpose to the enterprise. And now that we're moving into AI, the question's coming up in a huge way with a bit explanation point. Where should these workloads reside? Where should our storage sets reside? Where should our training data reside? And there's a real movement out there to figure out where the platforms that are gonna be desirous of our enterprises and strategically enterprises where it's going to be. And it's not always gonna be the public cloud providers. And I think most people understand that now. And based on the fact that anytime I post a video about repatriation or considering, you know, getting the cloud or kicking the cloud to the curb or things like that, which would have been blasphemy ten years ago, they're the ones that are hit the most, probably ten times more than the other videos out here. Is it is it fair to say that we know what we're dumping the cloud reset right now is the biggest shift you've seen since the initial kind of cloud migration wave, let's say from twenty fifteen onwards? Yeah, I think so, and it's also a secret shift. I mean, as I'm seeing some of these surveys pop up, you're not seeing it covered by the tech press as much. You gotta remember, that's going to be contrarian, it's a contrarian opinion in terms of what the zeitgeist is, in terms of where things should be running. We've been saying for the last fifteen years that there should be cloud first, people should be moving their stuff to a public cloud provider, you know, shareability, agility, you know, all the cool reasons to do that. And when those promises weren't kept, many of the enterprises in the back in secret, you know, started to repatriate stuff to the cloud. And so I saw this in my consulting days and suddenly it's like, wow, there's a lot of people who are pushing stuff back on to managed service providers, co location providers, you know, products like yours. And I think ultimately that showed me that a larger trend and a larger new revolution was occurring. And now people are coming out of the shadows, they're talking about it, about it, having them on my podcast all the time. And I think this is the reset that's coming. People are normalizing their platforms, running their workloads and their data sets on the platforms where it's gonna make the most sense and bring the most value back to the business. Who would have thought that would have been important? Yeah, exactly. So let's transition into kind of what you would call the three C's, cost, complexity, and compliance. I want to break those down individually with you. So can you can you break us can you get us started with cost? You know, according to VMware's report, ninety four percent of respondents, I'm quoting the report, believe their company is wasting public cloud spend with nearly half stating that that waste exceeds twenty five percent of their IT spend. So where is their money? Where's the budget? Where's the money going? Yeah. In fact, we started a whole discipline around that called FinOps. That started up last five years ago and it was around the inefficiencies and people misunderstanding what their cloud bills were doing. The money is going for basically waste and lack of planning and also that your ability to use and allocate cloud resources willy nilly as you need them without thought or understanding as to how much they're costing. And I think that in most of the organizations out there, the enterprises have opened up the budget so people can allocate as many of the cloud resources that they need to apply the particular projects. When I audit these projects, they're over applying those things. They're using too much storage, too much compute, and it's costing them three, four, sometimes five. I saw one was ten times as much as they should be spending on the cloud. And they're not thinking around the discipline and how they're going to be leveraging these resources. So that's the fault of the enterprises. The fault of the cloud providers is they're not very clear on how much this stuff costs. Obviously, you know, if they get a big bill that's in their best interest. I'm not saying they're pushing them to spend more than they need to, but there is a huge amount of confusion in terms of what you're paying for in the public cloud providers. Egress fees, the junk fees that are out there, things like that. How much storage is allocated, your ability to kind of keep and move these things out to provision and deprovision these systems, spot instances, all that kind of stuff. Enterprises basically have no clue. And so when I work with them, the biggest understanding and the biggest message that they give to me, we're spending ten million dollars a year on this particular cloud provider, we have no idea what we're spending it on. And we know there's applications there, we know there's data sets there, but we don't know where they're allocated, if they're allocated correctly, if people are utilizing the cloud services correctly, all these sorts of things are there. It becomes kind of a black box unto itself, and so people are pushing back on that and looking to take control of their cloud costs and doing so in many instances despite the public cloud providers and their ability to support that effort. Wait a second, wait a second. I thought we were told that the cloud, the public cloud auto scales and auto optimizes. Did I mishear that? It doesn't auto optimize. It can auto scale, but you're going have to pay for that. And typically, if you're going to allow the cloud to scale, it's going to cost more than manual scaling that you're doing when just sizing your application. So if you're turning on auto scaling and you're turning on auto optimization, obviously the optimization's not working because you're still getting the huge cloud bills. I view it as cost optimization. I think they view it as processor and storage optimization. And the reality is if you take manual control of the number of processors you're provisioning, cores you're provisioning, storage systems you're provisioning, you're going to have more granular control over what you're paying. And I think many people are, just quite frankly, told by the providers to skip by that and go ahead and let the automated techniques take over, serverless computing, things like that. And they're not getting good value for the money that they're spending in these cloud bills. Now, ten years ago, it used to be ten thousand, dollars twenty thousand a month. Now it's a million, two million a month. And so this thing is taking away resources from areas where the business should be spending and investing. You gotta remember every dollar that's going to a public cloud provider where you're overspending on that resource. I'm not saying you shouldn't use a public cloud provider, but you shouldn't overspend for that resource. You're taking money away from strategic uses of those resources that are gonna bring value back to the business. Namely right now, we're facing AI. Many of these organizations are repatriating their workloads because they're trying to free up money to spend on the AI systems they're looking to build and then figuring out where to platform those things. So everybody's reguessing and rejiggering where these platforms should be working. They're looking at different alternatives, and I think it's a good thing they're looking at different alternatives. I know one area of particular ire for you, and in fact, I think the word ransom has been used, is egress fees. I think you did a whole video on egress fees not not too long ago. Why are we still paying egress fees? Because they view it as a legitimate fee to be paid to the cloud providers if we're going to use their network. And if we're going to move data onto their network or move data off the network, ingress and egress fees, they view that as a load on their system. They're gonna have to pay for the networking resources and there we should pay for it. I have no issue with them charging a fee for that. What I do have an issue charging them the massive fees that I'm seeing these days. And so in other words, most of these systems, the cloud based systems are gonna have to communicate with the existing on prem systems, legacy systems, systems exist in other areas, Salesforce, ERP systems, things like that. Anytime you move data in and out of the cloud, if they charge you a fee for that, that's going to be a very inefficient thing for you because you're going to lose value every time you're having one system communicate with a system that's native to a cloud provider. And so the cloud systems should communicate outside themselves to talk to the other systems. They're gonna allow them to process things better. But the reality is, is that if they charge you for that, there your value goes. And like I said, these fees are unreasonable. And I think many of the cloud providers are removing them now because they realize unpopular. You know, I'm talking to people in the UK and in the Europe where they're looking to pass legislation to eliminate the fees. I guess they see it as a as truly ransom. But the reality is there's a cost in doing that that I think is is usury, and I think they should and enterprises shouldn't pay it. So what's happening is that people are seeing these fees and suddenly they're cutting off the applications for communicating outside of the cloud providers. And therefore they're not getting as much value. So in other words, well, come your inventory system isn't communicating with your ERP system, which happens to be, say on SAP or Salesforce, something like that. They say, well, it does that, it costs us ten bucks. And it's okay, and it does it, you know, a hundred times an hour, and that adds up pretty quickly, so that's why we don't have this communication. So in other words, you're limiting the value you're able to get from your computing system by limiting the amount of data that it is able to see to allow it to do its job better just because of the expense of communicating outside the cloud providers. That's just plain wrong. So in addition to the fees that we're incurring by moving data in and out when we might wanna be a little bit smarter about what we store in the cloud, not just the hot data versus, you know, long term storage, whatever. What about over provisioning? You touched on this a little bit in idle resources. How do we get smarter about not over provisioning our usage of cloud services, not just storage, but cloud services? Well, the first thing you do is use FinOps or other disciplines to make sure that you're able to monitor through cost and accountability observability within your cloud environment. Most organizations don't even have, understand anything about doing that. So they don't have FinOps in place and they don't have cost governance in place. So if you're going to allocate resources, storage, CPUs, you know, serverless servers, container based servers, things like that, it should be under the guise of cost observability and FinOps. And so your ability to see it and therefore understand that it's running and your ability to deprovision those resources when they're done is going to be a discipline that many enterprises need to adopt if they're gonna use the cloud providers. And so also the ability not to over provision, which is a huge problem. When we first started to move into cloud, I saw this as really kind of the most systemic problem out there. They would use ten, sometimes twenty more servers than they're needed, and three or four petabytes of systems when they only needed maybe half that or even a quarter of that. And the reason they said, well, we need it for expansion. And I said, no, you're paying for a resource you're not going to leverage. The idea of a cloud provider, at least it was explained to me by the public cloud providers that talked to me, is that I only need to provision the resources that I need, and when I'm done with those resources, I can turn them back into the resource pool. I'm only gonna pay for those pay for those things that I'm using. People, they ignored that and they went ahead and took the lazy way to do it, over provisioned various resources, developers did this all the time because they wanted to have headroom for these various applications and data sets and the expansion of them, and they didn't work as planned and people paid way too much money than they should have, and I think the cloud providers, I'm going to put a bit of blame on them as well, they should have made it their job to explain to their users how to provision their resources responsibly and get more cost optimization out of these systems. But that wasn't done. Millions of dollars just flew out the window for no particular reason, but, you know, live and learn. Yeah. Good advice. So that for the sake of time, I wanna kinda touch on the second c, which is compliance. Two thirds of IT leaders, again, referencing the VMware private cloud report, are extremely concerned, in quotes, about data stored in public cloud. We spent a lot of time years ago when it was in other roles of trying to encourage people about the myth of security and cloud and all this. So what has changed all of a sudden? How we flip back to this concern about public cloud security concerns? Yeah, I think there were some key breaches that people saw and many of them we didn't hear about. And so, and some audits that were done where they were proven to be out of compliant, either it was responsibility of the enterprise or responsibility of the public cloud providers or both. So compliance is a bit more complex when you deal with public cloud providers. You're trusting the public cloud providers to remain into compliance. In other words, you're saying if I'm having HIPAA information on there, GDPR information, all this kind of stuff, financial information, audit, you know, auditability, things like that. You have to be able to, in essence, you know, find the ability to do that. And I think if people don't, then they're going to ultimately, you know, find that these issues are gonna be, you know, are gonna be a bit of a problem. Hey, David, for a second there, think we may have lost your camera. Sorry about that. I'm back, Welcome back. Thank you. Yes. So we were talking, we were finishing up our point about complexity. Okay. I think complexity is going to be the biggest issue when you deal with many different heterogeneous resources. You got to remember, it's a bit of a trade off. So, other words, we're moving to the cloud and put to the public cloud, and then we're looking alternatives. In other words, we're going to looking at your technology, we're going to looking at private cloud technology, managed service providers, colocation providers, sovereign cloud providers, things like that. It's going to cause a problem with operational complexity, which is going to be an issue we're going to have to deal with in dealing with a single cloud provider. However, we know how to deal with that now. In other words, we have multi clouds for, you know, last twelve years, you know, as far as I've been monitoring it. And we should have the ability to, in essence, monitor complexity and create common control planes and observability planes that go across these different platforms. And so your ability to, number one, understand that complexity is going to be a challenge and deal with complexity on complexity sake is going to allow you the platform options to make this stuff work. And I think that is ultimately, you know, what the enterprises need to do. So again, this isn't free. If we're gonna move to these heterogeneous platforms to leverage best of breed technology, public cloud and non public cloud based platforms, to provide us the best bang for the buck. Your platform, for example, mixed with the public cloud providers, with the on prem providers, things like that. We're going to have to deal with the heterogeneity of that. In other words, they have different platforms, different APIs, different systems that we're managing and common control planes and mechanisms to do that are in the way in which we carry it out. And so I think that's something that people need to think about. Okay, so I want to also touch on the third and final C from your perspective, which is you talked about a little bit about compliance. It seems to be coming up more and more. You talked a little bit about GDPR and keeping data local to the account or organization. Why is compliance or is compliance as important as cost or complexity at this stage of adoption curve? I think the reason why is because the amount of compliance and regulations are expanding quickly. And so you look at the European Union, you look at the UK and even the United States, the amount of rules and regulations either at the state level, local government level or at the international level or at the federal level, are growing by leaps and bounds. And so the ability to remain compliant is going to be linked to the ability to have control of your information. Always comes down to that. In other words, do we have control of the PII information, the HIPAA compliant data, the GDPR stuff, things like that, the financial banking stuff. And so more and more compliance is going to insist that you have tighter control over your information. So it's not about just pushing it up to a cloud provider and hoping they keep it into compliance. It's about a complete trusted system that we're able to rely upon, understand where it is, understand who's running it. Typically going to be smaller companies who do this, and they specialize in managing that particular data, or you own your own hardware. And so people are rethinking their use of public cloud providers based on their compliance requirements that are out there. Ultimately, it's going to take the rethinking of the fact that we have to figure out the amount of fees, the cost of doing it, and normalize that across the selection of the various platforms. Many people are repatriating their systems right now purely for compliance. In other words, it's expensive and they will tell me that, but it's not for the expenses not driving them there. They have to maintain a compliance and regulatory compliance stance that they can't maintain in the public cloud providers. They can't get the public cloud providers to check, have the checklist they need to show, you know, law enforcement in terms of their living up to their standards and it's different from country to country. So sovereign clouds, you know, and you know, based resources, that kind of stuff are starting to rise up, and the reason is because they have to be in control of their data. They have to have a physical capability of doing it. Before we move on from this part of the discussion, I want to drill just for one minute into egress. We actually have a question from the audience. Irma asks, how is egress computed for long term storage? It's not clearly described on the provider's website. Is it only when we access the data or even when their systems can crawl the data? It's typically not around access. It's going to be around transport. So egress or ingress fees is gonna be on pushing data into a system in the cloud. That could be a raw storage system or a database. And then our arm pulling systems away from the cloud provider, cloud based storage system, they're gonna count that as egress. So if you're just accessing the data from an application, typically that's not going to count as egress or ingress fees because we're not we're pulling a record at a time when we're bringing it to a user interface, observing it, and then pushing it back to the database if we need to. You're not typically going to pay for that, thank God. But you are going to pay for anything when you move any kind of, know, more than a few records at a time to a database and from a database. And again, it's going to vary widely based on the cloud providers and some cloud providers have started to waive these fees, so it's a little confusing right now. But the reality is you need to read your contracts and read your SLAs and it's gonna define exactly how they're gonna charge it. Most of the enterprises, when they're getting these, you know, many tens of thousands of dollars egress fees and I get a call from them, it's in their contract, they just haven't read it. I think this is something we need to go back and return to the contracts and see what it says and see what it doesn't say. You know, we just had a bunch of public cloud outages and over a billion dollars of damage was done in a very short period of time. And two major cloud providers went down for almost a day, Microsoft and Amazon. And now enterprises are going back and finally reading their SLA agreements and their contracts to see what kind of responsibilities that they have. And lo and behold, they don't. They don't have a lot of recourse. And you can get credits and things like that. I'm sure they'd be happy to give you Amazon dollars or Microsoft dollars, but that doesn't do you much good if you've lost, you know, a hundred million dollars in your sales and you had reputational damage by your clouds being out. So read those contracts, that's you'll see the ingress and egress fees. It's typically higher than it should be. I think they were built ten, fifteen years ago to create profit. The cloud providers were in a seller's market at the time, and those things are typically gonna be pseudo usury right now. Ransom would be a good analogy. Okay. That's good on Igor. So I appreciate that response to my question. I do wanna kind of shift the discussion today over to the, whatever you wanna call it, the portability or mobility, data mobility imperative. The VMware report shows that enterprises are restructuring around restructuring IT around platform teams, not technology silos. And I've often heard you discuss the importance of designing for portability or accessibility or mobility. How does data infrastructure fit into this? What does it actually mean in practice to have your data be portable across platforms? Yeah, that means I can move the data incrementally, in other words, record by record, that's able to communicate across platforms. It could be an application to application, application to database or even database to database. And it's absolutely imperative that that happens because the applications are gonna cease having value if they're unable to communicate and talk to other applications that are in the ecosystem. And so that's the way we make money with technology. It's not only technology itself that exists in the silo, but the ability for data to be transportable across different platform domains. And so portability should be absolutely one of the most important things you think about when you build and deploy these architectures. You know, one of the things I do when I teach cloud architecture is understand the fact that we have to look at different architectural assets and how these things are gonna communicate one to another and your ability to figure out how they're gonna move across the different platform spheres. And it's often overlooked and people love to use data or build data that exists in silos that does us no good. And at the end of the day, those things have to be fixed. In fact, in many cases, are starting to repatriate many of their workflows and their data sets around the portability or lack of portability that they're finding in the public cloud providers. And so they're pushing them on other platforms, certainly storage based services, similar to the ones you're selling, Adam. And at the end of the day, they're doing that for survivability and the ability to find data within these particular systems. At the end of the day, storage should not be hard and your ability to transport data across different, from platform to platform should not be hard, but these walls of proprietary systems that are put up within these platforms and the difficulty in getting information into these platforms and out of these platforms is causing huge amounts of value drain right now within the enterprises. And now as people are reevaluating their whole data stance, as they move into AI and move into different next generation systems, repatriating to a heterogeneous environment for a cloud only environment, That's gotta be first and foremost. And I'm seeing enterprises are becoming much more smarter about that. Portability is on top of their list now. It's there with security, it's there with governance, and it's absolutely one of the more important aspects of building an architecture. Can you give me an example of some of the data types that enterprises are finding trapped in their silo? I mean, what are they storing? I mean, you know, we work with lot of M and E customers, so we're talking about, you know, VFX or animation files that are part of the professional content creation process. But what where what what data silos are getting created and why and how what's getting stored there? I think normally it's transactional data to run the business. So in other words, if I'm selling something and I have an inventory of something and I'm, you know, carrying out a transaction, it's gonna be an instance of a sales. It's pretty important information to me where my customer information is gonna be stored. So, you know, it's the triad of business. In other words, who's buying, who's selling and what we're selling and your ability to store that in some place where it can be accessible and accessed. And I think that's where the portability issue comes in. So in other words, if I can't see those things from my CRM system, from my HR system, you know, from my logistics system, and see where the customer is, where they're located, what they're doing, things like that, and do so without having to replicate the data, and that always drives me nuts when people do that, in some sort of redundant area where you don't have a single source of truth, then that's going to cease to have value because that becomes my business unto itself. And many businesses, they just solve this issue by making copies of it. So they store customer information, their CRM system, and their inventory system, and their sales system, things like that. That's always going to lead to data confusion, and it's always going to be a larger problem you're going to have to fix. It becomes technical debt that you have to kick down the road to fix at a later time, and you don't have to do it. Let's be smart about this stuff. Let's build these things from the ground up to have a single source of truth, a single data asset, and the ability to share that data asset amongst many different platforms out there. And right now we love to put things in proprietary silos, whether it's a public cloud provider or an old some sort of a virtualization system, things like that, where the information is very difficult to get outside of those systems. So if you're going to have a frame of reference, the transactional data is going to be there, triad of value is going be within that data. You have to access it. It's not negotiable. I understand we can build around it. We can build very silly redundant systems. But eventually we're going to have to fix those things because right now they're just too expensive. Yeah. Let's talk about an exit plan, not for this webinar, but for moving data. What's the importance of exit plans in a cloud strategy? One thing we hear from our customers is we didn't know we needed an exit plan until we needed an exit plan. So what's the advice that you're giving your customers for teams that are designing a hybrid infrastructure today? My advice is open up your mind because the Cloud First stuff is kind of a real kind of almost has religious fervor out there. You know, I'm going to reinvent in a few weeks and there will be a lot of people there, all they use is AWS and all they think about AWS and they take pictures of the architecture diagrams that are given during the session to use when they drag them back to whatever Global two thousand company that they're working at. Those aren't the only platforms out there guys, and those are typically the most expensive things out there. So when I hear people taking a monolithic approach to how they're dealing with cloud computing and cloud first, not only a cloud first attitude, but a brand first. Microsoft, you know, Google or AWS, you're missing out on many other opportunities to innovate and use more valuable technology that will bring you more agility, more cost freedom, and the ability to do things as you need to do it without having to pay huge amounts of fees and huge amounts of penalties and huge amounts of issues. Take control of your data, take control of your platforms. That doesn't mean we have to give up cloud computing or public cloud providers, but look at different vendors out there and the capabilities of those vendors. And that's my biggest form of advice because sometimes when I'm meeting with these people and they're thinking about architectures, they're thinking single brand and they're never going to have an optimized platform in doing that. You got to remember if we're using a single brand or a single technology path, that's never going to be the most optimized solution. It's never going to be the most cost effective solution mathematically. Oh, think about openness. Think about the different options you have out there and use them to bring the best value back to the business. Is the best approach to think about listen. The notion of multi cloud. Right? Sometimes it's by necessity because you have you're merging different companies. There's acquisitions, and they're bringing Azure because they have enterprise contract with Microsoft and then but we use AWS. So you by nature have to support multi cloud. But is is multi cloud an outcome of just necessity or is it actually an architecture to think about? Do I need to think about using different vendors for different types of compute or storage that I may need? Is multi cloud really a thing, I guess is the question. Multi cloud is a thing and it's been a thing for a while and it's a necessity. In other words, an architectural necessity. We're not using multi cloud. We're not using best of breed technology. You gotta remember the technology vendors out there, the people who are providing the best of breed technology come from a variety of players. It may come from companies like yours, Adam, and they come from people who are basically putting different options out there. They're gonna be the best of breed technology for your particular solution. And by definition, that's gonna be multiple vendors. By definition, that's gonna be multiple clouds. It's gonna be big clouds, small clouds, small systems, things that exist on premise, private cloud providers, sovereign cloud providers. All these things have to exist in your mix of technology. They're going to bring, again, bring the most value back to the business. And so I never understood why people avoid that. Maybe it's more complex and you have to deal with more vendors and there's more moving parts, but the reality is you're gonna end up building a system that's going to bring back fifty, sixty percent more value back to your business just by using this technology. Isn't that worth it to you? Can't you use that money to spend on other strategic purposes for the vendors, I mean, for the business? And right now everybody is seeing, I think that that's the path and everybody's thinking multi cloud and I think they're thinking in the right place and let's keep let's keep momentum going. Repatriation, multi cloud, and looking at different architectural options for our enterprises. Alright. Yep. For a couple of questions from the audience? Sure. Alright. So we have a question actually that came in through LinkedIn. It's from Shoshana, and she asks, how would you respond to those who argue that private cloud is not a cost savings because it requires building the infrastructure, doing the training, hiring the talent to make it work? Well, they're all gonna require you know, particular skills that are native to whatever you're buying. Private cloud's not immune to that. But public cloud's same thing. You have people understand Amazon and Microsoft and people understand Microsoft and, you know, all over the place. Private cloud is less expensive these days because the cost of hardware has come down significantly. So in other words, if we're emulating a public cloud provider, which the private clouds are doing, and we're able to do it on hardware, that's going be a tenth of the cost than it was ten years ago. And that's truly what we're dealing with right now, then that's where the economy comes in. Now, you have to look at anything, any kind of technology out there in terms of the maintenance that goes into it and the skills you have to have around and the cost of the software. Typically, there's free open source private cloud software, there's software you have to pay for as well, proprietary. All that stuff really kind of comes into the mix. But the reason that private cloud is on the radar screens right now is not because you know, it's able to beat public cloud each and every time, but the cost advantages and also the fact that private cloud ten years ago used to be an engineering project. You know, try to do an OpenStack project when I was at Cloud Technology Partners, it was very difficult, very hard to get those things up and running. It's no longer the case. Everything's fairly turnkey now. It works very well. And people who deploy private clouds are very happy with them. So it's cost effective. It should be cost effective for your skill sets, your operations, things like that. What about well, let's talk about private cloud for just a second. I've got another question. This one from Gerard also from LinkedIn. Is private cloud really a cloud at all though? Yes. It's always felt like somebody else's, somebody's own data center with some orchestration dressed up as the cloud to keep leadership happy. Well, is a cloud in the fact that you own the hardware, that's going to be the differences, but that doesn't make it not a cloud. We consider it a cloud because you're able to do self provisioning, you're able to do auto provisioning, auto scaling. You have the ability to mix and match different aspects of the platform to bring together systems and how you want to bring them together. So it looks like a public cloud provider at the end of the day. The menus are the same, the services are the same, object based storage, block based storage, databases, all that stuff is there. You just own the hardware. And again, that could be an advantage in the case that if you're dealing with compliance and you wanna know where the hardware is and your auditors wanna know where the hardware is, well, guess what? Not only do you know where the hardware is, but you can get them into the data center to look at it. And so that seems to be a large advantage there as well. So don't discount private clouds just because they're not on somebody else's equipment that somebody else owns. They function just the same. You just happen to own the equipment. You got to remember private clouds aren't typically something we have to own as well. We can use managed service providers, colocation providers. In many cases, if people are deploying a private cloud deployment, they're not going out to Best Buy and buying their hardware. They're going with a colocation provider that's engaging a contractor to get leases in place to buy the servers, same with managed service providers, they're able to provide private clouds as a service. There's lots of ways to do it, which looks very cloud like or public cloud like, but you still maintain ownership and control of the hardware, which many organizations like. You know, earlier in this discussion, you brought up the idea of FinOps or financial operations as a relatively new practice area. But so just kind of expanding on that. How do you justify infrastructure changes to a finance team? Because we're not talking about, you know, some SaaS monthly subscription here. We're talking about a pretty major chunk of your IT budget. Yeah, I mean, I think it has to be how much value you're able to obtain from it. In other words, if you're investing in FinOps, there should be some sort of a value metric that comes back. And so in many cases, and I've seen this a lot where people are investing in FinOps end up losing money because they're not saving any more money than they did in the past. And they're paying, you know, dollars ten million a year for FinOps assets, including people around to, you know, maintain these systems. So what I would look to do is make sure that FinOps earns its keep and there has to be metrics around the utilization of it. Also look at the inefficiencies they have on your current infrastructure right now. So in other words, we talked about things like over provisioning, under provisioning, not keeping track of what you provisioned, all those sorts of things that are kind of rookie mistakes that are people making when cloud computing and making these days. So if those are systemic to your environment, typically FinOps is gonna have value, but you have to figure out how much value it's going to have. And I think people have a tendency to, when they adopt FinOps, they may over pend on it and then contract it down once they realize that they're not getting the value out of it that they thought. So they may have thirty people in their FinOps organization seeing this firsthand, but get it down to about ten people, something like that for an organization, a global two thousand companies to run perfectly fine. So again, it's becoming smart with the money, smart with the allocate the resources, and that's the way you win with FinOps or anything by the way. Makes sense. You know, I don't know if it's generally known, but in every webinar or online event in twenty twenty five, it's required that you ask at least one question about AI. So here's our AI question. Sure. What about gen AI workloads? Where should training data live on storage infrastructure? Yeah, the training data should live where you can have least cost of maintaining the training data. You got to remember, training data is just data. So it's just data that we may be accumulating inventory information, sales information. Information about our business is going to be most valuable to you to trained AI systems. So on the training side, it should live on any platform where it's going to do the best good. So I don't look at training data as something that's going to be copied over from a transactional system. I look at the transactional system or the system of record that's going to be my training data. And people have a tendency to try to over complicate these things. In other words, if there's going be training data, they try to create an aggregated model of the transactional data and the customer data and the sales data as it exists in some sort of a pseudo data warehouse, so they're going to prepare for training operations to train an AI system. That does not have to be that way. We can use data abstraction layers, metadata management layers to map the data however we want to map the data and use it as training information. So wherever it exists, public cloud providers, on prem, Resilio, you know, all that sort of stuff, that's fair game for leveraging the data. We should stop using these proprietary silo based systems as training information. So to answer your question, it should live anywhere you need it to live that's gonna bring the most value back to your business. I know that sounds like a non answer, but it's absolutely the right answer you need to hear. No. I think it it maps with what we, you know, try to help our customers with, which is by nature of distributed work, distributed teams, global information systems, multinational corporations, you're going to have multiple storage systems across your enterprise environment, And you're going to need to replicate, move, or keep active that data in multiple places or keep it closest to the compute or accessibility or your employees or your teams. And that's a challenge we're hoping to solve. Just kind of wrap it up before we finish. You know, the cloud reset is real. We can all agree on that. What is the one thing you want viewers of today's event to take away from? What what what should they be chewing on after this after this webinar? Yeah, you gotta reopen your minds about what options are out there. I think everybody has a tendency to group think around the use of technology. And so you get into the cloud computing realm, you know, where everything has to move into the cloud and basically thinking in this one particular direction. You're not going to end up in optimized areas when you do that. Because again, if we're moving in a single direction, that's not going to work for everything that's out there. So you're choosing to be under optimized, you're choosing to spend more money, you're choosing not to select the most optimized architecture that you're going to be using for your enterprise. So don't stop thinking like that because I understand it works. People always tell me, well, Dave, I moved everything to Amazon and web services and it works just fine. I get it, it works, but you're paying ten times as much you should be paying for that. That's money that comes out of the business. It has to be spent in other ways. So look at the optimization of the money aspect of this, not just the technology brand name. And I think people are marching in, you know, single directions into, you know, kind of technological thought silos, so to speak. And we need to stop doing that. Think differently. Think differently and move faster. David, I could go on for like another hour, but listen, maybe we'll have you come back for a part two on this discussion in a future show. I wanna thank you for your time. I wanna thank you for your insight. This has been incredibly valuable, and I've learned a couple of things myself. Just to wrap it up, I want to make sure that people know that they can go to YouTube and look for Cloud Computing Insider. That's David's channel, very popular channel. Subscribe to David's information there at YouTube at Cloud Computing Insider. You can also check out davidlynthicum dot com for all things David and what he's doing in his books as well. I would also suggest that folks, I wrote blog about the Cloud Reset. It's on Resilio's website. I believe Kathy shared the link in our chat, so check that out as well. And for those of you who are interested or new to Resilio, check us out, resilio dot com. We're happy to do a cloud assessment with you or just an infrastructure assessment, help you understand how data portability and accessibility can help you move faster and gain a competitive advantage. David, thank you so much for your time. This has been an awesome chat and look forward to catching up with you online. You got it. Thanks, guys. Thanks, everyone.
