Gartner Blog Network

Why would we want a private PaaS?

by Richard Watson  |  May 3, 2012  |  8 Comments

Private PaaS is overcoming existential angst, to really keep me busy in terms of client inquiries.

For some people, private PaaS is an oxymoron: ‘how can it be a service if my organization hosts the infrastructure’? Admittedly, to date, most of the discussion about PaaS has been purely in terms of describing a public cloud service. But the “as a service” aspect of PaaS really depends on the service consumer’s point of view. From a development team’s viewpoint, when its interface is a set of platform services, the team couldn’t care less whether its infrastructure team or an external provider such as Microsoft supplies the infrastructure.  Below this level of abstraction, of course, the team must care for various reasons — for example, best practices for using Microsoft’s Windows Azure PaaS must be learned by developers, and applications must be developed according to the Azure programming model to exploit it fully.

Here’s a flavor of some of the inquiry questions I’ve been dealing with and my answers.

Client: “Richard, are you getting direct inquiries for private PaaS strategy advice at this point, or is it still very early?”

Answer:  Yes!  I’m getting plenty of client inquiries on building/buying private PaaS. I don’t think we are too early in this cycle at all to have a strategy. The inquiries tend to fall into several categories (with the most typical organization type in parentheses):

  1. Looking for PaaS to build a set of applications (both internal and customer facing) in a standard way (gaining productivity by using application services and useful infrastructure abstractions)
  2. Looking for PaaS to offer partners a consistent platform for building applications in their ecosystem (e.g. service providers, telcos, or vertically focused managed service providers).  For example, I spoke with a telco client recently, they are looking to build out a PaaS for their 3rd party ISV partners.
  3. Looking for PaaS to provide a path towards app platform consistency (dare I say it, governance) (e.g., large enterprises with a heavy custom-development bias). Coincidentally I’ve just got off a phone dialog about private PaaS with another a big financial group client looking at a CEAP. They are in an interesting position, having both a mature IaaS cloud and mature PaaS offerings for Java and .NET. They are now planning to rehost the Java and .NET PaaS on their IaaS cloud.
  4. Looking for PaaS to provide automation of development and test provisioning (e.g. large enterprises, major customer development orgs.)
  5. Looking to keep developers away from Amazon, Google App Engine, Heroku, etc. because of risk concerns (real or imagined)

Here’s another question from a recent dialogue.

Client: “In all my meetings last week, internal PaaS came up as a way of enabling a new balance of control and autonomy (e.g., for citizen developers). Are you seeing the same thing? Anyone actually doing it? How?”

Answer: Yes! I’m gathering the same messages in client dialogues – lots of people are attracted to the PaaS model but can’t or won’t commit to public cloud. And yes, people are really doing it.

As you say, the reason is a balance of control and enablement. Adding another application platform to an already sprawling platform environment is as unpalatable to enterprises as lock-in. Platform consolidation is a real concern for infrastructure managers. Their desire to consolidate the number of application platforms and variations is driven by the cost of managing complexity. Homogeneity and automation at the infrastructure layer (while maintaining choice at the language, tooling and framework layers) are the keys to lowering the cost of provisioning and managing those platforms.  IT infrastructure managers are constantly grappling with nonconforming projects (the “I’m special” mind-set) and the question of how to enforce platform standardization. Private PaaS offers a welcome tool for enforcing platform standardization: delivering real developer agility by giving developers what they want in standard platforms. When IT infrastructure can provide a set of standard application platform templates in an automated, self-service way, they gain insight into how developers are using the approved platform set. If they make platform configuration easy and quick to use, the developers will not feel like they are being governed. Successful governance is about making the right thing also the easiest thing.

It’s also interesting for me to see that how they’re implementing private PaaS varies significantly. For some, it’s a natural extension of their shared platform hosting model, for others it’s a way of validating their internal IaaS cloud works for a different audience, and for some more it’s the impetus they need to coalesce the 5 different departments responsible for putting together app stacks.  A small band of mavericks are leapfrogging internal IaaS clouds, jumping straight to internal PaaS.

It’s also important to grasp that private PaaS is not all a developer /operations kumbaya. Let’s not forget that major platform vendors who have had a hard time pushing public PaaS (especially with the change required to their business model, or were just late to the party) are also pushing internal/private PaaS today. Some of this is undoubtedly vendor-driven.  However, I think that flavor of internal PaaS the incumbent platform vendors are pushing is the ‘application stack automation’ flavor – the end of the spectrum I call “earth-born migrants” in my recently published paper assessing private PaaS [see note 1 below].  Most clients I’ve spoken to see through that approach.  They are generally more interested in basing their PaaS on CEAPs (Cloud Enabled Application Platforms). This means lots of interest in Apprenda on the .NET side and VMware vFabric, GigaSpaces, Longjump, Cloudsoft, etc. for Java.

Here’s the summary and an excerpt from the opening of the paper:

Summary: Organizations are turning toward private platform as a service (PaaS) to gain the benefits of PaaS while avoiding the business and technical risks that come with public cloud computing. Private PaaS allows IT departments to retain control of security and performance characteristics while providing their developers with an agile environment for solution delivery. Enterprises also look to private PaaS as a lever to standardize application infrastructure. This assessment discusses the drivers for private PaaS and different implementation approaches and challenges that organizations will face in this pioneering stage.

Organizations are busy building private Infrastructure as a Service (IaaS) clouds. These initiatives are largely driven by infrastructure and operations teams. Many development teams are left scratching their heads, wondering about their role in internal cloud initiatives, and what it offers for them. Infrastructure people puzzle developers with their claims of instant virtual machine provisioning. Why then, can it still take weeks to set up a complete development or test environment for an application on-premises? This is especially puzzling when they can commission a new environment from a cloud provider in a matter of minutes. Typical lead time is measured in weeks: ordering and provisioning hardware, installing software, migrating code and databases delays a project and limits software delivery agility. The development team’s software development process can be agile, but if overall delivery agility is hamstrung, this may be wasted.

Is that you?  An agile dev team and creaking IT ops?

Before we all get carried away thinking we can offer a private PaaS that’s better than, Windows Azure, Google App Engine, Engine Yard, and the others, let’s keep another very important point in mind: You own and manage the infrastructure that underlies a private PaaS.  This implies a sophisticated standard of IT operations to keep the PaaS running (regardless of the neat abstractions a CEAP may provide).

And one more thing.  Here’s a head scratcher. I’m doing a presentation at our Catalyst conference in August based on some of my recent paper, newer market research, and client experiences. The session is titled “Do you need an internal IaaS cloud for internal PaaS?”.  Spoiler alert!  My first slide will be busting the myth of the *aaS cloud ‘stack’. Has the term ‘stack’ ever bothered you when people describe the ‘troika’ of IaaS, PaaS, and SaaS?  I feel strongly (as others do at Gartner) there is no “stack” in cloud computing, because the word stack implies a dependency of each layer on the layers below. In other words, I don’t agree that in order to have PaaS you must also have IaaS. So, please come and participate in the debate in the “Building internal clouds” track at Catalyst.

Now, over to you: I’d really like to start a conversation about this rapidly emerging research area.  Are you implementing private PaaS? Why? And how?  Please leave a comment with your thoughts.

[1] The Gartner for Technical Professionals (formerly Burton IT1) client subscriber URL is here: 



Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research

Category: application-development  paas  private-cloud  

Tags: cloud  paas  

Richard Watson
Research VP
5 years at Gartner
21 years IT industry

Richard Watson is an analyst in Gartner's Technical Professionals Research Service. He advises clients on cloud computing, application architecture, and application platforms. ...Read Full Bio

Thoughts on Why would we want a private PaaS?

  1. Richard, great post! I think you’re post reflects what we see in the field. Not surprisingly, we see that enterprises in the Global 2000 with strong Central IT capabilities look at private PaaS as a mechanism to achieve an internal service provider model, and those without strong central IT looking to private PaaS on an LOB basis for transformational value among certain application profiles.

    I wouldn’t be surprised if private PaaS (and private cloud, in general) drives most organizations toward a more centralized IT organization. This approach would drive ultimate efficiency, and in cases where strong central IT doesn’t exist, one of the primary blockers is technology.

    Richard, do you think that private PaaS will help bolster the value of a strong central IT organization?

  2. Chris Haddad says:

    Richard, the five use cases cited are pragmatic. We see significant client interest in #2, building a domain specific ecosystem platform. Our clients use WSO2 Stratos and WSO2 AppFactory to deliver a private PaaS with automated governance, service level management, metered consumption, and DevOps tooling. The environment enables ecosystem partners to deploy their own projects within the PaaS environment.

    I have create a PaaS evaluation framework for CIOs and architects [1], and a blog post describing our emerging WSO2 AppFactory product [2].



  3. Richard Watson says:

    Thanks for your comment, Sinclair. You raise a couple of important points I want to respond to:
    1. Agree 100% there’s no single use case for PaaS. The list I included in my answer to the 1st question above is biased towards my clients’ demographic: architects within G2000 companies and governments. Enabling citizen developers in lines of business is equally appealing to organizations with backlogs of applications their full-time programmers will never get to.
    2. I do take issue with your point that technology is a primary blocker to having a strong central IT organization. In my experience, other factors determine this. They are a heady mix of industry sector, specific operating model, politics, and management. I think we probably share experience in investment banking where IT control is more distributed than other industries.
    3. The pendulum of outsourcing/insourcing is right now swinging away from central IT organizations. Many I speak to are rethinking their role in this great IT transformation – in which cloud is only one part. Some are focused on becoming brokers of internal and external services, rather than risk becoming irrelevant.

    To your question, my short answer would be yes. Organizations with strong central IT – and that minimum operations sophistication – can pull further away from their competition with private PaaS, but expecting it to fix a dysfunctional IT function is asking way too much of any technology. IT execution inequalities will remain. Or, as Leonard Cohen said, “The poor stay poor, the rich get rich / That’s how it goes / Everybody knows”.

  4. Angie Hirata says:

    Richard: Good view into the real-world of how organizations are seeing private PaaS. (Full disclosure: like Sinclair and Chris above, I am also with a private PaaS vendor – here at ActiveState we offer Stackato, a CEAP technology.)

    In our work with both centralized IT teams and individual business units, we see evidence of your point #5 above: Developers are demanding Google App Engine- or Heroku-like services within the “rules” of internal corporate IT. I see this in the same lines as other technologies that are driven by the “consumerization of IT” (like mobile). Developers, as consumers, have all tried public PaaS services where they are able to get near one-click deployment and app management capabilities that they try at home at night; but then are frustrated when they go to work and are handcuffed by corporate IT because they’re not allowed to use those services, and it takes days or weeks to get their app deployed.

    IT, on the other hand, has been accustomed to having control over systems. But with mobile, SaaS, IaaS, and now PaaS offerings targeting individuals, IT is recognizing the challenge of maintaining that control while still giving freedom to Developers. Devs tend to resist control and fight for their freedom, but in today’s age of services exposing choices, IT needs to be even more mindful of giving those Devs the freedom and choices to innovate and create.

    Sinclair ponders whether private PaaS will help bolster the value of a strong central IT organization. I think what PaaS can offer is greater respect for central IT and Devs & IT getting along better by giving Developers the freedom of instant access to what they need to get their jobs done.

  5. Brian Seltzer says:

    Richard: You’re hitting the nail I’m holding right on the head. We’re early in our private IaaS deployment and it’s obvious that although it’s handy to reduce administrative overhead when deploying traditional hosting instances, it doesn’t help much at all when trying to provide complex development platforms. I see private PaaS as a must have, while IaaS and public cloud access are nice to haves. Now, what’s the right way to build or buy a private PaaS? That’s the real head scratcher…

  6. […] example, in a recent blog post, Gartner Group research director Richard Watson asks “Why would we want a private PaaS?” Apparently his clients do. He writes that “Private PaaS is overcoming existential […]

  7. […] example, in a recent blog post, Gartner Group research director Richard Watson asks “Why would we want a private PaaS?” Apparently his clients do. He writes that “Private PaaS is overcoming existential […]

  8. Chris Haddad says:

    Richard, you mention organizations are “Looking for PaaS to provide a path towards app platform consistency (dare I say it, governance)”

    Do you see the organizations choosing a PaaS environment that includes governance practices? If a PaaS does not offer governance workflow, must organizations spend a considerable amount of time integrating PaaS services into their governance processes?

    At WSO2, we have been working with clients to deliver a radically new approach that is lightweight, cloud based, and integrates the development lifecycle right into the cloud, bringing superb agility (and enterprise required controls). The productization is called WSO2 AppFactory, which merges software development lifecycle governance and workflow with PaaS environment provisioning.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.