Six months ago there was no Cloud Foundry Foundation. This week, its biggest problem at the user conference was the fire marshal. At 1,500 reported attendees the event was a multiple of the project’s inaugural Platform event. To the point that it’s hard to see the Summit going back to the Santa Clara conference center. Enthusiasm will make people patient with standing room only events with seating along the walls two deep, but there are limits.
For an event reportedly put together in a little over two months, execution was solid. From HP’s magician/carnival barker to the Restoration Hardware furniture strewn liberally across the partner pavilion – excuse me, “Foundry” – walking the show floor had a different feel to it. Sessions were a reasonable mix of customer case studies and technical how to’s, which was fortunate because the attendees were an unusual mix of corporate and very pointedly non-corporate.
The conference comes at an interesting point in the Cloud Foundry project’s lifecycle. The first time we at RedMonk heard about it, as best I can recall, was a conversation with VMware about this project they’d written in Ruby a week or two before its release in 2011 – two years after the acquisition of Cloud Foundry. There are two things I remember about that call. First, that I was staying at the Intercontinental Boston at the time. Second, that I spent most of the briefing trying to imagine what kind of internal battles had been fought and won for a company like VMware to release that project as open source software.
By the end of that year, the project had enough traction to validate one of my 2011 predictions. Still, Cloud Foundry, like all would-be PaaS platforms, faced a substantial headwind. Disappointment in PaaS ran deep, back all the way to the original anemic adoption of the first generation of Google’s App Engine and Saleforce’s Force.com – released in April of 2008 and September of 2007, respectively. All anyone wanted to buy, it was argued, was infrastructure. Platform-as-a-Service was one too many compromises, for developers and their employers both. AWS surged while PaaS offerings stagnated.
Or so it appeared. Heroku, founded June 2007, required less compromise from developers. Built off of standard and externally available pieces such as Git, Ruby and Rails, Heroku was rewarded by growing developer adoption. Which was why Salesforce paid $212M to bring the company into the fold. And presumably why, when Cloud Foundry eventually emerged, it was open source. Given that one of the impediments to the adoption of Force.com and GAE in their initial incarnations was the prospect of being locked in to proprietary technologies, the logical alternative was a platform that was itself open source.
Fast forward to 2015. After some stops and starts, Cloud Foundry is now managed by an external foundation, a standard mechanism allowing erstwhile competitors to collaborate on a common core. The project has one foot in the old world with participation from traditional enterprise vendors such as EMC, HP and IBM and another in the future with its front and center “Cloud Native” messaging. How it manages to bridge that divide will be, to some degree, the determining factor in the project’s success. Because as Allstate’s Andrew Zitney discussed on Monday, changing the way enterprises build software is as hard as it is necessary. This is, in fact, one of three important questions facing the Cloud Foundry project in the wake of the Summit.
Is the Cloud Native label Useful or a Liability?
There are several advantages to the Cloud Native terminology. First, it’s novel and thus unencumbered by the baggage of prior expectations. Unlike terms such as “agile” which even one of the originators acknowledges has become “sloganized; meaningless at best, jingoist at worst,” Cloud Native gets to start fresh. Second, it’s aspirational. As evidenced by the growth of various cloud platforms, growing numbers of enterprises
are hyper-aware that the cloud is going to play a strategic role moving forward, and Cloud Native is a means of seizing the marketing high ground for businesses looking to get out in front of that transition. Third, it’s simple in concept. Microservices, for example, requires explanation where Cloud Native is comparatively self-descriptive. By using Cloud Native, Cloud Foundry can postpone more complicated, and potentilly fraught, conversations about what, precisely, that means. Lastly, the term itself explicitly disavows potentially fatal application compromises. The obvious implication of the term “native,” of course, is that there are non-native cloud applications, which is another way of saying applications not designed for the cloud. While it might seem counterintuitive, acknowledging a project’s limitations is a recommended practice, as customers will inevitably discover them anyway. Saving them this disappointment and frustration has value.
All of that being said, much depends on timing. Being exclusionary is an appropriate approach if a sufficient proportion of the market is ready. If it’s too early, Cloud Native could tilt towards liability instead of asset, as substantial portions of the slower moving market self-select themselves out of consideration by determining – correctly or not – that while they’re ready to tactically embrace the cloud, going native is too big a step. Even if the timing is perfect, in fact, conservative businesses are likely to be cautious about Cloud Native.
Cloud Native is a term then with upside, but not without costs.
How will the various Cloud Foundry players compete with one another?
The standard answer to questions of this type, whether it’s Cloud Foundry or other large collaborative projects, is that the players will collaborative on the core and compete above it. Or, as IBM’s Angel Diaz put it to Barb Darrow, “We will cooperate on interoperability and compete on execution.” From a high level, this is a simple, digestible approach. On the ground, temptations can be more difficult to resist. The history of the software industry has taught us, repeatedly, that profit is a function of switching costs. Which is where the incentive for ecosystem players to be interoperable enough to sell a customer and yet proprietary enough to lock them in, comes from.
Which is why the role of a foundation is critical. With individual project participants motivated by their own self-interest, it is the foundation’s responsibility to ensure that these do not subvert the purpose, and thus value, of the project itself. The Cloud Foundry Foundation’s primary responsibility should ultimately be to the users, which means ensuring maximum interoperation between competing instances of the project. All of which explains why core.cloudfoundry.org will be interesting to watch.
How will the Cloud Foundry ecosystem compete with orthogonal projects such as Docker, Kubernetes, Mesos, OpenStack and so on?
On the one hand, Cloud Foundry and projects like Docker, Kubernetes, Mesos and OpenStack are very different technologies with very different ambitions and scope. Comparing them directly with one another, therefore, would be foolish. On the other hand, there is overlap between many of these projects at points and customers are faced with an increasingly complicated landscape of choices to make about what their infrastructure will look like moving forward.
While there have been obvious periods of transition, historically we’ve had generally accepted patterns of hardware and software deployment, whether the underlying platform was mainframe, minicomputer, client/server, or, more recently, commodity-driven scale-out. Increasingly, howevever, customers will be compelled to make difficult choices with profound long term ramifications about their future infrastructure. Public or private infrastructure? What is their approach to managing hardware, virtual machines and containers? What is the role of containers, and where and how does it overlap with PaaS, if at all? Does Cloud Foundry obviate the need for all of these projects? And the classic, rhetorical question of one-stop-shopping versus best-of-breed.
While Cloud Foundry may not be directly competing against any of the above, then, and certainly is not on an apples to apples basis, every project in the infrastructure space is on some level fighting with every other project for mindshare and visibility. The inevitable outcome of which, much as we saw in the NoSQL space with customers struggling to understand the difference between key-value stores, graph databases and MapReduce engines, will be customer confusion. One advantage that Cloud Foundry possesses here is available service implementations. Instead of trying to make sense of the various infrastructure software options available to them, and determining from there a path forward, enterprises can essentially punt by embracing Cloud Foundry-as-a-Service.
Still, the premium in the infrastructure is going to be on vision. Not just a project’s own, but how it competes – or complements – other existing pieces of infrastructure. Because the problem that a given project solves is always just one of many for a customer.
