This blog post compliments the Virtualization Review article ESXi: A Technology Embedded in Marketing Hype or Destined for Greatness?. The version of the article in print was shortened due to space constraints and because of this, lost some facts that supported my arguments. In particular the section on how small code-bases do not necessarily reduce problems is missing code examples that support the arguments. To that end I am including that section in this blog post with the original code examples.
SPIN: ESXi is small! Smaller is better!
REALITY: ESXi is small. But it doesn’t necessarily follow that smaller is better.
The industry has gone ga-ga about the fact that VMware was able to strip ESX down to 32 MB. While an impressive accomplishment, it has nothing to do with creating an embedded hypervisor. While reducing the size of the hypervisor may help facilitate “embedding” the product, it is certainly not necessary to do so. The size of flash drives today could easily support the full ESX stack, even with the service console that was removed from ESXi.
There has also been a lot of discussion how a smaller code footprint means that the product is in some way better — that it has fewer bugs. The idea that a fewer lines of code (LOC) absolutely equals fewer bugs is a myth that has existed in IT for far too long. The reality is that reducing the number of lines of code in can sometimes add confusion, and even when it doesn’t, mistakes can still be made.
The above arguments are supported by a great, recent blog on the subject. In the interest of inclusion, I will go ahead and present the author’s arguments:
1. More lines can lead to easier readability, resulting in fewer bugs.
For example, imagine you write want to assign a value to an integer variable based upon a series of boolean comparisons:
1: int x = b1 ? 1 : b2 ? 2: b3 ? 3 : b4 ? 4 : 5;
The above line of code says “assign x the value of 1 if b1 is true, otherwise assign x the value of 2 if b2 is true, otherwise assign x the value of 3 if b3 is true, otherwise assign x the value of 4 if b4 is true, otherwise assign x the value of 5.” While the line of code is perfectly legal, it is not entirely straight-forward. Let’s take a look at the same logic written in a different manner:
1: int x;
2: if ( b1 )
4: x = 1;
6: else if ( b2 )
8: x = 2;
10: else if ( b3 )
12: x = 3;
14: else if ( b4 )
16: x = 4;
20: x = 5;
Both code snippets accomplish the same task, the first snippet in one line and the second in twenty-one lines. While I agree that the first method is far more elegant, the logic is much easier to read in the second, and thus less likely to be error-prone. It is also possible for very simple, very short, very straight-forward statements to contain a mundane error that drastically changes an expected outcome. For example, what is the value of y after the following loop?
1: int x = 1; int y = 1;
2: for ( x = 1; x <= 100; ++x );
4: y *= x;
The value of y should be the factorial of 100, instead it is still 1. Can you spot the error? I accidentally typed a trailing semi-colon at the end of line #2. As you can see, a simple piece of obvious code can easily be subject to a seemingly innocuous error that has great consequences.
As you can see, reducing the number of lines of code in can sometimes add confusion, and even when it doesn’t, mistakes can still be made.