The Holy Grail of Truly Automated Multi-Cloud
Allyson Klein moderates a panel of industry experts on how we achieve true multi-cloud automation, the challenges of automation today, and technology advancement in VMs, containers, and web assembly architectures to achieve single pane of glass oversight. Don’t forget to check out ctoavc.com for more of this content and all our sessions from The CTO Advisor Hybrid Cloud Virtual Conference (2023). The CTO Advisor The Holy Grail of Truly Automated Multi-Cloud Play Episode Pause Episode 1x 00:00 / Subscribe Share Apple Podcasts Spotify RSS Feed Share Link Embed <blockquote class="wp-embedded-content" data-secret="5IY9GLclfc"><a href="http://thectoadvisor.com/the-holy-grail-of-truly-automated-multi-cloud/">The Holy Grail of Truly Automated Multi-Cloud</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="http://thectoadvisor.com/the-holy-grail-of-truly-automated-multi-cloud/embed/#?secret=5IY9GLclfc" width="500" height="350" title="“The Holy Grail of Truly Automated Multi-Cloud” — The CTO Advisor" data-secret="5IY9GLclfc" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelecto
Transcript
All right, our good friend Alison Klein did a session, a panel at the CTO Advisor Hybrid Cloud Virtual Event last week, led a great conversation with three other industry giants from Fermion, AMD, and Cloudflare around this whole concept of hybrid cloud, single pane and glass, abstracting away the complexity of the hybrid cloud. I thoroughly enjoyed the conversation, I hope you do too. com to check out all the sessions from the content. Talk to you next podcast, enjoy. Welcome to the CTO Advisor Summit.
My name is Alison Klein. I am the principal of the tech arena and the host of our kickoff panel today. Let me introduce our panelists. Today we've got Rebecca Weakley, Vice President of Hardware Engineering at Cloudflare. We've got Matt Butcher, CEO and founder of Fermion, and we've got Lynn Komp, Corporate Vice President of Server Technology Marketing at AMD. Why don't we go ahead and just let each of you quickly introduce yourselves and your roles at your respective companies. Rebecca, we'll start with you.
Awesome. Hello, Alison. I am excited to be here. I am Rebecca Weakley. I do hardware systems engineering here at Cloudflare, which means compute, servers, network, storage, as well as any kind of low-level system optimization, OpenBMC, firmware BIOS development in delivering 20% of the world's internet traffic. And Matt? I'm Matt Butcher. I was the creator of the helm of the package manager for Kubernetes. After that, I did the illustrated children's guide to Kubernetes, in which I used my daughter's stuffed animals to tell stories about how Kubernetes works.
But these days, I'm the CEO of Fermion, and we're building the third wave of cloud computing. We think of waves of cloud computing being like the first wave was the virtual machine world. The second wave was when we added containers and orchestration systems to that. And the third wave to us is really, you know, kind of powered by WebAssembly. So we built some tools like Spin to be web development tools. And we're really focused on kind of this core user story of making it so that developers can go from a blinking cursor to a deployed serverless function in 66 seconds or less.
All right. And how about Lynn? All right. So I'm Lynn Komp, and I have just started building a server technology marketing organization. And it's super exciting because our job is to basically explain why AMD in a cloud instance or AMD in hardware makes the IT decision makers and the infrastructure and ops teams look awesome and brilliant. So that's what I do. Fantastic. Well, I've assembled you all here today to help me answer one pressing challenge that the industry is facing as they look at helping their customers deploy multi-cloud substantiations across their environments.
And this is something that Keith Townsend and I have discussed, and it's something that I've actually discussed with all of you in the past of why have we seen cloud proliferation across VMs, containers, and now WebAssembly entering the foray, why have we seen that environment get so complex in terms of the numbers of environments, the numbers of types of applications, and the number of instances that any one company is managing at every given moment? And can we ever achieve a single pane of glass for multi-cloud management?
What is it going to take from the entire ecosystem? So I'm going to set this up and say, that is the question that I want to start with. And Matt, you have been involved across VMs, containers, and WebAssembly, so have a very unique purview into all of those environments. I'm just going to ask you to start with what is the problem statement that we're looking at in your mind, and what do we need to start thinking about to frame this question? And this is a great question, because I know we can go a lot of different directions with it, and I know Rebecca and Lynn will both take us in different directions from mine.
I kind of, to me, what has been interesting in cloud is that cloud introduced a sea change along a number of dimensions, but where I think it was really most profound is that it took us from looking at distributed computing as a purely academic subject many years ago to the kind of thing that we're all actively engaged in trying to do right now, right? The birth of the microservice architecture helped us think about composing our applications differently. Containers and container orchestration made us realize, oh, so we can stop thinking quite so much about having X number of servers running X number of applications and start to think about pooling resources and then moving applications to the place that it makes the most sense.
But what I think that caused is this sort of conceptual explosion of all these different services that suddenly we realized, oh, if we start thinking about these services in that same kind of way, then we're going to be able to create applications that have distributed storage and the storage can synchronize here and distributed relational databases, and we're in that phase of sort of like throwing everything out there and saying, let's fill out the conceptual space, and I think we're probably getting close to filling the whole frame of the conceptual space before we start saying, oh, we've created something way too complex for any one human being to keep in mind anymore, and now it's time to start saying, okay, we need to kind of pare back and say, how are we going to manage all of these things?
For me, you know, and of course I'm going to talk a little bit about WebAssembly. I think the interesting thing about WebAssembly is that because it's platform and architecture agnostic, we don't have to build a WebAssembly binary that requires an Intel processor or a Windows operating system, and so we're kind of increasing the mobility of some of these workloads, and I think what's good about that is that's a step toward simplicity, and I think we're going to start seeing a number of these areas, you know, relational databases, for example, I think are making probably the biggest set of leaps and bounds since the 70s and early 80s, and I think we're going to start seeing simplicity and elegance once more trump feature richness and, you know, the great diaspora of services.
Lynn and Rebecca, any comments on that? Yeah, I think, you know, one of the things, when I hear one pane of glass, and it's funny because I just had an analyst recently ask me, you know, so are we ever going to get to one pane of glass for hybrid cloud, and I had to ask them, how long have you been in the industry? One pane of glass is not a new thing, and there's a lot of people who hear one pane of glass, and they think, oh, great, so it's going to solve world hunger and stop the oceans from rising, and so it's been a really great concept, but I think that there's three things we can ground ourselves in, really.
One, the people who are purchasing services or they're purchasing hardware that they're going to try and repatriate workloads onto and move things back and forth who are buying services from multiple clouds, the things they're trying to solve don't change. They need to make sure, did I get what I paid for, and how do I prove it? Did I do everything in my power that was possible to secure it in case anything goes wrong, and then how do I improve and get those insights into where should I run the workload and how can I improve user experience in running?
So that never changes, and one pane of glass or not, there's a number of tools that need to come in that help people and help these people making these decisions who are accountable for what happens understand if I'm running across these different clouds, and most of them have balance of trade with the cloud service providers that are offering these services, how do I manage it in a way that doesn't have tons of fragmentation? And right now, if you just look at FinOps tools, it's a hugely fragmented space.
So I think we're a little ways off from that. I think I have to agree with Matt. Rebecca, anything? Absolutely. The one comment Matt made that made me chuckle in my heart was this concept of cloud is the auspices of distributed computing or something along those lines. And truly, I mean, client-server architecture mainframes started these problems. Everything was solved in the 60s. And we are revisiting a lot of these problems by coming back to a lot of the same things.
And my total nerd, like, love first computer science project was writing, you know, a compiler for Lisp, in Lisp, loves to come back to the world of, you know, ultimately, this is getting down to bytecode and letting developers own that and own that in a distributed fashion. And for me, as a hardware person, the more encapsulated and in some sense obfuscated, I hate to say that, from the specific architecture software can get, the better I can use my Legos to solve their problems. And, you know, as an infrastructure person, that's my job.
It's to find the Legos that work best to solve the problems. The software layers, the tunneling, the challenges that we're going to have from a network perspective, and just Lynn spoke of, you know, balance of trade. This is like the politics of cloud are very similar to the politics of a globally distributed world with many, many, many different fiefdoms we call countries. There's a lot of political, there's a lot of social and, you know, obviously business constraints that get in the way of the concept of a single pane of glass.
I love it. I love it as a concept. We obviously have lots of interesting services that drive to give you visibility of your workloads across these many different clouds. But it is, you know, hard to be Sweden in this world. And we got to own that and think through the specific use cases of large customers, which tend to incentivize our cloud providers to play nicely together, like the UN. Okay. So that's where I'm going, because I was going to say, look, we could just shut down the panel now and say, okay, we've solved it.
But I think I'm going to be a little bit harder on the three of you and say, I still think that we've made it as an industry too complex for consumers to consume cloud services from multiple cloud providers. And, you know, as we look through producing the stacks, producing the underlying hardware, there's probably things that we can think about that we could do better. So my next question is, what can be done to incent those public cloud providers to deliver full multi-cloud management access and, you know, eliminate this concept of siloed services?
And I'm going to send that to Rebecca. Oh, friend. Let's start at the very beginning. There's a lot of fun in, again, this comes down to business incentives, as far as I'm concerned. So when you are setting up a complicated network distributed across, in my case, 296 cities in the world, over a hundred countries, you're going to have a lot of reasons to focus first on making sure it works, works within your environment before you get to multi-vendor testing, but it is the customers.
It is when we get to fight for the user that we have the strongest incentive to partner, right? So, you know, our cloud network interconnects or private network interconnects with other cloud providers for the sake of our magic product line, right? The ability to do tunneling across, whether for WAN or WAF or different networks and to have secure traffic go between these entities. This is a huge opportunity to make sure that our clouds all work together. Similarly, things like R2, right?
Distributed storage. Matt already brought that up earlier. These are areas where getting access to user data so that we can give them the best user experience for how network traffic is running or what's happening, you know, in terms of development in a worker's environment. These are areas where we have to partner together to be able to deliver the service to end users. So, it is at the intersection points of a customer's demand that we are going to see everybody play nicely, right?
This is kindergarten rules. Just to play it the way that I see it. You know, if you want to share your sandwich, you're going to be nice to one another. And that is how things work in any kind of business culture, I would argue. So, that's where I'm seeing the more we have specific use cases that need to be enabled for customers, the more we're going to play nicely. And that's the only way it's going to happen. So, when user communities get together and talk about best practices and talk about what they expect and then hold their vendors accountable, that is when we will start to see simplification, at least for flows like FinTech that Lynn brought up earlier or, you know, any kind of, obviously, network traffic is an area where we spend a lot of time thinking about zero trust and network traffic.
Yes, I did. So, I was going to ask another question back in. I'm not going to take your job, Allison. You're an amazing interviewer. So, you know, it's interesting because one of the questions that I do have is every IT deployment, every infrastructure strategy that many of the big enterprises have, it tends to be, in the end, a snowflake. And so, there's a lot of help between the major cloud service providers and what they can do versus the channel of integrators, MSPs, farms, GSIs, et cetera.
And I do wonder how much of bringing things together is really going to fall on that part of the ecosystem, mostly because it's really difficult for any cloud company, Amazon, Google, Microsoft, CloudFlare, whoever it is, how can they come up with something that's so bespoke as to perfectly fit the specific IT needs of a very specific enterprise in a specific location? Isn't there a part of that people who are the hands and feet to make certain things deploy, how much do they actually have a role in this?
It's a really good question. Matt, any thoughts on that one? There's so many things, so many ideas floating around here. And I really want to kind of pick up on something that Lynn started on in her first question that reminded me of a book I read many years ago called, I think it was In Pursuit of Elegance, that, you know, the point at which we started this morning, you know, this discussion is saying, look, complexity has gotten out of control. And we start to frame the solution of complexity to be simplicity.
And the kind of cool thing about this book, and I think Rich Hickey, who wrote The Closure Programming Language, picked up on something similar to this. There's a difference between simplicity and elegance, right, where elegance is, you know, the Steve Jobs fanaticism about the iPhone having just the things the user needs right in front of them and easy to access. That's probably where we really need to go, is back toward elegance. And to kind of weave this then, you know, through what Rebecca was saying, and back to your original question, Allison, I think then, you know, the challenge for us now is, can we as an industry now embrace together this concept that, look, we're at complexity.
A simple solution is not what we need. A really elegant solution is what we need. And I think when Rebecca started talking about the policy part of it, I think that's definitely a huge one. I mean, we cannot understate the importance of all of that. On the technology side, I guess where I'm kind of hoping to see things shift to is along the same lines of what Rebecca described, that, you know, technologies like Kubernetes were supposed to offer a solution to some of this complexity that was supposed to be elegant by saying, look, any cloud provider that has a Kubernetes offering, the developer can take their workload, the DevOps and platform engineers can take those workloads and move them around, right?
It's a, but it's only a very small slice of the big pie of cloud services that that has been working for, right? So my hope being kind of, you know, technologist at heart is that we will begin to build technologies again the way we did 20 years ago and say, okay, standards, you know, GCP IP was a great innovation. Do we build, do we build a couple of new layers of standards that will help us implement that kind of technology policy? Such that we will be able to manage things regardless of which cloud they're on.
We'll be able to move workloads to the places where it's most cost effective or most performant or whatever our particular goal at that moment is. That's kind of the, that's kind of the direction I'm going. And now I've completely lost the track of Lynn's follow-up question. So I'm just going to stop right here and let somebody else jump in. So, yeah, I will say what Rebecca's entirely right though, commercial interest. We tend to forget about, we love technology. We want to create this elegant technology because we're all nerds.
And at the same time, when there's commercial interest at play to not play nice, you could end up with a situation like what you had, I don't remember how many years ago it was where basically the US government told AT&T, no, really, you have to make the interfaces something that other people can have access to. You cannot treat it like it's an entire silo. And so the question is really, will it be commercial interest, like what Rebecca said, or will it be something else?
Because this is truly a utility of capabilities and services that everyone depends on. So I don't know which of those two forcing functions is more likely, but it's going to be. I have to believe I will, I will pick an open mark up born capitalist. I will believe a business model that is logical and capital constraints pushing us towards the right things versus government policies towards technology. As a security company that operates in many different countries, we have a lot of eyes on compliance and how we do this correctly.
And it is a lot of work, not necessarily for better end states for users. And that is a trouble if we do not have technologists. And there's wonderful programs out there to try and bring more technologists into our government programs, and they are getting better. But if we don't have people who deeply understand what we're dealing with and can come up with an elegant solution, we end up with simplified standards that are really quite difficult to work with. And the inner technologist in me wants to say, no, no, no, give us guidelines, give us rules, give us principles, help us understand.
What is what is the Antoine de if you want someone to sail, you know, make them yearn for the vast and endless sea, something like this, right? Don't give them wood and tell them what to do. We don't do well, I think, when policies are so prescriptive. They need to be descriptive of what we're trying to do and then let technologists solve these problems. But if commercial interests get in the way where there's so much boundary and so much disincentive to solve problems, that's where I think government does have to start to say, hey, no, play nicely.
AT&T example, great example. So, Rebecca, I'm going to throw a question back out to you is, you know, we've talked about how the complexity of our stacks and maybe underlying hardware are some of the key determinants of the complexity of cloud. Do you think that government regulations should be looked at as a third pillar of complexity as we try to solve towards that more elegant future that Matt describes? Absolutely not, but yes, sort of. I will put on my other hat.
So in my intro, I talked about Cloudflare, which I love, but my other hat is Open Compute Project, and obviously I'm the chairperson of Open Compute Project, which is really about the community coming together and establishing the norms, the policies, and obviously the specifications we need to follow to have systems work, right? Whether NVIDIA's making the ASIC or Broadcom's making the ASIC or Intel's making the ASIC or AMD is making the ASIC, how do we make sure these things play nicely together? And there are plenty of standards bodies, whether we're looking at PCIe, USB, JEDEC, the world lives on standards and hardware, and we like those.
And letting those technologists work together to come up with the defined plans so that Thermal's electrical work, much better place than letting the government try and define these things. It's just, it's not logical. That's not what they've specified and worked towards. So I'm a huge fan of open source, open projects for collaboration to drive closure on what we need to accomplish. It often leads to not perfection, right? VHS, Betamax, like what wins in the community is not necessarily the best and most elegant thing to go back to Matt, but it is the one that has market pressure behind it.
And the one that works, that makes us have less complexity is the one that will win. And so there is this kind of simplicity, complexity, elegance spectrum and community winning with their feet is probably the only thing we can really rely on to move forward. That's why I think it's so important that we get involved in open and community environments. We cannot solve these problems in our silos. No one company is going to be able to solve the complexity that is the cloud.
It's just not possible. One of the more memorable meetings I had, I was at Microsoft for many years and one of the most memorable meetings I think I had there was when the topic of hybrid cloud came up and people started in the room started saying, you know, we really need to make sure that we deal with this by making it easy for people to move off of Azure and onto other systems. And my eyebrows sort of shot up. I'm going, wait a minute, you know, we want them to run on Azure, right?
And somebody, you know, at some point somebody said, why are we talking this way instead of talking about wanting everybody to stay on Azure for all time? And the answer that came back was, well, you know, what we're seeing from our customer base is that when we're signing big contracts, there's a checkbox on there that says I can migrate off to another cloud. And that moment was a moment where I realized, okay, you know, when and to kind of Rebecca's notion of community, I like to think of it primarily in terms of open source.
Again, my background, I think the same way, but that was one of those moments where I had to realize that my view needed to be a little more expansive, right? That this was essentially an ad hoc community of CTOs in large companies had sort of formed merely by saying vendor lock-in is something we did before back then and we don't want to repeat it in the cloud world. And that to me is, you know, going to Rebecca's point of like, the government should really be the standards body of last resort, right?
But one of the things we can do to get, you know, us as vendors, one of the things you can do to get us as vendors to not try and go the lock-in route is to say, we really, that's not what we desire as users. And that's an anti-feature and something that is going to prevent us from wanting to use your product. So that one moment was for me kind of one of those profound experiences of going, oh, right, okay. So community is a bigger thing than I thought.
And there can definitely be some sort of upward pressure from the community back to the people who are, you know, earnestly trying to figure out how to pay the paychecks of all of their employees and rightly so. But you can put pressure on them to say, these are the features we want. And one of those features has to be the interoperability story among, you know, along multiple dimensions. And I think it's still for us to kind of figure out which ones we need to push on and say, we need more interoperability over here, a little over here.
Yes, you're going to build your awesome thing over here and that, you know, go ahead and do that because I really want to use it. But we need a story here for migration or interoperability or hybrid. Yeah, I have a great example of industry giants being able to come together, come up with a standard where things are interoperable. And it's the ITU and cellular standards. So, you know, if you think about it, those have to interoperate. There's a huge global implication.
And it's in their commercial best interest to make sure that things can interoperate, because, you know, trying to get spectrum and frequency, if you've ever looked at cellular spectrum maps within each country, it's nuts in terms of what you're trying to work around. And, you know, the other thing that is true is when they figure out how do we actually come up with a standard we can agree on of how these complicated systems and cellular networks are probably as complicated as cloud architecture itself, they can make things work.
And, you know, there's another time that we've seen a commercial alignment between large vendors kind of onboarding the most elegant technology. Everyone remembers Iridium, which was before SpaceX, there was Iridium. And what ended up changing the trajectory of that particular project was the fact that the European operators realized, you know, people just want to be able to use the same number in Britain that they actually have in Germany. Let's just sign commercial agreements. And with a stroke of a pen, things were interoperable because of the ITU.
And, you know, Iridium had a very long wait until we had SpaceX. So there's a couple of good examples and reference points from other similarly structured, similarly complex industries that I think could be used. And it really comes down to, I think, this particular cloud industry as a whole saying, you know, let's be pragmatic about how things are really going to work. And I agree completely, Rebecca. The technologists really need to be able to come up with the elegant and appropriate solution.
Because if it comes down to policy, I mean, you're talking about people who have no idea what they're legislating. So I agree. Lynn, I would be remiss in not sending you a question about hardware's role within this. Your company just released an announcement that you were doing a very cool collaboration for multi-cloud across AMD abstentiations in multiple clouds. But it gave a reminder that there's a limitation here, right? There's a limitation to how customers can use that. Do you see a day where we get past that?
What do you think about that? And what should the silicon arena be thinking about to contribute here? So, wow, lots of questions in there. In terms of multi-cloud and limitations, you could probably guess I do have a deep network background. And so I feel like there's a point at which going too far with distributed anything is going to run right up against the reality that bandwidth is not free. The network is never 100% reliable. And so I think that there's going to be a limit on how far we can go with that.
And the other reality is most of what AMD has done with the EDA tools that we use for basically constructing our silicon, a lot of that is hosted in the cloud. But very often you will find, and I'm sure Rebecca is going to nod her head on this one, you will find that you might need to have those resources in Japan. But the closest thing is in Korea. And by definition, the type of workload, thou shalt not cross those boundaries. So I think that there's just some pragmatic limitations of policy placement and where you actually have availability zones of what you can do.
Because it makes no economic sense for every cloud provider to have exactly the same resources everywhere that they're operating. And then as far as silicon goes, I think that it is contingent on the silicon vendors to come up with innovations that give the maximum flexibility. So one example that I've learned recently is CXL is something that I looked at. And I thought as a motherboard systems engineer, that would be really cool to help increase your memory for core. What I actually learned is that kind of capability can support memory tiering in a cloud instantiation.
So how we would think, oh, this would be useful. We actually have to talk with our customers and say, how are you going to use that to make sure that we actually got it right? Matt and Rebecca, any comments? Well, I could talk for days about CXL, but I'll restrain myself. Because of course, as soon as you cool and disaggregate memory, now you have to think about reliability on a totally different level. And that's a really fun problem to solve.
And how do you expose that new tier of memory in a transparent and interesting fashion when you've got WebAssembly running in some applications, Rust for other... The world is still quite complex to deal with changing the compact between compute and its memory devices, but we're going to do it. And that's really exciting. I think we're in a very interesting place. I've said this multiple times that it's so true that we are at the golden age of silicon. And I say that with all due respect for the era that was the 1960s, where everything was invented.
But we really are just scratching the surface of what we can do with the material science, with the physics, with the... It is so cool. And I think what I really get to see is that we're seeing some of these most large and influential clouds, right? GCP, Azure are coming together in communities like OCP and driving those standards, in communities like CXL and driving those standards. So they really are working together and seeding the future in ways that, you know, I hope we'll never get to the AT&T moment, not to pick on AT&T.
They've obviously changed a lot of things about their life and business model. So I am super excited about it. I think silicon vendors have a role. I think the standards bodies have a huge role. And I think we have to keep seeing the leadership of these largest clouds. I love your example, Matt. But in Azure, they were like, we're not going to win the biggest customers if we don't check that box. That is where voting with our dollars as consumers is going to help us.
And then the last thing I would say is as consumers think about sustainability, and we've talked about this, Allison, like as they think about the value of doing the work and not backhaul bandwidth, the point that Lynn was making, in a different country, or as they think about their privacy concerns and become more informed about whether or not their data is leaving their country or their, you know, EU region, that creates new constraints that we as vendors have to support and supply. And it's also another aspect.
So you can vote by having the big checkbox if you're a big company. But even as a consumer, if you are willing to think about, am I doing this in a greener fashion? Am I doing this in a way that I am protecting the privacy and the rights of not just me, but my children? And if you bring that knowledge as a consumer into your experience, you will demand those companies to be better. And they will only be better. Back to the, it's hard to be Sweden.
We will only be better if you demand it of us, right? Okay, I do have one thing that I should put out there. It's just that sustainability and physics, which I love too. So I think one of the things as a, you know, that I would say to anybody that is using silicon in their systems, which is, you know, pretty much everybody, and it is a golden age. ISA is not implementation. So I have built, I have done silicon for base stations.
I have done silicon for smartphones. I have done silicon for server infrastructure. I've done things for NFV infrastructure. And, you know, instruction set architecture, and AMD is neutral about instruction set architecture, but an ISA is not an implementation. And physics is still physics. You still have to run the same freaking program, whether it's reduced instruction sets or complex instruction sets. And so in terms of thinking about the sustainability perspective, you know, like just one example, when I was marketing a product that was, this will tell you how old it is by the way, 200 megahertz and was 30% more TDP than the next nearest competitor, which was running at 40 megahertz.
Now this is a cell phone. And what was really fascinating is the lower TDP device at 40 megahertz actually had worse battery life than the 200 megahertz processor that had a little bit more TDP. But it's called the race to idle. And basically you see a lot of that even in the infrastructure place. So it's one of those things where it's like ISA is just an ISA and you have the same work to do. And I think it is really exciting because we're seeing a lot more innovation happening in a lot more architectures than what we saw 10 or 15 years ago.
Matt, 30 seconds to close down this topic if you want it. I just, there's something that just emerged in from Liv's last two answers that I think really encapsulates why conversations like this are so cool. We just saw sort of unwrap here, this idea that we really as technologists are pushing forward experiments and innovations. Then we observe how people use them. And then we end up in this decision-making process where we're going, oh, now we need processes, policies and standards on top of it.
And that fact that that last part is reactive is really facilitated by the fact that this whole process is an experimentation in improving all of this. It was so fun to watch that story sort of narrate itself in the course of this conversation. I loved it too. And Hot Diggity, this was a good panel. I knew that the three of you would come together and really knock it out of the park and you did. I have one final thing for each of you.
And I want to have you give your final thoughts, but do it from a standpoint of, I'm a customer listening to this panel and I just want to know how to take action. So we've discussed a lot of things. What should they go do now to engage with the industry? And what are the most important things that they do to ensure that their voice is heard in this key challenge? Rebecca, go first. I think I've said it. I think be a conscientious consumer.
Think about not just right now, who's giving you the cheapest bill. Think about what you're going to be facing in four years when renewal is up. Click the box for multi-cloud. Yes, it is more complicated, but whatever bargain deal you're getting at that exact moment, it's going to be more expensive in four years if you put yourself in that corner. But recognize it's complex. There's going to be many different elements that come into a multi-cloud strategy. Focus on your core business.
That's fine to keep on-prem. Look at hybrid. Really understand you have to look at the long-term and you're going to have to stitch this problem back to Lynn's original snowflake portion. You're going to have to stitch this problem through your cloud, through their clouds. Losing the expertise in that domain is probably not your best corporate decision. All right, Matt, you're up next. I'm just going to riff on what Rebecca said. And a little bit earlier, and we got this experimenting part of the journey where we build a new technology, we put it out there.
For technology to evolve well, technologists need that feedback from it. And Rebecca articulated that by talking about community. Those voices are profoundly impactful on the next phase. I was just trying to paint the sandwich picture, right? The bottom layer is the innovation. Then there's this period where we see how the innovation takes hold in actual practice. And the feedback out of that informs how we do the policy layer and the standardization layer, the higher level standardization layer. And that middle part is the part where you have this profound ability to impact the shape of the technology as it evolves.
And Lynn, why don't you bring us home? All right. So I think one of the biggest nuances that I've seen get lost over the last X number of years that I've watched cloud evolve, a lot of people focus on where the workloads run. And there's this whole repatriation initiative that seems to be on the way right now. What many of these customers and consumers forget is data, data movement, data redundancy, data management. And a lot of people think about how do I have workload flexibility in multi-cloud?
But they kind of forget that if you're not artful in how you approach the question of data, you could end up with an absolute hotel California effect where sure, you can check the workload out, but your data is never going anywhere. And I think that is the main thing that I would say, pay attention to that because workloads matter, but your data is your mission critical enterprise business value. Way to sneak that small topic in right at the end, Lynn. That was fantastic.
Thank you all three of you for being with us today. And that was a fantastic discussion.