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.
What do you think?
Agree, disagree, or have another perspective? Tell us in the comment section below.