Why OpenShift has polyglot baked in

Another day, another language. Yesterday, another PaaS provider announced they were adding additional language support to their PaaS—in this case, supplementing their initial .NET PaaS with Java. Such moves have become something of a pattern. Many of the initial hosted PaaS offerings were unabashedly monolingual. 

Engine Yard began with a Ruby on Rails focus, but has since added PHP and node.js. Google App Engine initially supported a variant of Python but now does Java and Go too. (Go is a Google-developed language that aims to provide the efficiency of a statically typed compiled language with the ease of programming of a dynamic language.) AppFog recently discontinued their PHP-only PHPFog platform. Even Microsoft's .NET-centric Azure PaaS has added Java.

I can't say I'm surprised. Whenever Red Hat has conducted surveys about intended language use in the cloud--whether private, public, or hybrid--we've always seen a great deal of diversity in the answers. (As well as considerable correlation with the languages those taking the survey are currently using.) Given those facts, it seems unlikely that most enterprise development shops would be interested in adopting a service that limited them to a narrow set of languages or frameworks. 

This isn't to say that enterprise software development is completely ungoverned. (Though sometimes it seems that way given the breadth of tools in use.) In fact, as I discussed previously, one of the big attractions of PaaS for enterprise architects is that it provides opportunities for standardizing development workflows and thereby make both the initial development of and subsequent lifecycle management of applications much more efficient. But, standardization notwithstanding, enterprise applications and infrastructure are heterogeneous. And that means a polyglot development environment is a must.

Which is the approach Red Hat has taken with OpenShift from the beginning—whether we're talking the OpenShift Online hosted service or the OpenShift Enterprise on-premise version. (The other thing we hear consistently is that many large organizations adopting PaaS want to run it on their own servers; application development is just too central a task for them to be comfortable running on a hosted service.)

OpenShift is fundamentally architected around choice. "Technologies" (language, databases, etc.) are delivered as cartridges--a pluggable capability you can add at any time. When you create an application, you start with a web platform cartridge to which you can add additional capabilities as you choose. Each cartridge runs on one or more "gears" (basically, a unit of OpenShift capacity) depending on how high your application has been scaled. 

Major open source Web language choices are ready to grab and go: Java EE 6, PHP, Ruby, Perl, Python, and node.js. But you can also build your own cartridges. You can even connect cartridges together. For example, you could have a PHP cartridge in one gear and a MySQL cartridge in another gear. (We're in the process of rolling out a new cartridge design to make building cartridges easier.) 

This ability to extend OpenShift is an important architectural feature that dovetails right into the open source development model and leverages the power of the community. And it's not an afterthought. It's in OpenShift's DNA.