What I'm doing is I'm looking at the color of your skin as you open and close different windows. And I'm trying to figure out what you're doing. It'd be like one of those research articles. We were able to extract the contents of email people were reading through their webcam by looking at reflections off their skin.
Exactly. That's exactly right. Because Mark Russinovich and Scott Hansman had such great skincare, we could see the reflection in their pores. Yeah. Then we do de-blurring from the reflection. You can see... private Microsoft information in the reflection of my... In your retinas, actually. In my retina? Oh, God. Actually, your glasses probably. I can probably read your email from your glasses. All right. La la la la la!
Hey, friends. I'm Scott Hanselman, and Mark Rusinovich is here checking email. Busy man. I do not have a problem with you checking me out. Let me know when you're ready for me. Doing our show. I'll let you know. Go ahead and get on a Teams call and I'll let you know when we're ready for you here on the show.
i want to say it was 1990 something something and i was working at 800.com and we were selling three dvds for a buck and um when we did that three dvds for a dollar promotion it changed the way that the site traffic work and it was on the usenet and it blew up the internet like everyone rushed
to 800.com to buy three DVDs for a dollar. And historically, 80% of our traffic had been people wandering around on the product catalog. And then 20% was people checking out of the shopping cart. And then... Once everyone had picked all their DVDs, the traffic changed. And it was like, everyone was done going through the product catalog. No one was going through the product catalog. Everyone wanted to get through the shopping cart. And we had to go and...
change the way our site scaled. This would be like a very simple problem with Kubernetes today. But then it was redeploying. It was thinking about hardware. We had shoppingcart.800.com. We had to go down to PC Micro Center, buy... racked computers, stick them into the rack. Is this going somewhere? Scaling the web farm was a physical thing.
But now it's just a command line. It's just a checkbox. It's just a slider bar. What happened that we needed to go away from self-hosting to hiring a local host, a local company? put our computers in a box and put our computers in a big giant Costco, to the elasticity and the programmaticness that we have with the cloud. What business, what capitalism caused the cloud to need to exist? That's a good...
way of framing that question. Because I think you were racking and stacking your own servers, it sounds like. Yep. And people still do. Like Blue Sky has got their own servers. But then there was hosters, too, that they would rack and stack them for you. And just give them to you. But it was very much, you know, you order the server and spec it. Yeah, call Dell. Yeah, and then they deploy it.
and then give you access to it, and then they would manage it. But it was very much just, you know, you get raw access to the server. The economics that led to it, I think, were, first of all, the rise of the internet and internet services, especially services that were... driven by mobile. In fact, the way that I actually got into cloud was I was in Windows. I joined Windows in 2006. And it was right then that the mobile revolution was happening.
I was in Windows through the end of Windows Vista, Windows 7, and then Windows 8. And one of the things that I looked at was... What was really necessary to scale mobile were centralized services. And this was very much aligned with what Rayazi had put in his memo in 2005 that he sent to the company, software. as a service. And services were the future of Microsoft. And this was like echoing Bill Gates' internet tidal wave memo from the 90s, saying Microsoft needs to get...
to change itself to embrace this service world we're in because of mobile. And a year later, Amazon launched AWS with EC2 and S3 that were... that they built for their own services, for their own Amazon.com services. Microsoft actually had, in parallel, been looking at what kind of platform we could build for our own services internally to make it easier for people to deploy and build these services.
And that led to the launch of something called Project Red Dog, which literally as I was joining Microsoft in mid-2006, the Red Dog team was forming. My hero, Dave Cutler, who was the creator of Windows and T and VMS, joining Windows and... to work with Dave, and he's like, no, I'm joining this Red Dog thing to work on. Just when you show up to work on Windows, he's like, no, I'm going over there. Yeah. So a small group of people working under Ray Ozzy were...
seeing if they could build a platform for services. So if you take a look at Amazon and Microsoft, the genesis of the clouds for us were focused on serving our own service needs, but then saying, hey, we can also make this available to customers as well. And this is a big difference between hosting your own platform and hosting a platform for other people.
that brings a huge amount of additional work and complexity because of the fact that you can trust your own people, but you can't trust the public service. the people that are going to be using your public service. Was it the case that at Amazon, they had basically separated things where it's like, we have this shopping thing we need to build?
And we're going to need hosters to do it. And we're not going to, like you said, we're not going to trust other people to do that. So we'll create a platform group and they'll do the hosting. And we had similar things going on with Halo and with Xbox and with Xbox Live. So like Halo multiplayer was huge.
had their own cloud, lowercase c maybe, as well, that wasn't in Azure. And they were learning about elasticity. They were learning about orders of magnitude of scale. Yeah, so that's true. And teams like... you know, Hotmail and Bing and whatever, they were building their own kind of platforms. But that's different than cloud. And in fact, when I joined Azure in 2010, there was even raging debate. And NIST came up with, here's the definition of cloud.
which has had like five attributes. And all of these attributes distinguish it from hosting or creating your own internal scaling platform. Like it has to be multi-tenant, it has to be on demand, it has to be self-service, and I can't remember what the other ones were. Those were some of the definitions. If you take a look at those, like on-demand self-service...
those bring in some requirements that you don't have with your internal platform. With the internal platform, somebody wants to scale something, they can open a service ticket and it can be like days. And so the platform... It goes and manages to scale. On-demand and self-service means, like you were saying, you move the slider. And that's your way of saying, I want it to scale. And you expect it to scale.
You don't, humans shouldn't be involved with like, oh, Scott moved the scale, it's lighter. I need to go like. And that's the part that I have my head kind of having trouble getting around is that I. We went from a time where a business person would say scale on a Friday and they would go golfing and they would come back on Monday and the scaling problem would be solved. But we worked all weekend racking and stacking servers.
And now it's a checkbox. And as someone who's been on both sides of that, it feels weird. So as we try to explain what the cloud is to young people, to early in career people who weren't there in 2006. the appreciation for what is happening to make something of the cloud, I think is missed. Yeah, it's kind of people just take it for granted once it shows up. Going to the economics, so what drove the economics of cloud?
It's the multi-tenancy. It's the fact that instead of getting dedicated servers, now I'm using servers from a giant pool of servers. That actually allows me to scale in and out and save money. Because I don't need, and this was one of the big arguments for enterprises about what's the value of going to the cloud, where there's two big values. One of them is if you've got workloads that are elastic, or...
Like you have to spin them up, like test resources or spin them down. What you do typically do in enterprise, you just need to provision for the max because you have nowhere else to go other than your own. And we used to talk about, well, we have 30% CPU as a good baseline because we have room and we have headroom, or 60%. We would all decide as a workload what was a reasonable amount of headroom, but everything else was wasted.
We were not running those servers a lot. If they're not being used. If you talk about a company that does taxes or a company that does financial reportings, so those things are going to burst at the end of the month or once a year. and they've got a provision for that max capacity. Whereas when you're dealing with a multi-tenant environment, you do statistical oversubscription, which means...
There's a whole bunch of customers in there. They all have peaks, but those peaks happen at different times. In an aggregate, the amount of capacity there satisfies everybody's peaks, but they can all scale down and the cloud can drive.
close to 100% utilization, giving everybody this illusion that they can scale down and they can scale up and it's kind of infinite and they can do it whenever they want to. And so that is part of the economics of the cloud. The other part of the economics of the cloud is agility. Because again, self-service on demand, API-driven, just go do it means that you can stand up a new site.
within minutes. And like, you know, in Azure, this was one of Scott Guthrie's in the early days of Azure, he's like, I want it so that you can go to Azure Web App, in 90 seconds, you have your website. But there's a VM underneath and something has to be kept warm. Like, keep the car running is what he's saying.
But in keeping the car running, then it's on us, it's on Azure, it's on the cloud hoster, the cloud provider to be smart about economies of scale. Otherwise, then it's just somebody else leaving the car running all the time. idle cars because then you're wasting energy you're hurting the environment etc etc yeah okay the um the scale up illusion is very complete like there's I can go from 1 to 30 like that, but I don't see what's really happening in the back end. It's looking for capacity.
all over? Is it like, remember in the old days when we used to defrag our hard drives? I imagine, this is how I visualize the cloud, I imagine like a Costco, like, you know, a Costco warehouse filled with computers. And then I zoom out and I look at it like a defrag thing. And I'm like, okay, my computer is here, here, here, here, and here. Now that's multi-tenancy. But when I was working in banking and we were going and selling multi-tenant banking systems, the banks were like, no.
I don't want to be on the same physical computer as my competitor because bad stuff could happen. The idea that we would all live in an apartment, like I don't want to hear my neighbors. I don't want to hear the people above me or below me. How did we get past that? And are we still bumping up against people who don't like that idea? So you bring up another technology that led to cloud, that cloud is built on top of, and that's virtualization.
virtualization and compute virtualization and networks, the ability to segregate people in a safe way. In fact, in the early days of Azure, I wanted to really reinforce the difference between enterprise multi-tenancy and what we had to deliver in Azure. And so I came up with two terms, enterprise multi-tenancy.
to represent the kind of tendency that companies have in their own self-hosted infrastructure, which is, hey, we want, Scott, you're causing noise by DOSing or so much network traffic that you're basically DOSing the apps around you. Why don't you just cool it? Denial of service. But somebody would come and talk to you about changing your app's behavior to not affect performance of the other apps in the infrastructure. Enterprise multi-tenancy is kind of friendly multi-tenancy.
And by the way, you won't do something bad like try to DOS everybody because you'll get fired and the company will take legal action. So there's this kind of this friendly nature. and disincentives to do harm, where if you've got a public cloud where anybody can come in with a credit card, even free trial, and they can come in with their own motivations like, you know what, I just want to DOS the cloud.
The term I came up to represent that is you've got to assume that your customer is hostile. Now, typically they're not going to be. It's going to be Scott, who's just trying to run his website, but somebody could come in. Zero trust. Zero trust, yeah. So we call it hostile multi-tenancy for what we've got in Azure. And that reinforces the fact of, I need to be defensive. I need to anticipate somebody wanting to do bad things.
Virtualization is a way we believe is strong enough given there's a small what's called trusted computing base around a hypervisor and the supporting software to isolate compute in a safe way. We treat it as a security boundary. There's very few vulnerabilities. When there are, we can patch them very quickly. And this is the same assumption that all public clouds are built on top of, really. It's virtualization.
And then we also virtualize the network as well. Instead of having physical networks and ports, it's all virtualized. That, I think, is, you know, amongst cloud people, they get that that's amazing, but software-defined networking. is the thing that is underappreciated. The idea that we think about ports and nicks and stuff like that, but they don't exist is...
Even to me, it's crazy because I've rewired my whole house. And we've talked about how, you know, you had a guy wire your house and I wired it all myself and I know where everything is. But like, I probably could have just come up with a software-defined networking solution for this. I can't even visualize it, how it looks in Azure. Yeah. I mean, it's going to what you were saying. Everything is virtualized. There's physical resources underneath everything at some point, you know.
It's an illusion, right? Yeah, there is a physical wire and there are physical nicks. So you were talking about the Costco and how did we place things. We've got a very sophisticated what's called resource allocator that goes in when you deploy a VM, figures out...
given this pool of servers, where's the ideal place to put that VM? And ideal means, well, first of all, there's hard constraints, like you said you want this size of VM, you said you want this much network, or whatever other characteristics you wanted. Got to satisfy those first. Secondary constraints. We want to make sure that we're not fragmenting the server capacity. If you allocate a one-fourth size VM...
We want to put it on another server that already has one-fourth-size VMs on it. Because if we place it on an empty server, that means a full-size VM, full-server-size VM, can't land on that server. And we want to keep full... servers empty as much as possible so that we can satisfy somebody's deploying a full-size VM. That allocator is actually incredibly sophisticated, and I'm a co-author on a paper on it that we call the scheduler Protean.
And there's a paper that we published a few years ago about the design of Protein at the time. It's been evolving since, but it's a fun problem. And we use machine learning now, too, to predict. VM arrivals, so we can say, oh, it looks like given anonymously, of course. Scott, every day, deploys a VM of this size. Right, yeah, person, GUID, something, you know, this GUID, he shows up on Tuesdays.
They're probably going to show up next Tuesday as well. And so then we can allocate with that in mind of knowing, hey, Scott's going to deploy a 1.4 size VM. Here's the place where it can go. We also know spot instances too are preemptible VMs. We try to make those last a long time. So we use that kind of ML and history to know if we put this spot VM here, it's unlikely that somebody with an on-demand VM is going to come and force us to kick it off.
And many years ago, I want to say five, maybe even 10 years ago when the cloud was, you know, like in the middle of the cloud, like, you know, like this has been 20 years, 18 years. I think it was Aaron Crockford, somebody from Fastly.
who was talking about his relationship with the decision-making process that they made at the company he was working at at the time, which was to switch from spinning Rust, spinning hard drives, to SSDs. During that time when the cloud was moving from... hard drives that spin to hard drives that don't spin.
And some person in the audience came up and asked him a question and said, well, you know, SSDs are very notoriously unreliable and they stop working suddenly. And, you know, there was a time when an SSD would either work.
or it would stop working. And there was no warning, at least with a spinning rust hard drive, you got a little bit of a warning that it might go sick. And they said, what do you think about that, sir? He was basically accusing Aaron. He's like, wait, this is a huge problem. And he says, that's not my problem. That is the cloud's problem.
whether or not 20% of the SSDs fail, I don't care. And that was a moment for me, just like my brain exploded because I was like, I don't know how much of the cloud could be broken at any time. Could be 1%, could be 40%. But that's hidden from me. It's like saying I could drive with three flat tires. Do you think about how much of the SSDs, I'm just making that up, could be down at any moment or VMs could disappear and the cloud continues?
Absolutely, because a resource that's not working is a resource that we've paid for that we're not making any money off of. And then there's also cost to repair. too. So those things balance together to have some amount of the fleet is always out of service. In fact, we call it OFR, out for repair. And we try to keep that number as low as possible without the economics of...
you know, keeping standbys and having too many repair technicians and that fine balance there. But so it's low single digits, like in the low, you know, 3% or lower is out for repair. it's because it's a fleet it's like you know if you're a rental agency like hertz or avis you know yeah some of the cars are going to be broken some of the buses are going to be broken you got to go and have mechanics fixing them and then once they get fixed they just
they're back into the fleet. The scheduler knows that they're available now and they just get picked up. And by the way, that highlights something else that people recognize as a key distinction between your own infrastructure or hosted infrastructure and cloud. and cloud-native apps, and that is the distinction between a server that has got your app running on it and it's got a name and you don't know how to rebuild it, so you take care of it.
And those are called pets. And then there's the fleet of servers or virtual machines where if one goes sick, you can just redeploy it. And that is what people called cattle. I know that there's kind of... cultural sensitivities to that, but that's what the people would describe, the distinct difference between enterprise. Things you love and things you don't love as much. Yeah. Interesting. Okay. We talked about the...
the formation of Red Dog is the project that we're going to create an internal cloud platform. And so the Red Dog team went around and talked to Bing and Hotmail and to try to figure out how to build that platform. And one of the ideas they came up with is we're going to make...
an app model, an application model. It's called cloud services for people to be able to define their apps that are typically web-related apps, right? Web plus database. So Azure SQL. Azure SQL plus cloud services plus a network, endpoints. And you've got your cloud at that point. And by the way, it's designed to be cloud native. You can scale these cloud services out and in. And you don't have to manage the servers. You just give the code, the cloud services code.
And we deploy it and run it. It felt like heavy containers to me. It was heavy containers. Containers didn't exist, so we made really heavy ones. Yeah, and people, so the term to describe... this model where you just give the code and the infrastructure is taken care of as platform as a service or PaaS. So Azure was born as PaaS, not just PaaS, but Windows only PaaS. And so when it...
was announced at the PDC in 2008 by Ray Ozzy, was announced as Windows Azure. So when I joined in 2010, a few months after the commercial launch in February of that year, it was called Windows Azure, and we had cloud services. Windows-based. And this is kind of interesting because when I showed up the first day, the engineer that ran the app platform team...
He's like, hey, he's one of those people that likes to go for walks in your one-on-ones. He's like, let's go for a walk. He takes me on this walk and he's like, so here's the deal. There's a raging debate. Should we do infrastructure as a service? IaaS. And what IaaS is, is give the customer a virtual machine. Let them deploy the software onto it.
The benefit of that is you can lift and shift your existing software from your on-premise to center infrastructure into the virtual machines in a cloud if it's got the right capabilities, making it really easy to move into a cloud. Whereas PaaS, like Azure's cloud services, required you to rewrite your app to work within its constraints. And so the debate that I showed up for was, should we do IaaS? And there was a...
contingent of people that were very much like, has is the future. Like, we shouldn't waste our time on the past. And so this engineer was looking to, he very much believed that Azure needed to do IaaS and was looking for... people to recruit to help push it. So I shut up and I'm like, I can see both sides. I see paths of the future. I also see IaaS as a place to, what do we call, meeting customers where they're at.
This debate lasted a while, and then the head of Microsoft Sales actually had a meeting with Amitabh Servastrava, who was running Azure at the time, like in 2011, so about a year after I joined. And he's like, look. I'm being told to sell Windows Azure. I can't sell it because customers want IaaS and you're not giving me IaaS. So unless you give me IaaS and promise me IaaS, I'm going to stop selling this. And so Amitabh came to me.
and said, hey, what would it take for us to do IaaS? And so I sat down with Corey Sanders, who was the program manager for Compute at the time, and we wrote a paper, like, here's what we need to do to build IaaS. in Azure. And so we started building that. Then the paper, Amitabh was like, yep, let's do this. And a year later, we launched IaaS. And I remember that date very faithfully because we turned on IaaS for the public a year later.
We all went into one of the engineer's offices because we'd storage and the disk drives being served off of storage for these VMs. We were worried about, because we didn't have real disks for our paths for cloud services. We had to have disks for IaaS. is will storage hold up to the load of people starting to use this thing? And so we're sitting in the office watching a line of storage IOPS on the back end looking...
And nervously to see if Windows Azure was going to fail because we didn't have provision enough capacity and storage to handle the load. And fortunately, it didn't. But that was kind of a cool moment. I remember that you could just, you can still, you can go onto disk management on your Windows machine right now, go to disk manager, say create VHD, make a VHD, just a virtual hard drive.
upload it into Azure Storage and mount it and go in and then remote desktop into a Windows machine. Yeah. Attach the VHD. There's some code from disk to VHD, a tool that I... Yeah. So I used to use disk to VHD because it's like, okay, I'm getting ready to upgrade my machine. I'll do a snapshot like a mosquito in amber of my machine. I'll snapshot disk to VHD and then I'll throw it up in the cloud and then I'll boot up.
a version. And then that's the moment when it's like, the computer doesn't know. It doesn't know if it's on a physical machine or virtual machine. And that, for me, was the difference between a cloud-native app and a non-cloud-native app. If the computer can be effectively lied to... then it's naive. It could be on a physical machine, it could be on the cloud. And that's lift and shift. It's a naive way to move things up in the cloud. But then if the computer is aware that it's in the cloud...
meaning the software is aware it's in the cloud. If your app is aware it's in the cloud, then it can participate. in cloud things. It can call cloud APIs, it can scale better, and a cloud-native app knows it's in the cloud, but an IaaS, I don't care. That's a good way of putting it. Very cool. Here's another... big moments in Azure's history? Yeah, what you got? So the creation of Azure, the launch of Azure, the introduction of IaaS in 2012. Another big moment was when we introduced IaaS.
By the way, it was kind of a combination of moments because it was Azure embracing IaaS, which actually started to cause the business to really scale. But the other one was when we introduced IaaS, we introduced both Windows and Linux VMs support. And this was kind of one of those pig's fly moments in Microsoft's history of what? You're supporting Linux in your cloud. And so this led to...
Microsoft really embracing Linux and, by extension, open source. And Satya famously at an event in New York that I happened to be attending, posting a... Microsoft loves Linux slide. I remember that. Microsoft heart Linux with Penguin. And that was just a wow moment. And one of those took a long time. And it took years and years and years. And I think we're finally there now.
where people were like, oh, you don't really believe it. No, it's not true. Or they just didn't even know it. And it was the old, you know, Microsoft's just the, Azure's just the Windows.net cloud. And you guys don't know like Linux or use Linux. And actually, we've come so far from that to the point where we've got our own Linux distro, Azure Linux, where we've got our Azure Boost offload card that runs Azure Linux. We've got our network switches running Sonic on Azure Linux.
So we've really just embraced open source, really, and leveraged it a lot in the building of our cloud. And I think that it also showcases that we decided to be a utility. and sell for loops in the cloud. We don't care what language, we don't care what operating system. You got a for loop, we'll sell it, we'll make it in the cloud. Serverless, IaaS, PaaS.
Wherever your for loop runs, we'll run it. We're non-denominational. Yeah. And now I think that there's more Linux in the cloud than I think it's something. Yeah, there's more virtual machines in Azure that are Linux than Windows. Yeah. And that's fine because we're providing a utility.
So popping off the stack to the beginning, how much should a young person know about this stuff? If you're an early in career person, if you're five years into your career and you're used to going to the command line and you say, scale out. And then you go and have lunch and you come back and now there's a thousand VMs. Is there value in visiting a cloud and watching a video about what goes on there? Like, I always talk about driving stick shift. So when I teach...
cloud at the local high school or when I teach it at the local university, I bring my Kubernetes cluster and I talk about scaling and I say that that's the cloud. Imagine that except bigger. And then I pull a network wire. on one of them and watch the others scale like that kind of like fundamental stuff i think that has value historical context
But I don't think it always will. At some point, everything will be serverless and people won't think about that. But should we know? Actually, I don't know. I think if you want to be a full systems person, it's helpful to know. But I think a lot of people... Might not know. And the analogy I draw here is in programming languages. With garbage collect... Stop doing email. Garbage collect... I'll wait till you're done.
I'm telling this guy I'm late for a meeting. This show's going to go late. So I'm telling the guy I'm going to be late. I apologize. Let me steeple my fingers and show direct interest in the story of Azure as we get to the end of our podcast. So as garbage-collected languages showed up, people didn't have to worry about memory management, and they didn't have to worry about threading, and they just knew, here's my code, and it's just going to do stuff.
And the question is, knowing about virtual memory and page tables, is it necessary knowing about threading? It depends. It depends on the day. It depends on the business problem. But a lot of people... In fact, I would say probably most enterprise app developers don't know those things. And they're successful with the skills they've got. So then...
Am I being doom and gloom when I say, well, what percentage of developers should know about this stuff? We have only so many plumbers available. We have only so many electricians available. We have lots of... home architects, but there's only so many people that know how to pull wire. I think that that's just the way that the technology evolves. As the layers of abstraction get built, the people that are down in the guts...
It becomes very specialized. I'll give you the other example of how I saw this happen. Inside Windows NT, the book that came out in 1996 describing the internals of Windows, and it was a very high-level description. That book sold like 250,000 copies because that was it. That was the frontier of technology was the operating system and its APIs. Then came...
Inside Windows NT 2nd Edition, Inside Windows 2000 that I joined Dave Solomon, the co-author, and they covered Windows 2000. That book sold 75,000 copies. The next edition sold 50,000 copies. The next edition's 40,000. And you see where this is going. People don't need to know that stuff anymore. There's some factor of the stuff's available on the web, too.
Most people don't need to know that stuff. And so, because everybody's, there's so much surface area, even at the abstraction layers above that, that people need to worry about and learn that they don't have time or need. to go down to the lower layers. But there are the right number of people know these things to keep it running and keep it building and going forward.
So let me ask you this then to close, because I think that the advice that I give people is whatever level that you operate at, if you're Power Platform or you're C Sharp or you're C, just pick one layer below your comfort zone. and explore that area. It kind of echoes what we were talking about when it came to giving technical talks, is go one level below. Or just knowing and understanding technology. You know one level below where you are at, because that'll...
They'll give you powers that other people don't have. Which arguably we just did with this episode. Yeah. Callback. Wow. That's cool. This is one of those things where, you know, I was listening to this podcast called Acquired that Damian Edwards and David Feller told me to listen to. There's like a two-part, two, three-hour part podcast about the history of Microsoft. It's a six-hour long.
podcast of like from Bill Gates is 12 years old. And like his dad was a lawyer and all the way up until, you know, and they were selling basic and like the history of Microsoft six hour long podcast. I would listen to one. By the way, there's another. So Dave Cutler, interview with Dave Cutler that's like three hours long too. Okay, then we need to find that and link to it in the show notes.
And I think that makes people understand. Historical context matters. What were the factors happening in the marketplace that caused the perfect moment for the cloud to happen? And someone at Microsoft was like, all in. Let's go. This is the thing. We're doing this thing now. I remember when Satya was just like the cloud guy. Yeah. We'd go to meetings and it's like, yeah, he's the cloud guy. He ran Azure for a while. He ran Azure until he became CEO. Yeah, he ran Azure. That's so cool. Ah, okay.
I'm just wistfully thinking about history and being there before. Like that was the cloud, man. It wasn't that long ago and it cut the world in half. And now there's before the cloud was a thing and after the cloud is a thing. I hope it's good. I hope it's a good thing. All right. I think that's a show as well. It's a wrap. You feel good about that? I do. I feel good. Okay.
All right, friends, if you want more things for Markets Got to Learn, please, again, the comments. And leave reviews for us. It cannot be overstated that you leaving a review on iTunes or Spotify or wherever helps us grow the show.
We enjoy doing this. We're not getting paid for doing this. We just think that this is fun because we think learning is where it's at, and we hope that you learn with us. But we want to keep doing the show, and in order to do that, we need to grow the audience. So anything you can do to share. Scott and Mark learn too. Tell your friends and family. Friends and family, yeah. Text your mom. Tell Uncle Fred that they can learn about the cloud. Share our skincare episode.
All right. We'll see you again next week, everybody. Bye.