The questions around OpenStack today are different than they were last year, just as they were different the year before that, and the year before that. Go back far enough, and the most common was: has anyone ever successfully installed this? These days, installation and even upgrades are more or less solved problems, particularly if you go the distribution route. Even questions of definition – which of the many individual projects under the OpenStack umbrella are required to actually be considered OpenStack? – have subsided, even if they’re not yet addressed to everyone’s satisfaction.
The real questions around OpenStack today, in fact, have very little to do with OpenStack. Instead, the key considerations for those using the technology or more importantly considering it have to do with the wider market context.
The most significant challenge facing most enterprises today isn’t technology, it’s choice. For every category of infrastructure software that an enterprise can conceive of today, and many that they can’t, there are multiple, credible software offerings that will satisfy their functional requirements. At least one, and likely more than one, of the options will be open source. If you enjoy the creativity of software as an endeavor, this is a golden age.
The problem then is not a lack of technology options, as it might have been ten years ago if a business wanted to, as an example, store information in something other than a relational database. The problem is rather the opposite: there are increasingly too many options to cope with.
Which means that OpenStack, like every other piece of infrastructure technology, is facing more competition. Not in the apples to apples sense, of course. OpenStack outlasted its closest open source functional analogues in CloudStack and Eucalyptus, and the 7500 attendees at this week’s summit would argue that it’s the most visible open source cloud technology today.
But if projects that are exactly equivalent functionally to OpenStack are not emerging at present, technologies with overlapping ambitions are.
Consider containers. By themselves, of course, a container is from an OpenStack perspective little different from a virtual machine – an asset OpenStack was built to manage.
But if you’re making a Venn diagram of technical roles, the vast array of projects that are growing up around containers to orchestrate, schedule and otherwise manage them definitely overlaps with OpenStack today and will more in future. Like other projects that predate the explosive ascent of containers, OpenStack has been required to incorporate them after the fact via projects like Magnum, and according to numbers cited at the Summit 70% of users still want better support for what is, effectively, the new VM. Which OpenStack will ultimately provide, both directly and by serving as the substrate upon which users can run anything from Kubernetes to Mesos.
But what if projects like a Mesos herald a return to our distant past? From the earliest days of computing, the technology industry has been steadily been turning larger machines into larger numbers of smaller machines. The mainframe singular was broken up into mini-computers plural, mini-computers gave way to more machines in the client-server era, and client-server in turn to the scale of virtual machines and eventually clouds. Where we once deployed workloads to a single computer, then, the mainframe, today we deploy them to fleets of machines – so many, in fact, that we require scheduling software to decide which computers a given workload should run on.
What if compute took the next logical step, much as Hadoop has in the data processing space before it, and abstracted the network of machines entirely to present not the fleets of machines we have become accustomed to in this cloudy world, but one big computer – a virtual mainframe? This is, of course, the goal of Mesos and the recently open sourced DC/OS, and while it’s hardly a household name at present, it will be interesting to see whether customers remain fixated on the discrete, familiar asset model that OpenStack represents or whether they are attracted, over time, to the heavy abstraction of something like Mesos. If the web world is any indication, the latter is more probable.
The real problem for OpenStack, however, is that even if users come to believe that OpenStack and container-based infrastructure are not competitive but purely complementary, discovering that fact will take time. Which means that whether container-based infrastructure is or is not technically competition for OpenStack, from a market perspective it will function as such. The reverse is true as well, of course. Container-based infrastructure players continually face questions about whether they require foundational platforms such as an OpenStack (as at Time Warner), or whether users are better off running them on top of bare metal and cutting out the middle man.
All of which again is more of a commentary on the market today than anything OpenStack has or has not done. Like virtually every other infrastructure project today, the primary challenge for OpenStack at present is helping customers make sense of a sea of different technology options. The real danger for OpenStack and its would be competitors and partners, then, is that customers decide to make these choices someone else’s problem by advantaging public infrastructure. For OpenStack, then, and the vendors within its orbit, my message at the Summit was that the most important investments in the near term are not technology, but rather education and messaging.
Projects and the vendors that support them have a tendency to focus on their capabilities, leaving the wider context for users to work through on their own. In general, this is an unfortunate practice, but with the landscape as fragmented as it is today, it is a potentially fatal approach. If you don’t make things simple for users, they’ll find someone who will.
