T-Shirt Size Instances and Storage Management in AWS and vCHS

In the last few weeks I had lots of discussions with customers and partners regarding the concept of T-Shirt Size instances as well as the nuances of storage management in both AWS and vCHS.

In this post I’d like to touch on both. A similar (albeit not as detailed) discussion was included in the AWS and vCHS parallel session I presented at VMworld 2013. The content was somewhat controversial as you can read here and perhaps a bit misinterpreted (make sure to read the comments of that post as well).

Why am I writing this?

There are two main reasons for which I am writing this post.

The first one is to argue why I think the AWS T-Shirt Size concept isn’t a “feature”. I would like to demonstrate why vCHS doesn’t need that. Ideally, the next time you start with “oh vCHS doesn’t support T-Shirt sizing? How come? AWS does!” I can point you to this post instead of wasting 20 minutes telling every time the same story.

The second reason for which I am writing this post is to give you a sense of what I mean by hybrid cloud.

Most people tend to associate the concept of hybrid to the ability of configuring a VPN all the way into the public cloud or having a single “pain” (not a typo) of glass, which is oftentimes too high level, and even more often useless and expensive. These are all (somewhat) valid angles but to me hybrid can be much more.

It is the operational continuum of how you do things on-premise and off-premise. More on this later.

T-Shirt Vs. Tailor-Made

Without any further ado, this is one of the slides I used in my presentation to show how T-Shirt Sizing works with AWS.

Allow me to over-simplify for sake of time. You can deploy a certain number of instance configurations in AWS and they are a fixed matrix of CPU, memory and (ephemeral) storage capacity. You can’t mix and match at will.

For example, if you need 8 vCPUs, you need to get (and pay for) 30GB of memory. If you have an application that requires a huge amount of memory but could leave with half vCPU? Sorry, you can’t do it.

Oh, and (almost) all of these instances include ephemeral storage: if you don’t need it because you need to use persistent storage (common for existing traditional workloads and many application architectures), well it gets wasted. Sorry.

Sure there are memory, compute and storage “optimized” instances (to alleviate this problem) but yet they can’t cover all potential combinations you may need.

Note: persistent storage (aka EBS) is not part of the instance configuration matrix as it gets configured separately, which is good. More on this later.

If you have been working in IT for a few years, you’ll realize that this T-Shirt Size approach isn’t how it’s been working in the past. What you are (most likely) used to do is to right-size your VMs based on their application profiles and their actual needs. That’s how it works with vSphere and, in turns, with vCHS.

As a matter of fact, when you deploy a new VM in vCHS this is how it looks like:

I guess the slide says it all but, essentially, you can configure your VMs with the CPU and memory combinations you need and want. Do you have an application that requires a lot of memory and close to zero cpu cycles? Sure. Do you have an application that requires a lot of cpu cycles and close to zero memory? Sure. I will discuss the storage aspects later on in this post. Hang on.

Note: this discussion isn’t about absolute configurable numbers (which change often and not necessarily may see AWS at a disadvantage compared to vCHS), but it is rather about the flexibility of mixing and matching the configuration of these two subsystems.

Why is this ironic? 

It is a well known thing (or at least a common understanding) that Amazon uses this fixed matrix technique to better use and allocate their physical servers. Since Amazon doesn’t have (yet?) anything like vMotion or DRS they need to plan very carefully where and how they statically place workloads on “standalone” virtualized physical boxes. They can’t afford to have un-balanced configurations running on their hosts because they would end up wasting resources and their “economy of scale” story would go belly up.

On the other hand vCHS can leverage all vSphere advanced workloads placing algorithms and optimize workload run-time location on-the-fly. This creates more flexibility (than what Amazon can achieve with AWS) and that flexibility allows users to pick their mix of configurations at will. The algorithms running in the back-end will take care of proper run-time placement regardless of the configurations of VMs.

This is where psychology comes into play and make all this so funny (or ridiculous).

The clouderati call the vCHS approach virtualization 2.0 implying it’s “the old way to do things”. AWS is now so “cool” that their advocates turned a necessary limitation of the service into a “most wanted” feature (or “the new way to do things”). And customers are all over it given the amount of “oh vCHS doesn’t support T-Shirt sizing? How come? AWS does!” I hear every other day. Amazing!

Disk Management

In an attempt to not bore you to death I’ll just say that I am focusing on the use case that requires disk persistency here.

While ephemeral storage and block storage (EBS) opens up a certain number of innovative use cases, I am going to focus here on the most simplistic and basic scenario of a user that wants to create a Windows instance/VM with a persistent drive.

vCHS doesn’t have the concept of an ephemeral disk: all disks are persistent. In vCHS you just deploy from a template and the “Hard Disk” you configure (essentially a VMDK) will be persistent. Done.

In AWS you need to use an EBS to provide persistency. Amazon did a good job at creating a workflow that mimics how customers often deploy persistent VMs in a data center. This is somewhat similar to what VMware does with vCHS.

But the devil is in the (operational) details: let’s say that, at some point of the life cycle of this instance/VM, you need to extend the size of the disk you configured. This is a very common use case. A quick search on Google let me pick, for example, a nice article from David Davis on How to Extend a vSphere Windows VM Disk Volume. That’s how you often do it. On-line expansion of the disk with a click of a mouse. That’s what IT users would expect.

Let’s switch to the cloud now.

This is how you extend a disk of an instance on AWS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html

In short and in a nutshell:

  • Stop the instance

  • Create a snapshot of the EBS disk

  • Create a larger EBS disk from the snapshot

  • Detach the previous disk from the instance

  • Attach the new larger disk to the instance

  • Restart the instance

By no means this is the end of the world, yet it is clearly a departure from the operational model you are used to.

Regardless of whether that is vSphere or another enterprise context such as the on-line expansion of a logical unit of a physical disk array (SAN or DAS that is).

Now let’s look at how you extend a disk of a VM in vCHS.

I have created a Windows 2008 R2 VM that has a 40GB persistent C:\ drive. This is what the properties of the VM on the vCHS portal look like:

This is how the disk layout is represented inside the Guest OS. Note the 40GB C:\ drive:

With the VM up and running, you can go back to the portal and click on the hard drive.

A new window (“Change Hard Drives“) pops up.

Here you can type the new size of the existing disk. In this case I need to add 20GB of disk space so I am entering 60GB (40GB existing + 20GB of additional space):

Click Save. You’re done.

Notice the portal now says the disk size is 60GB:

Note: if you have an inclination for APIs, you can do the exact same thing via the vCloud APIs as described at page 125 of the vCD API Guide.

If you go back to the in-guest disk management tool and rescan the disk subsystem (while the VM is still running) it will show the additional 20GB of free space I just added:

This is exactly where you’d be after following the much longer and articulated AWS procedure to expand an EBS.

Conclusions

The point of this post isn’t so much to say that consuming vCHS is easier than consuming AWS. The point of this blog post is to underline that, whether it’s the CPU, memory or disk configurations, vCHS provides a familiar operational model that most (if not all) IT people are used to.

One may also argue that vCHS has a better operational model compared to AWS (in the context of what I touched in this blog post, at least) but, you know… de gustibus non est disputandum.

To recap: no, vCHS doesn’t need T-Shirt sizing and you can operationally consume vCHS the way you have enjoyed consuming vSphere in your data center. That’s what I also mean by hybrid.

Massimo.

5 comments to T-Shirt Size Instances and Storage Management in AWS and vCHS

  • PJ Spagnolatti

    Totally agree once again. I’ll allow that the ‘simplified’ t-shirt approach might sound appealing and simpler, and as soon as you try (for example) to define a homebrew vm/service catalog for your own IaaS cloud, you’ll probably end up in categorizing your offering the t-shirt way.

    And there’s even value in the ability to choose and enforce this kind of standardization. Fact is, in the real world there IS real need to change and deviation from standard offerings, thus the elasticity that the VCHS/VMware approach provides, as you described.

    At the end of the day, it’s about having (as end user, tenant, whatevs) a choice: the choice of going standard/t-shirt sized, wildly customized, or anything in between.

    Again, the differences you highlighted enforce the concepts you wrote about in the “Cloud Spectrum” post: given the underlying architectural design, product features and service offerings, enterprise vs design-for-fail apps and the like naturally shift and sit to the (as of today, at least) proper side of the spectrum.

    My S sized view on that :-)
    PJ

  • Unfortunately, I think this is fighting yesterday’s battle. VMWare is probably a better low-level infrastructure than AWS. They have lots of enterprise customers and with VMotion and DRS lots of great functionality. They will have revenue coming in from these for years to come. Amazon AWS have built a good enough IaaS infrastructure and are now going flat-out creating services on top of it. Currently they have dozens – redshift, cloudfront, Route53 etc etc. That is what they are really selling and the cloud battleground will be on the services that save IT having to build them. Probably the best way for others to compete with AWS is to standardize the IaaS on something and double down on building the services on top of it but i have not seen much evidence of this happening.
    Maybe VMWare should charge more for their better low level infrastructure but give away the services to run on top that would save IT folks building them i.e. the equivalent of redshift, rds, cloudformation etc)

    • Massimo

      Interesting thought. Not disagreeing in principle. However I don’t think that this is a black and white world.

      I agree that the advantage (for some people) is to abstract a lot of the infrastructure stuff underneath. Not sure why a developer, for example, would be interested in setting things like load balancers, firewall rules, and those infrastructure things (even if delivered aaS).

      At VMworld 2013 VMware announced the desire to lay CloudFoundry services on top of vCHS (as one of the ways) to address this “new world”.

      18 months ago I came to the same conclusions (http://it20.info/2012/02/the-cloud-magic-rectangle-tm/ > see last picture and subsequent conclusions).

      Other customers (particularly for existing applications) need more control and a lower level of abstractions. They essentially need a raw IaaS layer with a lot more control at the middleware layer. So those “IaaS+” or “IaaS and a half” services AWS provides aren’t really needed. Look at the 180′ turn MS had to do when they introduced “Azure PaaS” and then they had to go back and introduce “Azure IaaS”.

      There is another dynamic that will be interesting to watch going forward. A lot of the Cloud Management players (Enstratus, RightScale, you name them) are scared like hell of AWS eating their lunches and are advocating against using heavily those AWS “add-on” services (to allow portability, to avoid lock-in, etc etc).

      I am just saying that the world (and the market dynamics and politics) are slightly more complex than what many people that are only looking at AWS may look like.

      Also, I am not sure that if Amazon wins all the others lose.

    • Another example Mass re-enforces, like most other VMWare fanatics (as ec2dream correctly identifies) are once more “fighting yesterdays battle”. This has been VMW major mistake over the past 4-6 years – “.. lets keep the discussion (and focus) on how our hypervisor is better (it was and still is) than the competition” and the rest-of-the-world (and competition) just moved on. Onto more important things such as COST and SERVICES.
      The outcome was that VMW repeatedly won the hypervisor battle but lost the bigger cloud war because they focused their previous glories like some fading Hollywood star. Well, there is an opportunity cost to everything, especially in War. Dwelling in the past cost you dearly.
      Who was it that said ” forget the underlying technology, look at the layered services”?

      • Massimo

        Steve, there is some truth in what you are saying. VMware sometimes is maniacal in thinking that his technology can solve all world’s problems. Sadly, this is a disease that plague many other people (including AWS and AWS fanatics).

        If you have a big hammer the world looks like a big a nail. This is true for both of us.

        As per calling DRS and vMotion “yesterday’s problem” …. I found educational watching this 2012 video (https://www.youtube.com/watch?v=8FJ5DBLSFe4#t=2506) where Reed Hastings (Netflix CEO) describes picking instance types the old way of doing things (re-read this blog post) and that in 5 to 10 years cloud will be easier to consume by being able to move running live instances. You call it “yesterday”, he calls it “the future”. He also mentions “VMware does it today, so it is possible”.

        Minute 40:00 through 43:00. 3 short (yet educational) minutes.

        Does this make the VMware cloud better than the AWS cloud. Not for sure.

        Remember, if you have a big hammer, the world looks like a big nail.

Leave a Reply