I’ve been a technology and start-up lawyer for some years (I’m older than I look), and now I’m corporate counsel to a web hosting company. When I started out in IT, there were some concepts that, frankly, blew my mind a bit. I felt stupid asking my clients or my technical team about them — but I asked anyway. And, fellow lawyers, to save you the pain and embarrassment of having to ask those same stupid questions of your clients or IT team, I want to use this column to share some of what I’ve learned. Today’s topic: virtualization.
In its most basic sense, virtualization is the creation of a virtual computer that acts like a real computer. Instead of building out your IT infrastructure physically, with sprawling stacks of hardware and software, you build it out virtually. A host server is the one physical server on which multiple guest servers, or virtual machines, can run.
So . . . what does that look like?
Here’s how one of my very patient engineers once explained it to me:
Imagine you run a delivery service, and you have a big company moving van (Important note: it’s the most space-age van possible. It’s from the future.). You only have a single van, but one day, you get triple-booked for three small jobs. What to do? You’re going to have to turn down one of your jobs, aren’t you? Or you don’t turn down any of those jobs because your van has van virtualization technology! You can take your one large van, turn a dial in the dashboard, and end up with three smaller vans that can each do a job!
Where the analogy falls apart
Me: So, are you dividing space within the same van for the three jobs?
Vastly more intelligent engineer: It’s mini vans within the van!
Other engineer who finds this conversation annoying but can’t resist chiming in: No, it’s multiple vans that are independent of the other vans!
(Several minutes of argument follow.)
What we were all able to agree is this: Each hypothetical van (a guest van) can run its own tasks, and follow its own delivery routes. And I only had to buy one van. It’s my prerogative whether I want to split up that one delivery van into 50 Matchbox-car sized vans, or two Honda Civic-sized vans. The customization is all up to me.
So why would you (or your client) want to do this?
The arguments for virtualization are easy. You can save money and maximize your IT resources by running multiple operating systems off one physical server. You split your host server up and “rent out” some of your guest servers to make some money. You could decide you don’t need a host server and run purely off a guest server that you purchase from a host, saving money on hardware costs. Or, from an administrative point of view, you can divide your guest servers by task, and have one server dedicated to company e-mail, another to web, and so on. The possibilities really are endless.
The licensing lawyer in me has to ask . . .
So if virtualization is standard practice (which it absolutely is, whether you know it or not) how does a licensor of software ensure it is getting adequately paid for the use of its software?
This has been a topic of some conversation among software and application providers for some time. We’re so beyond the days where you buy a physical piece of software off a shelf and are reasonably expected to only download or use that software in one instance. To go back to my van analogy, I have one van. So I buy one copy of the software, but then decide to have 50 Matchbox vans — and I run 50 copies of the software.
The bottom line is that software providers must price and license their product assuming it is going to be used in a virtualization scenario; otherwise enforcement becomes a nightmare. A licensor can’t audit each and every customer to ensure it’s only running the number of copies licensed; the costs would be astronomical and frankly, not great for customer relations.
There are technical measures and digital rights management tools that can enforce license terms. For instance, a piece of software can be designed to “phone home” to the licensor every time it’s booted up, to verify the system using the software is properly licensed. But the dreaded DRM is generally met with a chorus of concern regarding online privacy.
A more effective approach that is gaining popularity is to license applications according to the capacity of the host machine: forget licensing to a user or to a particular machine, and license according to RAM or CPU core. If a software provider prices for my one big super-futuristic van, knowing I can only divide it up into a maximum of 50 Matchbox vans, it might be able to price its software more accurately.
Real-life virtualization: Netflix
Netflix and Gmail are two services that run on virtualization. Netflix is a good example of a business that scales its guest servers up or down depending on capacity. If, at its peak, it has a million users, a pre-virtualization Netflix would have to have the physical servers to meet this capacity. My Netflix subscription would probably be way more than $7.99 per month if Netflix had to build that IT infrastructure. However, thanks to virtualization, it can run extra servers as needed to meet peak times and scale down accordingly. Renting someone else’s virtual vans as needed.
Wait a second, is virtualization the ‘cloud?’
Why yes, yes it is. Cloud servers are virtual machines. Now you’re catching on.
In its most basic sense, virtualization is the creation of a virtual computer that acts like a real computer. Instead of building out your IT infrastructure physically, with sprawling stacks of hardware and software, you build it out virtually. A host server is the one physical server on which multiple guest servers, or virtual machines, can run.
So . . . what does that look like?
Here’s how one of my very patient engineers once explained it to me:
Imagine you run a delivery service, and you have a big company moving van (Important note: it’s the most space-age van possible. It’s from the future.). You only have a single van, but one day, you get triple-booked for three small jobs. What to do? You’re going to have to turn down one of your jobs, aren’t you? Or you don’t turn down any of those jobs because your van has van virtualization technology! You can take your one large van, turn a dial in the dashboard, and end up with three smaller vans that can each do a job!
Where the analogy falls apart
Me: So, are you dividing space within the same van for the three jobs?
Vastly more intelligent engineer: It’s mini vans within the van!
Other engineer who finds this conversation annoying but can’t resist chiming in: No, it’s multiple vans that are independent of the other vans!
(Several minutes of argument follow.)
What we were all able to agree is this: Each hypothetical van (a guest van) can run its own tasks, and follow its own delivery routes. And I only had to buy one van. It’s my prerogative whether I want to split up that one delivery van into 50 Matchbox-car sized vans, or two Honda Civic-sized vans. The customization is all up to me.
So why would you (or your client) want to do this?
The arguments for virtualization are easy. You can save money and maximize your IT resources by running multiple operating systems off one physical server. You split your host server up and “rent out” some of your guest servers to make some money. You could decide you don’t need a host server and run purely off a guest server that you purchase from a host, saving money on hardware costs. Or, from an administrative point of view, you can divide your guest servers by task, and have one server dedicated to company e-mail, another to web, and so on. The possibilities really are endless.
The licensing lawyer in me has to ask . . .
So if virtualization is standard practice (which it absolutely is, whether you know it or not) how does a licensor of software ensure it is getting adequately paid for the use of its software?
This has been a topic of some conversation among software and application providers for some time. We’re so beyond the days where you buy a physical piece of software off a shelf and are reasonably expected to only download or use that software in one instance. To go back to my van analogy, I have one van. So I buy one copy of the software, but then decide to have 50 Matchbox vans — and I run 50 copies of the software.
The bottom line is that software providers must price and license their product assuming it is going to be used in a virtualization scenario; otherwise enforcement becomes a nightmare. A licensor can’t audit each and every customer to ensure it’s only running the number of copies licensed; the costs would be astronomical and frankly, not great for customer relations.
There are technical measures and digital rights management tools that can enforce license terms. For instance, a piece of software can be designed to “phone home” to the licensor every time it’s booted up, to verify the system using the software is properly licensed. But the dreaded DRM is generally met with a chorus of concern regarding online privacy.
A more effective approach that is gaining popularity is to license applications according to the capacity of the host machine: forget licensing to a user or to a particular machine, and license according to RAM or CPU core. If a software provider prices for my one big super-futuristic van, knowing I can only divide it up into a maximum of 50 Matchbox vans, it might be able to price its software more accurately.
Real-life virtualization: Netflix
Netflix and Gmail are two services that run on virtualization. Netflix is a good example of a business that scales its guest servers up or down depending on capacity. If, at its peak, it has a million users, a pre-virtualization Netflix would have to have the physical servers to meet this capacity. My Netflix subscription would probably be way more than $7.99 per month if Netflix had to build that IT infrastructure. However, thanks to virtualization, it can run extra servers as needed to meet peak times and scale down accordingly. Renting someone else’s virtual vans as needed.
Wait a second, is virtualization the ‘cloud?’
Why yes, yes it is. Cloud servers are virtual machines. Now you’re catching on.
