In my last blog, I wrote about pattern idea from the famous books “Design Pattern” and “A Pattern Language” and how it can be applied to cloud architecture design. Below and in later posts in this series I shall follow the content outline used there to illustrate the cloud architecture patterns.
Provide a standard way to create new virtual machines based on user requirements.
There are enormous combinations of virtual machines with different operating systems, middleware, and applications. And then we have user data to the mix! We need a standard way to create new virtual machines.
General speaking, there are three basic ways to create new virtual machines:
1. Create bare metal virtual machine and install operating systems, etc. You can manually mount CDs for installing, or use PXE booting for automatic installation
2. Clone an existing virtual machine
3. Deploy from a virtual machine template
These could be complicated because you have to take care of many details. To use a virtual machine, do you care how it’s created? Not really, so long as you get the virtual machine that meets your specifications.
Things get more complicated when you have to deal with both private clouds and public clouds. Also, the way you create new virtual machines differs from one cloud vendor to the other. You want a unified way to hide these differences.
We can delegate the creation of new virtual machines to a specific application for simplified user experience. You just tell it what you want and let it handle all the details.
Specifying VMs You Want
There are two major aspects specifying the VM you want:
1. Hardware specification. This includes how many virtual CPUs/how much virtual memory/how big of disks/how many virtual NICs, etc.
2. VM template. This is the “gene” of the virtual machine, based on which you want to create your own virtual machine so that you can inherit all the software from the template
For the hardware spec, you may choose three different approaches:
1. OVF. This is a standard by DMTF and has been accepted as ANSI standard. It defines comprehensive details beyond hardware itself. It is by far the most flexible yet complicated way. VMware vCloud uses this approach.
2. Limited parameters. It covers most commonly used parameters like vCPU, memory, and disks but without the complexity of OVF. Some of VMware’s vCloud Express partners use this approach.
3. Pre-defined choices. You can pick most commonly used combinations of vCPU/mem/disk, and make them as several possible choices. It’s much like a menu, very easy to pick from. Amazon EC2 uses this approach.
For the VM template, it could be very simple. You can create a catalog with many possible templates, each of which is assigned a unique ID, and make them available for users. All the users need to do is to choose a template.
How It Works
Figure 1 shows the process of a VM factory. The Client first sends a request to the factory and the factory creates a new VM based on the client specifications. Once the VM is created and powered on, it can be accessed by anyone authorized. The client can, for example, bypass the factory and access the VM directly.
More often than not, a newly created VM is not good enough. You may want to install applications of your own, or at least modify the configuration settings of the existing OS, middleware or applications.
You may connect to the virtual machine and inject and run certain scripts for installation/customization. Optionally, you can embed a script in your VM and let it run automatically when the OS boots up. The former approach is always more flexible than the latter but require more work.
General VM Factory
“Wait a second, why should I need this? Isn’t this what cloud service providers do for me already?” That is true. But you may want to build your own private cloud, or leverage both a private cloud and a public cloud (That is double cloud, by the way). I see the double cloud or hybrid cloud as the future.
With the double cloud scenario in mind, we will need a more complicated structure as follows. Note that the VM template is not transferrable from one service provider to the other.
Figure 2. Example of a two-tiered VM factory
When multiple service providers are involved, you may add additional functionalities into the general factory. For example, you can implement a policy engine to decide which service providers to select for best price, SLAs, etc. You can also keep account information within your general factory without exposing it to all your users. It definitely helps IT control.
You can use a two-tier VM factory to:
- Simplify VM creation while keeping flexibility;
- Hide the details of virtual machine creation;
- Integrate private and public cloud with unified APIs;
- Control VM creation policy in an environment involving multiple clouds.
The VM factory pattern centralizes and simplifies the creation of new virtual machines. Users who want to create new virtual machines are isolated from the complexity underneath.
At the same time, it can be a single point of failure. You may need a HA solution for best availability.
In some cases, for example limited instance types, you give up flexibility in specifying VM configurations.
Almost all of the public service providers implement factory pattern and provide a public interface for users to create new VMs. VMware vCloud Director offers similar APIs as well.
For the hybrid cloud use case, I haven’t seen much about how this works in the real projects. Please leave a comment if you have a story to share!
VM pool (coming up soon): after a new VM is created by the factory, you can optionally put it into a pool for instant provisioning later on.