LinkedIn Twitter
Director, OpenShift Strategy at Red Hat. Founder of Rishidot Research, a research community focused on services world. His focus is on Platform Services, Infrastructure and the role of Open Source in the services era. Krish has been writing @ CloudAve from its inception and had also been part of GigaOm Pro Analyst Group. The opinions expressed here are his own and are neither representative of his employer, Red Hat, nor CloudAve, nor its sponsors.

10 responses to “PaaS Is The Future Of Cloud Services: CloudFoundry Is Ramping Up Big Time”

  1. PaaSCloud

    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.

  2. Lucas Carlson

    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. 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.

  3. Sinclair Schuller

    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”

  4. JP Morgenthal

    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’

  5. Nati Shalom

    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

  6. Sinclair Schuller

    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.

  7. @somic

    PaaS as it exists today is not the future of cloud services. What the industry will call PaaS in the future might be though.

  8. Scott Levy

    Great post. Here’s an article that describes the top benefits of utilizing cloud computing in general, and a cloud database in particular

  9. Chris Haddad

    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.