This second part contains best practice No.1 ~ 3.
＃1 Move Up to Higher Level Software Stack
“If I have seen a little further it is by standing on the shoulders of Giants.”
Isaac Newton
Modern software development is all about leverage. You don’t want to build everything from bottom up. Whatever “giant shoulders” you can leverage, you should do so. Remember the keyword here is “giant shoulders.” You got to be selective on what is “a giant” and what is not, for the best quality of your system. Your application’s quality is a function of that of the systems underneath it.
The typical “giant shoulders” includes middleware, high level programming languages, tools. By leveraging these, you should expect your applications portable, and with much less code and higher developer productivity. The portability is very important when you want to deploy your applications in federated cloud environment.
I posted a short article after the cloud demo in VMworld 2009 keynotes. It’s reposted at SpringSource blog. The article introduced “DIY PaaS” concept which you could have a higher level of development platform inside your enterprise in a similar way as would you get from vendors like Google, but without vendor lock-in.
The “DIY PaaS” does not require you to use any specific platforms, middleware or framework. You could use any existing combination of systems on top of Java, .Net, Python, PHP. For example, you could use Java with Spring framework for building your web applications or enterprise integration frameworks. The choice is really yours, not of any vendors. When making a decision, you want to consider various factors like your team’s expertise and preference, total cost of software licenses, design constraints posted by for example existing investments on particular software.
Having decided the combination of software stack, you want to pack them into virtual machine templates that can be re-used by various teams. If you have multiple combinations, you can have multiple virtual machine templates in your catalog.
In general, you want as few templates as possible. Why?
Having less VM templates means less effort to build them, to manage, to upgrade, and to test. This might not seem like a big deal but could become a big deal in a longer term when you have to maintain multiple versions of these templates at the same time.
It also means less storage. vSphere has a special technology called linked clone. The new virtual machine doesn’t fully clone the disks, but links back to the template. If you have least templates, you can have a huge saving on the disk space. High quality storage can be very expensive.
Last but not least benefit is less memory. vSphere has memory page sharing technology which keeps one copy of same page contents, and converts others as pointers to the single copy. It’s only possible when you have identical memory pages. When you have virtual machines cloned from a same templates, the chance of identical memory pages increases dramatically.
There are several techniques to keep the least number of virtual machine templates: Read more...
