There has been a raging debate about Platform-as-a-Service and whether it is still a valuable part of a cloud portfolio, so InfoQ reached out to four leaders in the cloud domain for their opinions on the future of PaaS.
In this interview, cloud advocate Krishnan Subramanian, cloud developer Dan Turkenkopf, cloud executive JP Morgenthal, and cloud expert James Urquhart discuss misperceptions about PaaS, and its role in the future of cloud computing.
InfoQ: What real (not theoretical) value does PaaS bring that IaaS doesn't? Why can't I just use virtual machines to host my diverse application portfolio?
Krish: Yes, you can use virtual machines, management tools, etc. to set up an environment that offers value similar to PaaS. No doubt about that. But what PaaS does is to take the complexity out of automation for IT shops in the enterprise market while seamlessly bridging with developer tools. These are the two key takeaways in my opinion and the side effect of this is increased developer productivity, lack of burden on organizations to acquire newer DevOps skills because the roles of Devs and Ops are kept separate while tightening the collaboration between then from Development to Production.
JP: I believe the #1 value of the PaaS in this regard is simplified lifecycle management of the application including scaling the application to meet user demand and established service levels. Consider that an application deployed without using PaaS probably uses an n-tiered server approach. This means setting up and configuring all the various components of the stack including the database, web server, app server, load balancer, etc. This takes considerable effort for operations and is expensive to maintain over time. Moreover, the stack that development uses is typically not the same exact configuration as operations uses, thus setting up a potential for production failure that cannot be replicated in development. The PaaS provides the services to the application and allows development to focus on building out solutions to business problems instead of engineering a stack for execution and delivery. It manages the deployment and ensures the application meets determined services levels in production.
Dan: Framing it in this manner begs the question a bit. If all you're worried about is hosting application components, then, as you mention, you've got lots of options. I'd still argue that PaaS is better suited than most for enterprise environments because it creates a common interaction model for developers and operations staff, but I also think that's the least part of the value of a platform.
I'm not going to get all cloud architect (in the old sense of the term) here and talk about proper levels of abstraction and all that. Instead, let's focus on how PaaS enables and benefits from a service ecosystem in a way that an automated container solution can't. A proper platform allows for the seamless consumption of enterprise services like authentication, authorization, map/reduce, etc. The best do it through the "don't call us, we'll call you" principle of inversion of control. You can see that today with CloudFoundry service binding, OpenShift plugin cartridges and Apprenda & Heroku add-ons.
Even deeper, and where I see the real future of PaaS, is injecting capabilities directly into the application to either provide additional features (like Apprenda can do with multi-tenancy) or to instrument the applications to enhance management capabilities (see William Louth's theory of PaaS). But I'm getting a little far afield from the question.
James: This question reveals a key misconception about what developers (and others) think about when consuming the cloud. It’s not a question of consuming one service category exclusive of another, but rather what is the best way to combine the services (and other software) available to me via the cloud. This is why I think the ultimate model that developers will care about is best captured by the term “Services as a Platform”, as Cisco’s Lew Tucker and others have stated.
“Services as a Platform” bleeds together the concepts of SaaS, PaaS and IaaS from a developer’s perspective, and focuses much more on what can be consumed, rather than on how services are consumed. Services as a Platform drives the idea that composability trumps context (see here) and that “SaaS, PaaS and IaaS” just refer to different consumption experiences that often overlap each other.
Is there value in PaaS being able to automate core scalability and availability concerns for large classes of online software applications? Heck, yes. But AWS and others are adding service capabilities every day that begin to blur the lines between a fully formed framework and a completely self-composed “IaaS” option.
In the end, PaaS has always been a spectrum that ranges from pure IaaS (with some developer-focused automation thrown in) and targeted extension of SaaS and other context-specific software models. The need for PaaS to be a “separate catagory” in this sense is minimized by the value it actually brings in the broader context of cloud as a whole—as one (albeit important) service consumption interface.
InfoQ: Has the idea (and reality) of PaaS evolved since the early days of Heroku and Google App Engine? If so, why and how?
Krish: Yes, it has evolved since the early days. Early day PaaS was focused on solving the scale issue with hosted services. Most of the early day platforms were orchestrated using different services on top of compute fabric. In order to achieve efficiencies in scaling, the early PaaS offerings had restrictions on how the applications were architected. It gained some developer interests but enterprises were vary of the restrictions put forward by these PaaS vendors. With enterprise focussed PaaS, we saw an evolution away from the focus on scale and into developer productivity without many restrictions. We also saw some of the open source platforms using the container model which is important for application portability.
JP: PaaS has evolved as a concept and tool considerably since the early days of Heroku and GAE. I would classify those to be frameworks more than PaaS. Today, PaaS offers much greater control over scale and ability to incorporate new services. There is much more instrumentation in the platform that simplifies meeting certain service levels. However, the concept has definitely forked with the advent of private and public PaaS. Private PaaS focuses heavily on the experience of developer to deliver their application into the hands of IT operations and public PaaS focuses on enabling the developer to operate and manage the application in production.
James: At first, PaaS offerings attempted to be integral to the developer coding experience, providing fixed constructs for key services in a “take it or leave it” model. It quickly became apparent, however, that such a model simply didn’t work for the broader web developer market, and the early PaaS providers quickly revamped to accept a broader range of services, programming languages and deployment options.
Modern PaaS is much more about operations automation than about coding abstractions, which is incredibly important. Interfacing to services is standardized, but more from a connectivity and operations perspective than from a “dictating how services are used” perspective. The ecosystem work of both Cloud Foundry and Heroku are evidence that opening the doors to a highly composable model with an emphasis in operations automation allows for applicability to the widest swath of application models.
In the end, as noted in my A1, the lines between the types of automation the most advanced IaaS tools (namely AWS, Azure and GCE) will provide, and the “pure PaaS” offerings provide will be blurred to such an extent that service interface standards will begin to appear, I think. The value add that the PaaS platform offerings will provide will then be around consistency of interface and format, which will blow open the doors to an application platform marketplace across multiple vendors. That’s when we’ll stop talking about PaaS vs. IaaS, and start talking about what all of this has enabled.
Dan: Early PaaS was essentially application-level hosting for individual developers or small shops. Instead of buying server space from a hosting company and configuring the LAMP stack yourself, you rented compute resources from the PaaS provider and conformed to their design and deployment rules. Really, the killer feature of early PaaS was the Git-based deployment. Not only was it a cool feature, it shortened development time and played into the whole "we make things easier for developers" value proposition.
Today, the term 'PaaS' has been 'hijacked' by zealous marketers and operations folk. While that's mostly tongue-in-cheek, I do think there's some truth to it. One of the reasons we're having the conversation is that just about anything that automates deployment and scale is now called a PaaS. As such, we've see a wide spectrum of capabilities blended into a single category.
I think we'll see some fine-tuning of terminology over the next 18 months or so - starting with acknowledging that providers like Azure, Google Compute, Verizon, etc. aren't IaaS or PaaS providers - they're resource providers that offer multiple form-factors for consumption. With that, I think we'll see a renewed focus on enabling the service model I mentioned in my previous answer, and possibly a new buzzword.
InfoQ: These descriptions of PaaS are excellent, but still feel somewhat aspirational. Don't the majority of today's commercial (public) PaaS products offer web and application services, deployment tools, and application management tools in a managed fabric instead of Krish's "unconstrained environment" or James' "automation over coding abstraction" model? Where are you seeing movement today towards this ideal "Service as a Platform" that transcends classic PaaS constraints?
Dan: I think there have been bits and pieces of this vision in most of the traditional PaaS providers for some time now. I mentioned the add-on models from a bunch of providers in a previous answer. Apprenda's entire philosophy is built around deep integration with the guest applications. Azure offers a bunch of platform services like an ESB, multi-factor auth, etc. Buildpacks and cartridges are mostly used to bundle specific runtimes or plugins today, but they open the door to more robust composition applications. I could go on and on.
So why does the market appear focused on application hosting and management? Partially because it's early and managing an application is a necessary first step to a platform. Partially because these capabilities are the common thread among all the options calling themselves platforms (regardless of whether they offer the right level of abstraction as per Simon Wardley). And partially because the platform providers are evolving too. Nobody has a complete solution today - nor would I suggest we know what a complete solution should look like. Just look at the conversation here. We've got very similar philosophies - especially compared to the general public - and yet we all endorse slightly different end states and, I would imagine, very different ways of getting there.
As usage matures, as platforms evolve and more people see IT as a system rather than a bunch of disparate applications, I think we'll see the other aspects of PaaS move to the forefront. There are definitely companies acting like this today (see Netflix) but a lot of their tech is homegrown. Which is great, but doesn't diffuse very well. Application as business systems and PaaS should move to the mainstream together.
Krish: I agree with Dan. We are still in the early stages of PaaS adoption and it will change as usage increase. The biggest reason why PaaS is still seen as an extension of hosting is due to the early success of hosted PaaS services which were more tuned to meet the needs of customer facing web applications than a platform for IT rethink.
But it is changing as more and more enterprises embrace “modern PaaS” offerings, they realize that PaaS offers them a chance to completely rethink IT and transform themselves to meet modern day challenges. In this context, I like the idea of Jonathan Murray’s Composable Enterprise and I think he has the right prescription for modern enterprises in terms of how enterprises should go about building their IT platform. We are seeing more and more organizations embracing the approach and platforms with open architectures will help enterprises build such robust and flexible platforms.
Change in enterprise is slow and PaaS vendors haven’t done a good job of how their offerings can be used to build such modern IT platforms. But the tide is changing fast with sensors getting everywhere inside the enterprises and organizations realizing that they will be missing the benefits of big data if they don’t transform their approach to IT.
PaaS vendors need to send a clear message to enterprises. Modern day IT needs large scale automation but it can be done more efficiently with higher order abstractions. Plus, they need to do a good job of explaining to IT folks that abstractions at the higher layers of stack helps reduce the surface area for errors.
JP: Your question begs the alternate question, do we need to consider private and public PaaS independently. Ultimately, they could share a consistent model, but private PaaS indicates a much greater level of distinction between the responsibilities for operations and application development. Public PaaS is appropriately designed for teams that are designing cloud applications and will most likely be the team responsible for the management and operations of that application in production. So, I would not represent the prior descriptions as aspirational, but I agree you may not find all these features in a public PaaS offering.
InfoQ: JP brings up a distinction between private and public PaaS. Do you think there should be a difference between the characteristics of each, or are there capabilities more important in one environment than the other?
JP: For one thing, private PaaS must be supportable by the IT operations staff. That alone introduces a whole range of requirements for administration, monitoring and configuration that are handled by the public PaaS providers as part of their offering. Additionally, as I indicated in the last question, I believe the tooling is different. In a private PaaS I would expect the tooling to support a collaborative DevOps process between application development and IT operations, whereas public PaaS can focus their tooling on supporting and simplifying the process of application deployment and management for the engineer/developer.
Dan: The important distinction isn't private vs. public; it's middleware vs. operational service. The capabilities of the platform should be entirely separate from the compute services on which they run. That allows for a consistent application experience across any number of service delivery forms - from bare metal, to internally virtualized, to hybrid cloud, to fully public. The choice of application platform should not dictate the result of what should be a completely unrelated decision.
Obviously a company will make decisions based on whether it plans to operate a platform itself. And then things like machine administration and policy management become important pieces of the evaluation criteria that might otherwise be ignored. But that doesn't eliminate the need to manage the platform. It just changes who is responsible. To the platform vendor, it shouldn't matter whether it's an internal or external service provider fulfilling that function.
If the initial PaaS vendors didn't try to offer both the software and the underlying operating environment, I don't think the market would be begging for them to be tightly coupled. That we continue to conflate the two areas of responsibility is an unfortunate legacy, not a feature.
Krish: I agree with Dan. It is not about private or public. A well architected modern PaaS offering can offer the same experience when offered as a public PaaS or private PaaS (hosted on-premises). In the early days of PaaS when we had only hosted offerings by Google App Engine and Heroku, they had certain limitations on application design in order to achieve operational efficiency at scale. But it changed with newer PaaS offerings focused on enterprises. Whether we like it or not, hybrid cloud is going to be the reality for sometime into the future. Modern PaaS offerings try to bridge the distinction between public and private PaaS so that organizations can take advantage of both on-premises as well as hosted versions.
In this context, I would like to bring Docker into discussion. With the proliferation of containers, whether it is Docker or something else, the distinction between private and public will go away completely. Not only we can have comparable environments in both versions, we can also seamlessly port applications between public and private PaaS. In some cases, we may even be able to port across multiple platform offerings once they standardize on a container model.
InfoQ: PaaS seems to get brought up in context of other "hot" concepts like containers and DevOps. How do you see the intersection of these ideas?
Krish: For me, it is pretty simple. PaaS is the enabler of DevOps and Containers are the underlying standardized components (for certain PaaS offerings).
Dan: I think all the concepts you mention drive at the same goal; we're trying to improve the delivery of business services. DevOps is an approach to service delivery that recommends certain types of processes without necessarily dictating how those processes are implemented. Both containers and PaaS play nicely into the devops space - especially when you try to fit the devops concepts into a currently-siloed enterprise IT shop (definitely easier said than done).
Containers provide a few very nice capabilities - namely portability and application isolation - that may meet the needs of many organizations. That's just a subset of what a platform should offer - and, as Krish said, PaaS providers should consider a container technology to achieve those goals.
Paas is a more complete solution - and private PaaS in particular can encourage devops values in a place where the organization might not be structured in a way that's amenable to pure devops. In those cases, the platform can act as a lingua franca that gets developers and operations staff on the same page to ensure the highest quality service delivery.
JP: In my blog, "Without A Strong PaaS, ITaaS, DevOps & IaaS Fall Short," I make a strong association between using PaaS as a conduit to delivering a common shared platform between operations and development that formulates the DevOps pipeline of design, build, test, run, & terminate (decommission). Ultimately, PaaS is just a tool and like all tools, the secret is in knowing how to use it to obtain the outcome you desire. Having a production environment that is configured differently to the development environment has been the cause of poor quality, downtime and increased costs for years. The PaaS provides IT the application-centric focus required to be agile and effective for a non-IT-related business. It allows Ops to focus on the design and delivery of services in support of the PaaS and application development the focus on the business requirements. As for containers, they're a fantastic tool in support of this goal as they provide isolation of processes and data, which enables simpler delivery of the dev/test scenario.
About the Interviewees
JP Morgenthal is best described as "the voice of Enterprise IT". Bringing insight to the application of technology and the real world complexity of delivering for large and mid-sized enterprises. He is a senior information technology executive with more than twenty-five years experience and a unique combination of strong business acumen complemented by technical depth and breadth.JP is a recognized author and thought-leader in cloud computing and integration.
James Urquhart is Director of Product for Dell Cloud Manager (formerly Enstratius), the pioneering multi-cloud management environment. A long time distributed systems technologist, focused on virtualization, scalable architectures, and cloud computing, James was named a leading cloud expert by The MIT Technology Review, NextWeb and The Huffington Post, James frequently writes about cloud and distributed systems trends for GigaOm.
Dan Turkenkopf (@dturkenk) is currently a developer and analyst in the front office of the Tampa Bay Rays. Prior to finding his dream job with a baseball team, he worked as an application and cloud architect with Apprenda, CGI and IBM. He lives in Saratoga Springs, NY with his wife and four year-old twins. In his rare moments of free time, he spends his time reading about systems complexity, programming and enjoying craft beer, not necessarily in that order
Krish Subramanian is currently working as Director, OpenShift Strategy at Red Hat. At Red Hat, he is working with the OpenShift team in their quest to become dominant PaaS offering. Prior to that he was an industry analyst and founder of Rishidot Research. His focus areas include platform services, big data and open source