Thursday, March 13, 2014

Links for 03-13-2014

Monday, March 10, 2014

Links for 03-10-2014

Monday, March 03, 2014

Devs and automated Ops

Over at CIO, Stephanie Overby presents a GE Capital case study in which

The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.

7249435726 91f8f3e818

DevOps is often thought of as the breaking down of walls between operations and development. As such, it’s the IT equivalent of other types of integrated teams—an organizational style that goes in and out of fashion but is more in that out at the moment.

Looking at DevOps this way is… well, not wrong exactly but it misses important points. It’s worth stipulating here that there’s not yet a broad industry consensus around what DevOps. Nonetheless, it’s broadly recognized that historical boundaries between developers and operators and—as important—between the tooling that they use are rapidly breaking down.

Let me lead into my point with another quote from the article.

The project not only proceeded quickly -- the application was delivered within several months -- it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well. 

Note the repeated use of the word automation.

A naive view of DevOps (which corresponds to how it was often discussed a few years back) was that DevOps was about the merging of developer and operator roles into one. The developer grabbed the production SQL database root password and the operator started churning out PHP. But that’s not really the DevOps story.

Much remains to be written and discovered on this topic. (By myself and others.) But one way that I increasingly think about DevOps is that the architects and operators build the infrastructure, setup developer self-service, automate scaling and deployments and then get out of the way.

For example, here’s how Paypal’s Ryan Granard described their approach with Red Hat’s OpenShift PaaS at GigaOm Structure last June:

Our concept is you walk up to a portal, you pick the product that you want to work on. You're not asking VMs and RAM. You just say, I want to work on Wallet. In minutes, we have you up and running in a fully connected container and you're developing. That's the key. That's a real benefit to just the speed of innovation and ultimately not having developers or testers or any of these folks do anything that's not part of what their role fundamentally is.

Viewed through this lens, DevOps can be seen as not necessarily about developers becoming amateur DBAs or operations folks slinging a lot of code. It’s true that some of the newer management and operational tooling—think Puppet, Chef, Foreman, and so forth—is lighter weight and perhaps more suited to a degree of joint dev and ops use. However, it’s also clear that DevOps is about automating the relevant subset of operations for developers and providing easy-to-use instrumentation and controls that let them make effective us of that underlying infrastructure.

photo: CC/flickr by M Ray http://www.flickr.com/photos/mray/7249435726/

Video: Translating Open Source Value to the Cloud



Here's a video of the talk I gave at the Linux Collaboration Summit in 2013. I'll be giving a new presentation on How OpenStack is Paralleling Linux Adoption (and how it isn't) in a few weeks at this year's event in Napa.

Podcast: Cross-realm trust with Dmitri Pal and Ellen Newlands

Ellen Newlands and Dmitri Pal handle product management and engineering respectively for Red Hat Identity management. In this podcast they discuss cross-realm trust, a new feature in Red Hat Enterprise Linux 7.0 (currently in beta), which centralizes identity and makes integrating identity management from Linux with Active Directory and managing it much easier than it has been in the past. We also cover some of the work that Red Hat is doing around one-time passwords.

Listen to MP3 (0:12:02)
Listen to OGG (0:12:02)

[Transcript]

Gordon:  We're going to be starting to talk about some of the new features coming down the road in RHEL 7, Red Hat Enterprise Linux 7, that's scheduled to ship later this year. Today, we're going to talk about one of the new security features in RHEL 7, namely, cross‑realm trust.
Maybe, get a high level view to start off. Ellen, why don't you explain what it is and why people care about it?
Ellen Newlands:  Microsoft’s Active Directory is installed in many, many of our customers' accounts. In addition, of course, customers also are using Red Hat Enterprise Linux.
One of the things that we will be shipping in the latest version of RHEL, which will be RHEL 7, is the ability to easily integrate identity management from Linux with Active Directory, something that centralizes identity and makes the management of those identities much easier than it has been in the past.
Gordon:  Dmitri, could you tell us at a reasonably high level what this cross‑realm trust is?
Dmitri Pal:  Cross‑realm trust is the capability of the identities from one domain to access systems and resources in another domain. So instead of systems having to be directly connected to the Active Directory as they have been in the past, we can have a central server that would manage those systems while enabling users to come from Active Directory and access those systems and access the resources provided by those systems, for example, NFS and things like that.
Gordon:  From the point‑of‑view of a system admin, how is what they can do with cross‑realm trust simplified or different from how they would do things today?
Dmitri:  Today, with the solutions that are available, Linux systems are usually joined directly into an Active Directory domain. That means that they need to be managed through the Active Directory tools or found by the tools related to or integrated with the Active Directory.
In some cases, that's the preferred method, but that requires the protocols that are driven from Active Directory. Linux systems have their native needs in terms of POSIX attributes, the SELinux capabilities, the sudo capabilities. Linux systems are really not exactly the same as Windows systems, so turning Linux systems into Active Directory directly requires a lot of remapping things.
We had a solution for managing Linux systems, but it was isolated. The idea is to provide the best‑of‑breed services for the Linux systems on one hand, and to enable the users from Active Directory to access those systems on the other hand. It's the best‑of‑breed of both worlds.
Gordon:  This is really a way of essentially federating identities.
Dmitri:  Yes, but using domain‑to‑domain. It's federation on the Kerberos level. It's domain federation rather than other ways of federating like SAML or OpenID. This is on a lower level, on the infrastructure level rather than on the application level.
Gordon:  Is there a particular audience for this type of approach versus other approaches? In other words, who's been asking us to do this?
Dmitri:  The main consumer is the part of the organization which is responsible for the infrastructure, for maybe cloud services or storage services, the things that provide the fabric required for the enterprise to do their business. The applications can be on the top of that, consuming the cloud or the big data that is running on top of this infrastructure.
Clearly, having a set of the systems that constitute the infrastructure as a part of Linux and joined into the Active Directory through the trusts is that domain audience.
Gordon:  Ellen, what have you been hearing in terms of demand for this?
Ellen:  One of the things that I find quite interesting is we are now in the high‑touch beta phase for RHEL 7. A number of the customers who have shown a great deal of interest in this particular capability, the cross‑realm trust, are in banking, telecommunications, retail, healthcare, and public sector.
What we find is that these are accounts where Active Directory may be what we call the authoritative source for compliance.
But there's a large infrastructure component for Linux that also wants to be involved in the higher levels of compliance but managed with the Linux capabilities. As Dmitri explained, there are certain native Linux capabilities, like automate and sudo, et cetera, that this enables that area of the corporation to maintain while still falling under the corporate architecture where maybe Active Directory is the authoritative source.
We've seen a lot of interest from generally very large customers who have a complex or heterogeneous environment.
Gordon:  That's pretty common these days.
Ellen:  Yes it is. It seems like very, very few customers have only one vendor or one operating system Linux is very often in a division or the development group or whatever in a wider context.
Dmitri:  I want to add one important factor of the cross‑realm Kerberos trust. That kind of a deployment allows great integration from whatever solution the enterprise has at the moment to the future vision and the future architecture. By deploying identity management in Red Hat Enterprise Linux that comes with Red Hat Enterprise Linux 7.0, you can establish this trusted domain and then gradually move your systems into that domain.
One of the important things is that you don't need to move to the latest versions of Linux. You can serve with this solution both the latest the version, the 7.0, and the latest version of RHEL 6. You also can integrate earlier Red Hat Enterprise Linux versions as well as non‑Linux systems.
Gordon:  This highlights what the analysts are telling us. What we see is an idea that IT is increasingly hybrid, and that solutions that force homogeneity are increasingly uninteresting, nonviable even, at customers.
Ellen:  That's absolutely true. Increasingly, it's a heterogeneous world. Increasingly, also, the corporate boundaries are somewhat porous. The ability to move in and out of vendors' various environments is very valuable, especially when we offer centralized management. It takes less time, less work and is easier to manage and, to some extent, update.
Gordon:  I would be remiss and some of my friends would disown me if I didn't mention that Red Hat Summit is coming up mid‑April in San Francisco. For listeners who are interesting in this sort of thing, there are going to be a lot of great sessions around identity management at Red Hat Summit.
Ellen:  Yes, indeed. Dmitri will be doing demonstrations not only of the new cross‑realm trust coming out in RHEL 7. One of the other features that I think is interesting is, we've done some work in what we call OTP, which is one‑time password capability.
Dmitri, would you like to explain a little bit about why that would be of value?
Dmitri:  We have been working on the one‑time password technologies and integrating them directly into the identity management solution for quite some time. It's not going to be available in Red Hat Enterprise Linux 7.0, but it is in a stage of development that is ready for us to talk about that.
It's coming down the road. It's pretty solid technology right now. We will demonstrate it in the booth at the conference.
The main value is that you can authenticate with two‑factor authentication, like a token fob that you have or a token that you have on your smartphone, and then acquire, as a result of this authentication, Kerberos trust, that would allow your enterprise single sign‑on between different services within your enterprise.
In the past, there has been no solution that allowed you to do that in an integrated fashion. There has always been a password hidden somewhere. You authenticate with two factors. With that you unlock a password, and then that password is played against Active Directory or LDAP or any kind of authentication server.
With identity management in Red Hat Enterprise Linux, we are building it in such a way that it is single stack. That's pretty powerful. There is a lot of potential in this technology going forward.
Ellen:  By the way, I think everybody in your listening audience will know that two‑factor authentication increases your security.
Gordon:  Pretty dramatically
Ellen:  Very dramatically.
Gordon:  Thank you for your time today. Anything else either of you would like to share?
Dmitri:  Come to the conference, join us in the booth, and join us at the talks that we'll have during the course of the summit. There will be some labs, also, dedicated to identity management. See you there. Thank you.

Ellen:  Looking forward to seeing you at summit. Thank you.

Links for 03-03-2014

Monday, February 24, 2014

Links for 02-24-2014

Tuesday, February 18, 2014

5 ways in which OpenStack doesn't parallel Linux

Last month, I wrote a post discussing the parallels between OpenStack and Linux. Briefly, these are the following:

  • Part and parcel of a new approach to computing
  • Adoption rates won’t be uniform
  • It takes time
  • About community as much as technology
  • Open source development is an incremental process
  • Commercial distributions make consumption by businesses possible
  • Need for complementary components and integration

A number of folks have pointed out that there are differences too. To which I say "I agree!" From my perspective, here are five of the most salient deltas.

Opst blogimage opst parallel linux 700x400 11851957 0114 jw

1. Open source is now ubiquitous and part of the landscape. In 2001, Microsoft CEO Steve Ballmer was giving interviews like the one he gave to the Chicago Sun Times in which he said "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches." In 2001, Gartner analyst George Weiss was writing that between 2003 and 2005, "enthusiasm for Linux will increase selectively... However, their enthusiasm will be tempered by the entrenched position of Unix, which has already achieved mission-critical scalability and availability, by the strong Windows 2000 upgrades in the pipeline, and by the potentially heavy cost of migrating to Linux." My point here isn't to pick on anyone in particular (well, maybe Steve Ballmer) but to highlight that, circa 2001, Linux and open source generally faced an environment that ranged from skeptical to unremittingly hostile outside of (mostly) leading-edge technology adopters like Wall Street. Today, by contrast, open source is used widely--ubiquitously even--and companies like Google and Facebook would not even be feasible in open source's absence. In short, OpenStack's birth and maturation is taking place in a much more welcoming environment than did Linux'.

2. Open source is in the enterprise. And not just some enterprises in some industries. According to Red Hat's data, "more than 90% of Fortune 500 companies use Red Hat products and services." That's just Red Hat. (And, one suspects, there are open source pockets at most, if not all, of the remaining 10 percent.) Here's what Gartner is now writing about open source software in their Hype Cycle for Open-Source Software, 2013:

Continuing a trend over the past 10 years, the open-source software (OSS) model continues to expand and affect market segments across nearly the entire IT industry spectrum. For example, Linux was the first widely acknowledged success of open source in many IT organizations, and it remains the flagship of OSS success; however, the list of "industry-changing" OSS solution continues to grow year after year as well. Today, projects like the Apache Web Server, the JBoss Application Server, MySQL RDBMS, Eclipse IDE, MongoDB, and many more show the broad influence that OSS continues to have on the industry as a whole.

3. Open source is driving innovation. Historically, open source was more about commoditizing and democratizing technology approaches that already existed and were proven in the world of proprietary software. BSD and then Linux did so to proprietary Unix but they are hardly the only example. OpenOffice, the Apache web server, and MySQL database all didn't initially drive the state of the art forward so much as they drove price points dramatically downwards--and thereby greatly increased the number of people and organizations that had access. This dynamic remains true for some open source software, but the collaboration that the open source development model makes possible is now driving industry innovation in so many areas. In data storage and analytics, almost all of the interesting new approaches are in open source. And that's true also with building IaaS clouds where OpenStack is gaining so much attention. OpenStack isn't about mimicking a proprietary IaaS. There isn't such a thing outside of a few big public cloud providers (and, with the exception of Microsoft, they all make extensive use of open source as well). 

4. OpenStack is for the datacenter. So far, I've mostly discussed how the milieu in which OpenStack plays is different from the one in which Linux operated at first. There are some differences in the projects themselves too. Linux has probably had its greatest impact as a server operating system, but there's nothing inherent to Linux that limits it to that role. Indeed, the fact that someone could spin up Linux on an old PC and tinker with it arguably had a great deal to do with its grassroots encroachment into the server room. In the modern era, variants of Linux appear in everything from mobile devices to Mars Rovers. OpenStack, designed as it is for datacenter infrastructure, is more expressly tailored to run on a (moderately large) pool of servers. It's also more likely to enter the datacenter by the front door as a result. 

5. The OpenStack community is different from the Linux kernel one. Finally, it's worth observing that the OpenStack project's organization differs significantly from that of the Linux kernel. There are some similarities in that large commercial organizations (not least of all Red Hat) make significant contributions to both projects. But the Linux kernel runs as a sort of "benevolent dictatorship" (reflecting its roots) while OpenStack is governed by a foundation established for the project (reflecting its establishment primarily by a number of companies coming together). The difference also reflects how the Linux kernel has a singular identity and purpose while OpenStack is more of a framework for a number of sub-projects and includes more rapidly changing technology. In some ways, OpenStack looks more like a distribution than a single open source project--although that comparison fails in a number of respects as well.

Different doesn't mean better or worse. It means different. I always favor looking for historical parallels because they can be instructive and offer a window to the future. It's equally important though to understand the differences in the environment between yesterday and today, as well as between the things being compared themselves. In the case of Linux and OpenStack, there are lessons to be drawn for OpenStack by looking at Linux adoption so long as they're not slavishly drawn.  

Links for 02-18-2014

Monday, February 17, 2014

Links for 02-17-2014

Friday, February 14, 2014

Links for 02-14-2014

Tuesday, February 11, 2014

Links for 02-11-2014

Thursday, January 23, 2014

Links for 01-23-2014

Tuesday, January 21, 2014

Links for 01-21-2014

Thursday, January 16, 2014

Links for 01-16-2014

Wednesday, January 15, 2014

Links for 01-15-2014

Monday, January 13, 2014

What Red Hat's up to with partners and AWS Test Drive

The AWS Test Drive Program is a way to easily try out enterprise software. To quote AWS:

Test Drive simplifies clients’ access to complex IT environments, using the programmable infrastructures of AWS. Test Drive enables customers to rapidly deploy a private sandbox environment containing pre-configured ISV server applications that are ready to Demo and use. Test Drive labs are provided from the APN partner ecosystem, providing rapid provisioning of private IT environments. In a few minutes you can login and start using the software, following a guided tour Video and Lab Manual.

Test Drives labs have been developed by our APN Consulting and Technology partners and are provided free of charge for educational and/or demonstrational usage. Each Test Drive includes around a half a day’s use of free AWS server time for using live enterprise solution stacks, from the industry’s leading ISVs and SIs. You can return here and try any or all of the Test Drives at any time, so feel free to experiment, explore and learn.

The basic idea behind Test Drives is that you can get free limited-time access to complex enterprise software and work through a scripted use case to evaluate that software quickly. Software can then be purchased through AWS Marketplace or other channels. AWS Test Drive is a fairly new program. It was rolled out relatively quietly last year. 

Quoting Red Hat North America Channel Sales Senior Director Bob Wilson, The VAR Guy writes: "The test drives lend themselves to complex solutions, so partners that have offerings that require multiple steps, components and complexity to display to an end customers are optimal candidates," he said. "However, any solution-based offering that solves a specific customer issue would make a good test drive."

Red Hat's announcement today is for new test drives with three of our largest North American Partners. Mark Enzweiler, Red Hat's senior vice president, Global Channel Sales:

We've enjoyed working with CITYTECH, Shadow-Soft, and Vizuri to develop these initial solutions, and are eager to develop additional Test Drives with other partners. We believe these Test Drives are invaluable, they enable partners to use their expertise in pulling together complete solutions to solve complex customer challenges and illustrate how easily customers can use these tools to migrate to the cloud.

 

Punting on the Cam

Punting on the Cam by ghaff
Punting on the Cam, a photo by ghaff on Flickr.

This is from my trip to the UK last fall. I plan to be in London and Belgium in a few weeks for at least some of the end of Jan/beginning of Feb open source extravaganza set of events.

Links for 01-13-2014

Friday, January 10, 2014

Why you need a cloud management platform

I put this post up on the Red Hat OpenStack blog. If you haven't checked this blog out, give it a look and consider subscribing. 

Cloud infrastructure and cloud management. As an industry, we conflate these two things far too often.

This is understandable up to a point. Cloud computing architectures are relatively new and new architectural approaches often involve figuring out how functions are best partitioned and how they relate to each other. The process tends to be pragmatic; that’s how the networking stack first developed. That terminology is often morphing and inconsistently applied (innocently or otherwise) doesn’t help matters.

The overall building blocks of the private and hybrid cloud stack have now crystallized to a significant degree. The boundaries of these blocks aren’t hard-edged of course; there’s always overlap in the management space given that basic functions tend to come built-in even if they’re superseded at scale or for more complex requirements. But we’re at a point where we can describe the relationship of a cloud platform such as OpenStack to cloud management platforms (CMP)s like CloudForms that shouldn’t be too controversial.

Continue reading at Red Hat Stack

Thursday, January 09, 2014

Links for 01-09-2014

Fishing boat in fog

Fog by ghaff
Fog, a photo by ghaff on Flickr.

Finally got around to processing my photos from a couple of Maine trips during the summer/fall last night.

Wednesday, January 08, 2014

Will IaaS and PaaS converge?

Iaaspaas

 

 

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.