The Road to PaaS: Understanding Your Post-IaaS Options

We’ve generally come to see infrastructure-as-a-service (IaaS) as the foundation for a cloud, where compute, network and storage capacity are provisioned and scaled dynamically to automatically adjust resources to fluctuating demand patterns.

The result? Dramatic reductions in the time and effort required to provision and scale infrastructure, which impacts business agility, operating costs, performance and resiliency.

It’s a significant leap forward toward the sort of zero-latency responsiveness that business lines need from IT, taking a process that once took weeks or longer and compressing it to minutes.

But IaaS is just the first step on the journey to the full realization of cloud’s potential.

That potential lies in feature-rich business services and complete application stacks, which are provisioned and scaled dynamically — just like the infrastructure enabled by IaaS.

Looking Beyond IaaS

Today, IaaS abstracts away the complexity of underlying infrastructure, but it still requires the old methods for installing, configuring and managing software.

So-called platform-as-a-service (PaaS) promises to abstract the complexity of the next layer of the stack — the enabling software like operating systems, databases and other middleware. This automates everything but the application tier so developers can focus on delivering working application code, which — let’s face it — is the only thing that business lines care about anyway.

The Road to PaaS

PaaS is an enticing proposition that has generated a lot of market buzz.

But PaaS forces tradeoffs and it shouldn’t be seen as a one-size-fits-all proposition.

To understand, I like to draw the distinction between what I call “Silicon Valley PaaS” and “Enterprise PaaS.” The majority of the discussion in the market today revolves around the Silicon Valley PaaS pattern, which is a truly abstracted “black box” approach to software platforms.

This form of PaaS exposes a set of standardized services to which you write your applications, completely sheltering developers from the underlying complexity below the PaaS abstraction.

It makes a lot of sense for brand-apps built with modern frameworks like Python and Ruby in greenfield development environments that are highly standardized.

This approach to PaaS often makes sense for Web 2.0-style companies without the generational baggage of older application portfolios and layers and layers of technology acquired over time. It may also make sense for large enterprises that, under the pressure of time, turn to PaaS to deploy certain departmental and deadline-driven campaign applications.

From Silicon Valley to Main Street

Of course, it’s simplistic to think of traditional enterprises as larger versions of SMBs or Web 2.0 companies. Enterprises are complex, bureaucratic, often regulated beasts that are bound by deep historical IT investments.

That’s why starting from scratch with a fully standardized PaaS platform probably doesn’t make sense for the Fortune 500. The Silicon Valley model doesn’t necessarily apply on Main Street.

Why? First, while enterprises do release new apps, the vast majority of their effort is expended on evolving the current applications that run their business. The Silicon Valley approach to PaaS would require these applications to be rewritten to the services exposed by the PaaS framework.

Next, Silicon Valley PaaS dictates extreme standardization of operating systems and other middleware that doesn’t even make sense in concept for large enterprises, which often have incredibly diverse operating environments resulting from distributed purchasing decisions, mergers and acquisitions, reorganizations and decades of business requirements run amok.

Understanding Enterprise PaaS

While driving toward standardization is certainly a goal for most enterprises, the level of standardization dictated by Silicon Valley PaaS isn’t realistic for most large companies.

But that’s not to say that enterprises will pass on PaaS. The Silicon Valley model may not suit all their needs, but enterprises must still find a graduated path to delivering PaaS-like value.

That’s the role of what I call “Enterprise PaaS.”

This approach deeply automates a series of platform stacks that are available for on-demand provisioning. Rather than forcing applications to conform to a standardized set of services exposed by a single PaaS layer, this approach offers some relief for enterprises that are not ready to make the leap to extreme standardization.

Enterprise PaaS allows IT to define custom stacks that conform to varied application requirements. These pre-configured, ready-to-run stacks are published to a service catalog where developers and business users can request and provision them on demand.

Here’s what’s happening behind the scenes, courtesy of deep policy-driven automation:

• Provision compute, network and storage infrastructure
• Install OS and middleware software and update licensing servers
• Discover and resolve all software dependencies and configure the stack
• Configure network and security layers
• Integrate with release and continuous integration for controlled handoffs and updates

The result is an environment that enables much of the speed and efficiency of Silicon Valley PaaS, while allowing relief from extreme standardization and without forcing application rewrites.

Interestingly, we’re seeing the emergence of PaaS platforms like Cloud Foundry, which attempt to thread the needle by enabling existing middleware services to be incorporated into the PaaS deployment model. This sort of thinking promises a bridge between the present and the future.

In the end, the journey to a cloud operating model begins with infrastructure and ends with the application itself. In between is the software platform that allows the application to run.

In this manner, if you’re building a cloud, PaaS must be part of your thinking.

But how you think about PaaS, however, will vary depending on who you are.