In the beginning, Platform-as-a-Service (PaaS) was created for developers, not for enterprises. Developers could deploy and test applications within minutes, not days, weeks or months. PaaS enabled developers to sidestep the need to invest in a platform of their own (or mess with jumping the IT queue). And Developers found it good. Agility and velocity became the primary drivers for moving workloads off-premise and into public clouds. As a result, PaaS rapidly became the preferred platform for cutting-edge startups and ambitious developers within small and large organizations.
Low introductory prices made it easy for developers and executives to adopt PaaS as their platform; and everyone enthusiastically embraced the agility and velocity they realized through PaaS. Even corporate IT executives saw the upside of PaaS: faster application development reflects well on them. But they saw a downside, too, especially as business units went off the reservation for PaaS suppliers. The lack of central control complicated management of corporate system and created potentially serious liabilities because the integration points were unclear and complicated. The first PaaS providers ignored all of these concerns, even claiming that incumbent systems “didn’t exist” because they weren’t focused on enterprises.
But these days, early PaaS success is making the enterprise adoption problem even more pronounced. Not only is adoption slow to arrive, the push to the cloud is also increasingly splintering development within enterprises, pushing “cloud sprawl” to its limits and making Enterprise IT even more resistant to PaaS.
There are various underlying causes for this state of affairs.
First, early PaaS providers priced their services to make them irresistible to start-ups and hackers – so that spinning up a couple of instances for an application was cheap. But the economics of early PaaS providers were not designed for scale. If an application was successful and went into production, the price of operating it went up much faster than with traditional infrastructure. It didn’t make sense for successful businesses to stay with PaaS, or for large enterprises to bet on PaaS. As a result, many developed a practice of using PaaS for dev/test only and then migrated off to go to full production deployments. And though early PaaS providers realized that they needed to make their services stickier with third-party and proprietary services, most haven’t made much progress on this front.
The second obstacle to PaaS growth in the enterprise is that platforms are typically confined to the public cloud, while most enterprises want the flexibility to move between public and private in a hybrid model. For example, an enterprise might deploy a short-lived marketing promotion application on the public cloud, but want to capture customer data from the promotion and store it in an on-premise database.
A new generation of PaaS is solving for this.
Simply put, enterprises are willing to wait on PaaS adoption until providers can resolve these issues. But a new generation of PaaS is rising up to meet their needs while simultaneously serving startups. The modern PaaS infrastructure is designed from the outset to handle large-scale deployments, rather than just a few apps or instances per customer. As a result, it can scale up to large-scale production deployments cost effectively.
The modern PaaS provider understands that big customers want multiple options without the burden of managing multiple providers. Today’s enterprise CIOs demand platforms that deliver agility and velocity and which work just as well in the public cloud as on-premise, providing the same insight, tooling, and control and governance. They want to enable and encourage their developers to dev/test in the public cloud and deploy production on-premise. They want a single PaaS provider that works as well in Ruby as it does in Java or Node or PHP or Ruby. And they want consolidated analytics and insight into all their PaaS activities. This set of requirements is the antidote to “cloud sprawl”.
Responding to these demands, the modern PaaS platform enables something akin to Java for the cloud: enterprise developers can write code once and run it anywhere, so migrations are fast and easy, even in the case of pulling deployments in-house. The benefits now open to enterprises via modern PaaS are enormous: physical servers can be placed in a customer’s data center and managed remotely; IT staff can be enabled to stand up platforms on dedicated hardware or on dedicated virtual machines within the enterprise’s architecture; enterprise IT can give developers in business units the same agility and velocity that drove those developers to the public cloud in the first place.
So, how can you distinguish modern PaaS from early PaaS?
To determine if a PaaS is modern or early, you can ask yourself the following questions:
Does it run just as well in the public cloud as it does in the private cloud? Can you choose to run it behind your firewall or run it in your existing public clouds? Can you migrate apps between public clouds (or from private to public or vice versa)? If the answer these these questions is a resounding “yes,” you’re looking at a modern PaaS.
Where early PaaS delivered the benefits of the cloud—agility, velocity, governance, security, provisioning, dev/test—solely to developers, modern PaaS delivers all these benefits to developers, small startups, and large enterprises alike. Modern PaaS platforms close the gap, making the cloud just as powerful for the CIO as it has been for the developer. By bringing agility and velocity into public and private clouds, modern PaaS brings back control and governance, ultimately mending the problems of “cloud sprawl” for everyone in the organization and finally delivering the initial promise of PaaS: making developers lives easier.