Will IaaS and PaaS converge?

 

 

tl;dr version: No per Betteridge's Law of Headlines (in many cases). But if you want a more nuanced take on this question, you'll need to read on.

Some history

The definitions that we use for the layers of cloud computing today--Infrastructure-as-a-Service (IaaS), Platform-as-a-Service(PaaS), and Software-a-Service(SaaS)--are enshrined in a remarkably thin document, NIST Special Publication 800-145, which wasn't finalized until October 2011 by which time many aspects of cloud computing were in full swing. However, this publication has been influential nonetheless because it began life as a draft in 2009 and, furthermore, was developed together with a large number of users and vendors. Indeed, NIST noted upon the finalization of the publication that "While just finalized, NIST's working definition of cloud computing has long been the de facto definition."

Here's how NIST defines IaaS, PaaS, and SaaS respectively: 

[IaaS] The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

[PaaS] The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

[SaaS] The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

It's worth noting at this point that the PaaS service model was a relatively late entrant to the discussion. For example, when I wrote a research note that took a crack at defining cloud computing architectures at the beginning of 2008, I only discussed IaaS and SaaS. The on-demand services these provided were clear. IaaS provided compute, storage, networking and related services--server-like things. We already had a working example in Amazon Web Services (AWS)--which was also starting to expand beyond basic infrastructure with SimpleDB. SaaS was at least equally well-understood; it was a Web app. [1]

The point of this history lesson? Two-fold.

First, it's to point out that the widely-accepted NIST cloud computing definition focuses specifically on the level of abstraction presented to a generic consumer. Secondly, it's to show that PaaS is defined, at least in part, as something that sits in between IaaS and SaaS--which were far better understood by way of concrete examples like AWS and Salesforce at the time than was PaaS.

How do IaaS, PaaS, and SaaS relate?

The significance of PaaS filling the space between an IaaS and a SaaS is that it touches both of those abstractions. Although a PaaS like OpenShift by Red Hat can sit on bare metal, it can also take advantage of flexible IaaS infrastructure. I'm not going to get into all the details of how OpenShift might use the OpenStack IaaS, for example, but I'll touch on what some of those integration points are and how they might evolve in a bit.

It's also worth observing here that simply thinking of PaaS as a higher level of abstraction than IaaS for a generic consumer of computing resources of various types misses an important distinction. PaaS presents an abstraction that is primarily of interest to and used by application developers. IaaS can also appeal to developers seeking more options and control of course. But a PaaS like OpenShift focuses on giving developers and/or DevOps the tools they need and then getting out of the way. IaaS is infrastructure--and therefore often more focused on system admins who are supporting developers (whether through a PaaS or otherwise) and other consumers of business services. This will increasingly be the case as IaaS, or something close to it, increasingly becomes how computing infrastructures are built--whether at a cloud provider or in an enterprise.

SaaS also touches the PaaS layer. This interface typically takes the form of what analyst Judith Hurwitz refers to as a PaaS anchored to a SaaS environment. Another way to think about this is that software is increasingly expected to surface APIs so that users can extend and integrate that software as they need to. These APIs and surrounding tooling may constitute a sufficiently rich and extensible environment to be considered a PaaS (as in the case of Salesforce).

The blending of IaaS and PaaS

Given the relationship I've described, it's reasonable to ask whether IaaSs won't just add abstractions until they're PaaSs or whether PaaSs won't just build in the infrastructure they need until they don't need a discrete IaaS layer. 

This will happen in some cases. Azure is an example of a PaaS offering that is a monolithic stack (and which can now also run operating system images as well as .NET applications). A variety of AWS services go beyond the infrastructure layer (databases, Hadoop, Elastic Beanstalk).

However, as discussed above, IaaS and PaaS often address different types of consumers--who may have different types of requirements--so there will likely be benefits  in many cases to having a PaaS that is discrete from (but integrates well with) an IaaS as well as other types of software.

How might this integration work with OpenShift and OpenStack?

OpenShift, like other PaaSs on the market, uses a form of Linux containers. (Red Hat's now collaborating with Docker on containers; Docker is planned for inclusion in Red Hat Enterprise Linux 7). They're lightweight and quick to spin up and spin down. However, to the degree that OpenStack and OpenShift don't talk to each other, neither has any visibility into optimization possibilities. However, as Red Hat's Matt Hicks notes, if a PaaS

is natively integrated into OpenStack, things get really interesting. The containers themselves could be managed in OpenStack, opening up full visibility to the operations team. They wouldn’t just see a virtual machine that is working really hard, they would see exactly why. It would enable them to start using projects like Ceilometer to monitor those resources, Heat to deploy them, etc. In other words they could start leveraging more of OpenStack to do their jobs better.

The OpenStack Solum project is one of the parts that Red Hat (along with a variety of other companies) is working on with an eye to this sort of integration. Solum is intended to meet various needs of developers (integrated support for Git, CI/CD, and IDEs; take advantage of Heat orchestration; etc.) in what you can think of as a PaaS-like way but without all the trappings of a full-fledged PaaS. 

The bottom line here is that there's a continuum between a bare-bones IaaS and a full-fledged development platform. This continuum can be thought of as laying along an axis from complete fine-grained control on one side to various hosted PaaSs on the other. Even this oversimplifies things though as offerings may also differ based on target workloads or other aspects. Which is another reason why a monolithic IaaS+PaaS may not be the best approach.

Finally, as I wrote at the beginning, PaaS is really the youngest of the cloud service models. So it probably shouldn't be surprising that it's evolving so rapidly. (Although all the community energy OpenStack is creating lots of innovation and change there as well at the IaaS layer.) And that evolution will continue--which may well mean that our understanding of the optimal locations for abstractions and interfaces may evolve as well.

Red Hat's cloud portfolio philosophy

Our approach to working on integration points between OpenStack and OpenShift--while leaving customers the ability to use them separately as well--pretty much sums up our philosophy across our entire product portfolio: Red Hat Enterprise Linux, our Red Hat CloudForms and Red Hat Satellite management products, JBoss Middleware, Red Hat storage in addition to OpenStack and OpenShift. Much of this integration work is happening in the upstream communities. You see other examples in the reference architectures created by our system engineering team. (See, for example, Deploying a Highly Available OpenShift Enterprise 1.2 Environment - Using RHEV 3.2 and RHS 2.1.) Openness and flexibility are at the core of our cloud strategy and that applies whether you just want IaaS, just want PaaS, or if you want a well-integrated combination of the two.

 

[1] I actually used the Hardware-as-a-Service term in that research note, which was being used mostly interchangeably with IaaS at the time. I also discussed the idea of Data-as-a-Service which was primarily about data returned through APIs--an important trend but one that isn't today really directly part of the cloud computing service model.