PaaS software and services defy easy compartmentalization. PaaS alters how software developers create applications,...
but it also triggers changes in how IT designs and provisions infrastructure in support of custom enterprise applications.
Complicating clear categorical definitions is the fact that platform as a service (PaaS) is a moving target. As the least mature of the three XaaS varieties -- behind software as a service (SaaS) and infrastructure as a service (IaaS) -- PaaS is an area where companies and products come and go, merge or get acquired, and create new features faster than the enterprise IT buyers can assimilate the old. IT leaders can be excused for tuning out the whole PaaS concept since it's largely targeted at developers, where the discussion can quickly turn into arcane debates over technical minutia. Further sowing confusion is the interchangeable use of the term PaaS: Rentable services running on shared public clouds and buyable software installed on dedicated private servers are PaaS examples. For example, some leading PaaS vendors like Appenda, HP Enterprise, Pivotal and Red Hat specialize in on-premises software.
From this muddle, two important yet distinct concepts emerge: PaaS software primarily changes the application development process, as well as infrastructure deployment decisions. As with other cloud options, there are examples where PaaS can replace existing deployment models and examples where it opens new options to the enterprise.
What is PaaS and how does it affect IT?
It's easier to define PaaS by what it's not (IaaS or SaaS), but broadly speaking PaaS is a set of application, data or developer components delivered as self-service, shared services. PaaS capabilities are more complex than basic VM instances or object storage and include things like database tables, big data storage and queries (e.g., Hadoop, MapReduce), middleware services, software configuration management, mobile back ends, application programming interface (API) gateways and management, user and group identity directories and access controls. Delivered as higher-level services, PaaS software insulates developers both from the details of infrastructure configuration, provisioning and management and the coding required to build low-level services and APIs. In this sense, building applications with platform services is akin to creating complex financial models with Excel macros or data query front ends with Access or Visual Basic instead of coding in C# using the native Windows API.
Abstracting the application development components from their implementation means there are various PaaS examples to follow. The typical PaaS implementation is a cloud service that provides a suite of platform services delivered from multi-tenant infrastructure as a usage-billed service, often, as with Microsoft Azure and Google Cloud Platform, as part of a larger IaaS offering. However, PaaS software stacks can also be built on dedicated private systems and delivered as an exclusive service to internal developers. In this example, PaaS software is often layered on a virtual infrastructure stack like VMware vSphere, OpenStack or Amazon Web Services, however some products like Apprenda act as an application like Internet Information Server or Apache Tomcat running directly on the server OS.
PaaS stacks include such a wide variety of features targeting different constituencies and use cases that it's difficult to make direct comparisons. The easiest way to compare PaaS examples is to examine specific features, service tiers and pricing models of the major vendors. No one product is likely the best fit for every application. Some, such as Azure, Google App Engine or CloudFoundry, are suited for new application development. Other PaaS vendor examples -- Force.com and SAP HANA Cloud Platform -- are better for augmenting existing software with custom features.
PaaS examples: What works and what doesn't
PaaS works best from scratch, designing applications around the capabilities available on a cloud service. Best Buy's experience with Google App Engine is a good example. Best Buy wanted a way for customers to share wish lists with their friends. Its first try took eight developers over a year to create a functionality that buckled under heavy use and was hard to change. Best Buy turned to PaaS, rewriting the code from scratch using about one man-year of developer time: one eighth the original effort and 11 weeks start to finish. According to Best Buy, using Google's PaaS requires one-fourth to one-tenth of the resources that its in-house functionality consumed.
The biggest mistake when using PaaS is trying to force-fit legacy applications, built around mainframe or client-server systems, into a service-oriented model. PaaS works best when you don't blindly port an existing application onto the platform and model, but instead redesign the requirements around its service-oriented capabilities using a cloud-native design. The benefit of PaaS over IaaS in this scenario is access to higher-level application services that by design and testing are already well integrated.
What PaaS means for IT
The operational model of a PaaS varies between public and private platforms. For public PaaS, it's identical to using IaaS: IT is out of the systems management business and instead manages services and provisions users via the vendor's admin portal. While PaaS offerings are typically self-service, IT organizations can -- and many do -- set limits on usage and access via user, group or role-based policies.
As the Best Buy example illustrates, IT administrators no longer manage systems or deploy and configure servers. One survey found cloud adopters in general spend significantly less time on scheduled and unplanned maintenance, storage and quota management, data recovery and upgrades than data center IT managers. This leaves more time to collaborate with business units on new services and applications.
In contrast, a private PaaS operates like other large enterprise systems, where IT runs the hardware and software. Since PaaS stacks are relatively complex, there's usually a domain expert responsible for the software, similar to how a database administrator runs databases.
In either scenario, IT will need to have people and processes for managing and monitoring PaaS resource usage, performance and, with public PaaS, spending, availability and service-level agreement compliance.
Sort out the PaaS options available
PaaS picks up where IaaS leaves off
Here's how to bridge IaaS to PaaS