I will make this simple. There is only one question you need to ask yourself or your IT department to determine if what you have is really an Infrastructure-as-a-Service cloud.
Can I get a VM in 5-10 minutes?
Perhaps a little bit more detailed?
Can a properly credentialed user, with a legitimate need for cloud resources, log into your cloud portal or use your cloud API, request a set of cloud resources (compute, network, storage), and have them provisioned for them automatically in a matter of a few minutes (typically less than 10 and often less than 5)?
If you can answer yes, congratulations – it’s very likely a cloud. If you cannot answer yes it is NOT cloud IaaS. There is no wriggle room here.
Cloud is an operating model supported by technology. And that operating model has as its core defining characteristic the ability to request and receive resources in real-time, on-demand. All of the other NIST characteristics are great, but no amount of metering (measured service), resource pooling, elasticity, or broad network access (aka Internet) can overcome a 3-week (or worse) provisioning cycle for a set of VMs.
Tie this to your business drivers for cloud.
Agility? Only if you get your VMs when you need them. Like NOW!
Cost? If you have lots of manual approvals and provisioning, you have not taken the cost of labor out. 5 Minute VMs requires 100% end-to-end automation with no manual approvals.
Quality? Back to manual processes – these are error prone because humans suck at repetitive tasks as compared to machines.
Does that thing you call a cloud give you a 5 Minute VM? If not, stop calling it a cloud and get serious about building the IT Factory of the Future.
“You keep using that word [cloud]. I do not think it means what you think it means.”
– The Princess Cloud
(c) 2012 CloudBzz / TechBzz Media, LLC. All rights reserved. This post originally appeared at http://www.cloudbzz.com/. You can follow CloudBzz on Twitter @CloudBzz.
Red Hat has ben making steady progress toward what is shaping up as a fairly interesting cloud strategy. Building on their Deltacloud API abstraction layer and their CloudForms IaaS software, a hybrid cloud model is starting to emerge. Add to this their OpenShift PaaS system, and you can see that Red Hat is assembling a lot of key components. Let’s add the fact that Red Hat has gotten very involved with OpenStack, providing an interesting dynamic with CloudForms.
Red Hat is the enterprise king in Linux (RHEL), strong in application servers (JBoss), and has a lot of very large customers. Their VM environment, RHEV (aka KVM) won’t displace VMware in the enterprise space any time soon, but it is pretty interesting in the service provider space.
Red Hat’s community open source model will be very appealing to the market. In fact, any of the OpenStack distro providers should be at least a bit worried that Red Hat might leapfrog them. With their OpenStack move, CloudForms is being repositioned as a hybrid cloud management tool. Now their competition in the future might be more along the lines of RightScale and enStratus. What I’ve seen so far of CloudForms shows a lot of promise, though it’s still pretty immature.
Red Hat is pushing a message about “open clouds” – which is less about open source than it is about avoiding vendor lock in with cloud providers. That’s something that CloudForms is intending to address. It’s also why OpenShift has been released as an open source project (Apache 2.0 – yay) that can be deployed on other clouds and non-cloud infrastructures.
The big opportunity, IMO, is for Red Hat to go very strong on the OpenStack path for IaaS (e.g. release and support an enhanced Red Hat distro), really push their OpenShift conversation vs. Cloud Foundry based on their ability to drive community (along with it’s deep integration with JBoss), and move CloudForms further up the stack to a governance and multi-cloud management framework (their messaging on this is not very strong). It’s this model of openness – any cloud, any app, that will make their “Open Cloud” vision a reality.
On many of the key points – such as elasticity being a side-effect of how Amazon and Google built their infrastructure – I totally agree. We have defined cloud computing in our business in a similar way to how most patients define their conditions – by the symptoms (runny nose, fever, headache) and not the underlying causes (caught the flu because I didn’t get the vaccine…). Sure, the result of the infrastructure that Amazon built is that it is elastic, can be automatically provisioned by users, scales out, etc. But the reasons they have this type of infrastructure are based on their underlying drivers – the need to scale massively, at a very low cost, while achieving high performance.
Here is the diagram from Randy’s post. I put it here so I can discuss it, and then provide my own take below.
My big challenge with this is how Randy characterizes the middle tier. Sure, Amazon and Google needed unprecedented scale, efficiency and speed to do what they have done. How they achieve this are the tactics, tools and methods they exposed in the middle tier. The cause and the results are the same – scale because I need to. Efficient because it has to be. These are the requirements. The middle layer here is not the results – but the method chosen to achieve them. You could successfully argue that achieving their level of scale with different contents in the grey boxes would not be possible – and I would not disagree. Few need to scale to 10,000+ servers per admin today.
However, I believe that what makes an infrastructure a “cloud” is far more about the top and bottom layers than about the middle. The middle, especially the first row above, impacts the characteristics of the cloud – not its definition. Different types of automation and infrastructure will change the cost model (negatively impacting efficiency). I can achieve an environment that is fully automated from bare metal up, uses classic enterprise tools (BMC) on branded (IBM) heterogeneous infrastructure (within reason), and is built with the underlying constraints of assumed failure, distribution, self-service and some level of over-built environment. And this 2nd grey row is the key – without these core principles I agree that what you might have is a fairly uninteresting model of automated VM provisioning. Too often, as Randy points out, this is the case. But if you do build to these row 2 principles…?
Below I have switched the middle tier around to put the core principles as the hands that guide the methods and tools used to achieve the intended outcome (and the side effects).
The core difference between Amazon and an enterprise IaaS private cloud is now the grey “methods/tools” row. Again, I might use a very different set of tools here than Amazon (e.g. BMC, et al). This enterprise private cloud model may not be as cost-efficient as Amazon’s, or as scalable as Google’s, but it can still be a cloud if it meets the requirement, core principles and side effects components. In addition, the enterprise methods/tools have other constraints that Amazon and Google don’t have at such a high priority. Like internal governance and risk issues, the fact that I might have regulated data, or perhaps that I have already a very large investment in the processes, tools and infrastructure needed to run my systems.
Whatever my concerns as an enterprise, the fact that I chose a different road to reach a similar (though perhaps less lofty) destination does not mean I have not achieved an environment that can rightly be called a cloud. Randy’s approach of dev/ops and homogeneous commodity hardware might be more efficient at scale, but it is simply not the case that an “internal infrastructure cloud” is not cloud by default.
I was first briefed on the Savvis Symphony VPDC (virtual private data center) back at Cloud Expo NYC in April of this year and had intended to post about it back then, or at least when they went live in July… so much for good intentions… They are starting to market this more heavily now, so perhaps it’s not a bad time to get this done because VPDC has a few innovations that are worth noting.
Perhaps the most interesting aspect of VPDC is their tiered QoS model. Think about it. Today clouds come in a one-sized-fits-all model. You either have the open Amazon model with minimal SLAs and fairly opaque underlying infrastructure based on commodity gear, or you get the “enterprise cloud” model with higher SLAs (and costs) based on enterprise-grade gear. Or something in the middle. But you can’t typically get two or three SLA/QoS configurations, with commensurate pricing, from the same cloud provider.
With VPDC, that’s exactly what you get.
VPDC never goes to the Amazon level – with very low cost instances and no SLAs – but they do offer two QoS tiers today, with a third tier planned.
VPDC Essential is their starter level, with 99.9% SLA, best-effort QoS and inexpensive SATA-based storage. This is targeted at the dev/test use case.
VPDC Balanced is the mid-tier offering, with 99.99% SLA, VLANs, enterprise QoS on a 100 Mbps network, and 2-tier ILM storage. They are targeting Balanced at the Web application use case.
VPDC Premier (planned) will have 99.995% SLAs, more VLAN provisioning, 1 Gbps network, and 3-tier storage for more “mission-critical” workloads.
As you move up, you get more prioritization of bandwidth, less storage contention, fewer VMDKs per LUN, faster drives, etc.
Savvis would not give me any pricing information, but clearly you will pay more for Premier and likely even the Essentials pricing will be significantly more than Amazon or Rackspace. Lack of pricing transparency puts them a bit at odds with AT&T (Synaptic pricing here) and Terremark (vCloud pricing here). The only information I have I that pricing is hourly based on CPU, RAM and which operating system you are using (Microsoft’s SPLA fees presumably causing the difference). Interestingly they are disclosing bandwidth fees and are charging for bandwidth like a hosting provider ($50/Mbps 95th percentile model) vs. the more typical straight per GB in/out metered model.
Savvis has no current intention of allowing credit card self-signup models for new users, even with their Essentials package. This could be a mistake as so many projects start off with a very small buy and the Amex charge is easy to expense. AT&T and Terremark might get those customers that don’t want to start with a sales rep, though the buyer seriousness is certainly better formed if they are willing to go through that pain. By and large, making it easier to sign up could be in Savvis’ best interests.
What’s VPDC Made Of?
VPDC is an enterprise cloud based on VMware virtualization, Cisco UCS blades, Cisco Nexus switching, HP Opsware provisioning automation, Compellent SAN storage, and other technologies – okay, good enterprise-grade stuff. Savvis relies heavily on deep integration with UCS and Nexus to get the QoS tiering to work with VMware. They also rely heavily on the flexibility of Compellent’s “Fluid Data Storage” virtualized storage software. All images are monitored using TripWire and connectivity can include MPLS and VPNs.
What’s VPDC Mean for the Cloud Market?
Amazon, Rackspace and others have grown largely on the backs of Web developers, SMBs, and enterprise usage outside the control of corporate IT. This is but a fraction of the potential future market as the enterprise moves more and more to the cloud. Enterprise IT buyers are much more precise and demanding when it comes to infrastructure than most Web and game developers. Having tiered SLA/QoS levels, with pricing to match, might become an important consideration for even the mass-market cloud providers if they want to win in the enterprise. The market is just too big to ignore.
Alternatively, you could see the mass-market guys go the opposite route – adding the “five nines” SLAs and high QoS capability to their core commodity-priced offerings. This is a technology and scale issue that Amazon and Google are probably in a good position to leverage. After all, if you can get VPDC Balanced for the price of EC2 reserved instances, it will be pretty hard for Savvis to compete. But that’s a big if.
In any case, Savvis has done a nice job leveraging the technology now available to create a differentiated offering based on QoS and SLAs. VPDC is available through data centers in the U.S. and U.K.