vCHS: Stop Thinking About Building a Cloud, Start Thinking About How to Consume It

Today (technically it’s still 11:59 PM Pacific Time) VMware announced the vCloud Hybrid Service (aka vCHS).

I have been keeping an eye on how this idea developed internally for a certain amount of time. I have been more closely involved since December last year when I participated in some “sausage making” summits (boy, those things are scaring if you are not used to them). And then I started working full time on it since roughly February this year. It’s been just 4 months but it feels like they have been 4 years. Intense to say the least.

I couldn’t be more excited. vCHS, welcome to this nasty cloud world.

By now you should have already seen it but this is how the main dashboard looks like. For the records this is a “Dedicated Cloud” with 9 vDCs instantiated (only 3 are shown in the screenshot):

And this is a screenshot that shows all the Edge Gateways running on this “Dedicated Cloud” instance:

 

Many customers will get used to the screens above (albeit I can see them also consuming these resources in a more programmatic way). And I believe “consuming” is the key word here.

A software company that enters a service market is going to face a number of challenges. One of them is that there are a lot of people (internally and externally) that gravitate around the challenges of how to build a cloud. One of the reasons for which I have always been interested in this project from the get go is because it gives people (and me in this particular case) the luxury of exploring the opportunities to consume a cloud.

Take AWS for example and the people that gravitate around their service. There are (very) few geeks that keep wondering how the service works. However the vast majority of the people don’t giv are not interested in that. They are just interested in what the service exposes. That’s very powerful if you ask me and unleash a lot of potential.

Do you see a pattern?

Challenges Vs Opportunities

Build Vs Consume

How Vs What

That’s in essence the value a public cloud can provide.

There is no doubt VMware will continue to build their own software stack with a focus on ease of use. After all the concept of the hybrid cloud requires, by definition, on-premise and off-premise cloud end-points. However this software industry (as a whole) is challenged in many ways. I won’t bore you too much about this but I have been lately thinking that the vendor that will win the on-premise battle in the next 5 years is not the one whose software is the best but the one whose software sucks the least (you’ll excuse the language). Having that said VMware is certainly up to the challenge to make the best software experience ever. As hard as it sounds.

But I am digressing. I have already ranted about the cost of building clouds. That’s not a trivial exercise. VMware took that out of the equation for you with vCHS. VMware has a bunch of smart engineers working on how to integrate all the pieces (that are not yet natively integrated or that will never be natively integrated for many reasons). These engineers have been building clouds for the last 10 years. They know these stuff. They do this day in and day out.

Now that we announced the service I will try to post more regularly in the coming future on its characteristics and how it differs from other clouds out there. In particular it is fascinating the challenge ahead to capture, potentially, all the workloads out there (existing and new).

So, in conclusion, my ask to you. As you will explore this service in the near future, please do not focus on the brand of the servers that have been used, the configuration of the storage or the bonding of the pNICs. Focus on how you can consume it without having to think how someone built it and is maintaining it for you. That part is already done.

In the meanwhile remember, forget about the “challenges on how to build“. Focus instead on the “opportunities of what to consume“.

Massimo.

P.S. This is probably the shortest post I ever wrote. Wow.

P.S.2 I didn’t even use the world “seamlessly”. Wow.

9 comments to vCHS: Stop Thinking About Building a Cloud, Start Thinking About How to Consume It

  • Hi Massimo,

    You have a valid point here, but there is another side that I think is missing.

    From a consumer perspective you are completely right, and in most cases I agree with you, This is enough for the end user, the one that doesn’t know how to design their infrastructure, the developer who needs some extra space because his IT department are not flexible enough. We all know what the benefits of having an “never-ending” cloud to play around with.

    But for the consultant, for the architect, this is not enough, They need to know how it is built to understand where to expect the unexpected. Take for example AWS and their redundancy with regions and availability zones. It has taken people many nail biting months to understand exactly how these worked and how they should design their application to survive an outage.

    And still when AWS hiccups, the repercussions for their customers business are not far behind.

    So yes I would agree – we do not need to know every detail about how the cloud was built, but architecture behind the new service, availability models, how it effect my RPO and RTO is a very valid request, and I think that announcing a new service (again) without providing that information brings nothing new to the table…

    And I didn’t use the word seamless either… :)

    • Massimo

      Agreed Maish. There will be an infinite nuances of colors in the questions that will be asked. Some of them will be irrelevant, others will be relevant. Most of those you are referring to are not related to how we built it but on how you are going to consume it so they are legitimate.

      I think the AWS example is misleading. I think there are enough information out there re the AWS architecture to properly design resilient applications. The problem is that people has no clue about them or just consciously decide to ignore them (and… fingers crossed). It’s all good until an AZ goes down (let alone a Region). Not all are a Netflix that has a very deep understanding of how AWS works and have worked around perfectly the limitations of running existing traditional applications on AWS.

      The information you are looking for will be provided.. we haven’t had yet time to do that (and that won’t happen overnight either as it will be an iterative process). Give us more than 36 hours.. ;)

      Thanks.

  • Massimo, love this post. The only thing from my perspective that companies will have to think about, in many cases, before they ‘just consume’ is where their data is held. Right now vCHS is not available in Europe and once it is in 2014, companies must know where their data is being held for many regulatory and compliance reasons. So it’s not about the architecture in this instance but location of the DCs. Just my two cents.

    • Massimo

      Absolutely.

      I think there is going to be an infinite scale of greys in terms of what customers will deem acceptable.

      For some hosting data in the US will not be ok.
      For others hosting data in Europe in a DTC owned by a US company will not be ok (patriot act etc)
      For others hosting data in the same country (perhaps by a local VSPP partner) but outside their perimiter firewall will not be ok.

      For many others either one of the above scenarios will be ok.

      VMware is trying to serve all use cases and give options. Not easy… but I think overall the strategy is sound.

  • [...] will not talk about what vCHS is and how it can be consumed (read Massimo Re Ferre’s vCHS: Stop Thinking About Building a Cloud, Start Thinking About How to Consume It post) but how it differs from the typical private or public vCloud Director based cloud. It is [...]

  • I agree at a surface level, vCHS sounds like an impressive feat for VMware. But, as I’ve drilled into the details, I’ve noticed the following concerning items:

    - Cost – compared to Windows Azure, AWS and Rackspace, vCHS is a pricey solution – as much as 1.5x – 2x the other cloud providers
    - Availability – the vCHS SLA defines availability in an interesting way – network interfaces have to be down for 3 consecutive minutes, VMs for 5 consecutive minutes to be considered an SLA event. In addition, downtime caused by VMware planned maintenance, VMware bugs or viruses, hacking, major disasters are all excluded from the SLA
    - Not really “Pay-as-you-go” like other cloud platforms – it appears that customers must pre-purchase reserved blocks of resources in advance, rather than paying only for what they need as they go. This eliminates a lot of the value of being an “as-needed” operational cost, vs large capital pre-purchases upfront in many cloud computing application scenarios
    - Limited compliance certifications (today) – only ISP/IEC 27001 and SOC II Type 1 – hopefully this will be expanded to a broader offering to support the needs of other industries
    - Largely an IaaS only offering, many of the expected cloud use cases, such as Web Hosting, Packaged Applications and Off-site Backups are generally handled more cost effectively via SaaS rather than IaaS
    - Unclear PaaS vision with planned 3rd party integration of Cloud Foundry Open Source stack – how it will integrate into cost model is unclear, as a large part of the value of PaaS is through more cost-effective cloud resourcing than IaaS can provide.
    - Datacenter expansion plans leveraging third party relationship with Savvis – this appears to be a third-party doing private label hosting of vCHS rather than truly part of a global cloud fabric like Azure and AWS. I will be interested to see how security, compliance, governance and management are applied to these third party locations.

    Thoughts?

    Keith

    http://KeithMayer.com

    Disclaimer: I am a Microsoft Employee, but my tweets and comments posted are my own.

    • Massimo

      Thanks Keith for your comments.

      - I don’t think VMware sees this as a price race to the bottom. Having that said I’d be interested to see the detailed / break down analysis of your price outcome as it’s fairly easy to compare apples to oranges when you have so many nuances and so many items you need to consider. Care to share?
      - I’ll be honest with you. I haven’t read the SLA T&C’s in their entirety. I often consider them a lawyer language somewhat cryptic to decipher and interpret. Are the AWS / Azure language and T&C’s better?
      - Yes this is not PayGo. I think PayGo has its place in this industry (particularly if you need to spin up 5.000 cores for 2 hours of you are a startup that goes from 0 to capacity in a matter of months). There are many other scenarios where a predictable / fix bill at the end of each month is a preferred solution (either because of Enterprise customers purchase preferences or because of steady-state workloads that have not so much fluctuation). I remember having read studies that say that AWS customers would save tons of money if they decide to run reserved instances. Which is just like buying capacity upfront. PayGo is very sexy, that doesn’t always translate in less expensive. Having that said we know there are use cases where PayGo makes a lot of sense.
      - (today). That’s right.
      - Fair. It is, as you say, IaaS.
      - We are at the early stages with this. We have just announced it and it’s not available yet. More clarity will come in the next few weeks / months. I am not sure the value of PaaS is around “cost effective cloud resourcing”. I think the value of PaaS is more around the operational model and the higher level consumption experience for certain use cases (e.g. developers).
      - This is not an area I have explored in details but that is definitely part of the same “fabric” (I like that). This is the same service, with the same operational model and support structure. As per security, compliance etc… I don’t think that running off Savvis data centers would increase the risks compared to running off VMware data centers (or Azure data centers for that matter).

      Thanks for chiming in. Good discussion.

Leave a Reply