10 Reasons Why Ruby Hosting is Best on OpenShift

The idea of PaaS came from the Ruby land and nowadays the market there is quite saturated. OpenShift came from a polyglot by design and Ruby is very well supported. Let's take a look why OpenShift is a great option for a Ruby developer.

1. No changes to the application required & no proprietary APIs

For me, personally, this is one of the most important points. When I code an application I want to be able to create it in a standard way and not to be forced to use some special code snippets or libraries to inter-connect with the platform. OpenShift has no proprietary APIs. As an example, for storing the data you just choose from PostgreSQL, MySQL or MongoDB (or some other, as we will see later) databases and you connect to it just by using the basic drivers provided by the project (or community). There is no need to bend the application to deploy it to the platform.

As I mentioned before, this is a crucial point for me and should be also for you. You as a customer, you are supposed to have control over where you deploy your application and you should be allowed to move to other providers when you are not satisfied with the service. When you are forced to use some proprietary APIs, you will be bound to that particular provider and you will have to hope that somebody someday will code a new platform and re-use the APIs to allow you to move somewhere else. Such a vendor lock-in was common in the '90s and at the beginning of the new millennium, nowadays there is enough choices to trash such providers.

And actually you may be totally !@#$% depending on the result of the on-going lawsuit. So far it seems that APIs are not copyrightable, however if this goes the wrong way, providers may have much more difficult road to re-implement proprietary APIs and you may be stuck at a particular provider forever or be forced to re-code the application.

2. Quick-starts for no-hassle deployment

Sure this is possible on other platforms, but I believe that OpenShift really makes this effort a no-brainer for people who are not developers, but just want to run some simple (or complex) application. Let's take a look on my super-trivial case study.

During the Christmas holiday I started to work on my new side-project. Because I am working with more than one more person, I wanted to have a single place to share and keep information. I am a big fan of Redmine, as I had used it previously and found it user-friendly and probably the most intuitive project-management tool. Thus I wanted it to run it somewhere. I did not have time to really dig into the problem (what's the newest version, how to install it, etc.) and had my friend sitting next to me and needed a place to note down the things we were talking about. So what is the simplest way to do it? It turned out OpenShift is of a great help. I used the longer way as described in the text, but to deploy to OpenShift, it could be as simple as this one command

rhc app create -a redmine2 -t ruby-1.9 --from-code=git://github.com/openshift/redmine-2.0-openshift-quickstart.git

in a few minutes and everything was done. Redmine is running. Log in and started to use. Simple I say! Too complex you say? You can do the same using web-console and you do not need to even install the command-line tools.

Redmine in web console

3. Polyglot by design

Sure you are a Ruby developer ... but sometimes you may need to use some other language than Ruby. A good PaaS should be able to accommodate all your needs. Why? Well, Ruby is not the best tool for everything. There are other technologies that in specific cases may be much more useful than Ruby. Node.js for real-time applications, Java for performance or some enterprise features, PHP - well, not sure what for, Python for scientific applications and similar stuff .... there are lots of reasons and OpenShift is here to help you with all of those.

OpenShift provides comprehensive support for many languages and as we shall see in the next point, it's possible to extend it to give you almost any possible technology you need for your next big super-awesome thing. These technologies are provided by default

Short Name   Full name
==========   =========
diy-0.1      Do-It-Yourself 0.1
jbossas-7    JBoss Application Server 7
jbosseap-6   JBoss Enterprise Application Platform 6
jenkins-1    Jenkins Server
nodejs-0.10  Node.js 0.10
nodejs-0.6   Node.js 0.6
perl-5.10    Perl 5.10
zend-5.6     PHP - Zend Server 5.6 (PHP 5.3)
zend-6.1     PHP - Zend Server 6.1 (PHP 5.4)
php-5.3      PHP 5.3
python-2.6   Python 2.6
python-2.7   Python 2.7
python-3.3   Python 3.3
ruby-1.8     Ruby 1.8
ruby-1.9     Ruby 1.9
jbossews-1.0 Tomcat 6 (JBoss EWS 1.0)
jbossews-2.0 Tomcat 7 (JBoss EWS 2.0)

When you are creating a new application on OpenShift you need to choose a technology to use. I call this a "primary technology" because it only means that your new OpenShift environment will be configured to deploy such a technology, but all the other technologies are also available to you at the same time. Need to use Python from Ruby? No problem! Python is there, even though you have chosen the Ruby application as the web language!

4.Extensible to your needs

OpenShift is extensible. OpenShift has a concept of so-called cartridges that do provide some functionality. Let's take a quick look at some terms.


When you create a new application, OpenShift creates something that is called a Gear for your application. Gear is an isolated environment where your application will be deployed. It's a set of directories, cgroups configurations and SELinux policies. It's empty by default and provides no functionality except the environment isolation.


Cartridges are put into Gears to provide functionality. E.g. you do create new applications and you choose ruby-1.9 .... OpenShift creates new empty gears and puts ruby-1.9 cartridge into it. After that you are free to add any other number of cartridges into the same gear.

OpenShift by default provides a set of cartridges as you have seen in the previous point. However OpenShift also allows developers to build their own cartridges and actually allows them to extend the functionality of the platform. As one more recap, let's take a look at how to create a Ruby application

rhc app create myapp ruby-1.9

and now let's say I want to deploy Clojure. Clojure is not supported by OpenShift by default, but I had actually built a cartridges for it so anyone is free to deploy Clojure to OpenShift. What would the command look like now?

rhc app create myapp http://cartreflect-claytondev.rhcloud.com/github/openshift-cartridges/clojure-cartridge

Boom! And now you have support for running Clojure applications. And the same is true for databases. OpenShift supports PostgreSQL, MySQL and MongoDB, but you are free to provide deploy any other database of your choice, for example there is already a cartridge for Redis.

5. Full access to the environment

PaaS should be something like a black-box to you. You should not care about any underlying technologies and systems the platform uses to run your applications. You should be freed from all the operations. The only thing required should be git push and have the application magically running. And OpenShift - by default - works just like that.

However we techies are curious people and we like to poke into things. We enjoy exploring and we enjoy dismantling things.

Some PaaSes are really black boxes and you have no way to take a peek inside what it looks like. OpenShift, on the other hand, allows you full access to the application environment using SSH. And it's super-easy

rhc ssh myapp

You are SSHed into the environment and you can move around, touch things and destroy and create things. You can run arbitrary programs and command in the environment to tune it to your needs. It's completely up to you. But given our use of SELinux, Cgroups and other Linux security goodness you can't mess with other people's applications.

6. Most common gems already installed

This is a very Ruby-specific feature. OpenShift provides it's own Rubygems mirror and also provides some gems as pre-installed. People are encouraged to use Bundler to manage dependencies. Once you have Gemfile and Gemfile.lock in your application. OpenShift then runs bundle install --deployment to fetch your gems. Some binary gems may take a longer time to build and thus OpenShift provides pre-installed gems that Bundler is free to use if they match the requirements. This way the deployment process is faster than fetching the gems from Rubygems.org and building all of them all the time.

7. Pricing

In the end everything boils down to money. Money, money, money! The less you need to spend, the more you can keep.

With OpenShift's free tier you can run 3 applications for free. It's a great way to bootstrap your business. It's actually pretty powerful and can handle even middle-sized applications (but in the end, it depends on every specific deployment. There is not golden rule here!)

Once your business runs and you need to scale, you can upgrade to the commercial tier. The pricing can be found here and it's extremely competitive to all the other competitors in the market.

8. Run on Red Hat Enterprise Linux and operated by Red Hat

Red Hat has a long reputation in the Open-Source world and in building the most used enterprise Linux distribution. Red Hat Enterprise Linux powers the most dependable systems in the world and can be seen literally everywhere (not always seen, but it's there). With OpenShift Online, you get all the benefits of Red Hat Enterprise Linux for free, as the platform is using it as a core operating system. Also, Red Hat knows how the Linux kernel works and pushes this knowledge into fine-tuning the platform to give the best-possible experience. And all this is backed by Red Hat's award winning support.

9. Open-Source

The complete platform is Open-source. And it's Apache2 licensed. The Open-Source project is called OpenShift Origin. You are free to use it for whatever you want.

Are you now satisfied with our service? Is the Online environment too restrictive? Build you own! If you believe you can make a better service, do it! Use OpenShift Origin as a base and build your own service.

Do you have developers in-house and you need them to be able to deploy application PaaS-style on premises? Deploy OpenShift Origin internally and give your developers, QAs and others involved a nice environment to run their code.

Want a supported product but Online service is not for you? Try OpenShift Enterprise a fully-supported PaaS platform running on premises tailored specifically for your needs.

10. Extend & contribute

OpenShift is written in Ruby and you, as a Ruby developer, can extend the functionality of the platform. As was mentioned before, the project is licensed under the terms of the Apache2 licence. OpenShift itself consists of several components that after deployment cooperate with each other. Broker is responsible for coordinating the platform and handle all the tedious management tasks. Node manages the single nodes that are connected to the Broker and do the actual deployment of applications and communicates with the underlying operating systems. Console is a management interface that gives the user a nicer experience in working with the platform. Broker itself provides REST interface that allows management of the platform.

So, you are interested in hacking the platform, but are also intrigued how to get started? Super-Simple!

  1. Go to he Github repository
  2. Fork the repository
  3. Code your idea, commit it and push it to Github
  4. Send a pull request

Done! Congratulations! You have contributed to the OpenSource project and there is chance your code will get into the service as well as the Enterprise product.


From my perspective, OpenShift is a great PaaS for Ruby applications. In the years I had been using it I had never had problems. In case there is something missing, I am always free to extend the platform and get myself the functionality I need. As mentioned, getting started with OpenShift is free. Try it and see yourself if you like it or not.

Next Steps