In the big picture of software development and computing, Platform-as-a-Service is still in its infancy. But because it is tied to “the cloud,” people seem to think it’s older than it really is.

PaaS confuses people and fills them with fear of vendor lock-in because the early platforms are tied to specific infrastructures. The overwhelming majority of people using the Force.com platform, for instance, are those working with Salesforce’s CRM system.

(Related: Which PaaS is for you?)

The only alternative up until now has been the private cloud, which allays fears of security that comes up short and of the vendor lock-in issue. Unfortunately, it doesn’t scale, and the economic benefits of a true cloud solution have yet to be proven internally.

So, just where does this leave PaaS going forward? According to Ben Grubin at Boston-based Cloud Technology Partners, a truly effective PaaS is like what the .NET Framework is to C#: You can write the code yourself in C#, or you can take advantage of the broader framework, with the ability to reuse software components between apps and to integrate with outside resources and services. “It becomes a migration target more than what Force.com was,” he said. “There’s no ‘Write your app for MY platform.’ ”

Amazon is the cloud leader because it has executed this exact strategy perfectly. You can use Amazon Web Services in your applications—which can be reused in other applications—or choose from a host of integrations. “They are offering phenomenal service and they’re dominating the market, but not in a way that locks you in,” said Grubin.

So, while a number of PaaSes exist, each with their own benefits, there are commonalities among them. They all rest on traditional storage and virtualization. We’ll see an explosion in PaaS, Grubin believes, when there is standardization in the platforms. This will allow folks to move their applications from one PaaS to another without (significant) modification, and still leverage security and scale. That’s an advantage PaaS has over container solutions such as Docker, in which you have to maintain the entire stack to port an application. Also, it only works on Linux for now.

Yet Grubin admits most organizations are nowhere near ready to have this kind of conversation yet. We still haven’t seen a tipping point for Infrastructure-as-a-Service, he said, so the tipping point for PaaS is probably another five years out. Companies are still having a hard time getting a handle on what their data center costs even are, what with real estate, hardware, utilities and human resources to be factored in. But they know one thing: They don’t want to have to manage those things that are not core to their businesses any longer.

“Enterprises are not talking about cloud adoption. They’re talking about data center consolidation. They want to get out of the data center business,” Grubin said. “But the biggest problem they have is deciding what to move” out of their data centers and into the cloud.

Millions of enterprise workloads remain in data centers, where servers are 30% to 40% underutilized, and that’s if they’re virtualized. If not, they’re only using 5% to 7% of capacity. “That’s a lot of machines making noise, and generating heat, and doing next to nothing,” said Grubin. Take, for example, servers that spun up for a project two years ago that were never decommissioned, just sitting there, waiting for a new workload that will never come. And, because the costs of blades and racks went down, cheap hardware has led to a kind of data center sprawl. Now, he said, “It’s too big a problem” to untangle.

For developers, a key aspect to writing applications for the cloud is understanding the choice of end target. “Where I write the app has a lot to say about maintainability, and the cost of running it in the long term.

“The future is not resilient hardware; it’s resilient software,” he continued. “In the old days, you needed hardware resiliency, because when the infrastructure went down, the app died. Today, apps have to be architected to know how to be resilient, so if the server dies, it can run on other nodes.”

Developers will need to begin designing for application-layer resiliency once PaaS reaches that tipping point. But it’s something to start thinking about now.

David Rubinstein is editor-in-chief of SD Times.