> | > Top 5 Best Practices for Architecting "Existing Workloads" for VMware Cloud

Top 5 Best Practices for Architecting "Existing Workloads" for VMware Cloud

Posted on Thursday, March 25, 2010 | 2 Comments

Inspired by Steve Jins "Top 10 Best Practices Architecting Applications for VMware Cloud" here is the list of five best practices for preparing your "existing workloads" for VMware vCloud. After all, its going to take time and money to re-architect your applications and you may want to gain some of the benefits of cloud from your existing systems.

Here is what you can do.

Yes, your migration is going to be easier if its already a virtual machine. A V2C (Virtual to Cloud) is going to be a simpler transition that an P2C (Physical to Cloud). The figures vary, but a recent Gartner report (Oct 2009) indicated that only 16% of workloads are running as a virtual machine today. How is work on your virtual first policy going? What is your current virtualisation level and when will you be at the 90% level?
What is the dispersion of your current workloads? Do you have a ROBO (Remote Office / Branch Office) or a centralised model? Are all of your workloads in close proximity to the accessing users or systems? How many data centres do you have? Once you start to move to a Cloud model your workloads are going to be access via a network, whether that be your own, a private network with your service provider or the Internet. The proximity of the applications is going to change and this may have unexpected effects.
The more work you can do beforehand it educating and training your yours the less you will be taking on as you move to a Cloud model. Likewise any associated application issues can be dealt with in preparation. Do you need to change some of your printing environment given a more centralised architecture?
Centralising is a good pre-emptive strike to needle out any application issues before you start moving workloads to the Cloud.
How tidy and efficient is your wide area and local area networking? Is your IP address register up to date? Would you easily be able to break down your subnets based on associated workloads or are the servers intermixed with the addressing for of your other infrastructure such as networking devices, printers or even desktops. Do you fear changing an IP address on a server because you know it will probably bring down your core application, or who knows what? Is your WAN routing a mess with lots of old entries, a convoluted mix of static routes with no dynamic routing protocols? Have you implemented Quality of Service (QoS) to ensure that important traffic is protected and given priority. How long will it take for you adjust the bandwidth around your network if needed?
A key element to Cloud is that it is connecting to remote services over a network and to be prepared for Cloud you want to ensure that you network is going to be up to the task.
How much of the configuration and operation of your workloads is automated? Is everything efficient or are people always running into the server room to remediate and repair? Are new machines deployed from a number of templates or is everything built from scratching by popping a CD into a tray or mounting the ISO? The more automation you can achieve the better for continuing the same practices once you have moved to a Cloud service. It will be easier to add a few additional orchestration features (such as some vCloud API calls) to your deployment method rather than scratching your head whilst waiting to transfer new images to the Cloud every time you need a new machine. How is your server and application patching, patchy at best?
A good activity here is to start to utilise the vApp features of vSphere. Packaging workloads into containers that contain one or more virtual machines. Can you extend the networking of your vApps to be more automated through the use of IP pools?
Cost Model
What does it cost in terms of dollars and kilowatts to run a workload in your environment today? Not how much did a physical server which runs ESX cost you when you purchase it last year, but how much to run a workload? If you do not know your internal costs, regardless of whether you are passing those costs back to internal departments, its going to be much harder for you to do a business case for moving some workloads into a Cloud. When the Cloud provider quotes you a dollar per Gb for storage what does it cost you to operate and maintain storage per Gb now? Simply taking the purchase price of your SAN and dividing it by the total capacity of the raw disks is not an acceptable model. How much do you pay for electricity and how much does that SAN consume?
Understanding your current internal costs is important to prepare for moving to Cloud.
There are your five steps for Architecting your existing workloads for VMware vCloud. Of course there are many more things that might be done but I think these are the big ones, and I have seen these validated time and time again since developing them over a year ago.

Now here is the really amazing thing about these five components, each of these will drive great return and potentially cost savings to your business right now. Virtualising more of your workloads, improving your network, efficiently using your vSphere infrastructure and automating more. Even something like understanding what your real internal costs are may drive improvements, "Wow, we analysed our storage and realised that our consumption is really high, if we started to use thin provisioning we could reduce consumption and delay that storage upgrade".

It is probably worth mentioning that I am not saying all of these are mandatory before moving to Cloud consumption, just that they will be very beneficial and ease that journey. I am also talking in regards to IaaS and utilising a Cloud service provider with vCloud Service Director (Redwood) or potentially vCloud Express. However, these may also be important if your goal is based around developing ITaaS with internal Cloud first, and then federating in the future.

As always, I appreciate your thoughts in the comments.



  1. Anonymous10:54 pm

    Hey Rodos,

    Good Post however i think the wider community forget that security in the cloud whether external or internal are a critical component. I know you only chose to name 5 but we could swing that under networking etc :) or how it needs to be leveraged through out the infrastructure stack

  2. Yes security is an area to work through. However its probably less of a high order "preparation" and more something that occurs as you prepare the actual migration.


Powered by Blogger.