Red Hat takes OpenShift platform cloud private
'If you can run RHEL, you're good'
With the the rollout of its OpenShift Enterprise, Red Hat wants to put programmers and system administrators on an assembly line. And not just its own people, but you and your colleagues in the IT department – and it's for your own good. Well, for the good of your bean counters, at least.
That, in a nutshell, is the message behind OpenShift Enterprise, the commercial-grade, private platform cloud that Red Hat has been promising to release since it launched the OpenShift public platform cloud 18 months ago to compete against Microsoft Azure, Google App Engine, and other services.
With platform clouds, you expose runtimes, databases, and file systems as services and hide all of the underlying complexity of the physical and virtual infrastructure and the hodgepodge of systems software from developers. You also get to charge a premium over infrastructure cloud services and – depending on the vendor and the cloud – you get to exercise a bit of leverage over companies that deploy apps on your cloud.
The OpenShift that comes to market is a bit different from the one Red Hat first talked about in May 2011 and eventually installed atop Amazon Web Services' EC2 cloud to give developers a peek at it before it went into production.
That OpenShift public cloud is still in beta testing, as it turns out, and Ashesh Badani, general manager of the cloud business unit at Red Hat, said on a call announcing the private version of the OpenShift PaaS cloud that it would be commercialized – meaning with fees as well as an entry free version – in 2013. Red Hat CTO Brian Stevens let Badani do most of the talking, but said that the public version of OpenShift has nearly 100,000 applications deployed on it to date.
It is not clear how many companies have set up their own private PaaS clouds based on OpenShift Origins, which Red Hat open sourced in April of this year. What is clear to Red Hat, however, is that commercial enterprises want to run their own internal platform clouds because of compliance and security issues with the option of bursting out to public clouds based on the same PaaS abstraction layer. And so the company has been working to harden OpenShift Enterprise and build up its tech support team so it can peddle it to IT shops.
The irony is that the internal PaaS version is coming to market ahead of the public PaaS variant.
OpenShift Enterprise is based on the same OpenShift Origins code that Red Hat currently uses to run its public platform cloud. But over time Badani expects for the OpenShift Origins project to become the development release for the PaaS stack and get out a bit in front of both the OpenShift service and the OpenShift Enterprise stack.
OpenShift Origins will be roughly analogous to the Fedora Linux development effort, and OpenShift Enterprise will be like Red Hat Enterprise Linux. RHEL has a three-year major version cadence with dot releases twice a year, and Fedora has updates twice a year. While Badani is not committing to any particular schedule for OpenShift right now and is not keen on letting the open source OpenShift get too far out ahead, he tells El Reg that it will be reasonable to expect for the releases of OpenShift to synchronize with RHEL and Fedora over the long haul.
The bits and pieces of the OpenShift Enterprise PaaS cloud
As El Reg already reported, the Fedora 18 beta was supposed to include the latest snapshot of OpenShift Origins, but then Fedora 18 jumped to Ruby 3.2 and Origins is coded in Ruby 3.0, so it will take another cycle to test the code and weave it into Fedora.
The important thing about OpenShift is that the product that Red Hat is bringing to market is less convoluted than the original plan. In the beginning, OpenShift came in three flavors and was tied increasingly tightly to various Red Hat wares. The freebie edition was called OpenShift Express and it could run Ruby, PHP, and Python applications on Amazon's cloud. OpenShift Flex allowed you to deploy multi-tier Java and PHP apps that were back-ended by MySQL or MongoDB, and OpenShift Power Edition ran OpenShift atop Red Hat's cloud controller fabric and application deployment system, called CloudForms, or public clouds running Microsoft's Hyper-V, VMware's ESX, and Red Hat's KVM hypervisors.
That's more like three different PaaS clouds than one, and in June of this yearRed Hat scratched that plan and went with a single OpenShift stack, and removed any need for virtualization or cloud fabric controllers underpinning the OpenShift PaaS.
You heard that right. You can run OpenShift on bare metal if you want to – such as on your laptop or even on a cluster of servers – or you can prop it up on virtualized servers or even put it inside of an infrastructure cloud such as OpenStack. If you are managing multiple and incompatible clouds, you can bolt on the CloudForms tools, as well. You can use VMware or Microsoft virtualization and cloudy tools. Red Hat doesn't care.
"OpenShift Enterprise can run anywhere RHEL can run as a physical or guest instance," says Badani. "If you can run RHEL, you're good."
But don't get the wrong idea. Given the benefits of virtualization in terms of driving up resource utilization and offering more flexible systems management, you probably do want to run OpenShift in a virtualization manner – after all, that is how it runs on Amazon's EC2 for the public PaaS variant. And given the benefits that come from running VMs under the thumb of a cloud control freak, you'll probably want to run it in conjunction with some kind of controller (perhaps Red Hat's own variant of OpenStack when it ships early next year). But you don't have to do that, as was the original plan for the OpenShift PaaS.
The reasons why Red Hat is not requiring server virtualization managed by a cloud controller for OpenShift Enterprise are simple: it doesn't have to, and some customers have asked it not to.
As Badani explains it, OpenShift is based on Enterprise Linux 6 and makes use of the SE Linux security and a virtualization construct called a gear that is based on Linux containers – what we would call a virtual private server and what is just shy of a partition on a type 2 hypervisor.
With the Linux containers and SE Linux security, another abstraction layer or two that eats up capacity is not always necessary. If Red Hat ever sets up its own OpenShift public cloud, it will be interesting to see if it uses the enterprise-grade KVM it peddles, called Enterprise Virtualization.
The shift in OpenShift is all about giving developers an automatic transmission to shift application development into high gear.
Moving from IT craftwork to a PaaS-based app assembly line
While cloud computing is great in terms of resiliency and flexibility, it introduces several more factors that developers and system admins have to cope with as they push applications out into the cloud. It is no longer one app on one static box. A platform cloud is supposed to take that complexity and hide it once again. Even in infrastructure clouds, "this still feels like craftwork," says Badani. "What PaaS does is streamline the application development process, transforming it from craftwork to an assembly line."
In other words, you are going to have to do a lot more coding, programmers. And you are going to be doing a lot less stuff, system admins, because the PaaS layer by its very nature has self-service capacity and automatic scaling.
The good news is that with PaaS, at least you will have something to do. When your company goes with SaaS software like Saleforce.com, you are stuck maintaining legacy code on Unix, proprietary, or even Windows systems. Don't worry, you will have plenty of work for years. But make no mistake about it: Red Hat wants all the cool new code to go on OpenShift, and for your boss to pay Red Hat some more dough rather than spending it on a whole bunch of you infrastructure techs and software experts.
OpenShift Enterprise includes Enterprise Linux 6 and chunks of the JBoss application server necessary to run the platform cloud. As El Reg explained when OpenShift was opened up, OpenShift uses a hierarchy of abstraction to encapsulate and manage applications. The basic element is a gear, which is a Linux container allocated with a certain amount of CPU, memory, and disk capacity for an app. You load up your code and the databases and file access methods the app needs into what is called a cartridge. Multiple gears and cartridges make up a node, which is called CrankCase, and the RESTful API stack to manage it is called StickShift.
Java, Ruby, Python, PHP, and Perl applications can run inside of cartridges, and Node.js support should be coming soon. (It's in the public version of OpenShift.) The Jenkins and Apache Maven code build management tools and Git software version-control systems already plug into and run on OpenShift, and more languages, frameworks, and add-ons are not only in the works, but being encouraged.
The reason is simple: Red Hat wants public and private clouds alike to be running its stack, not someone else's. And it wants all of its code to be open source, too, to give customers the comfort of not having lock-in. Just using software causes lock-in because of the limited capacity of human beings to change and the cost of changing software, so this is a pyrrhic kind of superiority at some level, even if it is comforting at another.
OpenShift Enterprise is available now in North America, the UK, and continental Europe, and will be rolled out globally over time. The pricing for OpenShift enterprise is intended to compete with a large or extra large EC2 virtual server instance, says Badani, and will initially be available in licenses for two or four processor cores – this is different from RHEL and RHEV, which are sold in licenses for two or six sockets, respectively.
Depending on the underlying hardware, a two-core OpenShift slice can support as many as 25 different applications, according to Badani. That initial two-core license to OpenShift Enterprise will run $5,500 with a standard support contract, with larger slices costing more and premium support costing more, too. ®
Sponsored: The Nuts and Bolts of Ransomware in 2016