Red Hat has released a 2.0 version of OpenShift, its on-premises (private) PaaS. OpenShift seems to build on real customer experience to address a range of issues that come up in real deployments, providing an out-of-the-box solution that is likely to appeal to enterprises seeking to offer a consistent development/deployment option to reduce complexity and cost.
Pivotal’s Cloud Foundry and Red Hat’s OpenShift are in many ways mirrors of each other. Each contains the same three elements—an open source project, a public PaaS, and an on-premises PaaS—and the concept is similar. If I were asked to give an off-the-cuff comparison, I’d say Pivotal has a more diverse open source community, Red Hat has a more widely adopted public PaaS, and there really isn’t anything that distinguishes them from each other with regard to the private PaaS. Most likely, the current leader on public PaaS is actually Heroku, although it doesn’t play in private PaaS, nor does it try to develop its own open source community. You may also want to consider Azure as part of the same family, although it has more of a proprietary focus.
Private PaaS may seem quite a long way from the initial concept of Platform as a Service, where everything is taken care of (including the hosting). I tend to think of private PaaS as a return to a pre-1980s concept of a server operating system that directly runs applications. Essentially, all those extra things like databases, messaging systems, web servers, load-balancers, application servers, etc. are provided in the PaaS and automatically configured to work. It’s a bit like buying an AS/400 in 1989, only less proprietary. Since the 1980s, we’ve become used to dealing with integration headaches between software from multiple vendor sources. PaaS promises to at least streamline the integration process—when it works.
The trouble is that life has become complex since the 1980s. Like the vast array of languages, frameworks, and services that applications integrate with, and a server platform that has itself become distributed and virtualized (and self-service through IaaS), so the role of the PaaS as a super-O/S is huge. One of the key features of this marketplace now—in private, public, or open source forms—is that the PaaS is not one platform, but multiple platforms. It needs to support a very broad range of legacy, current, and future programming languages and frameworks. By legacy, we aren’t talking Cobol and RPG, but certainly for private PaaS you do need legacy J2EE support.
There is some difference in philosophy between Red Hat and the other players in that Red Hat is operating with the same sort of “distro” models under which Red Hat Enterprise Linux is offered. It wants to supply you with a private PaaS in a box that contains all the pieces all working together, and for all of those pieces to be open source. From an enterprise perspective, there is a lot of reassurance in knowing that (1) the pieces are all known to work together, and (2) the possibility of lock-in is reduced because it is all completely open source. But Red Hat could end up isolating itself from the open source community, because the long-term viability of a business model for third parties to partner with Red Hat is unclear. However, Red Hat has enough cash to acquire companies with technologies it needs (as it did with OpenShift in the first place), and it has enough of the pieces (notably JBoss for legacy J2EE) that come together to make a solution. PaaS generally (but not always) sits on IaaS, and this is one area of concern for Red Hat’s approach. It doesn’t have its own IaaS layer. It has a cloud management product known as CloudForms, which was originally positioned as a stand-alone IaaS but now targets third-party IaaS like, for example, OpenStack.
OK, so on to the recent announcement of Red Hat OpenShift Enterprise 2.0. This is the private PaaS version. It is designed to go into your data center and provide you with an elastic, self-scaling environment onto which you can deploy production applications. In practice, Red Hat primarily gives examples in which people are using it as an elastic environment for dev/test. It’s good for this, because developers don’t have to get their hands dirty configuring infrastructure. Notably, VMware started in dev/test and moved into production. Another positive side effect is that the PaaS can enforce enterprise standards, ensuring developers don’t configure non-standard environments.
OpenShift Enterprise installs with a Red Hat Enterprise Linux (RHEL)–based physical or virtual infrastructure, either directly or with an intermediate IaaS layer from OpenStack. It’s a 2.0 product, so the recent developments have been about consolidating a feature base with the details that make it actually workable.
To make it play better in the data center, they’ve done a lot of work on the installation engine to simplify installation and provide OpenStack support. They’ve provided some hooks into the PaaS’s availability layers to allow them to speak to external services in the data center that are providing similar services (like routers and load-balancers); they’ve provided a Kerberos-based authentication mechanism for direct access to components of the PaaS (rather than using ssh); and they’ve moved the firewall down into the O/S kernel to reduce overheads.
One crucial thing they have done to deal with the complexity of real-world applications is expose a mechanism to pass good old-fashioned environment variables to the components of the PaaS (and on to the running application). If you read my “secret shopper” story about Cloud Foundry, you will see reference to the way the PaaS can simply read and overwrite the application config to point to the PaaS services. If this fails, however (and to deal with many real-world situations that can’t be known in advance to the PaaS), environment variables can be used. This is particularly important if the application is deployed in multiple configurations—the environment is used to tell the application whether it is in development, QA, or staging of production, and then to branch the config file appropriately.
Another thing they have done is provide hierarchical roles-based security for teams within the PaaS, allowing teams to define their own access controls for their own members. The full list is at this link.
Over the next week or so, I plan to have a go at deploying to the public version of OpenShift—based on the same codebase—so I hope to tell you if all of this is real. In the meanwhile it does at least smell real, they are talking about real-world complexities, and it seems to be based on practical experience.