Comments (0)

This 4th and last part contains best practice No.7 ~ 10. To be notified for future posts, feel free to subscribe to this feed, and follow me at Twitter.

#7 Levarage vApp

vApp is a new addition to vSphere. It’s essentially a group of VMs that work together as a solution. You can manage them as a basic unit like a VM. It provides you higher level granularity for resource allocation and management.

This is an ideal container for your application if you have multiple virtual machines involved. They may or may not form a cluster, but are bundled together for a same goal.

The vApps are not only easily managed by the vSphere, but also imported and export as a bundle. Therefore you can easily move it without worrying what should be included while copying it.

VMware provides tools like VMware Studio using which you can create and configure vApps easily. The VMware Studio has Web based console, customization and build engine, build process automation with CLI (command line interface).

Other alternatives include: Read more »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (0)

This 3rd part contains best practice No.4 ~ 6. To be notified for the rest, feel free to subscribe to this feed, and follow me at Twitter.

#4 Scale Applications as Needed

Most time, people think scalability is to handle more workload when needed. This is true, but not enough. A truly scalable system should scale back. This is how you will save money. This is equally important as the first case where you get more revenue by serving more traffic.

There are different ways to scale:

• Up and down. This is unique in virtualized environment in which you adjust the memory or CPU allocation and use more or less of them instantly.
• Out & in. This means you include more machines either physical or virtual into your application.

You have to think over several architecture decision points: Read more »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (0)

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 »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (4)

Overview

With more data centers running on purely virtualized systems, more applications are therefore running on top of virtualized environment than ever before. These virtualized systems are interconnected with each other and become a cloud platform. Virtualization is the pre-requisite and starting point of the cloud computing at the IaaS level.

Most of the applications running on virtual machines are just converted as part of physical machines to virtual machines, or installed and run in a way just as before. Essentially they are not much different from counterparts running on physical machines. We call these applications as “Application In the Cloud” (AIC).

Cloud environment brings in new opportunities and challenges for application development. Modern applications can, and should, be designed or re-factored to fully leverage cloud infrastructure. When that happens, we call these applications “Applications For the Cloud” (AFCs), versus AICs as described above.

The following is a table that compares these two types.

What’s Different in Virtualized Cloud?

In the cloud environment, the terms like application and virtual machine could refer to same thing because a virtual machine could have one application running. The operating system is there just to support the application running on top of it, and therefore can be reduced down to the minimum which we call Just Enough Operating System (JEOS). The virtual machines used as such are often called virtual appliances (VAs).

The virtual machines are essentially a bunch of files that can run on hypervisors. They can:

• be created dynamically and cheaply;
• be cloned from another VM or template;
• share resources with other virtual machines running on the same physical server, and even other physical servers in the same cluster;
• be allocated with more or less memory, CPU on the fly without being powered off as physical machine;
• be pre-installed with all the software;
• be self-containing with guest OS, middleware, and  applications. You don’t need to do extra;
• move around from a physical server to another without being noticed by external parties.

The applications that run on physical hardware continue to run on vSphere, but they can be much more:

• Flexible
  Applications can move around as a result of virtual machine vMotion. In a clustered application, the topology can be more flexible with cheaper virtual machines.
• Scalable
  The system resource is no longer limited to one machine, but expanded to whole infrastructure cluster like DRS. The resource allocation can be adjusted up when needed, and down when no longer needed.
• Dynamic
  New virtual machines can be provisioned easily. Resource allocation and networking can all be changed on the fly.

The characteristics of the applications could mean big opportunities for enterprises to transform IT toward efficiency and cost saving. As everything else, no pain no gain. Designing AFCs also means challenges.

The good news is that these challenges are mostly old problems with new dimensions in the cloud context. In the following parts, I will go through 10 design best practices for architecting your cloud applications.

Just to set the expectation, we are not going to talk about specific techniques, design methodologies, or even what programming languages, etc. We will just focus on the design principles for cloud applications.

Stay tuned by subscribe to this feed.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (0)

Many folks mentioned their presentations for VMware Partner Exchange in Las Vegas next month. Let me share mine here.

As you migth have guessed from the blog title, the presentation has a lot to do with both the cloud and application. My presentation title is “Architecting your applications for VMware Cloud.” I will discuss the challenges and opportunities the cloud brings in for application development, especially for the application architecture, and more importantly how to get it done.

There are basically two types of applications running within the cloud: applications in the cloud (AIC) and applications for the cloud (AFC).

For the legacy applications, you can easily convert them to virtual machines and run these virtual machines in any cloud. These applications are AICs. They do not take much advantage of the benefits of cloud infrastructure, but the benefits of virtualization.

For the new applications, you want to design them to leverage the cloud from ground up. These applications are then native cloud applications, or AFCs. To make this happen, there are certain guidelines and best practices you need to follow, and pitfalls and exceptions to watch out. I will discuss these in my presentation at PEX.

Although AFC is the direction to go, but it won’t happen over night. It takes time. As I can see, there will be an evolutionary process for enterprises to get there.

1. AICs. This is a small step for virtualization, but a big step for cloud computing. It helps to not only protect your investments on the legacy applications, but also familiarize your IT team with the cloud environment.
2. Mixed. As time goes, new applications for the cloud will be developed/purchased and deployed, and you will see more and more AFCs in enterprises.
3. AFCs. In the end, AFC will graduately take over as the main stream. I don’t think there will be 100% AFCs in enterprises any time soon because certain AICs are not really worthwhile to be re-designed as AFCs due to limited ROI. But the majority of AFCs will happen in next major upgrade cycle.

My session is Feb 10 (Wednesday) 1:30PM. Look forward to meeting/seeing you there. If you will present a session in PEX, please feel free to post it in the comment.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.