Having attended the OpenStack Design Summit this week and at the same time fielding calls from Forrester clients affected by the Amazon Web Services (AWS) outage, an interesting contrast in approaches bore out. You could boil it down to closed versus open but there’s more to this contrast that should be part of your consideration when selecting your Infrastructure as a Service (IaaS) providers.
The obvious comparison is that AWS’ architecture and operational procedures are very much their own and few outside the company know how it works. Not even close partners like RightScale or those behind the open source derivative Eucalyptus know it well enough to do more than deduce what happened based on their experience and what they could observe. OpenStack, on the other hand, is fully open source so if you want to know how it works you can download the code.
At the Design Summit here in California this week, developers and infrastructure & operations professionals had ample opportunity to dig into the design and suggest and submit changes right there. And there were plenty of conversations this week about how CloudFiles and other storage services worked and how to ensure an AWS Elastic Block Store (EBS) mirror storm could be avoided.
Having this knowledge about the AWS architecture might have helped many Elastic Compute Cloud (EC2) customers work around the problem or even potentially detect it and act preemptively. Certainly all enterprise I&O customers should have employed disaster recovery and HA best practices with their cloud applications so any unforeseen issue could be dealt with. And that would be true no matter what cloud you choose.
Another stark difference is in the ecosystems of these cloud technologies. Amazon’s massive ecosystem of management software, SaaS, Platform as a Service (PaaS) and independent software vendor (ISV) partners are all just customers of AWS. They aren’t contributors, nor are they I&O peers. OpenStack’s ecosystem includes many of the above but also service providers, government agencies and enterprises who are implementing OpenStack as well. Which means that if you choose to implement OpenStack for your private cloud or you are a hoster implementing it for your IaaS, there is an I&O peer network you can call on in times of crisis who have intimate knowledge of the software and can help you diagnose the problem and even potentially supply a patch to reverse the problem.
You could argue that there is similar value to deploying VMware vCloud Director as I&O peers would be able to help as fellow administrators, but everyone would have to fall back to VMware to resolve the issue if deep knowledge or code changes were required.
The picture painted here is certainly not Nirvana. Open source projects are starting points, and commercial implementations often intermix this code with commercial code that mirrors more the VMware model. Plus every implementation will differ based on hardware used, components deployed and scale. But in all cases, the greater I&O community can be called upon to help in times of crisis and that’s worth considering when choosing your private cloud platform or public cloud provider.