There has been a great deal of passionate debate over the last few months within the OpenStack community. There is one camp that is advocating for building APIs that are compatible with Amazon Web Services (AWS) APIs, while the other camp argues for augmenting the existing OpenStack APIs. Those in favor of making the APIs more compatible with AWS are focused on standardization and compatibility between OpenStack and AWS. Standardizing on the AWS APIs makes moving workloads between OpenStack and AWS clouds easier, thus giving OpenStack a competitive advantage over other private cloud stacks. It also makes it easier for customers to move workloads off of AWS (public cloud) to OpenStack (private cloud) for customers wanting to deploy on bare metal machines, keep critical data out of the public cloud, or have the flexibility to target a cloud endpoint based on their customers’ desires (for those delivering solutions to customers outside of their enterprise).
The counterargument is that copying the AWS APIs and architecture can restrict innovation. Instead of copying AWS, they want to improve on the APIs and deliver more of what they feel customers need rather than what AWS provides. This camp feels that time is also better spent focusing on adding more APIs, which is an area where all IaaS vendors are far behind AWS. Both camps have valid points, but as Ben Kepes eloquently penned, “Who Cares?”
Get Over it and Get Going
As a cloud architect who talks to Fortune 500 enterprises every day, I can say that none of my clients even talk about this topic. What they want to talk about is how can they leverage “the cloud” to help solve their business problems. In just the last year the conversation with enterprise IT has changed dramatically. A year ago, many enterprises were very focused on building private clouds because of their belief that the public cloud was just too insecure and that handing over the responsibility of managing SLAs to a third party was just too risky. But over the course of the last year, a few things have changed that have caused some enterprises to rethink that position, or at least to consider the public cloud a viable solution for some workloads. In no particular order, here are factors that are changing enterprises’ binary view of “public versus private” to “public and private”.
- AWS’s focus on solving problems in the enterprise
- Exponential growth in data accelerating capacity needs in data centers
- Increasing number of enterprise success stories in the public cloud
What does this mean to those whose revenues depend on the adoption of OpenStack? It means that enterprises are becoming more open to solving their business problems in the public cloud. The argument that data cannot be secure in the public cloud does not hold as much water anymore with the maturity of AWS’s Virtual Private Cloud (VPC), AWS Storage Gateway, Direct Connect, and others. Now many enterprises are asking us questions like, “What data can I put in the public cloud?” and, “What is a good archiving strategy in the public cloud so I can stop buying so much disk?” and, “How quickly can you help me migrate these applications to the cloud before I outgrow my datacenter?”.
I believe the OpenStack community should be aggressively focusing on aggressively making OpenStack easier to use. A main contributor to the adoption of AWS is how easy it is to simply swipe a credit card and started building solutions. In many companies, AWS has been brought into the organization from outside of IT or through grassroots efforts from within IT without any official approval from those responsible for security, compliance, or governance. Often, once applications and services deployed on AWS make their way into the enterprise, it is impossible to keep it out. This is where AWS has a great competitive advantage in its ease of use.
OpenStack, on the other hand, is more complex to install and manage. Other than your hardcore IT geeks, very few people are simply “turning on” solutions in OpenStack. In fact, many organizations have to enlist partners like Cloudscaling just to setup their private cloud before they can dream about deploying software on it. This is not a knock on OpenStack but a reality of the tradeoffs between public and private clouds. Private clouds give you more control over your data and SLAs, but they also put the burden on you to install and manage both the infrastructure and the cloud stack. With the public cloud, the infrastructure and cloud APIs are in place, ready to go the second you create an account. The OpenStack community should be focusing on providing tools to reduce the time it takes to get a private cloud ready for developers to start innovating.
While the OpenStack powers-to-be are having the API debates, AWS is continuously making their public cloud offering more enterprise friendly with features like CloudHSM, AWS Import/Export, Amazon EMR, and it is providing more PaaS like features to simplify cloud management like OpsWorks, Elastic Beanstalk, and Data Pipeline. I actually agree with both camps in the Open Stack API debate. OpenStack should build APIs compatible with AWS APIs because enterprises live in a multi-cloud world. At the same time, the rate of innovation needs to drastically increase. OpenStack is a mere three years old, and the open source project has come a long way in a short period of time. However, AWS has been around since 2006 and is light-years ahead of OpenStack and everybody else, and it is innovating much faster as well. OpenStack needs to make building and managing private clouds easier and faster. As time goes on, enterprises will be more open to leveraging the public cloud for workloads as AWS continues to innovate in the enterprise space. It is critical for OpenStack and all IaaS private cloud solutions to increase their install base now while private clouds are a very high priority within the enterprise.
Share this Article:
Latest posts by Mike Kavis (see all)
- The State of DevOps in 2016 - June 30, 2016
- What I Learned @ DockerCon 2016 - June 23, 2016
- Rightscale Publishes State of the Cloud Report for 2016 - May 11, 2016