I just returned from attending the Cloud Expo in New York City this week. The conference was dominated by private and hybrid cloud topics. There were several private Platform as a Service (PaaS) vendors attending whom I spent a great deal of time talking to as I walked the floor. It seems these days that many enterprises default to private and hybrid clouds and therefore insist on private PaaS as well. It is critical that consumers of PaaS services understand the pros and cons of both public and private PaaS before making a commitment to a PaaS deployment model.
Public PaaS
Public PaaS solutions are platforms that run on the public cloud. The first PaaS solutions in the market place dictated both the stack that the code would be written in and the location of the datacenter that the code would be run on. For example, Force.com requires a proprietary language called Apex, and all of the Apex code runs on Force.com’s datacenter. Google’s PaaS forces developers to write in Python and runs the code in the Google datacenters. Microsoft’ PaaS requires .NET and runs in their datacenters. The downside of these PaaS solutions is if the customer refuses to put their data in the public cloud, their choices are to either use a private PaaS or to architect their solution to leverage APIs from within the public PaaS to access the data inside their datacenter. This strategy can create latency issues, network issues, and other less than optimal performance issues.
The big advantage of public PaaS is that the consumer of PaaS services does not have to manage and maintain the infrastructure or the application stack (operating system, application server, database, and programming language). The PaaS provider does all of this on behalf of the customer. The customer simply focuses on building their application, which allows the developers to become more agile and get to market faster.
To sum up public PaaS, the tradeoff is giving up control in return for simplicity and speed to market. For startups and SMBs, the control issues were usually not a show stopper and these early PaaS solutions were eagerly adopted. However, the enterprise customers were reluctant to join because they had a number of development stacks and did not want to be forced into a single stack. In addition, many did not want to run the PaaS outside of their datacenter.
Over the last few years, a number of PaaS providers have emerged with the goal of solving the control issues that early PaaS providers did not address. Solutions like Cloud Foundry, Open Shift, Apprenda, and Stackato were born. These solutions allow customers to deploy PaaS anywhere, public or private. In addition, many of them support multiple stacks like Ruby, Python, PHP, Java, Node.js, and .Net.
Private PaaS
These newer generation of PaaS solutions offer greater flexibility and control for customers. Customers can now use these PaaS solutions for private, public, or hybrid clouds. In addition, customers can supply their own hardware and are no longer constrained to only the machines that the public cloud providers offer. Some customers choose to put certain high performance workloads on bare metal machines while putting other workloads on virtual machines which private PaaS providers allow. Private PaaS also allows companies to keep their data in their data centers if it is undesirable to put sensitive data in the public cloud.
But what the private cloud giveth, the private cloud taketh away. With private PaaS, customers are back in the infrastructure business again. They still have to procure, install, manage, and patch physical servers. In addition, they now have to patch the PaaS itself. Some of these PaaS providers do a good job of providing tools to make the infrastructure and PaaS management easier, but the reality is the customer must not only manage the application stack, but they must manage the infrastructure and the PaaS solution. That is an enormous price to pay to avoid the public cloud.
Developers’ view
Public or private, the developers’ life is almost unchanged when it comes to building software on a PaaS. The developers build on top of the PaaS and don’t need to worry about the infrastructure or the application stack. The only differences are the developers have more choices of the type of infrastructure to run on in a private cloud and the developers may have to wait on system administrators for installing and patching infrastructure and application stacks. Once again, customers get more control and flexibility, but sacrifice time and agility.
System administrators’ view
With public PaaS, there is very little systems administration work at all. The entire infrastructure layer and application stack is managed by the PaaS provider. A system administrator may or may not be involved in the deployment process or the process of managing access to the PaaS. Often the deployment process is performed by development, and the access management is performed by operations or even by the users themselves. With private PaaS, the system administrators are performing the same basic administrative tasks they have been performing in their datacenter for years. In fact, they actually have to do more now because now they must administer the PaaS.
Summary
Private PaaS is often preferred over public PaaS in the enterprise. It is extremely important that enterprises evaluate the trade-offs between public and private PaaS. As it so often does in the enterprise, it comes down to how much control the enterprise wants to have. If they must dictate what infrastructure is used or they must keep their data inside their walls, they will take on a large number of system administration tasks that are not required with a public PaaS. The cloud is all about agility. Choose wisely.