OpenStack Silicon Valley 2014 speaker Randy Bias considers himself a cloud person, not an OpenStack person. He sees OpenStack as a key technology in the cloud. On the other hand, he doesn't see OpenStack being a big public cloud play today, and he points to Amazon Web Services as the reason why.
A self-proclaimed "long-time infrastructure guy," Bias started his IT career in systems engineering and moved to backbone and network engineering for ISPs, as well as information security. When cloud services arrived, he parlayed his systems background into Integration as a Service projects. His career path then led him to founding Cloudscaling, which started as a cloud strategy and architecture design consulting firm and later began to create products.
Cloudscaling was an early backer of OpenStack. Why?
Randy Bias: Community engagement is one big reason we chose OpenStack. We had seen Eucalyptus and CloudStack stumble by being open source in license only. We were part of OpenStack's original launch, and then we transformed our professional services engagements with Korea Telecom and Internet into some of the earliest OpenStack deployments anywhere. We finished our transformation into a product business and in late summer 2012, and we have been going ever since.
How does your and Cloudscaling’s approach to using OpenStack differ from others?
Bias: Many people in the OpenStack community have the perception that OpenStack is software that can be sprinkled everywhere; in [the] public and private cloud and for many different use cases. That sprinkling of OpenStack everywhere is assumed to create software substrata that are highly interoperable.
The problem is that software doesn't create standards, and standards don't even create standards. If you look at things like IPsec and VPNs in the late '90s, everybody implemented IPsec VPN standard and nobody's IP technique and products were interoperable. Interoperability comes from actual testability and being able to know that one thing works, looks, smells, acts and operates in the same way as another thing.
The problem is that OpenStack is very much like the Linux kernel -- more of an open framework.
As an open framework, what can OpenStack not do that a standard does?
Bias: The Linux kernel is used in many different ways. Say, in Android, the Android handset operating system uses the Linux kernel, but not like Red Hat Enterprise Linux does. So, Android Linux and Red Hat Linux running on the hardware they're designed for are actually two incompatible environments. They're running the same software, but you cannot pour applications between them.
It is a false hope that OpenStack can ever create some kind of single monolithic, interoperable system that everybody can use. OpenStack is not a standard. Some people's intentions around OpenStack are malformed, because they're all trying to lead you to a single, unified vision of OpenStack that probably will never exist because OpenStack is far too flexible.
How do you make the next big leap to reasoning that OpenStack's not a public cloud contender?
Bias: My personal assessment is that OpenStack has no future in public cloud. Amazon is very dominant and has a huge amount of market share. Azure and Google are coming from behind. I think Rackspace and HP Cloud have shown that they cannot be competitive.
How should the OpenStack road map change, if it’s not focused on public cloud dominance?
Bias: First, we accept the fact that OpenStack is going to be hybridized with non-OpenStack systems, such as Amazon, Google and Azure. Then we come up with ways to test that and to create interoperability standards to help enterprises hybridize in the lowest-friction manner.
Let's go back to what OpenStack is, software or ….?
Bias: That's underlying tension in the OpenStack community. At the moment, if you asked an average developer if OpenStack’s value is in software or the APIs, the developer will say it's software. If you go to vendors or business people, they would say OpenStack’s value is in the APIs.
This clash creates an OpenStack culture unwilling to allow for competitive software projects. Apache Software Foundation supports multiple projects that offer different ways solve a similar or same problem. OpenStack does not allow that within the project.
In what other ways does the software versus API stance impact OpenStack’s future?
Bias: Having software versus API camps overshadows the importance of behavior, a key consideration in achieving interoperability. When IPsec VPNs were resolved, what happened was that there were all these VPN bake-offs; all the vendors would [put] their IPsec parts together to test. They worked together, and years later, it was standardized.
Now, behavioral testing is at the fundamental root of Defcore, the [committee] created to build on base requirements for OpenStack products [by defining capabilities, code and must-pass tests]. DefCore is working with existing OpenStack Tempest Project tests, which basically test behavior, not software. [They're examining the] combination of the API call, the software on the back, and then the actual behavior of all those things.