Virtualization

From GO Wiki
Revision as of 14:37, 17 September 2010 by Sjcarbon (talk | contribs) (more)
Jump to navigation Jump to search

Overview

Rational

In addition to the general advantages of virtualization in a computing infrastructure, there are potentially several advantages specific or especially important to the GO.

Consistency

AmiGO is currently. Other

This would also make the

Redundancy

Given that no infrastructure is bullet-proof, the ability to take a running machine and move it to a different facility without any downtime is a

Distribution

Similar to the idea of the experimental GO software ISO images, VM images are potentially a way to distribute GO software .

Also, with it's larger size, it would be possible to make

Platforms

Ubuntu/Debian

Currently, the preferred platform for future development on AmiGO is Ubuntu 10.04. Ubuntu is

In line with consistency and speed to production, a Debian-based system

In addition to being the

Eucalyptus

KVM

Amazon API

???

Cons

The cons list would seems to be fairly minimal with virtualization.

Initial infrastructure cost

While most newer machines support (necessary to get to make virtualization worthwhile) Not supported well by many older architectures Hopefully find new meaning as support machines (e.g. gateways, proxies, storage heads).

Moving large images around can me a slow and time-consuming process.

Increased complexity

Even though, the fact it that there is at least one additional layer between

Hopefully, however, this is somewhat mitigated by the increased ability to move VMs away from problem machines and technologies as problems arise.

Inexperience

Somewhat related to the above, as with any new way of doing things, there is going to be a learning period where

and the solution to new problems are not optimal.

Monoculture

Currently, AmiGO is developed on one platform, put into production on two others, with software developed for on a fairly wide variety. Just the act of having AmiGO function in all of these different places helps maintain a clean architecture and good coding practices (e.g. bugs that are not apparent on one platform cause crashes on another). To some extent, it becomes tradeoff between robustness and time to development. Given resource limitations, favoring the latter is probably the best at this time.

On a more paranoid angle, monoculture also increases the risk of a bug or security hole on one instance being trivially exploitable on all instances. I'm unaware of any specific attack again AmiGO/GO software, (only general attacks again, say, LBL), but the potential is there.

Put all your eggs in the one basket and--watch that basket!
Pudd'nhead Wilson's Calendar