Last month I attended the OpenStack Cloud Summit in Atlanta. It was a very
interesting experience. I learned a lot of things from the people there, from the organization, and how the OpenStack cloud community works. Without a doubt, the people who are writing the code are extremely talented. They are doing unbelievable work writing things that make something out of nothing – with just a few lines of code transform your whole system into a cloud that allows you do a huge number of things. It is absolutely amazing.
Not just for developers
Unfortunately, they don’t always understand that clouds have not really been used or built only for developers to write the code or for users to consume the cloud resources. There is a need to recognize the existence of a third party in the equation – the people who operate and manage the cloud, including the infrastructure. As a result, there are issues that have not yet been addressed but need to be considered and integrated into the system. An operator is not a developer, and a developer is not an operator. No matter how much people talk about DevOps, there is still some kind of disconnect between the two groups. I could see a huge difference between the two groups at the conference. I had expected to see a more integrated community and was surprised by the extent of the divide.
Enterprises are definitely looking to OpenStack for the purpose of deploying cloud infrastructure in their organizations. There are a number of very large providers that are looking to deploy OpenStack as a service that they will resell to customers. The majority of those looking to OpenStack are looking to use it to deploy their own internal clouds.
Obstacles to adoption
There are a number of obstacles that are slowing down the adoption of OpenStack cloud.
The upgrade process and migration process between versions is problematic, and any kind of change to the infrastructure affects the underlying workloads. One of the most frequently heard requests from the enterprise point of view is to make the upgrade possible with zero downtime for underlying workloads.
Yes, they have taken huge steps in that direction. But they aren’t there yet. It will take time. Until then people need to understand and make their decisions accordingly. The enterprise can build infrastructure and processes around these limitations, and the need to have downtime for upgrades, or wait until features are available in the regular code.
Another thing that I noticed is that there are a number of “distributions” of OpenStack. I don’t think the use of the term “distribution” is apt here. There is only one OpenStack software. Yes, you have Redhat, which deploys Redhat OpenStack one way, and Ubuntu, RackSpace and others that deploy OpenStack in other ways, but the software in essence is the same.
The software takes the same code from the OpenStack foundation. These are not different distributions, they are different deployment methods. Even in those cases where additional pieces are added to the system package, in essence the software is the same. The problem is that these distributed solutions are not interchangeable. The solutions can be good for one thing and not so great for another. You cannot easily mix and match solutions, particularly with different operating systems.
There are currently no simple solutions for backing up your OpenStack cloud. Some maintain that you don’t need to provide such a solution, but this is the kind of thing that the enterprise may want, or provide as an added benefit to their customers.
OpenStack as a disrupting technology
OpenStack is a disrupting technology. It is making people think differently and work differently. It is making IT work differently. One of the contentions raised at the Summit addressed the need to fix the features without disrupting things. For example, there are features with problems from four versions ago that have not been completely resolved. In the interim, there have been some 17 other products introduced into the OpenStack product and surrounding infrastructure. Meanwhile those original features have not been fixed. People want to see OpenStack fix what’s there before investing effort in making the product even brighter and shinier.
Emergence of OpenStack ecosystem
There is an ecosystem evolving around OpenStack. For now it is a very small ecosystem. For example, there are people who provide monitoring solutions or deployment solutions based on OpenStack. This ecosystem is limited, though I expect it to continue to grow. (The ecosystem around VMware, for example, is much larger. It includes security, compliance, replication, backup , disaster recovery, and automation solutions.)
I praise the OpenStack Foundation for trying to commit to providing better solutions for operators. A half day of sessions was devoted to topics of interest to operators. The ensuing discussions were enlightening. Not everybody agreed about everything. But in my opinion, this was definitely a step in the right direction. The Summit was a great learning experience for me, and would definitely plan to attend future OpenStack events.