I have high hopes on CloudFoundry (previous CloudAve coverage), VMware’s PaaS attempt, and consider the platform to be the standard for comparison in the PaaS space. Looks like it is not going to change anytime soon and last week showed that they are having ever increasing momentum in the market. No, they are not VMware’s cash cow but they are doing everything right to get the dominant marketshare in this space. From HP’s announcement to Joyent’s ecosystem play to positive Evans Data report, they are getting people excited big time. I am not a big fan of VMware in the infrastructure space but I am greatly pumped up on CloudFoundry. I will take this post to briefly discuss the news from last week which has got the CloudFoundry community excited.
HP to use CloudFoundry for PaaS
Last week Wired Magazine carried a story about how HP (disclosure: I had brief strategy discussion with HP on their public cloud strategy without any financial transaction and I was aware of their moves for sometime) is using CloudFoundry for offering PaaS to their cloud customers. Irrespective of what your opinion is about HP, this announcement is a big validation for CloudFoundry efforts and is a clear signal that enterprises can trust CloudFoundry PaaS layer for their needs.
HP has embraced the open source alternative to Windows Azure: VMware’s Cloud Foundry.
HP is currently running the VMware platform atop the cloud service it privately introduced to a small number of testers earlier this fall. In all likelihood, the company will eventually make good on its Windows Azure promise, but at the same time, it’s fully committed to Cloud Foundry, and the platform will be part of HP’s cloud service when it’s unofficially unveiled in the spring.
The move is a boost for VMware’s project, which seeks to provide a common way of building what are typically called “platform clouds.” VMware runs its own Cloud Foundry service — also in beta — and several outside outfits have deployed the platform in recent months, but HP is certainly the biggest name to do so. VMware aims to create a cloud “ecosystem” where applications can span disparate services — or even move from service to service.
Joyent joins CloudFoundry ecosystem
One of the biggest reason I got excited about CloudFoundry is that their framework is so flexible and open that anyone with expertise in any programming language framework can plug it into CloudFoundry. We already saw Appfog (previous CloudAve coverage), formerly known as PHPfog, joining CloudFoundry ecosystem as project lead for PHP and ActiveState leading the Python project.. They have strong expertise on PHP and they are putting it to use in the CloudFoundry project. Last week, Joyent announced that they will be joining as project lead for Node.js.
Joyent is proud to extend our stewardship of the Node.js open source project to Cloud Foundry,VMware’s open source platform-as-a-service. It’s with great pleasure that we take on the role of Community Lead for Node. We will be providing Cloud Foundry’s end-users with community support for Node.js and NPM. We will also make ongoing contributions for Node.js and NPM to keep them up to date and on the latest stable releases. One of our first contributions will be to add full server side support for NPM to the project.
A company like Joyent putting its weight behind CloudFoundry project bodes well for its future and can also act as an antidote against any “evil plans” which some people expect from VMware in the future. In fact, some people really worry that VMware will make CloudFoundry proprietary once they gain enough developer mindshare but I suspect VMware has any such plans. I have good reasons to feel that way. May be I should do it as a separate post another day.
More importantly, developers are warming up big time
Evans Data Corp took a survey of developers and they have rated CloudFoundry as the top cloud platform of choice in the user satisfaction survey. According to the press release,
Cloud Foundry achieved the highest overall score, while IBM’s cloud offerings ranked first among developers targeting private clouds, and Google ranked first with public cloud developers.
“The top three competitors were very close, with one appealing to private cloud development, one to public and Cloud Foundry™ appealing to both,” said Janel Garvin, CEO of Evans Data Corp. “This is important because many cloud deployments are hybrid clouds blending private, public and on-premises instances. Flexibility is key.”
The survey looked at fourteen different Cloud platform attributes and asked users to rate each one for the Clouds they use. Cloud Foundry was strongest in reliability, supplied development tools and price for service and storage among others, while IBM’s top scores included best security, proven expertise, and auto-scaling, and Google was seen as the vendor with the most market potential and best vision for the future.
Conclusion
It is still too early in the game. It will be premature to declare CloudFoundry the winner in the PaaS market segment but they are doing all things right and developers, businesses and, even, pundits are warming up to them. If you ask me if CloudFoundry will turn out to be a cash cow for VMware, I will say “it is doubtful” but I can say for sure that CloudFoundry is the way VMware will stay relevant in the cloudy world. Probably, it is a good topic for a separate blog post of its own.
Updated: I added the role of ActiveState in the CloudFoundry ecosystem. My apologies for missing it out yesterday.
Related articles
- Cloud Foundry meets the enterprise with Stackato (gigaom.com)
- Joyent is Community Lead for Node.js on Cloud Foundry (joyeur.com)
- VMware’s Cloud Foundry Tops List of Best Cloud Development Platforms (devx.com)
- What is Platform as a Service (PaaS)? (clean-clouds.com)
- Exclusive: HP Runs VMware’s Open Source ‘Cloud OS’ (wired.com)
PaaS is definitely going to be a dominant layer of cloud computing and true PaaS is not only a platform for developers but should be a viable platform to upgrade existing IT infrastructure rather than adding one more silo platform asset for developers. CF is way far from being that. Cloud Foundry ecosystem is already getting highly fragmented with several distributions, it will be hard for any one to differentiate and if companies do, its for their own niche purposes and for their own IaaS platforms. (we have seen this problem with Linux and only two distros mostly survived commercially) It will be hard for the community to deliver a true platform when no one will contribute back for the reasons of maintaining a niche. As you said, its too early in the PaaS space and time will tell.
I disagree strongly that the only way to differentiate between companies using Cloud Foundry is by maintaining niches and that nobody will contribute back, creating a fragmented ecosystem.
Disclaimer: I founded AppFog, a PaaS built using Cloud Foundry technology
There is a lot of confusion about Cloud Foundry. PaaS can be broken into three pieces of technology.
1) UX – web console, plans, pricing, support, UI, etc.
2) App lifecycle management – start, stop, deploy applications
3) Integration with IaaS – start and stop VMs, manage and maintain them
A full running PaaS service needs all 3.
CloudFoundry.org is ONLY #2.
AppFog built #1 and #3 on our own. This leaves a lot of room for innovation above and below the stack. When AppFog incorporated Cloud Foundry technology, we contributed back PHP support and are committed to fully contributing all the PHP technology we keep improving as our service matures.
Why? Because it is not the core competency of a full PaaS platform. Any company that feels like their branch of Cloud Foundry is their core competency is likely setting themselves up for failure simply because the open source community at large will likely rebuild their golden goose, and possibly end up out-doing their proprietary code.
That’s the brilliance of VMware’s move of making Cloud Foundry open source, they force companies to innovate at a level more interesting than App Lifecycle Management. For example, AppFog’s core competency is building the best PaaS service, running on AWS, Joyent and OpenStack, we already accept credit cards, we provide Varnish HTTP caching and a great web console and are innovating in ways that compliment rather than compete or fragment Cloud Foundry.
AppFog has submitted 4 pull requests (all accepted with many more to come) and developers and companies have submitted nearly 200 more pull requests so far.
AppFog is not alone, Joyent has made a similar realization about all of what I just stated and is acting exactly the same with Node. ActiveState is a great steward for Python. More companies are all making the same realization creating a strong and collaborative ecosystem.
Sure other companies are trying to do their own forks and try to make a quick buck, but that’s the beauty of open source. You don’t judge the heath of an open source ecosystem by the people who fork and try to make a quick buck, you judge it by how much contribution and what quality that contribution is. Being on the front lines of that, I can tell you we are in great company with some great contributions on top of a quality structure built by VMware.
Companies who bet their PaaS differentiation on App Lifecycle Management are scared, and with good reason. They are likely to spread FUD in an attempt to confuse the market even more. But they are scared for a good reason, they realize how futile it is to try to keep up with the pace of an open source developer tsunami. How can they possibly keep pace with an army of developers clamoring for languages and frameworks they never heard of? Cloud Foundry gives these developers a voice they have never had before. Cloud Foundry is by developers and for developers.
Good post and good follow-ups; clearly, there is Passion for PaaS (new website?);-) I think a lot of what has been discussed is not so black and white. CloudFoundry is a tremendous asset to the cloud ecosystem, but at the same time, is still very nascent – or at least early enough that any call that gives CloudFoundry pole position is at best, awkward. As a market, we have to rely on mission critical app deployments and scrutinizing customers as the gold standard for measuring leaders or even momentum. Anything else is vanity. Furthermore, “reports” make me nervous for a few reasons. Take statements like:
“Cloud Foundry was strongest in reliability, supplied development tools and price for service and storage among others”
Price? Really? How so? Are they referring to the “free as in beer” aspect, or Cloud Foundry service offering? If it is for service offerings, is there actually a pricing model in place that is public and available for review? Clearly, as Lucas pointed out, AppFog is now accepting credit cards, so maybe that is what Evans Data is referring to. These are honest questions. I don’t have access to the report, but the claims of Cloud Foundry being the best and highlighting things like price is very strange. Again, don’t get me wrong, I have plenty of respect for what CloudFoundry is doing, but we’re not at a stage of a market where blessing a leader is appropriate (unless we’re looking to create a self-fulfilling prophecy rather than a merit-based success).
Disclosure on my end: I’m CEO of .NET PaaS vendor Apprenda. CloudFoundry as an open source core can be a very powerful force, but open source is more relevant to PaaS vendors like Apprenda or AppFog than it is to end user customers (there is some value, but that’s for another post). End user customers care most about Open PaaS – being able to download the PaaS layer and run it anywhere to avoid a severe form of lock-in. I think comparing products on whether they are open source or not misses the point. Consider what Lucas posits when he states the PaaS is composed of three technologies, for example:
1) UX – web console, plans, pricing, support, UI, etc.
2) App lifecycle management – start, stop, deploy applications
3) Integration with IaaS – start and stop VMs, manage and maintain them
Understanding what PaaS is composed of is a better basis for comparing vendors than open source or not open source. I agree with #2 and loosely agree with #1 (another spot where context is important. For example, private PaaS has less emphasis on things like plans and pricing). #3 is not relevant in PaaS. A PaaS layer could in fact be layered directly atop raw hardware (so long as it isn’t of the instance PaaS variety that relies on virtualization as the underlying container mechanism). Whether IaaS exists beneath a PaaS or not is an optimization focused on infrastructure flexibility, and not on enhancing PaaS virtues.
What is missing in Lucas’ definition of PaaS is whether or not a PaaS truly provides an application runtime – a modern, distributed analog to the JVM or CLR. That should be #3 (which most PaaS offerings are sorely lacking, by the way) Does the PaaS influence application execution and messaging, conferring new capabilities on guest applications? Does the PaaS provide runtime services that are implicitly inherited by apps or accessible via APIs that resolve to interesting, high value behavior at runtime? Does the PaaS activate it’s own behaviors based on what a guest app is doing at any given time? This is tremendously important because it is such a runtime layer that allows a PaaS to behave like an OS, inherently increasing the value of guest apps as the OS gets better without requiring the guest apps themselves to change. Think about what happens when the CLR or JVM becomes better performing – all apps running on those runtimes perform better as well. The need for this PaaS quality of being a “runtime” rather than a “bit shoveler” is less obvious in the near term, but will be more obvious in the long term.
If one steps back and says “Let me think about PaaS in terms of what experience does the developer have when using it, what sort of application management capabilities does it give me, and what sort of next gen value do I get from its runtime and set of APIs?”, I think they will have a better lens for comparison than “what is open source and what isn’t”
If attempting to develop stateless web-based applications, today’s PaaS solutions are fine. Otherwise, any storage must be handled by networked connections, which doubles or triples the amount of network traffic that a PaaS platform must deal with. Unlike IaaS, which offers direct attached storage solutions, which can improve performance 10-fold, pure networked storage requires either a database server, network file system or object file system. If you compare AWS’ S3 to EBS storage solutions, S3 is far less performing than EBS. So, to achieve the level of performance you want, you end up deploying your app on top of IaaS anyway.
PaaS is nothing more than middleware rebranded. Anyone who has been working with application servers for the past 10 years knows that tuning is everything and so it will need to be with PaaS as well. Unfortunately, how do you tune a multi-tenant environment with 25 different focuses?
Just sayin’
I believe that the main reason for the slow adoption of PaaS during the past years is mostly to do with the pointed architecture (you application needs to fit into a certain blue-print that is defined by the PaaS provider) approach that were core to the design of both Google App Engine, Heroku as well as CloudFoundary. That means that it is the PaaS provider who determines which cloud you’ll be using, which stack, which version of each element in the stack, which language would be supported and which deployment model will be supported.
As JP Morgenthal mentioned this put a strong limit into the application that could fit into this model (mostly stateless and simple web apps)
After taking a close look into CloudFoundary i think that it will also take a while till it gets mature and will be able to support real workload.
On the other hand we see other framework like RightScale, Enstratus, Cheff, Puppet that start by automating the management and deployment of existing apps gaining much more adoption. The main reason IMO is their flexibility to support all kinds of application and deployment model.
For PaaS to gain adoption we need to take the ideas from the like of RigthScale and merge it into the Application Platform. The result would be a non-opinated PaaS – a PaaS that can fit into any existing and new application, a PaaS in which you could control which OS version, middleware service your going to choose etc.
This is the approach that we’ve taken with GigaSpaces/Cloudify
JP, if by “PaaS is nothing more than middleware rebranded” you mean PaaS is a type of middleware – guilty as charged. If you mean that PaaS is simply a wrapper to traditional middleware, I’d caution against using that definition in any sort of ideological way. While some vendors are simply providing a homogenized management layer in front of traditional application servers, others are trying to use application servers as a component in a larger, new type of application container architecture. This is where my PaaS runtime comment comes from (unfortunately, I can’t do the definition justice in a comment but will be putting up a post to explain in depth).
As for tuning a multi-tenant environment, that is part of what more cutting edge PaaS vendors are trying to do – ensure that applications can describing tuning constructs to the runtime that can in turn tune systems even with multi-tenant isolation in place. It’s part of the difficulty in tackling these architectures the right way. That said, it is part of the maturation process that PaaS is currently undergoing.
We’ve all seen the story of “it just has to be tuned right” turn into “the system just does it”: OS’ taking over what were previously application responsibilities. Think of how disgusting the concept of cooperative multi-tasking is today, where yield responsibilities lived with apps. Applications maintained effectively what were systems responsibilities, and then along came preemptive schedulers and huge boosts in system stability. Remember allocating memory, building insanely complex pointer reference tracking mechanisms so you didn’t go into memory leak world? Yep, me too. Then came things like the CLR and JVM that flattened that problem for the masses. Ask anyone coming from the C++ world, and they would have told you that no apps could rely on anything that managed memory for them because memory management was “too close to the app and nothing could deal with it correctly.” Granted, there are many cases where one would still prefer to manage their own memory, but the majority case is covered by modern memory management.
The point is that although many cases would call for working directly against IaaS, the PaaS market is evolving quickly and will provide solutions to problems that require high fidelity control without sacrificing the sanctity of a true cloud runtime. Nati’s proposal that “…a PaaS that can fit into any existing and new application, a PaaS in which you could control which OS version, middleware service your going to choose etc.” is the correct model is just plain wrong. It promotes legacy behavior and distracts focus from revolutionizing computing, and clearly identifies a model where PaaS is not a runtime but rather a management tool for IaaS/virtualization.
PaaS as it exists today is not the future of cloud services. What the industry will call PaaS in the future might be though.
Great post. Here’s an article that describes the top benefits of utilizing cloud computing in general, and a cloud database in particularhttp://blog.caspio.com/web-database/top-benefits-of-database-cloud-computing/
Great comments! My personal perspective is mostly aligned with Sinclair and Nati.
The PaaS on PaaS marketure surrounding Cloud Foundry has me confused. The ecosystem surrounding Cloud Foundry demonstrates how PaaS, the middle level between SaaS and IaaS is actually a multi-layered market space. A way to unwind the recursive relationship between Cloud Foundry and ecosystem partners is to first start calling the technology a ‘cloud-enabled platform’, and limit PaaS as an instantiation of the cloud-enabled platform delivered as a service. The CloudFoundry ecosystem partners (e.g. AppFog, Stackato, Uhuru, Tier3) seem to be competing on ease of use enhancements, bundled technology (e.g. language support, cache support, database support), or managed hosting.
I get confused when I hear AppFog or Stackato described as PaaS’ running on top of Cloud Foundry, which is also marketed as a PaaS. It becomes non-trivial to characterize the differences between offerings, but the vendors themselves are starting to sort out the nomenclature. In fact, Stackato is now promoting their offering as “The cloud platform for creating your private PaaS” and AppFog defines their offering as “a cloud-based hosting service for your favorite web application stack”. Under a more defined and consistent nomenclature, Stackato could be considered a cloud-enabled application platform build on top of Cloud Foundry, and AppFog considered as a Platform as a Service built on top of Cloud Foundry.
But the last paragraph still doesn’t describe ‘What is Cloud Foundry?’ Cloud Foundry self-describes their offering as “an open platform as a service, providing a choice of clouds, developer frameworks and application services”. But the open source project is not a service; it’s a cloud aware application execution framework, which sit underneath a traditional application platform and application frameworks (e.g. .NET, Java, Sinatra, Tomcat, Rails). Cloud Foundry capabilities are actually of little direct use to an application developer; unless during the time when the developer is building servers or deploying an application. The Cloud Foundry core does not help a developer design, code, or test applications (where hopefully they spend a majority of their time).
Cloud Foundry and ecosystem partners are focused at a different abstraction level when compared with traditional, integrated application platform suites (i.e. IBM WebSphere, Oracle SOA Suite, Tibco ActiveMatrix, or WSO2 Carbon). Application platform suites deliver high level APIs and components, which accelerate solution development. For enterprise development, teams often require a comprehensive, full-spectrum application platform delivering web application-hosting, service hosting for data and process, data persistence and queries, identity and entitlement (i.e. authorization, authentication, audit), mediation and transformation (often delivered via an ESB or gateway), workflow, presentation, rules, and development governance.