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):
- 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)
- 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.
- 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.
- Looking for PaaS to provide automation of development and test provisioning (e.g. large enterprises, major customer development orgs.)
- 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 Force.com, 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.
 The Gartner for Technical Professionals (formerly Burton IT1) client subscriber URL is here: http://www.gartner.com/resId=1996215
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.