ServiceMesh

  • Home
  • Agility™ Platform
    • Agility Planner™
    • Agility Factory™
    • Agility CenterPoint™
    • Agility Manager™
    • Agility Access™
  • Pro Services
    • Strategy, Process, & People
    • Technology and Tools
    • Agility Orange Book™
  • Resources
  • News & Events
    • News Stories
    • Event Calendar
    • Press Room
  • Blogs
    • Eric Pulier
    • Dave Roberts
    • Anthony Skipper
    • Bruce Greenberg
    • Mark Thiele
  • About Us
    • ServiceMesh Vision
    • Why ServiceMesh?
    • Case Studies
    • Management Team
    • Contact Us
    • Privacy Policy

Search

Contact Us | Site Map

Archive

  • Anthony Skipper
    • 2010
  • Bruce Greenberg
    • 2010
  • Dave Roberts
    • 2010
  • Eric Pulier
    • 2010
  • Mark Thiele
    • 2010
rss feed Subscribe

Enterprise Compute Units - Why you need them

comments (0)
Posted by anthony Tue, 18 May 2010 10:06:00 -0400

Many people are familiar with Amazon's EC2 compute units.  EC2 computer units are a way for Amazon to express their SLA for the virtualized resources you are consuming.  What most enterprises haven't realized however is that they need their own set of compute units.  The reason for this is that application owners quite often need to be able to guarantee their own SLA's to business partners.  If an enterprise is going to offer virtualized resources to their internal dev teams then they need to be able to agree on the an SLA for the consumption of those resources.  Until it's possible to do this then production workloads for businesses with SLAs aren't possible.  In fact in many cases even dev/test workloads can't be made available to developers as there would be no accurate way to gauge or predict behavior of the production environment when the dev/stage environment would contain a high degree of variability.

Assuming you agree with this line of thinking the next logical question is whether it's possible to just use Amazon's definition of compute unit?  Well, you could but there is one problem.  That problem is that there are few benchmarks that exist that show how an amazon compute unit maps to existing physical hardware, and correspondingly how VMware(the most common enterprise virtualization platform)  compute units would also map to the hardware.   The reason you need to benchmark to current hardware is that many software providers provide their own performance guearentees based on non-virtualized hardware.  So if you are going to switch a server to virtualization you need to be able to express what it's physical equivalent performance would be, and you may have to stand behind those numbers. It also bring up an interesting point which is that the best time to calculate an applications optimal compute units is before you've migrated it to a virtualized environment.

A natural question that arises from this discussion is whether guaranteeing resources using compute units means that you are unable to reclaim wasted rescources?  After all the purose of leveraging virtualization was to reclaim all the wasted compute from servers running all day at 5% capacity.  Luckily the answer to this is no.  Most virtualization solutions like vmware DRS can allow for migrating workload to another host if the current host can't meet it's guarantees.  The primary issue is what policies you need to use in product to ensure it doesn't do this "after" it has violated the SLA.

A standard in this area would be very helpful.

 
Built with concrete5 CMS. © 2010 ServiceMesh.    All rights reserved. Sign In to Edit this Site