2014-03-19

The Multi-Cloud Future: Challenges and Benefits

This is a re-post of my article, originally published on The Ravello Blog.

sunset-cloudsOver the last year, as enterprise awareness of the cloud has increased, more and more enterprises outsource their workload deployments to the cloud, in most cases to a single cloud provider or vendor. But the market is rapidly changing with more and more options becoming available from a variety of public IaaS providers, including Amazon, HP, IBM, RackSpace as well as private offerings such as Openstack and VMware.

The new deployment options make it possible to mix and match platforms and cloud providers, as well as to set up hybrid clouds where you keep some of your resources in your on-premises datacenter or private cloud while migrating parts of your workload to one or more public clouds. In this post I will elaborate more about the challenges, as well as the benefits of a multi-cloud environment.


Challenges of multi-cloud deployment

  • Complexity – The biggest challenge of multi-cloud is its inherent complexity – different technologies, different interfaces, different services, and different terminology. There is currently no standardization of terminology, instance sizes, or methodologies across cloud vendors.
  • Interoperability – or lack thereof – between different cloud vendors. This necessitates using workarounds or APIs to make the application set up work on different platforms and clouds. Specialized tools, such as Ravello, can be used to achieve seamless deployment on different external cloud providers.
  • Management overhead – Multi-cloud requires a higher level of expertise in determining what to move to the cloud, where, when and why. This brings with it an increase in overall management overhead, including investments in VPN connections and monitoring. The implementation of different platforms requires expertise in a more diverse range of subjects.

And of course, as with any public cloud solution, the issues of compliance, security, and availability must always be taken into consideration.


Benefits of multi-cloud

  • Autonomy – The ability to deploy your applications on different cloud providers has the clear advantage of reducing dependency on a single vendor. The resulting lower level of lock-in improves your position in negotiating with vendors for better SLA and/or costs. The ability to easily switch vendors means that you can take advantage of the most attractive offers available at any given time.
  • Hybridity – You can keep some applications on-premises and others on one or more public clouds, based on a variety of considerations, such as security, performance or cost optimization. For example, a hybrid cloud solution can also be used to provide faster service, particularly if your customers are located in different countries. Deploying your applications on a cloud that is closer to your customer’s geographical location can result in better response time and performance.
  • Extended capabilities – Different cloud providers support different platforms and offer constantly changing packages of capabilities. Some features, for example, Database as a Service, might not be supported by all cloud providers. It might be a good idea to shop around, comparing the various cloud offerings to identify which providers offer the best fit for you. You might prefer to pay more for specific deployments if it means you get special capabilities, while continuing to take advantage of lower costs offered by a different provider for resources where those capabilities are not relevant.


Bottom line

IMHO, the benefits of utilizing multiple platforms heavily outweigh the challenges. If cloud management is in place, including policies, automation and transparency, moving to a multi-cloud platform configuration can help you lower costs and improve performance. Over time, focusing on product development that is not dependent on a specific single cloud provider will also contribute to creating a better, more robust product that is supported on multiple platforms.

2014-03-17

VSAN - The Unspoken Truth

Last week VMware released the long awaited VSAN including the even more popular licensing information.

Today I would like to discuss what I see as one of the points that I have yet seen to be discussed regarding VSAN – and in my eyes the most problematic.

unspoken truth

An unspoken truth is something in life we all know to be true but to speak it is taboo.

Before I go in what this unspoken truth is of which I am talking about, I would like to congratulate the VSAN team on a job well done!! VSAN is something we have been waiting for – for a long time – and I voiced my comments before on the launch and its lack of licensing info – but that is now water under the bridge.

VSAN is a scale out storage solution – up to 32 nodes – which is a great thing. I am not going to go into the whole debate of - “Is this cheaper/better/faster/more reliable than a traditional SAN/All Flash Array?” – there are others who have already started to prepare VSAN calculators, price comparisons etc..

VSAN

VSAN is about flexibility – going from a configuration catered to high performance all the way to that catered to the needs of large storage capacity.

Here are the current VSAN Ready nodes (as of today’s date) on the VMware HCL.

PowerEdge T620 PowerEdge T620
PowerEdge T620 Primergy RX300
PowerEdge R720 PowerEdge R720 UCS C240 UCS C220

The Unspoken Truth

VSAN is not suitable for deployment on Blade servers.

  1. There are no VSAN Ready nodes that are Blades – only Rack mounts or Tower servers (who actually still deploys Towers in their datacenter anymore???)
  2. The number of disks that you can add to most blades is – yep two – that means one SSD and one Large SAS/SATA drive. Not enough for a decent VSAN node

We have now come to the conclusion that the flexibility is there – but just not for blades – which to me means, that if I would like to deploy a VSAN cluster – it will have to be on rack mounts.

What are the implications of such a decision?

  1. Larger Datacenter footprint. That means more power cables, more electricity, more cooling.
  2. Converged networking – is possible – but will usually require a minimum of 3 (perhaps 5) network cables per server.
  3. Central Hardware management – is going to be very difficult – compared to the Blade Chassis management provided by vendors today.
  4. This is actually the complete opposite of what the current industry trends – most companies have found the benefits of blades are highly beneficial to their environment – and this is the exact opposite direction.
  5. Change of current methodology and work practices – if today you are using blades – then you will have to move your virtualization workloads over to rack mounts.

Let me give a few examples.

    1. You have an established vSphere Infrastructure – all running on UCS/HP/Dell/IBM blades. To move over to VSAN – you will need to decide what workloads will be migrated to this new cluster – because VSAN is not (in its current version) accessible outside of the VSAN cluster. You will need to purchase new hardware for such a cluster – different to your standard deployment.
    2. To accommodate VSAN – it is recommended to have a dedicated 10Gb (actually 2 of them – for redundancy) for the VSAN traffic – that is above and beyond what you will need for each host for Mgmt, vMotion, OOB (iLO/IMM) and VM networking. that is a whole lot of ports that you will need.

Just to clarify once more – I am not saying that VSAN is not a good solution, it could very well be the perfect solution for the right use case. But it is not the be and and end all solution to all of your storage problems.

Do the math. For some of you it will be more than worthwhile – but for others, not so.

One more comment before I sign off.

I do see this as the second part in the direction that VMware is moving towards making the Virtualization Admin the “king of the castle” and the SDDC.

  1. Deploy NSX – and you now have full control of your network – relying on the Network Admin is a thing of the past.
  2. Deploy VSAN – and you now have full control of your storage – no need to ask for LUNS or storage space from the Storage group.

If only it was that simple – perhaps it will be one day, but I do not think that day has come …
Yet.

(Update March 18th, 2014) – This has brought on a very interesting discussion in the comments below and also some follow up articles from Christian MohnVSAN – The Unspoken Future and from
Duncan EppingVSAN – The spoken reality. (Flattery will get you everywhere guys…).
That was the purpose – to make people think, voice their opinion and their thoughts.

2014-03-06

How to Launch a Product

I am not a marketing genius – I don’t pretend to be – and honestly don’t think that is my line of work. I am just a customer.

When you announce a product – the message should (IMHO) contain the following:

  • What the product/offering is.
  • The features / benefits – including technical documentation.
  • Availability date.
  • Cost.

VMware did this at VMworld – announcing the availability of NSX. And it included 2/4 above points.
Until today – approximately 5 months after “GA” – no-one outside of VMware has seen:

  1. Any technical documentationvsan
  2. Pricing

Today VMware did it again. They announced VSAN – including a date (estimated – Week of March 10). The technical documentation is out there – at least for those who were on the Beta program – which was open practically to whoever wanted to join. And yet – there was one important thing missing.

  • Pricing

It seems I am not the only one with this feeling – but if you are trying to sell me something – I would like to get the full picture when you announce it and not wait for the sequel to get all the information.

Here’s looking forward to the week of March 10th – for the rest of the info.

(This is not to say that the technology and product has no benefit – I am just a bit peeved about the way VMware has been “launching” their products as of late – and specifically those which are supposed to the complete game-changers, the products that are to lead the evolution and revolution of the SDDC/SDDE)

What do you think?

(p.s. – If you look really hard – you can already find the licensing costs on several places on the great WWW)