WEBVTT - The Evolution of Virtualization 0:00:04.240 --> 0:00:07.240 Welcome to tex Stuff, a production of I Heart Radios, 0:00:07.320 --> 0:00:13.880 How Stuff Works. Hey there, and welcome to tech Stuff. 0:00:13.920 --> 0:00:17.159 I'm your host, Jonathan Strickland. I'm an executive producer with 0:00:17.200 --> 0:00:19.320 How Stuff Works and I heart Radio and I love 0:00:19.400 --> 0:00:23.200 all things tech. And today's episode comes to us due 0:00:23.320 --> 0:00:29.040 to a listener request. Martin many many moons ago asked 0:00:29.080 --> 0:00:31.880 if I could do an episode talking about the evolution 0:00:32.000 --> 0:00:35.520 of virtualization, and so that's what this episode is all about. 0:00:35.920 --> 0:00:41.520 But first, what is virtualization? Well, as the name implies, 0:00:41.640 --> 0:00:46.600 it's all about creating a virtual representation of something else. Now, 0:00:46.640 --> 0:00:50.479 in computing, we typically use it to mean creating virtual 0:00:50.640 --> 0:00:54.360 computer platforms, and there are a lot of reasons why 0:00:54.560 --> 0:00:56.560 you would want to do this. It would be a 0:00:56.640 --> 0:01:01.160 virtual computer platform that exists on top of actual physical hardware. 0:01:01.600 --> 0:01:04.040 And you might want to do it for security reasons, 0:01:04.319 --> 0:01:08.440 to separate different programs and storage systems from one another. 0:01:08.920 --> 0:01:11.160 You might want to do it to provide different stable 0:01:11.280 --> 0:01:16.120 development environments so that a mistake in one partition doesn't 0:01:16.120 --> 0:01:19.119 bring everything else down on the machine. You might want 0:01:19.160 --> 0:01:21.560 to do it to run different operating systems on the 0:01:21.600 --> 0:01:24.200 same physical hardware, or maybe you want to do it 0:01:24.240 --> 0:01:28.080 to maximize efficiency in your computer system, or perhaps some 0:01:28.160 --> 0:01:31.520 combination of some or all of the above, but we'll 0:01:31.520 --> 0:01:33.920 get into that later. For now, the important thing, no, 0:01:34.480 --> 0:01:37.000 is that the goal is to create a virtual version 0:01:37.120 --> 0:01:41.160 of something that runs on top of actual physical hardware. Now, 0:01:41.160 --> 0:01:45.119 the history of virtualization stretches back to the nineteen sixties, 0:01:45.480 --> 0:01:48.400 well before the days when the average person had any 0:01:48.440 --> 0:01:52.720 sort of interactions with a computer. Early computers were useful 0:01:53.120 --> 0:01:56.400 but had some limitations. This is like the main frame 0:01:56.600 --> 0:02:00.240 age of computers. So one of those limitations was that 0:02:00.360 --> 0:02:04.040 early computers could really only run one process at a time, 0:02:04.440 --> 0:02:06.800 and there had to be a person there to initiate 0:02:07.000 --> 0:02:10.000 a new program. At first, that wasn't that big of 0:02:10.000 --> 0:02:13.679 a problem because computers were such a niche gadget. Very 0:02:13.680 --> 0:02:16.080 few people had any access to them in the first place, 0:02:16.080 --> 0:02:18.960 so it wasn't that big of a limitation. The scientific 0:02:19.000 --> 0:02:23.280 and academic communities were using them, but beyond them, very 0:02:23.400 --> 0:02:26.880 few people had any experience with a computer. They were 0:02:26.880 --> 0:02:31.639 mostly unknown. But as computers were becoming more available, as 0:02:31.680 --> 0:02:35.160 businesses were starting to use them, and they were becoming 0:02:35.160 --> 0:02:39.160 more capable of handling processes that went beyond academic interests, 0:02:39.520 --> 0:02:43.080 it became clear that the limitations were a liability, and 0:02:43.120 --> 0:02:46.399 so you had companies like IBM researching ways to get 0:02:46.400 --> 0:02:50.480 around these limitations. One such way was an approach later 0:02:50.720 --> 0:02:54.680 called batch processing. This dates from the time when programs 0:02:54.680 --> 0:02:58.920 were represented on physical cards with holes punched in them, 0:02:59.000 --> 0:03:02.919 known as punch cards for obvious reasons. So in an 0:03:02.919 --> 0:03:07.240 early computer, you'd have a stack of cards representing a 0:03:07.440 --> 0:03:10.840 single program, and you would feed those cards into the 0:03:10.880 --> 0:03:15.280 computer's hopper, which is essentially its intake for cards, and 0:03:15.320 --> 0:03:19.280 the computer would analyze the cards, which would have instructions 0:03:19.320 --> 0:03:23.080 on them. The computer would then follow those instructions and 0:03:23.120 --> 0:03:26.480 produce a result and either printed out or create a 0:03:26.480 --> 0:03:29.840 new punch card or stack of punch cards, or later 0:03:29.919 --> 0:03:33.880 on it would display the results on a monitor. IBM 0:03:33.919 --> 0:03:37.680 developed computers that could accept stacks of cards that represented 0:03:37.760 --> 0:03:40.920 more than one process. The computer would be able to 0:03:40.960 --> 0:03:44.160 read out the stacks and complete each process in turn, 0:03:44.520 --> 0:03:47.840 so you could feed batches of cards to the computer. 0:03:48.200 --> 0:03:51.640 Thus batch processing it cut down on the amount of 0:03:51.680 --> 0:03:55.200 time people had to spend babysitting a computer or waiting 0:03:55.200 --> 0:03:57.520 for their turn to run a process, freeing them up 0:03:57.520 --> 0:04:00.560 to work on other stuff. But was still limited, and 0:04:00.560 --> 0:04:03.800 you were still stuck running just one process at a time. 0:04:03.840 --> 0:04:06.600 You would just run them in sequence, and you couldn't 0:04:06.640 --> 0:04:09.440 easily have multiple people using the same computer at the 0:04:09.480 --> 0:04:12.600 same time. At best, you could use batch processing to 0:04:12.720 --> 0:04:15.640 run a second job right after the first one, but 0:04:15.760 --> 0:04:18.800 it was restrictive, and as computers were becoming more important, 0:04:19.040 --> 0:04:22.160 this was a problem in the late fifties and early 0:04:22.320 --> 0:04:27.120 nineteen sixties some engineers or computer scientists, though that term 0:04:27.240 --> 0:04:30.520 was hardly in use yet, and many in academic fields 0:04:30.520 --> 0:04:33.080 were very snooty. They didn't quite yet view the subject 0:04:33.160 --> 0:04:36.640 as worthy of standing on its own anyway, Some of 0:04:36.680 --> 0:04:39.760 these innovators began to experiment with ways to get around 0:04:39.960 --> 0:04:44.160 these limitations. A fellow named John McCarthy, a professor at 0:04:44.160 --> 0:04:47.960 the Massachusetts Institute of Technology better known as m i T, 0:04:48.520 --> 0:04:52.080 proposed in nineteen fifty nine that an IBM seven O 0:04:52.279 --> 0:04:55.279 nine main frame could be tweaked to allow for a 0:04:55.360 --> 0:04:59.320 few people to use the machine more or less at 0:04:59.360 --> 0:05:02.120 the same time time. He then began to recommend some 0:05:02.240 --> 0:05:05.920 changes to the university's IBM seven oh four main frame 0:05:06.200 --> 0:05:10.400 to allow what he called a time stealing mode. In 0:05:10.440 --> 0:05:12.839 this mode, you could have a batch of jobs running 0:05:12.880 --> 0:05:15.760 on a computer, then someone else with an unrelated job 0:05:15.800 --> 0:05:19.000 shows up, and, using time stealing, the new person could 0:05:19.080 --> 0:05:21.960 interrupt the batch process to run this other job, and 0:05:22.000 --> 0:05:25.920 then the batch process could resume as per normal. Another 0:05:26.080 --> 0:05:29.760 m i T professor named Fernando Corbato worked on a 0:05:29.800 --> 0:05:33.599 similar project, tweaking the university's IBM seven oh nine main 0:05:33.640 --> 0:05:36.400 frame so that four people could use the system at 0:05:36.400 --> 0:05:39.599 the same time. But these were all solutions using systems 0:05:39.600 --> 0:05:44.120 that weren't natively designed to support multiple users. They were workarounds, 0:05:44.400 --> 0:05:48.479 and m i T computer scientists found manufacturers were uninterested 0:05:48.520 --> 0:05:52.200 in changing that because there seemed to be very little 0:05:52.240 --> 0:05:55.839 call for it. On July one, nineteen sixty three, m 0:05:55.880 --> 0:05:59.960 i T launched a project originally called Mathematics and Computation 0:06:00.040 --> 0:06:04.240 in or MAC, but later the acronym would be retroactively 0:06:04.320 --> 0:06:08.800 applied to the phrase multiple access computer. Funding for the 0:06:08.839 --> 0:06:12.080 project came courtesy of ar PA, which would later get 0:06:12.120 --> 0:06:15.560 its own acronym update to DARPA. And in case you 0:06:15.560 --> 0:06:19.200 are unfamiliar with that organization, it's a division within the 0:06:19.279 --> 0:06:22.800 United States Department of Defense, and its mission is to 0:06:22.920 --> 0:06:26.400 fund research and development into technologies that contribute to the 0:06:26.440 --> 0:06:29.719 defense of the country in some way. So why was 0:06:29.760 --> 0:06:33.480 the Department of Defense interested in this? It largely had 0:06:33.520 --> 0:06:36.719 to do with Russia and Sputnik. Now, I've talked about 0:06:36.720 --> 0:06:40.160 how spot Nick helped spur on a ton of innovation 0:06:40.240 --> 0:06:44.120 in the United States. It scared the daylights out of 0:06:44.240 --> 0:06:47.280 people in the US. It suggested that Russia was much 0:06:47.360 --> 0:06:51.520 further along technologically speaking than the US had suspected. And 0:06:51.560 --> 0:06:54.680 it lit a fire under the proverbial backside of the 0:06:54.760 --> 0:06:57.960 US military. And so there was a strong incentive to 0:06:58.040 --> 0:07:00.960 advance computer science and technolog g in the US to 0:07:01.080 --> 0:07:06.080 outpace the Russians. Project max primary purpose was to advance 0:07:06.120 --> 0:07:09.880 computer science in several ways, including the development of new 0:07:09.960 --> 0:07:14.080 operating systems and computational theory. It largely grew out of 0:07:14.160 --> 0:07:17.560 a meeting between m i T Professor Robert Fano and 0:07:17.640 --> 0:07:21.080 Joseph C. R. Lick Lighter, who had previously established a 0:07:21.120 --> 0:07:24.240 psychology group in the Electrical Engineering department of m i T. 0:07:24.840 --> 0:07:27.840 Then gone on to join a research firm called Bolt, 0:07:27.960 --> 0:07:31.240 Baroneck and Newman better known as B B N, and 0:07:31.280 --> 0:07:35.200 then was named the first director of ARPA's Information Processing 0:07:35.280 --> 0:07:39.520 Techniques Office or I p t O. Lick Lighter convinced 0:07:39.520 --> 0:07:43.240 Fano to head up Project Mac, which would receive funding 0:07:43.400 --> 0:07:46.800 from the I p t O through ARPA. But standing 0:07:46.800 --> 0:07:49.600 in the way of this goal were the limitations I've 0:07:49.600 --> 0:07:52.840 mentioned already. It's hard to make real progress if you're 0:07:52.880 --> 0:07:55.920 limited to just one person working on one computer at 0:07:55.960 --> 0:07:58.680 any given time, and so M I T sought out 0:07:58.680 --> 0:08:02.520 proposals from companies like General Electric and IBM to develop 0:08:02.560 --> 0:08:05.800 a computer system that could support multiple users through this 0:08:06.080 --> 0:08:10.480 time sharing idea. Now, the basic idea behind time sharing 0:08:10.880 --> 0:08:14.080 is that you have multiple workstations that all connect back 0:08:14.080 --> 0:08:17.760 to the same computer. The workstations are all dummy terminals 0:08:17.840 --> 0:08:21.080 or thin clients. The computer can only work on one 0:08:21.160 --> 0:08:23.360 job at a time, but it can do so at 0:08:23.360 --> 0:08:26.480 a pretty darn fast pace, and so as you run 0:08:26.480 --> 0:08:29.040 a job at your workstation, the computer waits for a 0:08:29.080 --> 0:08:32.040 break and its processing of other jobs, then slots your 0:08:32.120 --> 0:08:35.160 job in that break and runs your job to you. 0:08:35.320 --> 0:08:37.439 It's like you've got the full attention of the computer, 0:08:37.559 --> 0:08:40.400 but in reality, the computer is actually switching back and 0:08:40.440 --> 0:08:44.280 forth between users, finishing each job quickly before moving on 0:08:44.320 --> 0:08:46.920 to the next one, rather than doing all the jobs 0:08:46.920 --> 0:08:49.480 at the same time. The benefit of time sharing is 0:08:49.480 --> 0:08:52.320 that it's as if you've increased the number of computers 0:08:52.360 --> 0:08:55.480 by the number of workstations, and so more people can 0:08:55.520 --> 0:08:58.480 take advantage of the computer than with older systems. You 0:08:58.559 --> 0:09:02.520 reduce downtime, you increase efficiency, and more people can actually 0:09:02.520 --> 0:09:07.400 get stuff done. IBM was initially not interested in working 0:09:07.400 --> 0:09:10.000 with m I T. The company wasn't convinced that a 0:09:10.080 --> 0:09:12.520 multi user computer was going to be that big of 0:09:12.559 --> 0:09:15.320 a deal and that most of their customers would have 0:09:15.400 --> 0:09:18.840 no need for such a computer. So rather than dedicate 0:09:18.880 --> 0:09:21.480 the time and resources needed to develop something that the 0:09:21.520 --> 0:09:24.439 company wasn't convinced would ever be an actual product, it 0:09:24.480 --> 0:09:27.080 would just be a one off, they bowed out and 0:09:27.120 --> 0:09:30.040 so ge became the vendor for the early days of 0:09:30.080 --> 0:09:33.720 Project Mac. But over at IBM, minds were slowly changing. 0:09:33.800 --> 0:09:37.120 The Project Mac contract was a big deal with a 0:09:37.120 --> 0:09:40.079 lot of funding at that time, and then it became 0:09:40.120 --> 0:09:42.480 known that Bell Labs was also looking out for a 0:09:42.520 --> 0:09:45.400 system that would grant access to multiple users to a 0:09:45.400 --> 0:09:48.360 computer at the same time, and this was enough for 0:09:48.400 --> 0:09:51.920 the folks at IBM to say, huh, maybe we were wrong, 0:09:52.240 --> 0:09:54.040 and they changed their minds and they put some work 0:09:54.040 --> 0:09:57.840 into developing such a system. They created a prototype called 0:09:58.040 --> 0:10:03.120 the c P forty mainframe computer. The computer never became 0:10:03.120 --> 0:10:06.720 a product sold by IBM, but was used internally in 0:10:06.800 --> 0:10:10.360 IBM S labs. But the CP forty will be really 0:10:10.400 --> 0:10:13.280 important in our story because it was the starting point 0:10:13.360 --> 0:10:15.280 for a journey that would take us to the first 0:10:15.320 --> 0:10:20.360 commercial mainframe computer system that could support virtualization. The time 0:10:20.400 --> 0:10:25.000 sharing approach involved sharing parts of a computer's processing capabilities, 0:10:25.280 --> 0:10:29.280 such as its system memory or its storage, and sharing 0:10:29.320 --> 0:10:32.240 that with each user. But this was not just useful, 0:10:32.280 --> 0:10:35.160 it was also limiting. If something went wrong for one user, 0:10:35.600 --> 0:10:39.360 it would affect everyone on that computer. Creating more meaningful 0:10:39.400 --> 0:10:43.360 partitions that would isolate each user would be more useful. Now. 0:10:43.400 --> 0:10:47.839 Typically we described this process as a hypervisor, or sometimes 0:10:47.880 --> 0:10:51.559 as a control program. A hypervisor's job is to separate 0:10:51.600 --> 0:10:55.079 the applications and operating system running on a computer from 0:10:55.120 --> 0:10:58.440 the computer's actual hardware. There are a couple of different 0:10:58.440 --> 0:11:02.400 types of hypervisors. Type one hypervisors are also known as 0:11:02.520 --> 0:11:06.400 bare metal hypervisors because they exist in a layer that's 0:11:06.480 --> 0:11:09.600 directly on top of a machine's hardware. Then you have 0:11:09.679 --> 0:11:13.880 type two hypervisors that's a software layer that exists over 0:11:13.960 --> 0:11:18.200 top the existing machines operating system, so there's an extra 0:11:18.360 --> 0:11:22.360 layer of abstraction there. Now, through a hypervisor, a single 0:11:22.440 --> 0:11:26.760 machine can host multiple virtual guest machines. This idea would 0:11:26.800 --> 0:11:30.880 be further explored in the next phase, that of true virtualization, 0:11:31.320 --> 0:11:33.160 which I'll get to in just a moment. But first 0:11:33.240 --> 0:11:43.800 let's take a quick break. Okay, so we just got 0:11:43.800 --> 0:11:48.439 into what you could think of as the prehistoric virtualization era, 0:11:48.679 --> 0:11:53.240 with hypervisor technology just coming into development. IBM was at 0:11:53.240 --> 0:11:56.640 the forefront of this research with the CP forty mainframe 0:11:56.720 --> 0:11:59.560 system in the nineteen sixties. The system ran on a 0:11:59.600 --> 0:12:05.000 special operating system called CP slash c MS, which originally 0:12:05.040 --> 0:12:10.240 stood for Control Program slash Cambridge Monitor System, though later 0:12:10.280 --> 0:12:13.760 CMS would change to mean Conversational Monitor System and I've 0:12:13.800 --> 0:12:16.200 even seen a couple of other variants out there. The 0:12:16.240 --> 0:12:20.280 control program part was what allowed for this early virtualization 0:12:20.440 --> 0:12:24.760 in the CP forty. It effectively created a full virtualization 0:12:24.920 --> 0:12:28.200 of the underlying hardware of the CP forty for each 0:12:28.400 --> 0:12:32.560 virtual machine, so people on dumb terminals terminals that did 0:12:32.600 --> 0:12:36.319 not have their own solely dedicated computer could have a 0:12:36.440 --> 0:12:40.280 virtual computer at their disposal. All the work was actually 0:12:40.360 --> 0:12:43.719 being done on top of the single CP forty prototype, 0:12:43.960 --> 0:12:45.800 but to each user it was as if they had 0:12:45.880 --> 0:12:51.239 access to their own individual computer. The virtualization software partitioned 0:12:51.320 --> 0:12:55.120 computer assets to each user. This wasn't just a matter 0:12:55.240 --> 0:12:59.280 of convenience. It also allowed for rapid innovation. Programmers could 0:12:59.320 --> 0:13:03.320 work on their own virtual machines, creating applications without having 0:13:03.320 --> 0:13:07.120 to worry about a bug affecting everyone else. The partitions 0:13:07.160 --> 0:13:10.880 provided protection, so if you were plugging away on a 0:13:10.960 --> 0:13:14.679 difficult section of code and your coworker fouled something up 0:13:14.679 --> 0:13:17.320 on their virtual machine, you didn't have to worry about 0:13:17.400 --> 0:13:20.840 their mistake bringing you down with them. Each virtual machine 0:13:21.080 --> 0:13:25.640 acted like its own individual physical computer. You can see 0:13:25.679 --> 0:13:29.080 some similarities between this model of computing and what would 0:13:29.120 --> 0:13:32.200 come much later in the era of cloud computing and 0:13:32.240 --> 0:13:36.800 the brief age of netbooks. Technically, netbooks are still around, 0:13:37.000 --> 0:13:41.760 but they are no longer the heyday type device that 0:13:41.800 --> 0:13:44.920 they were for a very short while. The netbook essentially 0:13:44.960 --> 0:13:47.360 had a five year run from two thousand seven to 0:13:47.400 --> 0:13:51.520 two thousand twelve, and it's a category of lightweight laptop 0:13:51.559 --> 0:13:55.800 computers that had modest specifications because the real purpose of 0:13:55.800 --> 0:13:58.760 the computer was to use cloud based services. You didn't 0:13:58.800 --> 0:14:01.960 have to have a b E fee computer because most 0:14:01.960 --> 0:14:05.320 of the processing was taking place somewhere else. The netbooks 0:14:05.320 --> 0:14:07.920 were a type of thin client, kind of like those 0:14:08.000 --> 0:14:11.920 dummy terminals used in time sharing mainframe systems. You didn't 0:14:11.960 --> 0:14:14.000 have to have a lot of horsepower. You just needed 0:14:14.040 --> 0:14:18.719 input devices like a keyboard and output devices like a display, 0:14:18.760 --> 0:14:21.520 and the actual computing was happening on some other machine 0:14:21.560 --> 0:14:24.080 out on the internet. We'll talk about that more a 0:14:24.120 --> 0:14:27.920 bit later in this episode. So while work on and 0:14:28.040 --> 0:14:31.640 with the CP forty system was going, IBM researchers were 0:14:31.680 --> 0:14:34.840 looking into other breakthroughs that would become important for computers 0:14:34.840 --> 0:14:39.120 in general and virtualization in particular. In nineteen sixty five, 0:14:39.200 --> 0:14:42.240 IBM announced it was developing a thirty two bit central 0:14:42.280 --> 0:14:46.360 processing unit that included virtual memory hardware in it. This 0:14:46.480 --> 0:14:50.920 was called the IBM System SLASH three sixty. IBM researchers 0:14:51.000 --> 0:14:54.560 used what they learned developing the CP forty to create 0:14:54.640 --> 0:14:58.000 the CP sixty seven, which was built on this IBM 0:14:58.040 --> 0:15:02.560 system Slash three sixty DASH sixties seven hardware. I love 0:15:02.640 --> 0:15:06.200 these names, by the way, there's so much fun to say. Anyway, 0:15:06.360 --> 0:15:09.040 this would be the first computer to support virtualization that 0:15:09.040 --> 0:15:12.880 would actually be widely available as a commercial product, not 0:15:12.960 --> 0:15:16.880 just a prototype. This was an important component for mainframe users, 0:15:17.160 --> 0:15:20.760 but it wouldn't really transfer to micro or mini computers. 0:15:20.960 --> 0:15:23.000 So this is still in the main frame age where 0:15:23.000 --> 0:15:26.480 you have the big centralized computer, and it's not that 0:15:26.560 --> 0:15:29.240 big of a surprise. You know, a mainframe is a 0:15:29.280 --> 0:15:33.960 centralized machine, but later computers didn't necessarily follow that model. Instead, 0:15:34.200 --> 0:15:36.640 you could have a computer at your own desk. The 0:15:36.680 --> 0:15:39.800 need to partition and separate your machine from everyone else 0:15:40.200 --> 0:15:43.200 wasn't as pressing since you were working on an actual 0:15:43.320 --> 0:15:47.800 separate piece of hardware rather than sharing a centralized computer 0:15:47.920 --> 0:15:51.440 amongst everybody else, and the hardware you were using was 0:15:51.480 --> 0:15:54.000 capable enough to do whatever it was you were doing. 0:15:54.400 --> 0:15:57.800 Majorization reached the point where it was possible to produce 0:15:57.840 --> 0:16:01.760 a relatively small computer, especially compared to the giant mainframes 0:16:01.840 --> 0:16:04.480 of the nineteen fifties and nineteen sixties, and it could 0:16:04.520 --> 0:16:07.440 handle all the tasks that your average user could throw 0:16:07.480 --> 0:16:09.760 at it. So we started to see a shift away 0:16:09.880 --> 0:16:13.480 from this centralized model of the mainframe strategy to a 0:16:13.680 --> 0:16:17.000 decentralized approach in which everyone would work on their own 0:16:17.080 --> 0:16:20.800 separate machine. This would continue and accelerate in the mid 0:16:20.840 --> 0:16:24.440 to late nineteen seventies when the personal computer emerged and 0:16:24.480 --> 0:16:27.400 the general public began to dip their proverbial toe in 0:16:27.440 --> 0:16:31.600 the computational pool or something. Now that's not to say 0:16:31.640 --> 0:16:35.880 that all work on virtualization stopped completely in the nineteen seventies. 0:16:36.120 --> 0:16:38.960 It certainly didn't speed up, and it pretty much remained 0:16:39.000 --> 0:16:43.480 in the domain of mainframe computers, which still had their uses, 0:16:43.520 --> 0:16:47.760 but in niche cases, in fact increasingly niche cases. So 0:16:47.840 --> 0:16:50.960 whether they were legacy systems that companies depended upon to 0:16:51.040 --> 0:16:54.600 keep business going, or they were more powerful machines that 0:16:54.640 --> 0:16:57.560 could be realized in the smaller formats. You know, they 0:16:57.560 --> 0:17:00.400 were these powerful machines that were being used are very 0:17:00.440 --> 0:17:04.159 specific tasks. They still had a place, it was just 0:17:04.320 --> 0:17:08.400 a reduced place, and that was pretty much where virtualization 0:17:08.480 --> 0:17:12.439 was stuck until the mid nineteen eighties. That's when a 0:17:12.440 --> 0:17:17.280 company called Locust Computing Corporation developed special software in collaboration 0:17:17.320 --> 0:17:20.000 with A T and T for a computer called the 0:17:20.080 --> 0:17:24.399 A T and T sixty three hundred plus. The computers 0:17:24.440 --> 0:17:28.560 operating system was Unix s v R two. Now, the 0:17:28.600 --> 0:17:31.800 thing about Unix is. It's an operating system that can 0:17:31.800 --> 0:17:36.520 support Unix programs, but it couldn't run DOSS based programs 0:17:36.560 --> 0:17:38.600 on its own. And for those of you who aren't 0:17:38.600 --> 0:17:42.320 familiar with DOSS, it was the text based operating system 0:17:42.400 --> 0:17:45.399 used by many computers. There were lots of different flavors 0:17:45.440 --> 0:17:49.200 of DOSS um Apple had its own sort of version, 0:17:49.280 --> 0:17:52.359 but the one that everyone really knew was IMMAs DOSS, 0:17:52.480 --> 0:17:55.920 the Microsoft flavor of DOSS that was the most popular 0:17:56.040 --> 0:17:58.719 version of the text based operating system out there for 0:17:58.760 --> 0:18:02.399 IBM and IBM comp udible machines. So there are a 0:18:02.400 --> 0:18:06.880 lot of programs developed for MS DOSS and DAWs in general, 0:18:07.240 --> 0:18:10.120 but you couldn't run them on a Unix based device. 0:18:10.520 --> 0:18:14.119 So Locus developed some software that would handle the interaction 0:18:14.480 --> 0:18:18.840 between DOSS programs designed for the eight eight six instruction 0:18:18.920 --> 0:18:24.280 set that DOSS programs were reliant upon and the underlying 0:18:24.400 --> 0:18:27.560 Unix operating system, so it's kind of like a liaison 0:18:27.640 --> 0:18:30.879 between those. The software have become known as MERGE and 0:18:30.920 --> 0:18:33.960 would be one of the first virtual machine managing or 0:18:34.080 --> 0:18:37.800 VMM products on the market. So now you could have 0:18:37.840 --> 0:18:40.560 a Unix machine and still run DOSS programs on top 0:18:40.600 --> 0:18:44.320 of it. By having this virtual DOSS machine running on 0:18:44.400 --> 0:18:47.840 the Unix hardware. This would mark a new era in 0:18:47.880 --> 0:18:51.119 which companies would make software that would allow computers running 0:18:51.160 --> 0:18:54.120 on one type of operating system in hardware to run 0:18:54.160 --> 0:18:57.600 an instance of a different operating system, and it opened 0:18:57.680 --> 0:19:00.879 up access to other types of programs. Most of us 0:19:01.359 --> 0:19:05.040 don't tend to work on Unix systems. But what about 0:19:05.119 --> 0:19:09.040 max versus PCs. You know that a Mac computer can't 0:19:09.160 --> 0:19:12.800 run a DOSS or later on a Windows program, and 0:19:12.920 --> 0:19:17.560 vice versa Windows computer can't run a Mac program. But 0:19:17.640 --> 0:19:21.600 developers created virtual machine software that would allow a Macintosh 0:19:21.600 --> 0:19:25.600 computer to run a virtual instance of DOSS on a Mac, 0:19:25.880 --> 0:19:29.080 meaning you could access those DOSS programs on a Macintosh 0:19:29.240 --> 0:19:32.400 while running this virtual machine software. Suddenly you could take 0:19:32.400 --> 0:19:35.959 advantage of programs meant for another type of computer on 0:19:36.000 --> 0:19:39.439 your own machine. By the way, it probably comes as 0:19:39.520 --> 0:19:41.760 very little surprised to those of you who are familiar 0:19:41.800 --> 0:19:44.840 with Apple that the company was not a fan of 0:19:44.880 --> 0:19:49.240 anyone running the Mac operating system on a non Apple machine. 0:19:49.920 --> 0:19:54.119 Through virtualization. This was technically possible, but Apple maintained that 0:19:54.160 --> 0:19:56.960 the only legal way to do it was to run 0:19:57.080 --> 0:20:00.840 mac os on a virtual platform on top of another 0:20:01.000 --> 0:20:04.440 Apple branded computer. So why would you want to run 0:20:04.520 --> 0:20:07.320 a virtual version of mac OS on top of a 0:20:07.359 --> 0:20:11.520 computer already running Mac OS. One reason would be to 0:20:11.600 --> 0:20:15.399 test a new program against multiple versions of a single 0:20:15.520 --> 0:20:18.640 operating system. So you might want to run your new 0:20:18.720 --> 0:20:22.439 mac program against the latest version of Mac OS and 0:20:22.440 --> 0:20:24.800 then the previous versions of Mac OS to see if 0:20:24.840 --> 0:20:28.000 it's still compatible, making sure you have backwards compatibility written 0:20:28.000 --> 0:20:31.280 in there. That would be handy to know. For about 0:20:31.280 --> 0:20:34.680 a decade, that was the state of virtualization. Companies made 0:20:34.680 --> 0:20:38.159 programs that would allow users to run one operating system 0:20:38.240 --> 0:20:41.399 on top of a machine running a different operating system. 0:20:41.400 --> 0:20:44.119 It was useful for people who were developing software for 0:20:44.160 --> 0:20:47.960 other platforms, but beyond that, there wasn't much general use 0:20:48.040 --> 0:20:50.800 for it, because, again, everyone was relying on their own 0:20:50.800 --> 0:20:53.960 individual computers anyway, you didn't have to worry about creating 0:20:53.960 --> 0:20:57.160 partitions between users for the most part. There were other 0:20:57.240 --> 0:21:00.119 manifestations of virtualization that would come on the scene a 0:21:00.160 --> 0:21:03.359 little bit later. In the early nineteen nineties, a team 0:21:03.400 --> 0:21:06.640 at Sun Microsystems was hard at work developing a new 0:21:06.680 --> 0:21:11.600 programming language that would eventually take on the name Java. Initially, 0:21:12.000 --> 0:21:15.000 the idea was that this programming language would allow developers 0:21:15.040 --> 0:21:19.240 to create programs running on home appliances like television's. The 0:21:19.280 --> 0:21:21.800 need for a language that developers could use to create 0:21:21.840 --> 0:21:25.960 programs for different platforms was obvious because these appliances would 0:21:25.960 --> 0:21:28.760 be coming from different manufacturers who would be working with 0:21:28.880 --> 0:21:32.760 different microprocessor companies, so there was no guarantee that televisions 0:21:32.760 --> 0:21:36.280 from two different companies would have similar microchips in them. Now, 0:21:36.320 --> 0:21:39.400 this is a non trivial problem. If you are a programmer, 0:21:39.640 --> 0:21:42.080 you have to make some practical decisions that have little 0:21:42.119 --> 0:21:44.879 to do with the actual purpose of your application, and 0:21:44.920 --> 0:21:49.360 one of those decisions is what platform will I develop for. Frequently, 0:21:49.400 --> 0:21:52.440 the answer that many developers gravitate toward is I want 0:21:52.480 --> 0:21:55.680 to develop for the most popular platform out there because 0:21:55.680 --> 0:21:59.000 it represents the largest potential customer base. To put it 0:21:59.000 --> 0:22:01.520 in another way, let's say you're making a video game, 0:22:01.840 --> 0:22:04.119 and let's say there's only two consoles that are on 0:22:04.160 --> 0:22:08.119 the market. One of those consoles has a market share 0:22:08.280 --> 0:22:11.000 and the other has a ten market share, and they're 0:22:11.000 --> 0:22:14.000 both great game consoles, but you're more likely to focus 0:22:14.040 --> 0:22:15.760 on developing the game for the one that has the 0:22:16.680 --> 0:22:19.480 market share because that's where most of the gamers are. 0:22:19.920 --> 0:22:22.320 But one if you could create a programming language that 0:22:22.359 --> 0:22:27.440 could work on different platforms despite the underlying hardware, That 0:22:27.520 --> 0:22:31.760 was the idea behind Java. So programmer James Gosling and 0:22:31.880 --> 0:22:34.359 his team set out to create a programming language that 0:22:34.400 --> 0:22:37.280 could work on top of any device that was running 0:22:37.320 --> 0:22:41.200 a Java virtual machine. While the resulting language wasn't used 0:22:41.200 --> 0:22:44.359 in TVs at that time, it quickly became recognized as 0:22:44.359 --> 0:22:46.919 a valuable tool for web development by the time the 0:22:47.040 --> 0:22:51.760 Java Development Kit debuted in By then, the web was 0:22:51.800 --> 0:22:54.680 really starting to take off, but it was also pretty limited. 0:22:54.720 --> 0:22:58.040 All sorts of computers were acting as servers on the Internet, 0:22:58.240 --> 0:23:01.080 running on different hardware and using for an operating systems, 0:23:01.359 --> 0:23:04.800 and there was a need for more dynamic, interesting, rich 0:23:04.880 --> 0:23:08.320 experiences online. But with everyone running different systems, it was 0:23:08.359 --> 0:23:11.520 impossible to guarantee that a web app would work for everyone. 0:23:12.200 --> 0:23:15.880 Java helped take that pressure off. It was a right, once, 0:23:16.080 --> 0:23:20.359 run anywhere programming language, and so the language was adopted 0:23:20.400 --> 0:23:23.919 widely on the web, with web browsers building Java applets 0:23:23.960 --> 0:23:27.920 to support it within the browser itself. This virtualization made 0:23:28.040 --> 0:23:32.040 rich Internet experiences possible. As it turns out the Internet 0:23:32.119 --> 0:23:35.000 in general and the Web in particular would create the 0:23:35.160 --> 0:23:39.600 perfect environment for the evolution of virtualization. This appeals to 0:23:39.680 --> 0:23:43.480 common sense. After all, the Internet is a network of networks, 0:23:43.520 --> 0:23:47.119 and each network can potentially include millions of computers running 0:23:47.119 --> 0:23:51.600 on different operating systems and hardware. This makes common sense, right, 0:23:51.640 --> 0:23:54.119 after all, being Internet is a network of networks, and 0:23:54.160 --> 0:23:57.240 each network can potentially include millions of computers running on 0:23:57.240 --> 0:24:00.440