When enterprises consider putting business-critical workloads in public clouds, many of them overlook, at least in part, critical issues of economics and over what portion of their cloud software stack the cloud vendor has full control. This leads to a situation where sometimes relatively inexpensive offerings where the vendor has full control of their software stack (like Amazon EC2) are improperly compared to an offering from a vendor like Savvis or Terramark who is building a cloud out of either VMware-provided components or OpenStack components. This gives rise to important issues that drive both the cost of the respective offerings and the degree to which the cloud vendor can both enhance the offerings with rapid agility and quickly address service level issues.
Public Cloud Computing – Is there One Throat to Choke?
If you are going to put business- and performance-critical applications in someone’s public cloud, then you would expect to be able to hold that vendor accountable for the resulting quality of service provided as those applications are delivered to their users. In some cases, the ability to deliver quality service will be contingent upon the cloud vendor having ownership and control of the software that comprises their stack. This is certainly the case with respect to Amazon EC2 and Microsoft Azure, each of which own 100% of the software that comprises their clouds.
All other providers of public clouds rely at least in part upon layers of software from other software vendors. Google relies in part upon Red Hat KVM. Any vendor that offers up a VMware-based vCloud product relies at the minimum upon vSphere and may also rely upon VMware vCloud Director as the Cloud Management layer. Any public cloud vendor that offers up an OpenStack-based cloud will most likely be relying upon Red Hat KVM, as well as someone to provide a supported distribution of OpenStack. VirtuStream is in a unique position here, in the respect that they rely upon vSphere or PowerVM, but have their own Cloud Management layer, xStream.
So how important is this? It matters if you expect to put important workloads in that cloud, and if you expect the cloud vendor to be able to resolve issues with excellent agility and responsiveness. Due to the huge installed base of the VMware vSphere product in enterprises, it is safe to assume that public cloud vendors are not going to be dealing with legions of bugs in the underlying hypervisor. This means that any cloud vendor who relies upon vSphere needs to be evaluated on the basis of how much control they have over their cloud management layer. It would be fair to say that any cloud vendor who relies upon both KVM and OpenStack has little to no control over any of the underlying bits, and is therefore nothing more than a reseller of software that they do not control.
Public Cloud Computing – Vendor Economics
Amazon has clearly done an excellent job of driving down the cost of public cloud computing and establishing itself as the leader on the front of pricing and value for the dollar. This has put tremendous pressure on the rest of the public cloud computing industry. Cloud providers who license vCloud from VMware have found that they cannot offer a vCloud-based service that is price competitive with Amazon. As a customer of cloud services, this creates a clear distinction. If you want a public cloud that is based upon the same enterprise-class performance and scalability that vSphere offers on-premise, then you are going to have to pay more for that cloud than you would pay at Amazon.
The above dynamic has led many cloud providers to offer two solutions: one based upon vCloud (the VMware-compatible choice), and one based upon OpenStack (which allows them to compete on price with Amazon). This is all well and good for the cloud providers, but customers should be aware that you cannot have your cake and eat it, too. If you use OpenStack, you are not going to get the same quality of service and agility of response that you would get with a vCloud-based offering, given the diffused nature of the responsibility for the various layers of the stack that are required to construct the service.
Public Cloud Computing – Vendor Service Levels
Since this article is about putting business-critical and performance critical-applications in public clouds, the question of how to define, measure, and guarantee service levels has to be addressed. This is one area where the cheaper the cloud offering is, the worse the answer is going to be. A good answer starts with a proper definition of performance. Performance is equal to end-to-end application response time. Any service level or SLA that is not focused upon application response time is simply worthless. The fact that several Amazon-hosted properties were inaccessible during Amazon’s outage last year and that Amazon’s SLA was not violated while those properties were inaccessible simply proves this point.
This brings up an area where most public cloud offerings are extremely immature. Amazon offers no way to guarantee that latency in their infrastructure is not causing response time issues in the applications. Microsoft has application performance management partnerships with AppDynamics and New Relic, but similarly provides no mechanism to ensure that Azure itself is not the cause of the issue. VMware provides no measure of end-to-end infrastructure latency for vSphere or vCloud, so any cloud based upon its products is similarly impaired on this front. The only vendor that has effectively tackled this issue is VirtuStream, who actually measures application response time from the edge of the application system and offers SLAs guaranteeing response-time-based performance.
When it comes to public cloud computing services, that old adage of “fast, cheap, or good – pick any two” certainly hold true. Amazon can offer you cheap, and since they own their stack, a rapid cycle time DevOps approach to support. But you are not going to get enterprise-grade service level guarantees for Amazon’s pricing. To get both agile responsiveness and enterprise grade SLAs, you are going to have to give up on cheap.
Share this Article: