Listening to Krishna Raman and Daniel McPherson of Red Hat talking about how to build a PaaS (Platform as a Service) using Red Hat's just released OpenShift OSS (Open Source Software) platform (see here), a couple of not unrelated thoughts struck me.

Firstly, PaaS is about business applications, not virtual machines, so it cuts across the Ops and Dev silos (check out the NIST definition of PaaS - "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... but has control over the deployed applications and possibly configuration settings for the application-hosting environment" - here). That is, PaaS has a DevOps side to it

My general take from the 2012 Boston Summit is that Red Hat people tend to think of DevOps as developers managing operations (although Red Hat's official position is that "DevOps gives developers much more automation and control over their application in terms of being to deploy their application directly to the cloud, scale it, update it, etc."); while  I'm not sure it isn't going to be more about operations managing developers - but, really, both groups are needed and need to co-operate at a very intimate level - in other words, talk to each other. The trouble is, the cultures and mindsets are very different for Dev and Ops. McPherson pointed out that as a developer, he always worried about the CPU bottleneck but the operators he talked to said that the CPU was almost always woefully underutilised (which is why we need multi-tenanted PaaS - several applications sharing the same VM or Virtual Machine - not just PaaS); and I commented that developers usually just wanted to make changes efficiently, while Ops worried about maintaining service levels while change was happening and had to be convinced that any change would actually make things better, with minimal risk of making them worse.

I had an interesting conversation afterwards, around this and the need for all stakeholders to take an active part in the discussion (which might mean that the business needs to understand a few IT concepts at a high level, without trying to micromanage IT) with Amin Astaneh, an operations manager at Acquia (web content manager and packager of the OSS Drupal CMS: "Acquia is to Drupal as RedHat is to Linux", as Astaneh puts it) and he confirmed the essential issues. Personally, I think the Ops people will start to take the lead as they are interested in preserving and improving Business Outcomes (cf. ITIL) while developers are more interested in producing software - and software only delivers business value (to the people paying the developer's wages) after Ops have got it working reliably day-to-day. So, my first thought is that if PaaS is a DevOps thing, as McPherson suggests, that this implies that PaaS implementations will need to pay considerable attention to the cultural/people issues involved with getting developers, operators and the business singing off the same hymn-sheet

My second thought is prompted by McPherson's emphasis on the essential need for multi-tenancy and the need for a combination of Linux containers (LXC) and Security Enhanced Linux (SE Linux) and mandatory access control as a foundation for this. This ensures the absolute isolation between tenants that the business needs; and allows PaaS to deliver high utilisation of resources - typical mainframe utilisation levels approaching 100% perhaps, rather than typical Windows levels under 10%.

For an effective multi-tenanted PaaS environment, discretionary access controls (roughly, you can do anything unless it is expressly forbidden) gets too complicated and error-prone; military-type mandatory access controls, using whitelisting of expected functions and prohibition of anything else, is far more efficient and effective. Most Windows malware attacks, for example, wouldn't work if Windows simply disallowed unexpected logic as SE Linux does and, although this makes the developer work a little harder (or more carefully), it also makes business applications much safer.

This could be extremely important. It seems to me that PaaS on LXC and SE Linux delivers the "trusted automation platform" which I think is becoming seen as the essential - necessary - foundation of effective on-line commercial activity. So, will OpenShift PaaS with SE Linux deliver a commoditised, easy-to-use, trusted platform for ordinary commercial activity, of the sort currently really only feasible for the military? In other words, returning to DevOps issues, perhaps the sort of platform that Ops needs to help it maintain business outcomes and minimise the risk of service impact during Agile application delivery is going to be most easily and cheaply found in virtualised form on a PaaS cloud, not on physical hardware. Very possibly, this virtualised environment really is better than the real thing and cloud, implemented right, is the solution to the current untrusted computing issue rather than being part of the problem!

Red Hat points out that a more general DevOps issue is that it could result in less centralized control for IT Operations when it tries to manage across multiple application environments, leverage existing governance standards, and manage things like security, compliance & regulatory issues etc - all things that matter to Enterprise organizations. Red Hat feels that "this will limit Enterprise adoption of existing PaaS solutions that are Public PaaS only and push full DevOps models. That's why we announced our Enterprise PaaS strategy a few weeks back and introduced our OpenShift Enterprise PaaS solution at Summit - which will expand our PaaS capabilities by introducing a commercial version of our Hosted Public PaaS (OpenShift.com); and also introduce Private/Hybrid PaaS solutions that enable both emerging DevOps models and traditional enterprise application management methodologies". You can read the announcements of Red Hat hosted and hybrid PaaS offerings, and commercially-supported versions of OpenShift, here, here and here.

In other words, I think that Red Hat sees useful DevOps, in the enterprise, as a balance between agile delivery and appropriate control and I'm sure that makes sense. However, this is really no different to what IBM calls "Agile at scale" - Agile has always required discipline if it is going to scale and I don't see that addressing the "quality attributes" needed for enterprise-scale employment makes DevOps any less "Agile" - in my terms. I do think that Red Hat's espousal of hybrid solutions is spot on - and that hybrid cloud solutions don't compromise the Cloud ideal in practice.