Speaker 1: Welcome to tex Stuff, a production of I Heart Radios,
Speaker 1: How Stuff Works. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: How Stuff Works and I heart Radio and I love
Speaker 1: all things tech. And today's episode comes to us due
Speaker 1: to a listener request. Martin many many moons ago asked
Speaker 1: if I could do an episode talking about the evolution
Speaker 1: of virtualization, and so that's what this episode is all about.
Speaker 1: But first, what is virtualization? Well, as the name implies,
Speaker 1: it's all about creating a virtual representation of something else. Now,
Speaker 1: in computing, we typically use it to mean creating virtual
Speaker 1: computer platforms, and there are a lot of reasons why
Speaker 1: you would want to do this. It would be a
Speaker 1: virtual computer platform that exists on top of actual physical hardware.
Speaker 1: And you might want to do it for security reasons,
Speaker 1: to separate different programs and storage systems from one another.
Speaker 1: You might want to do it to provide different stable
Speaker 1: development environments so that a mistake in one partition doesn't
Speaker 1: bring everything else down on the machine. You might want
Speaker 1: to do it to run different operating systems on the
Speaker 1: same physical hardware, or maybe you want to do it
Speaker 1: to maximize efficiency in your computer system, or perhaps some
Speaker 1: combination of some or all of the above, but we'll
Speaker 1: get into that later. For now, the important thing, no,
Speaker 1: is that the goal is to create a virtual version
Speaker 1: of something that runs on top of actual physical hardware. Now,
Speaker 1: the history of virtualization stretches back to the nineteen sixties,
Speaker 1: well before the days when the average person had any
Speaker 1: sort of interactions with a computer. Early computers were useful
Speaker 1: but had some limitations. This is like the main frame
Speaker 1: age of computers. So one of those limitations was that
Speaker 1: early computers could really only run one process at a time,
Speaker 1: and there had to be a person there to initiate
Speaker 1: a new program. At first, that wasn't that big of
Speaker 1: a problem because computers were such a niche gadget. Very
Speaker 1: few people had any access to them in the first place,
Speaker 1: so it wasn't that big of a limitation. The scientific
Speaker 1: and academic communities were using them, but beyond them, very
Speaker 1: few people had any experience with a computer. They were
Speaker 1: mostly unknown. But as computers were becoming more available, as
Speaker 1: businesses were starting to use them, and they were becoming
Speaker 1: more capable of handling processes that went beyond academic interests,
Speaker 1: it became clear that the limitations were a liability, and
Speaker 1: so you had companies like IBM researching ways to get
Speaker 1: around these limitations. One such way was an approach later
Speaker 1: called batch processing. This dates from the time when programs
Speaker 1: were represented on physical cards with holes punched in them,
Speaker 1: known as punch cards for obvious reasons. So in an
Speaker 1: early computer, you'd have a stack of cards representing a
Speaker 1: single program, and you would feed those cards into the
Speaker 1: computer's hopper, which is essentially its intake for cards, and
Speaker 1: the computer would analyze the cards, which would have instructions
Speaker 1: on them. The computer would then follow those instructions and
Speaker 1: produce a result and either printed out or create a
Speaker 1: new punch card or stack of punch cards, or later
Speaker 1: on it would display the results on a monitor. IBM
Speaker 1: developed computers that could accept stacks of cards that represented
Speaker 1: more than one process. The computer would be able to
Speaker 1: read out the stacks and complete each process in turn,
Speaker 1: so you could feed batches of cards to the computer.
Speaker 1: Thus batch processing it cut down on the amount of
Speaker 1: time people had to spend babysitting a computer or waiting
Speaker 1: for their turn to run a process, freeing them up
Speaker 1: to work on other stuff. But was still limited, and
Speaker 1: you were still stuck running just one process at a time.
Speaker 1: You would just run them in sequence, and you couldn't
Speaker 1: easily have multiple people using the same computer at the
Speaker 1: same time. At best, you could use batch processing to
Speaker 1: run a second job right after the first one, but
Speaker 1: it was restrictive, and as computers were becoming more important,
Speaker 1: this was a problem in the late fifties and early
Speaker 1: nineteen sixties some engineers or computer scientists, though that term
Speaker 1: was hardly in use yet, and many in academic fields
Speaker 1: were very snooty. They didn't quite yet view the subject
Speaker 1: as worthy of standing on its own anyway, Some of
Speaker 1: these innovators began to experiment with ways to get around
Speaker 1: these limitations. A fellow named John McCarthy, a professor at
Speaker 1: the Massachusetts Institute of Technology better known as m i T,
Speaker 1: proposed in nineteen fifty nine that an IBM seven O
Speaker 1: nine main frame could be tweaked to allow for a
Speaker 1: few people to use the machine more or less at
Speaker 1: the same time time. He then began to recommend some
Speaker 1: changes to the university's IBM seven oh four main frame
Speaker 1: to allow what he called a time stealing mode. In
Speaker 1: this mode, you could have a batch of jobs running
Speaker 1: on a computer, then someone else with an unrelated job
Speaker 1: shows up, and, using time stealing, the new person could
Speaker 1: interrupt the batch process to run this other job, and
Speaker 1: then the batch process could resume as per normal. Another
Speaker 1: m i T professor named Fernando Corbato worked on a
Speaker 1: similar project, tweaking the university's IBM seven oh nine main
Speaker 1: frame so that four people could use the system at
Speaker 1: the same time. But these were all solutions using systems
Speaker 1: that weren't natively designed to support multiple users. They were workarounds,
Speaker 1: and m i T computer scientists found manufacturers were uninterested
Speaker 1: in changing that because there seemed to be very little
Speaker 1: call for it. On July one, nineteen sixty three, m
Speaker 1: i T launched a project originally called Mathematics and Computation
Speaker 1: in or MAC, but later the acronym would be retroactively
Speaker 1: applied to the phrase multiple access computer. Funding for the
Speaker 1: project came courtesy of ar PA, which would later get
Speaker 1: its own acronym update to DARPA. And in case you
Speaker 1: are unfamiliar with that organization, it's a division within the
Speaker 1: United States Department of Defense, and its mission is to
Speaker 1: fund research and development into technologies that contribute to the
Speaker 1: defense of the country in some way. So why was
Speaker 1: the Department of Defense interested in this? It largely had
Speaker 1: to do with Russia and Sputnik. Now, I've talked about
Speaker 1: how spot Nick helped spur on a ton of innovation
Speaker 1: in the United States. It scared the daylights out of
Speaker 1: people in the US. It suggested that Russia was much
Speaker 1: further along technologically speaking than the US had suspected. And
Speaker 1: it lit a fire under the proverbial backside of the
Speaker 1: US military. And so there was a strong incentive to
Speaker 1: advance computer science and technolog g in the US to
Speaker 1: outpace the Russians. Project max primary purpose was to advance
Speaker 1: computer science in several ways, including the development of new
Speaker 1: operating systems and computational theory. It largely grew out of
Speaker 1: a meeting between m i T Professor Robert Fano and
Speaker 1: Joseph C. R. Lick Lighter, who had previously established a
Speaker 1: psychology group in the Electrical Engineering department of m i T.
Speaker 1: Then gone on to join a research firm called Bolt,
Speaker 1: Baroneck and Newman better known as B B N, and
Speaker 1: then was named the first director of ARPA's Information Processing
Speaker 1: Techniques Office or I p t O. Lick Lighter convinced
Speaker 1: Fano to head up Project Mac, which would receive funding
Speaker 1: from the I p t O through ARPA. But standing
Speaker 1: in the way of this goal were the limitations I've
Speaker 1: mentioned already. It's hard to make real progress if you're
Speaker 1: limited to just one person working on one computer at
Speaker 1: any given time, and so M I T sought out
Speaker 1: proposals from companies like General Electric and IBM to develop
Speaker 1: a computer system that could support multiple users through this
Speaker 1: time sharing idea. Now, the basic idea behind time sharing
Speaker 1: is that you have multiple workstations that all connect back
Speaker 1: to the same computer. The workstations are all dummy terminals
Speaker 1: or thin clients. The computer can only work on one
Speaker 1: job at a time, but it can do so at
Speaker 1: a pretty darn fast pace, and so as you run
Speaker 1: a job at your workstation, the computer waits for a
Speaker 1: break and its processing of other jobs, then slots your
Speaker 1: job in that break and runs your job to you.
Speaker 1: It's like you've got the full attention of the computer,
Speaker 1: but in reality, the computer is actually switching back and
Speaker 1: forth between users, finishing each job quickly before moving on
Speaker 1: to the next one, rather than doing all the jobs
Speaker 1: at the same time. The benefit of time sharing is
Speaker 1: that it's as if you've increased the number of computers
Speaker 1: by the number of workstations, and so more people can
Speaker 1: take advantage of the computer than with older systems. You
Speaker 1: reduce downtime, you increase efficiency, and more people can actually
Speaker 1: get stuff done. IBM was initially not interested in working
Speaker 1: with m I T. The company wasn't convinced that a
Speaker 1: multi user computer was going to be that big of
Speaker 1: a deal and that most of their customers would have
Speaker 1: no need for such a computer. So rather than dedicate
Speaker 1: the time and resources needed to develop something that the
Speaker 1: company wasn't convinced would ever be an actual product, it
Speaker 1: would just be a one off, they bowed out and
Speaker 1: so ge became the vendor for the early days of
Speaker 1: Project Mac. But over at IBM, minds were slowly changing.
Speaker 1: The Project Mac contract was a big deal with a
Speaker 1: lot of funding at that time, and then it became
Speaker 1: known that Bell Labs was also looking out for a
Speaker 1: system that would grant access to multiple users to a
Speaker 1: computer at the same time, and this was enough for
Speaker 1: the folks at IBM to say, huh, maybe we were wrong,
Speaker 1: and they changed their minds and they put some work
Speaker 1: into developing such a system. They created a prototype called
Speaker 1: the c P forty mainframe computer. The computer never became
Speaker 1: a product sold by IBM, but was used internally in
Speaker 1: IBM S labs. But the CP forty will be really
Speaker 1: important in our story because it was the starting point
Speaker 1: for a journey that would take us to the first
Speaker 1: commercial mainframe computer system that could support virtualization. The time
Speaker 1: sharing approach involved sharing parts of a computer's processing capabilities,
Speaker 1: such as its system memory or its storage, and sharing
Speaker 1: that with each user. But this was not just useful,
Speaker 1: it was also limiting. If something went wrong for one user,
Speaker 1: it would affect everyone on that computer. Creating more meaningful
Speaker 1: partitions that would isolate each user would be more useful. Now.
Speaker 1: Typically we described this process as a hypervisor, or sometimes
Speaker 1: as a control program. A hypervisor's job is to separate
Speaker 1: the applications and operating system running on a computer from
Speaker 1: the computer's actual hardware. There are a couple of different
Speaker 1: types of hypervisors. Type one hypervisors are also known as
Speaker 1: bare metal hypervisors because they exist in a layer that's
Speaker 1: directly on top of a machine's hardware. Then you have
Speaker 1: type two hypervisors that's a software layer that exists over
Speaker 1: top the existing machines operating system, so there's an extra
Speaker 1: layer of abstraction there. Now, through a hypervisor, a single
Speaker 1: machine can host multiple virtual guest machines. This idea would
Speaker 1: be further explored in the next phase, that of true virtualization,
Speaker 1: which I'll get to in just a moment. But first
Speaker 1: let's take a quick break. Okay, so we just got
Speaker 1: into what you could think of as the prehistoric virtualization era,
Speaker 1: with hypervisor technology just coming into development. IBM was at
Speaker 1: the forefront of this research with the CP forty mainframe
Speaker 1: system in the nineteen sixties. The system ran on a
Speaker 1: special operating system called CP slash c MS, which originally
Speaker 1: stood for Control Program slash Cambridge Monitor System, though later
Speaker 1: CMS would change to mean Conversational Monitor System and I've
Speaker 1: even seen a couple of other variants out there. The
Speaker 1: control program part was what allowed for this early virtualization
Speaker 1: in the CP forty. It effectively created a full virtualization
Speaker 1: of the underlying hardware of the CP forty for each
Speaker 1: virtual machine, so people on dumb terminals terminals that did
Speaker 1: not have their own solely dedicated computer could have a
Speaker 1: virtual computer at their disposal. All the work was actually
Speaker 1: being done on top of the single CP forty prototype,
Speaker 1: but to each user it was as if they had
Speaker 1: access to their own individual computer. The virtualization software partitioned
Speaker 1: computer assets to each user. This wasn't just a matter
Speaker 1: of convenience. It also allowed for rapid innovation. Programmers could
Speaker 1: work on their own virtual machines, creating applications without having
Speaker 1: to worry about a bug affecting everyone else. The partitions
Speaker 1: provided protection, so if you were plugging away on a
Speaker 1: difficult section of code and your coworker fouled something up
Speaker 1: on their virtual machine, you didn't have to worry about
Speaker 1: their mistake bringing you down with them. Each virtual machine
Speaker 1: acted like its own individual physical computer. You can see
Speaker 1: some similarities between this model of computing and what would
Speaker 1: come much later in the era of cloud computing and
Speaker 1: the brief age of netbooks. Technically, netbooks are still around,
Speaker 1: but they are no longer the heyday type device that
Speaker 1: they were for a very short while. The netbook essentially
Speaker 1: had a five year run from two thousand seven to
Speaker 1: two thousand twelve, and it's a category of lightweight laptop
Speaker 1: computers that had modest specifications because the real purpose of
Speaker 1: the computer was to use cloud based services. You didn't
Speaker 1: have to have a b E fee computer because most
Speaker 1: of the processing was taking place somewhere else. The netbooks
Speaker 1: were a type of thin client, kind of like those
Speaker 1: dummy terminals used in time sharing mainframe systems. You didn't
Speaker 1: have to have a lot of horsepower. You just needed
Speaker 1: input devices like a keyboard and output devices like a display,
Speaker 1: and the actual computing was happening on some other machine
Speaker 1: out on the internet. We'll talk about that more a
Speaker 1: bit later in this episode. So while work on and
Speaker 1: with the CP forty system was going, IBM researchers were
Speaker 1: looking into other breakthroughs that would become important for computers
Speaker 1: in general and virtualization in particular. In nineteen sixty five,
Speaker 1: IBM announced it was developing a thirty two bit central
Speaker 1: processing unit that included virtual memory hardware in it. This
Speaker 1: was called the IBM System SLASH three sixty. IBM researchers
Speaker 1: used what they learned developing the CP forty to create
Speaker 1: the CP sixty seven, which was built on this IBM
Speaker 1: system Slash three sixty DASH sixties seven hardware. I love
Speaker 1: these names, by the way, there's so much fun to say. Anyway,
Speaker 1: this would be the first computer to support virtualization that
Speaker 1: would actually be widely available as a commercial product, not
Speaker 1: just a prototype. This was an important component for mainframe users,
Speaker 1: but it wouldn't really transfer to micro or mini computers.
Speaker 1: So this is still in the main frame age where
Speaker 1: you have the big centralized computer, and it's not that
Speaker 1: big of a surprise. You know, a mainframe is a
Speaker 1: centralized machine, but later computers didn't necessarily follow that model. Instead,
Speaker 1: you could have a computer at your own desk. The
Speaker 1: need to partition and separate your machine from everyone else
Speaker 1: wasn't as pressing since you were working on an actual
Speaker 1: separate piece of hardware rather than sharing a centralized computer
Speaker 1: amongst everybody else, and the hardware you were using was
Speaker 1: capable enough to do whatever it was you were doing.
Speaker 1: Majorization reached the point where it was possible to produce
Speaker 1: a relatively small computer, especially compared to the giant mainframes
Speaker 1: of the nineteen fifties and nineteen sixties, and it could
Speaker 1: handle all the tasks that your average user could throw
Speaker 1: at it. So we started to see a shift away
Speaker 1: from this centralized model of the mainframe strategy to a
Speaker 1: decentralized approach in which everyone would work on their own
Speaker 1: separate machine. This would continue and accelerate in the mid
Speaker 1: to late nineteen seventies when the personal computer emerged and
Speaker 1: the general public began to dip their proverbial toe in
Speaker 1: the computational pool or something. Now that's not to say
Speaker 1: that all work on virtualization stopped completely in the nineteen seventies.
Speaker 1: It certainly didn't speed up, and it pretty much remained
Speaker 1: in the domain of mainframe computers, which still had their uses,
Speaker 1: but in niche cases, in fact increasingly niche cases. So
Speaker 1: whether they were legacy systems that companies depended upon to
Speaker 1: keep business going, or they were more powerful machines that
Speaker 1: could be realized in the smaller formats. You know, they
Speaker 1: were these powerful machines that were being used are very
Speaker 1: specific tasks. They still had a place, it was just
Speaker 1: a reduced place, and that was pretty much where virtualization
Speaker 1: was stuck until the mid nineteen eighties. That's when a
Speaker 1: company called Locust Computing Corporation developed special software in collaboration
Speaker 1: with A T and T for a computer called the
Speaker 1: A T and T sixty three hundred plus. The computers
Speaker 1: operating system was Unix s v R two. Now, the
Speaker 1: thing about Unix is. It's an operating system that can
Speaker 1: support Unix programs, but it couldn't run DOSS based programs
Speaker 1: on its own. And for those of you who aren't
Speaker 1: familiar with DOSS, it was the text based operating system
Speaker 1: used by many computers. There were lots of different flavors
Speaker 1: of DOSS um Apple had its own sort of version,
Speaker 1: but the one that everyone really knew was IMMAs DOSS,
Speaker 1: the Microsoft flavor of DOSS that was the most popular
Speaker 1: version of the text based operating system out there for
Speaker 1: IBM and IBM comp udible machines. So there are a
Speaker 1: lot of programs developed for MS DOSS and DAWs in general,
Speaker 1: but you couldn't run them on a Unix based device.
Speaker 1: So Locus developed some software that would handle the interaction
Speaker 1: between DOSS programs designed for the eight eight six instruction
Speaker 1: set that DOSS programs were reliant upon and the underlying
Speaker 1: Unix operating system, so it's kind of like a liaison
Speaker 1: between those. The software have become known as MERGE and
Speaker 1: would be one of the first virtual machine managing or
Speaker 1: VMM products on the market. So now you could have
Speaker 1: a Unix machine and still run DOSS programs on top
Speaker 1: of it. By having this virtual DOSS machine running on
Speaker 1: the Unix hardware. This would mark a new era in
Speaker 1: which companies would make software that would allow computers running
Speaker 1: on one type of operating system in hardware to run
Speaker 1: an instance of a different operating system, and it opened
Speaker 1: up access to other types of programs. Most of us
Speaker 1: don't tend to work on Unix systems. But what about
Speaker 1: max versus PCs. You know that a Mac computer can't
Speaker 1: run a DOSS or later on a Windows program, and
Speaker 1: vice versa Windows computer can't run a Mac program. But
Speaker 1: developers created virtual machine software that would allow a Macintosh
Speaker 1: computer to run a virtual instance of DOSS on a Mac,
Speaker 1: meaning you could access those DOSS programs on a Macintosh
Speaker 1: while running this virtual machine software. Suddenly you could take
Speaker 1: advantage of programs meant for another type of computer on
Speaker 1: your own machine. By the way, it probably comes as
Speaker 1: very little surprised to those of you who are familiar
Speaker 1: with Apple that the company was not a fan of
Speaker 1: anyone running the Mac operating system on a non Apple machine.
Speaker 1: Through virtualization. This was technically possible, but Apple maintained that
Speaker 1: the only legal way to do it was to run
Speaker 1: mac os on a virtual platform on top of another
Speaker 1: Apple branded computer. So why would you want to run
Speaker 1: a virtual version of mac OS on top of a
Speaker 1: computer already running Mac OS. One reason would be to
Speaker 1: test a new program against multiple versions of a single
Speaker 1: operating system. So you might want to run your new
Speaker 1: mac program against the latest version of Mac OS and
Speaker 1: then the previous versions of Mac OS to see if
Speaker 1: it's still compatible, making sure you have backwards compatibility written
Speaker 1: in there. That would be handy to know. For about
Speaker 1: a decade, that was the state of virtualization. Companies made
Speaker 1: programs that would allow users to run one operating system
Speaker 1: on top of a machine running a different operating system.
Speaker 1: It was useful for people who were developing software for
Speaker 1: other platforms, but beyond that, there wasn't much general use
Speaker 1: for it, because, again, everyone was relying on their own
Speaker 1: individual computers anyway, you didn't have to worry about creating
Speaker 1: partitions between users for the most part. There were other
Speaker 1: manifestations of virtualization that would come on the scene a
Speaker 1: little bit later. In the early nineteen nineties, a team
Speaker 1: at Sun Microsystems was hard at work developing a new
Speaker 1: programming language that would eventually take on the name Java. Initially,
Speaker 1: the idea was that this programming language would allow developers
Speaker 1: to create programs running on home appliances like television's. The
Speaker 1: need for a language that developers could use to create
Speaker 1: programs for different platforms was obvious because these appliances would
Speaker 1: be coming from different manufacturers who would be working with
Speaker 1: different microprocessor companies, so there was no guarantee that televisions
Speaker 1: from two different companies would have similar microchips in them. Now,
Speaker 1: this is a non trivial problem. If you are a programmer,
Speaker 1: you have to make some practical decisions that have little
Speaker 1: to do with the actual purpose of your application, and
Speaker 1: one of those decisions is what platform will I develop for. Frequently,
Speaker 1: the answer that many developers gravitate toward is I want
Speaker 1: to develop for the most popular platform out there because
Speaker 1: it represents the largest potential customer base. To put it
Speaker 1: in another way, let's say you're making a video game,
Speaker 1: and let's say there's only two consoles that are on
Speaker 1: the market. One of those consoles has a market share
Speaker 1: and the other has a ten market share, and they're
Speaker 1: both great game consoles, but you're more likely to focus
Speaker 1: on developing the game for the one that has the
Speaker 1: market share because that's where most of the gamers are.
Speaker 1: But one if you could create a programming language that
Speaker 1: could work on different platforms despite the underlying hardware, That
Speaker 1: was the idea behind Java. So programmer James Gosling and
Speaker 1: his team set out to create a programming language that
Speaker 1: could work on top of any device that was running
Speaker 1: a Java virtual machine. While the resulting language wasn't used
Speaker 1: in TVs at that time, it quickly became recognized as
Speaker 1: a valuable tool for web development by the time the
Speaker 1: Java Development Kit debuted in By then, the web was
Speaker 1: really starting to take off, but it was also pretty limited.
Speaker 1: All sorts of computers were acting as servers on the Internet,
Speaker 1: running on different hardware and using for an operating systems,
Speaker 1: and there was a need for more dynamic, interesting, rich
Speaker 1: experiences online. But with everyone running different systems, it was
Speaker 1: impossible to guarantee that a web app would work for everyone.
Speaker 1: Java helped take that pressure off. It was a right, once,
Speaker 1: run anywhere programming language, and so the language was adopted
Speaker 1: widely on the web, with web browsers building Java applets
Speaker 1: to support it within the browser itself. This virtualization made
Speaker 1: rich Internet experiences possible. As it turns out the Internet
Speaker 1: in general and the Web in particular would create the
Speaker 1: perfect environment for the evolution of virtualization. This appeals to
Speaker 1: common sense. After all, the Internet is a network of networks,
Speaker 1: and each network can potentially include millions of computers running
Speaker 1: on different operating systems and hardware. This makes common sense, right,
Speaker 1: after all, being Internet is a network of networks, and
Speaker 1: each network can potentially include millions of computers running on
Speaker 1: different operating systems and hardware. When we come back, I'll
Speaker 1: talk about how virtualization really took off in the late
Speaker 1: nineties and what's been going on up to today. But
Speaker 1: first let's take a quick break. In a way, you
Speaker 1: could say that the Internet made the evolution of virtualization
Speaker 1: not just possible but necessary. Typically, I T departments like
Speaker 1: to dedicate servers to a specific task. They handle that
Speaker 1: one task and nothing else. This dedication helps keep things
Speaker 1: streamlined and reduces the chance that different tasks will start
Speaker 1: to interfere with one another and cost stability issues. But
Speaker 1: as the Internet was growing faster and faster, it became
Speaker 1: clear that this particular strategy was going to be unsustainable.
Speaker 1: It was just getting too big and too complex. Servers
Speaker 1: are expensive and they're not just expensive to purchase, they're
Speaker 1: also expensive to operate and maintain. If you're dedicating a
Speaker 1: single server to every single task and you're adding to
Speaker 1: the number of services you have on offer, your server
Speaker 1: room is going to get really crowded really quickly. Those
Speaker 1: machines take up physical space. Then you have other considerations
Speaker 1: you have to take into account, such as having a
Speaker 1: sufficient cooling system to keep everything operational, because computers don't
Speaker 1: do well when they overheat, and as you add more machines,
Speaker 1: you're generating more and more heat, so you've got to
Speaker 1: cool them down more effectively. Then you have to figure
Speaker 1: out how much electricity these things are gobbling up. It's
Speaker 1: it's getting more expensive as you're adding more servers, and
Speaker 1: and then there's the question of downtime. It's quite possible
Speaker 1: that some servers will be in less demand than others.
Speaker 1: So you might have one server operating at about fifteen
Speaker 1: percent of its overall capacity and it's essentially idling the
Speaker 1: other of the day. That's not an efficient use of resources.
Speaker 1: If you've got fifty servers but all of them are
Speaker 1: working at fifteen percent, you're saying, Wow, I'm I'm really
Speaker 1: inefficient with how I'm using these machines. Virtualization would prove
Speaker 1: to be a solution to this problem, but it wasn't
Speaker 1: an easy solution. One of the big challenges facing developers
Speaker 1: at that time was that the X eight six architecture
Speaker 1: that many modern computers rely upon wasn't designed with virtualization
Speaker 1: in mind, and there were some hurdles to overcome. And
Speaker 1: you may have heard of X eight six and maybe
Speaker 1: you wonder what the heck does that actually mean. It's
Speaker 1: a reference to Intel's eight eighty six microprocessor, which originally
Speaker 1: debuted in ninety eight. The eight eight six architecture is
Speaker 1: the foundation for successive processors such as the two eighty six,
Speaker 1: the e D three eighty six, and the eight four
Speaker 1: eighty six. So if you ever heard someone talking about
Speaker 1: like a three eight six or forty six computer, they
Speaker 1: were actually talking about this particular architecture. It's a computer
Speaker 1: that's based off this microprocessor architecture, which was largely designed
Speaker 1: so that it could be backwards compatible while adding to
Speaker 1: the various features and the processing speed generation to generation.
Speaker 1: More importantly, it became the dominant architecture for computing platforms,
Speaker 1: including Internet servers. But as I said that architecture was
Speaker 1: not created with virtualization in mind, and there were several
Speaker 1: key instructions that, when virtualized, would tend to cause an
Speaker 1: X eight six system to crash. So while there was
Speaker 1: a growing need for virtualization as the Internet was growing,
Speaker 1: there was this challenge of implementing virtualization without actually making
Speaker 1: everything crash all the time. Enter vm Ware. Now I'll
Speaker 1: have to do a full episode on the company a
Speaker 1: vm Ware someday. It's known for its virtualization software. In
Speaker 1: two thousand one, vm Ware would introduce virtualization platforms for
Speaker 1: Internet servers that handled the operations of virtualization in a
Speaker 1: way that wouldn't trigger these system crashes. So now you
Speaker 1: could run virtualization software on X eight six architecture systems
Speaker 1: and not have to worry about them just completely crapping
Speaker 1: out on you at a moment's notice. At first, the
Speaker 1: products were actually slow to catch on It was not
Speaker 1: yet apparent how useful they would be, but that would change,
Speaker 1: and vm Ware's early entry into the space would mean
Speaker 1: that the company would end up holding a dominant portion
Speaker 1: of the virtualization market even as other software companies caught
Speaker 1: onto it. Now, to avoid this episode just becoming a
Speaker 1: list of release dates, for virtualization software. I'm gonna summarize
Speaker 1: this to say that companies like Virtue Tech, A M
Speaker 1: D Connectics, Virtus, Sun, and then later Oracle when it
Speaker 1: would buy Sun Microsystems, also Microsoft itself, all of them
Speaker 1: released various virtual realization solutions over the years. Some were
Speaker 1: built to take advantage of changes in architecture, such as
Speaker 1: sixty four bit instruction sets. But beyond these technical specifications,
Speaker 1: there's not really that much to talk about. So I
Speaker 1: think it's better to go back to a broad picture,
Speaker 1: because otherwise, all I'm telling you is that the virtualization
Speaker 1: software improved so that it could take advantage of improvements
Speaker 1: in microprocessor design. That gets really boring really fast. So
Speaker 1: how did virtualization actually help in the Internet age? Well,
Speaker 1: by using this special software and I T admin could
Speaker 1: take a single existing Internet server and then create multiple
Speaker 1: virtual servers, and then each virtual server would perform as
Speaker 1: if it was its own physical machine, similar to the
Speaker 1: way previous implementations of virtualization would do. But you know,
Speaker 1: in those cases you were talking about running a different
Speaker 1: operating system on top of a machine or something like that.
Speaker 1: But in this case, all of the virtual servers would
Speaker 1: exist on top of a single device, and with careful planning,
Speaker 1: you can build out virtual servers to make each physical
Speaker 1: machine more efficient by run making it run closer to capacity. Right,
Speaker 1: so instead of running at capacity, you might have it
Speaker 1: running at seventy or eighty percent capacity. Now, you never
Speaker 1: really want to run at full capacity because you could
Speaker 1: have response time issues if they're if the demand is
Speaker 1: exceeding the server's ability to serve up data, then you're
Speaker 1: gonna have performance problems. But if you could get it
Speaker 1: closer to capacity, then you have less downtime for your
Speaker 1: machine and you're making better use of your equipment. And
Speaker 1: with the right virtual machine management software, each individual virtual
Speaker 1: server is totally partitioned from the others, which helps you
Speaker 1: maintain security and stability. If one virtual server does go down,
Speaker 1: the other virtual servers on top of that same physical
Speaker 1: machine should be able to continue to operate without being affected.
Speaker 1: So let's say you're a company and you have four
Speaker 1: different apps. This is just a very basic example. So
Speaker 1: you've got a server and you divided it into four
Speaker 1: virtual servers, and then one of your virtual servers for
Speaker 1: one of those apps fails, the other three apps should
Speaker 1: still be able to operate just fine. Meanwhile, you've got
Speaker 1: an I T admin frantically trying to fix the problem
Speaker 1: on the virtual server of the affected app and get
Speaker 1: it back online as fast as possible. But ideally you're
Speaker 1: doing this in a way where your other operations aren't
Speaker 1: being affected at all. So not only could you get
Speaker 1: better use out of your hardware using virtualization, you could
Speaker 1: also reduce the number of physical servers you had in
Speaker 1: your data centers, and this would become increasingly important as
Speaker 1: cloud services came on the scene and grew in popularity.
Speaker 1: A large cloud service, whether it's offering an operational platform,
Speaker 1: or storage space or something else, requires an awful lot
Speaker 1: of hardware, but that requirement would be gargantuan if it
Speaker 1: weren't for virtualization. For example, one of the many important
Speaker 1: concepts in computing is redundancy. That is, making sure the
Speaker 1: service you offer remains available even in the event of
Speaker 1: a failure in the system. And this is true for
Speaker 1: all sorts of services, but it's probably easiest to understand
Speaker 1: if we take something that most of us have had
Speaker 1: experience with. So let's talk about cloud storage. Let's say
Speaker 1: you're using an online data storage service like Google Drive,
Speaker 1: so you've stored some files on Google Drive. You've created
Speaker 1: numerous documents, or you've uploaded files into your personal Google Drive,
Speaker 1: and you expect to be able to access those files
Speaker 1: whenever and wherever you need them, assuming you have some
Speaker 1: sort of Internet connection, and you know that your files
Speaker 1: are not living on your own personal computer or device.
Speaker 1: It's living on the cloud, so you can use whatever
Speaker 1: device you want to connect to those files. So the
Speaker 1: files live somewhere on some server that is owned and
Speaker 1: operated by Google, and that's partly true, but it's more
Speaker 1: accurate to say that those files live on multiple servers
Speaker 1: and and operated by Google, because hardware occasionally fails, and
Speaker 1: if that were to happen to the machine that's holding
Speaker 1: your files, you wouldn't be able to get to your stuff,
Speaker 1: and that would be a problem for you and thus
Speaker 1: a problem for Google. So to avoid that, Google has
Speaker 1: copies of all of your files, and it's spread across
Speaker 1: numerous servers to provide redundancy. If one server should fail,
Speaker 1: Google can switch to a different one to serve up
Speaker 1: your files to you when you request them, and you
Speaker 1: get what you want and you're none the wiser that
Speaker 1: anything is wrong on the back end. Redundancy is important
Speaker 1: for any online service, and virtualization can help reduce the
Speaker 1: physical hardware requirements for redundancy. So now, let's say you're
Speaker 1: the one that's running Google Drive. It's it's under your direction,
Speaker 1: and while you'd be using virtual servers, you would likely
Speaker 1: still want to store the same information from the same
Speaker 1: client on different physical machines. So let's say you've got
Speaker 1: two physical servers. You've got server one and server two,
Speaker 1: and each physical server has four virtual servers on it.
Speaker 1: So Server one has virtual servers A, B, C, and D,
Speaker 1: and server too has virtual servers E, F, G, n H. Now,
Speaker 1: technically you could dedicate virtual servers A and B, both
Speaker 1: of those living on the same physical machine, to act
Speaker 1: as backups for each other. But if something were to
Speaker 1: go wrong in one of the virtual environments, it wouldn't
Speaker 1: affect the other one their partition from each other. However,
Speaker 1: if something were to go wrong to the underlying physical hardware,
Speaker 1: the actual machine that's running everything, you'd be out of
Speaker 1: luck because you'd lose both your copies or you'd at
Speaker 1: least not not be able to access them until you've
Speaker 1: repaired whatever the problem was. So for that reason, you
Speaker 1: want to spread the load around your physical machines, and
Speaker 1: you want to keep everything running at a good efficiency,
Speaker 1: so you want to use virtual servers to reduce downtime.
Speaker 1: And of course virtualization is used for all types of
Speaker 1: cloud services, including app development um. In fact, that's a
Speaker 1: great use of virtualization as it gives developers the chance
Speaker 1: to program in an environment where they are reassured they're
Speaker 1: not gonna mess everything else up if something goes wrong.
Speaker 1: And so there are companies out there that get massive
Speaker 1: amounts of revenue from customers who are essentially renting out
Speaker 1: a virtual server space to develop apps on top of
Speaker 1: before they develop, develop and deploy those apps into the
Speaker 1: into the wild to get them to actual customers. Now,
Speaker 1: I've talked a lot about why virtualization is useful, but
Speaker 1: it also presents challenges. It's not a perfect solution to
Speaker 1: all problems. It also presents opportunities for problems to arise,
Speaker 1: and one of those is in security. If someone is
Speaker 1: able to get access to the underlying hardware, either physically
Speaker 1: or remotely, then they could potentially affect all the virtual
Speaker 1: servers that are running on that physical machine. So instead
Speaker 1: of corrupting one service, a bad actor could have affect
Speaker 1: possibly several services. So security is a big concern in
Speaker 1: the virtualization world and in the information world in general.
Speaker 1: Another challenge is that there's a lack of established standards
Speaker 1: in virtualization, though there's movement in the space to change that,
Speaker 1: and that means that a data center might use several
Speaker 1: different virtualization strategies, which in turn means the I T
Speaker 1: department has to be able to handle all that, and
Speaker 1: this can get pretty tough as organizations and systems grow
Speaker 1: more complicated. There's also the problem that as systems grow,
Speaker 1: things can be forgotten. Just keeping track of all those
Speaker 1: virtual machines and what's running on each of them can
Speaker 1: become challenging in itself, and with a complicated enough system,
Speaker 1: it's possible for virtual servers to go overlooked. And if
Speaker 1: it's overlooked and no one is using it, that brings
Speaker 1: down the operational efficiency of the physical machine that's running
Speaker 1: that server, and it's hard to get around performance issues
Speaker 1: as well. A dedicated physical server that is only running
Speaker 1: one task can more efficiently handle that task than a
Speaker 1: computer that has a virtual layer on top of the
Speaker 1: physical layer. Think of it sort of like getting permission
Speaker 1: from a boss in a smooth operation. You just go
Speaker 1: to your boss and you ask for permission to do something,
Speaker 1: and you get it or you don't get it. But
Speaker 1: in a company that has, say a bloated middle management layer,
Speaker 1: maybe first you have to go through a lower level
Speaker 1: manager who doesn't have that authority, but you still have
Speaker 1: to talk to them before you can get access to
Speaker 1: the boss who actually does have the authority to say
Speaker 1: yes or no to your request. It slows things down. Well,
Speaker 1: virtual platforms can also slow things down a little bit,
Speaker 1: so that's another potential drawback to virtualization. However, overall, virtualization
Speaker 1: has been a huge reason why we've seen such explosive
Speaker 1: growth in online services, and it continues to be important
Speaker 1: for developers who are creating programs for multiple platforms. And
Speaker 1: so I hope this episode has sort of given you
Speaker 1: an idea of what virtualization is all about, where it
Speaker 1: came from, and why it's important. Uh, it's definitely something
Speaker 1: that has enabled us to have a world where we
Speaker 1: have discussions about things like the Internet of Things. Without virtualization,
Speaker 1: we wouldn't have the ability to support all those services
Speaker 1: because you wouldn't have a data center large enough to
Speaker 1: hold all the actual physical servers you would need to
Speaker 1: dedicate to each and every task. It would be a
Speaker 1: terrible waste of space, of energy, of resources, of money.
Speaker 1: So virtualization has really helped create an efficient and cost
Speaker 1: effective approach to deploying numerous services across the Internet. So
Speaker 1: we'll probably see a lot more development in that space,
Speaker 1: will see more competition in it, although the big players
Speaker 1: will probably hold on to a pretty large market share.
Speaker 1: They've got time on their side and their reputations are
Speaker 1: built on that. So I'll probably do more episodes about
Speaker 1: virtualization or the company is involved in it in the future.
Speaker 1: In the meantime, thank you so much for this suggestion.
Speaker 1: I greatly appreciate it. It's the sort of topic that
Speaker 1: I used to cover all the time on tech Stuff,
Speaker 1: but it's been a while since I've covered one like this,
Speaker 1: So Martin, thank you very much. I hope you enjoyed
Speaker 1: this episode, and I hope the rest of you were
Speaker 1: able to learn something from it. If you guys have
Speaker 1: suggestions for future episodes, you can send me an email.
Speaker 1: The address is tech stuff at how stuff works dot com.
Speaker 1: Drop on by our website that's tech stuff podcast dot com.
Speaker 1: There you're gonna find an archive of all of our
Speaker 1: past episodes, as well as links to things like our
Speaker 1: social media presence and our online store, where every purchase
Speaker 1: you make goes to help the show and we greatly
Speaker 1: appreciate it, and I'll talk to you again really soon.
Speaker 1: Text Stuff is a production of I heart Radio's How
Speaker 1: Stuff Works. For more podcasts from I heart Radio, visit
Speaker 1: the I heart Radio app, Apple Podcasts, or wherever you
Speaker 1: listen to your favorite shows. H