There is a lot of confusion about "PaaS" and what it means. The definitions are vast, vague and varying. The market and the media are understandably confused.
Different Solutions. Different Audiences.
The first obvious reason for confusion is that public PaaS and private PaaS are completely different solutions with different audiences. But it is worse than that...
Examples of "PaaS" solutions range from Salesforce, Heroku, Cloud Foundry and thin wrappers around Docker. All of these are vastly different in what they offer. Each targets very different audiences, but all are considered "PaaS".
You only have to Google "What is PaaS?" to see that the results cover all the above examples. Each type of solution has its own definition, which shines light on its particular feature-set. The common-denominator, that they should all share, is lost in the noise when PaaS is X plus Y and Z, depending on who you ask.
PaaS is Not Public PaaS
Public PaaS came first and it set out an expectation of what "PaaS" is, which differs from private PaaS. Public PaaS vendors define "PaaS", not "public PaaS", in a way that often also encompasses IaaS. This is understandable, because they are selling both in one package. A customer of public PaaS need not know or care what the underlying infrastructure is. This is true at least at the developer level. It is simply the solution provided by their public PaaS vendor. As far as the customer of public PaaS is concerned, it's turtles all the way down.
With private PaaS, customers do care; and they should. For software developers there may be little difference between public and private, depending on the depth of integration and complexity of their application. To Operations, it is different story. They own the PaaS, make it what it is, and they are the ones that keep it ticking like clockwork.
Distinct PaaS Layer
The expression "Public PaaS" is, ironically, only used in the context of talking about private PaaS. Google it and you will find it is only mentioned by vendors of "private PaaS" and commentators on "private PaaS".
Private PaaS more clearly defines a distinct PaaS layer. When private PaaS came on the scene, the layers of PaaS and IaaS had already become blurred and fused together by the story of what public PaaS could offer.
Most opinions of what the private cloud can offer are extrapolated from what the public cloud can offer. We have seen public PaaS vendors blur the lines by including close-to-IaaS offerings, and public IaaS vendors offering bits and pieces of PaaS as features. The public cloud is a moving target in this rapidly expanding and evolving space.
Easy Layman Terms, But Wrong
We often meet people who are not familiar with private PaaS, but are familiar with a public PaaS, like Heroku. The easiest way to describe a PaaS technology, like Stackato or the Cloud Foundry open-source project, is to say "it is like Heroku". But is it? From the developers point-of-view, pushing their code, provisioning databases and scaling their application, it is. For the IT department or Operations team, who would not see a correlation between their own infrastructure and a public PaaS, it is less easy to make the mental leap. Using this definition as a starting point; there are too many missing pieces.
Even to the end-user developer building enterprise solutions, the parallels are becoming less obvious with public PaaS and private PaaS. Private PaaS is focused on large enterprise. Even though public PaaS would obviously hope to attract more large customers, this is not where their existing customer base currently is.
The feature-set offered when the users are individuals or small teams is different to what you can offer when a whole organization is using the platform. ActiveState sees this and is pushing forward with collaboration features, such as the Activity Stream.
Most public PaaSes were originally focused on specific languages and simple applications, such as PHP and Ruby-On-Rails. These were not necessarily inline with the large and complex legacy applications that many large enterprises manage, so were dismissed by those enterprises.
Private PaaS, on the other-hand, is generally very flexible and can support whatever software stack is required. It can also utilize whatever infrastructure resources you throw at it. What is more, it does 90% of what most Operations have to do on daily basis in terms of resource allocation and orchestration for their software applications.
Gartner defines the term "aPaaS", where "...users deploy applications on an application platform running in the data center of the service provider". This is public PaaS.
Private PaaS solutions, such as Stackato, are defined as "CEAP" (Cloud-Enabled Application Platforms), which are deployed to form an internally run private PaaS or (public) aPaaS.
Gartner also distinguishes "high-productivity" PaaSes, such as Orangescape and Saleforce, and "high-control" PaaSes, such as Cloud Foundry or Stackato.
Unfortunately these terms are still only used in reference to Gartner literature, even though they have been available since 2010.
PaaS is still a young market and the terminology, as well as the technology, will evolve over time. The most important thing is a common understanding and clear distinct terms to help with adoption. Confusion is only a barrier to adoption. Anyone actively involved in PaaS knows it is a clear must-have piece of your internal IT infrastructure for gaining a competitive advantage.
As Gartner recommends to CTOs, IT planners, technology architects and heads of application development in user organizations:
"Invest in cloud application platforms. [...] Your visionary competitors are likely to deliver new kinds of services and gain competitive advantage by adopting aPaaS and/or CEAP technologies." - Gartner