On June 26, Red Hat announced a new version of OpenShift, and pricing for a future production offering (some time this year). You still can’t buy it but if you were able to buy it you’d know exactly how much it could cost – at least if you could work out what a “gear” is. Pricing allows us to start to compare it more meaningfully with other offerings. However rather than comparing with another PaaS offering, we think most people will be actually considering IaaS as an alternative, so we are going to do that comparison instead.

OpenShift is a multi-tenanted cloud which provides tenant isolation at the O/S level via SELinux not at the hypervisor level. I.e. users aren’t separate virtual machines but are Linux users which have an additional layer of encapsulation beyond that which you might see in a vanilla Linux environment.  It’s comparable to what Appsense and others do to lock down users in a Windows Terninal Server environment.

The “OpenShift” name (be careful not to type it too fast) is based on a metaphor of a gearbox. Each tenant runs a number of “gears” (typically 3 in a small installation). The following explanation from Red Hat may (or may not) explain how this works.

  • Gears: Gears provide a resource-constrained container where you can run one or more cartridges. They limit the amount of RAM and disk space available to a cartridge.
    OpenShift currently provides two gear sizes:

    • Small: provides 512MB of RAM, 100MB of swap space, and 1GB of disk space.
    • Medium: provides 1GB of RAM, 100MB of swap space, and 1GB of disk space.
    By default, you can use up to three small gears (a total of 1.5GB of RAM and 3GB of disk space). OpenShift can assign these three gears to a single app and its cartridges (Cron, MySQL, etc.) or you can use each gear for a separate application.
  • Nodes: To enable resource sharing, multiple gears run on a single physical or virtual machine. This machine is referred to as an OpenShift node. Gears are generally over-allocated on nodes because not all applications are active at the same time.
  • Districts: Districts define a set of nodes within which gears can be easily moved to load-balance the resource usage of nodes. This means that no node gets overloaded with many, heavily-used gears.
You can access a gear via ssh, so in some ways it feels a little like a “Micro” Amazon instance, except that
  • when you log onto it you are actually in a multi-user environment (locked down by SELinux);
  • each gear only runs one layer of the stack; and
  • OpenShift is managing the configuration of the O/S and application infrastructure components for you.
The base O/S is RHEL (running on RHEV/KVM as a virtualization layer – or maybe not, after all if the O/S is multi-tenanted what’s the point?) and you get JBOSS as the application server if you need one.  Other layers are quite flexible.  It’s multi-language, supporting Node.js, Ruby, Python, PHP, Perl, and Java, and a number of frameworks.
Originally it came in a number of varieties, most of which were free, except you needed an a Amazon Instance  to run java, which you had to pay for.  Now it is a consolidated offering, with its own free tier called FreeShift with up to three small gears, and pricing announced for a paid tier known as MegaShift which costs $0.05 per hour for a small gear or $0.12 per hour for a medium sized gear. These appear to be on top of a platform fee for MegaShift of $42 per month.
You might imagine that OpenShift’s main competition would be open source PaaS plays like CloudFoundry, however in reality I suspect it isn’t, it’s people doing IaaS. We can compare it in four areas.
Ease of adoption.  Is it really that hard to run up an Ubuntu 12.04 image on Amazon, run apt-get a few times, open a few ports on the firewall and upload a WAR file or zipped php code into the right directory?  Why is this intrinsically harder than  setting up your application to use Openshift-friendly environment variables for database access and running the shell scripts or ant scripts or configuring your IDE to point at OpenShift?  In practice it’s whatever you are used to that is “easy”.  One thing that can be said in Red Hat’s favour is that the documentation is surprisingly good.
Scaleup.  In absolute terms  it’s not clear how far the PaaS scales, and perhaps a comparison in that area isn’t particularly meaningful.  That said, the gears themselves are fairly small and having lots of little components in each layer (scale-out) can allow a lot of throughput but doesn’t usually lead to the highest overall level of performance – particularly at the database tier. However the PaaS does seem to offer an auto-scaling feature which you would have to hand-code to some degree in IaaS.
Security.  The big issue here is the nature of the multi-tenancy.  In IaaS the separation is at the Hypervisor layer, in OpenShift it is at the Operating System layer.  The Hypervisor probably has a smaller attack surface. How this multi-tenancy encapsulation works at the database layer and the web server is also a bit mysterious.
Price. It’s quite hard to do cost comparisons with Amazon because of the complex tarrifs don’t map directly on to each other.  You can probably do more with the free tier of OpenShift than you can with the free tier of Amazon because although each gear is smaller than a Micro instance, you get to run three of them at a time.  If you did this at Amazon you would run out of free hours fairly fast.  Beyond that, Red Hat has introduced a monthly fee to reduce tire-kicking on MegaShift, so for initial adoption it’s a bit more costly, but in practice pricng may end up similar.
Flexibility. Obviously if you’re on an IaaS image you can do almost anything you like. PaaS used to be a complete black box but things have moved on – you can run SSH into your gear these days, and you can install pretty-much any application you like into a cartridge, but there are certain things that are still annoying.  For example on Amazon I tend to use an elastic IP address and an external DNS because some parts of a domain are hosted on Amazon and some aren’t.  This doesn’t work on OpenShift because the web server doesn’t have an assigned IP.  It has an assigned DNS entry but you probably don’t want to expose that.  The way round this is to use a cname record pointing at the OpenShift dns entry rather than an IP address. But there is also a problem with https certificates. In IaaS clearly you can shove a security certificate on the web server and everything works fine, but in PaaS because the web server is also multi-tenanted, it needs to have certificates for each DNS entry which resolves to it and at the moment you can’t set this up – probably for good security reasons.

5 replies on “OpenShift — Pricing and Comparison to AWS”

  1. On the security section:
    It really depends on how you look at the attack surface. One thing multi-tenancy does that a traditional hypervisor PaaS doesn’t do as well is keep the system updated at the OS and application layer. It’s no small task keeping up with ruby, database, and web server issues or applications like WordPress. Putting that back on the user opens that surface up.

    The way that the web and databases are secured is very straight forward. Cgroups manages resources while SElinux puts things into user jails. It allows on the fly flexibility for a users instance to grow or be reduced.

  3. Pingback: Understanding how OpenShift fits into Cloud-scape | Krishna Raman

  4. By default, you can use up to three small gears (a total of 1.5GB of RAM and 3GB of disk space). OpenShift can assign these three gears to a single app and its cartridges (Cron, MySQL, etc.) or you can use each gear for a separate application.

    I love openshift and use it but we can not combine 3 gears to a one big server with 1.5gb ram and 3gb hdd. i asked it in openshift forums.

Comments are closed.