I code therefore I am

I code therefore I am

VMware Infrastructure is, well, infrastructure. That means it lives in the data center, behind faceless racks, under floors, hidden behind closed doors in lights-out data centers managed by creatures of the night (VCPs) who love nothing better than an efficient, effective and well governed system that is somehow alive and only needs a well-placed saucer of milk each night to make sure the backups work.

Developers, on the other hand, are a much more glamorous set: it’s a creative job; it’s about functionality and time to market; it’s about agile development with Ruby rather than correct spacing in Cobol; it’s about how the GUI looks; it’s about wearing your coding skillz and practices on your sleeve (or swimsuit – see left!) because what you are is what and how you code.

There are so many benefits to the developer when using virtualization you would think that virtualization was designed specifically for them:

  1. No more test cells!  Now your MacBook Pro can be a test cell, so you can be productive whilst looking cool sucking-on-a-frescato in Starbucks.
  2. No more slow, unresponsive, and weirdly configured test systems!  Using templates, and even self-service, YOU have control over how test systems are deployed.
  3. Take your system with you!  A virtual machine is just a file, and a virtual machine that runs on ESX in the data center will run on Fusion too!

I could keep on going, but the list is enormous, and it seems whilst there is benefit to the developer, to the vendor who supplies the platform they code on (e.g. Java), and to the application end user, it seems when it comes to running their application in production, that’s where the problems start.  “Test and dev?  Oh yeah.  But not in production”.  How’s that?

VMware is only for test and dev!

Before we delve into this one, let’s get a fact clear: This barrier harks back to the early 2000′s when ESX 1.5 and 2.0 was out.  It is now 2009 and we are on ESX 4.0, and there have been thousands of improvements in the product to make it what it is today.

When a developer says “VMware is only for test and dev” it is always worth asking “Why?”  Common answers are:

Winning over the developers

I’m 100% sure that the only way to get developers to like VMware products is to use them in their jobs, and see how their productivity improves.  Then, you can break down each of the other barriers:

Performance not up to scratch?  I think it is a fair question to make as long as it is objectively discussed and the performance required is defined (e.g. we need 100,000 IOPS) and that performance is also realistic (e.g. like current production).  With a well defined performance target you can check online benchmarks and most importantly, run your own test.   So many people have already done this that you are unlikely to find a new performance problem BUT you are most likely to find a problem with the way virtualization has been configured in your environment, so testing is super critical.  And developers will love the fact that, with virtualization, you can add/remove cpu, memory etc so easily it’s like painting on a canvas.

If reliability is a question, then make sure the Recovery Time Objectives (e.g. 1 hour) and Recovery Point Objectives (e.g. last atomic transaction, or updates to yesterday?) are accurately defined, then test it.  I will bet you that your recovery on VMware is massively and convincingly better than physical (or any other virtualization platform).  vMotion and DRS provide zero-downtime for planned maintenance, and High Availability recovers quickly from unplanned events.  VCB provides LAN-free data recovery and SRM provides dual-site disaster recovery.  FOR ALL APPLICATIONS. This is the beauty of virtualization: you get all this whiz-bang goodies with no changes to your applications with clumsy complicated things like MSCS.

If the application is not supported, is that really true?  The stance of vendors changes each week.  Microsoft have their SVVP program.  Oracle say they support virtualization but don’t certify it.

The bottom line

If an application developer has the authority to say “this application will not run on VMware virtualization”, for whatever the reason, then what impact does this have?

A lot of VMware customers have a “Virtualization First” policy where new requests for servers are automatically served by virtual machines, with an exception process.  This exception process is slow and expensive, because that’s the reality of deploying and managing physical servers.  So there should be a direct impact on that application’s project timeline, because it will be slower, and costs, because it is more expensive.

Resistance based on emotion, religion or politics should really be dealt with by facts and data; but sometimes you need The Boss to invoke the Virtualization First policy and sweep aside vague resistance.  However, there is one thing that really helps a Virtualization First policy and that is having a Tier 1 mission critical application already virtualization.  The saying is, “Hey, if we can virtualize our order-to-cash Oracle systems, then your 9-5 webapp is easy.”

Summary

You are likely to hear resistance along the lines of:

  1. Performance
  2. Reliability
  3. Supported

You can get over this barrier with

  1. Use virtualization to increase developer productivity: self-service VMs, faster break-down/testing, more control over their own systems.
  2. Facts/data/testing in the face of vagueness/emotion/religion/politics
  3. Virtualization First policy, backed up by an existing Tier 1 mission critical app

Lastly, Steve Kaplan of http://roidude.typedpad.com reminded me of the ultimate method of overcoming this barrier:  don’t tell the developer they are running their apps in a virtual machine!

Related posts:

  1. Virtualization Barrier #2: It’s just for Test and Dev
  2. Virtualization Barrier #5: The Storage Manager
  3. Virtualization Barrier #4: The Network Engineer
  4. Virtualization Barrier #3: VMware is Too Expensive
  5. Virtualization Barrier #1: Manual Processes