Platform as a Service is a cloud-based hosting environment for application development designed to provide a full-featured development, staging and production environment without the need for extensive in-house infrastructure.
Other benefits of PaaS include instant provisioning, easy collaboration and automatic load balancing.
We tested Red Hat’s PaaS OpenShift Online and the open source version, OpenShift Origin. Red Hat also offers an OpenShift Enterprise version, which we did not test. Overall we liked OpenShift Online better than OpenShift Origin, for its ease of setup and, surprisingly, better performance. Both products were winners in the collaboration category. In collaborative environments team developers can easily commit changes to OpenShift from different locations. This is one area where the power and ease of PaaS really comes into focus.
OpenShift Online is available either as a free plan or ‘Premium Silver plan’ (we tested the free version). All versions of OpenShift are based on RHEL (Red Hat Enterprise Linux) or Fedora for the OpenShift Origin version. On the development side, OpenShift supports numerous programming languages, frameworks and tools such as PHP, Ruby, JBoss and Python, plus database options (e.g. MySQL, MariaDB, PostreSQL to name a few) and a DIY (do it yourself) mode. OpenShift consists of two main units: the Broker, which manages logins, DNS and application states, and ‘cartridges’, which provide ‘plug-in’ functionality for various tools, databases and applications. Applications can be created using either command line or GUI-based tools. Red Hat claims if an app can run on Red Hat Enterprise Linux 64bit, then it can run on OpenShift.
We first tested OpenShift Online, which was easily accessed by setting up an account at the OpenShift Online management console. The web-based management console is user-friendly, with helpful ‘tool tip’ hints, enabling us to create our account and get ready for application development in just a few minutes. After getting our account set up and navigating around the portal, we took a look at the underlying architecture. OpenShift allocates resources using what Red Hat calls ‘gears’, which come in two sizes, small and medium. A small gear provides a single unit with 512MB memory and 1GB of storage and a medium gear is 1GB each of memory and storage. The free version allows the combination of up to three gears which provide a maximum of 1.5GB memory and 3GB of disk space. The OpenShift Online Silver plan provides more firepower with up to 16 medium gears. To upgrade to the Silver plan there is a monthly platform fee of $20 plus 3, 10 or 13 cents per hour per gear above and beyond the three free small gears included with both plans.
[ALSO: PaaS makes developers happy]
The management portal allows users to limit the number of gears used for an app, and also to control whether the app is automatically scaled. Scaling is controlled by a load balancing cartridge that sits between the application and the public Internet. The HAProxy cartridge sits on the first gear along with the application until the application has scaled beyond three gears, then the application is turned off on this gear, allowing the HAProxy the use of all available resources on this gear.
To determine when to add a new gear, the HAProxy orchestrates traffic to ensure it is balanced between the gears in use. Red Hat allocates 16 connections per gear and once the application is running at about 90% of this capacity, a new gear is automatically added. On the Silver plan, we calculated that if you run all resources 24 x 7 for 30 days you would pay around $1,000 per month. However, because most applications have peak periods, it’s not likely the app would need all 16 gears running flat out.
After setting up our account on the server, the next step was to configure the client tools. Although OpenShift apps can be readily managed with Red Hat’s RHC command line utility, we chose Eclipse and the convenience of the JBoss GUI, especially because it did not impose any overhead on our app once deployed. In further defense of our preference for GUI tools, we like the debugging features, which make it easier to track down potential issues.
Eclipse requires the installation of the Java JDK or JRE, and publishing via Eclipse to OpenShift requires a plugin that is easily installed from the Eclipse MarketPlace website. However, it should be noted that these prerequisites are only needed for local Eclipse development platforms and are not required for apps managed with the RHC command line tool. All source code for OpenShift apps is managed by GIT repositories, which can be local or remote, and can be synchronized between client and server.
We followed the instructions on Red Hat’s website, which were detailed, but as it turned out, not quite up to date -- resulting in a non-working configuration. As is often is the case with open source documentation, inaccuracies tend to creep in as new versions of the product and development tools are released. By digging a bit deeper we realized that although we had the latest version of Eclipse (Kepler) installed, the JBoss Tools referenced in the instructions were a revision behind and we needed to install a newer version to get the development environment up and running.
Once our development environment was properly configured, we set up our first app to use Apache Tomcat as a web server, with a PostgreSQL database for back-end web content. For the initial proof of concept our goal was to display a simple message on a web page, with content pulled from the database.
After creating security keys, setting up the database, connection strings and constructing our web page, it was time to build and deploy the new app. This process was pretty time-consuming for the first build, but went quickly for subsequent (incremental) builds. After some tweaks, our ‘Hello World’ page displayed as expected via remote browser on a hybrid OpenShift/user-assigned domain name, with no DNS setup required. Sounds easy, and overall it was, but developers new to OpenShift should be aware of what happens when an app is ‘pushed’ to the server.
When receiving pushed changes, by default the OpenShift host stops the application, rebuilds it and then restarts the application. This can be time-consuming and for production apps could create undesirable downtime. To mitigate downtime, OpenShift provides a hot deployment option that allows developers to push changes without restarting the application. Most application types can be pushed using hot deployment, with a couple of exceptions such as Jenkins and HAProxy.
Having successfully built and tested several apps on OpenShift Online, it was time to test OpenShift Origin. The source files for OpenShift Origin can be downloaded from GitHub as either a virtual machine (available for KVM, VMWare or VirtualBox) or you can download the source and build your own version by using Puppet and RPMs. To save time, we selected the VirtualBox VM, which we quickly deployed by following Red Hat’s online instructions, minus the requirement to run mDNS (an alternative, multicast host name resolution service).
The lead-in to the OpenShift Origin deployment guide states that it goes into ‘excruciating detail’ and we can vouch for that. But this is a plus, not a minus. The guide is excellent and in our opinion should serve as a model for documenting open source products.
Red Hat recommends mDNS, which bypasses the need for DHCP. We had a great deal of difficulty configuring DNS, whether or not we used mDNS. Our server was already running DHCP, so we expect this may have played a role. In the end we accessed the test apps via host IP vs. the FQDN (fully qualified domain name) assigned in OpenShift. This was a minor wrinkle, as it would not be a factor in a production environment using dedicated DNS servers.
Performance was a bigger issue. The OpenShift management console on our test server was slow to respond even though we assigned it 4GB of memory (3GB more than the minimum) and the host was a server class machine with multiple cores. We expected the local setup to run faster than the online version, but this was not the case. This might have been attributable to the aforementioned DNS issues.
On the Eclipse side, even after following the detailed instructions for security key management and assigning new keys for the local host, we found that we needed a separate Eclipse setup as OpenShift Origin had trouble with our security keys. Once again, not a major wrinkle as most developers would choose either the OpenShift Online version or OpenShift Origin version and not try to mingle the two environments.
In the end we successfully developed and deployed several kinds of apps to our local OpenShift Origin host, using various setups and databases. The host machine sputtered and froze a few times, requiring a cold start. Not a problem for development, but we could see this becoming an issue in a production environment where OpenShift Origin is used, for example, to host intranet apps which often have service-level agreements similar to Internet-hosted apps.
We concluded that for testing purposes it is faster and easier to use OpenShift Online, which eliminates DNS headaches we encountered with our local version of OpenShift Origin, although it still requires security keys. Managing security keys can be a hassle, but overall we are very encouraged by the improved security we see being built into open source products, as it seems industry has finally taken into account and addressed some of the security flaws that have plagued open source initiatives from the outset. That having been said, for best practices, organizations using cloud products in a production environment will gain the most protection by purchasing vendor support and SLAs.
Case in point, Red Hat offers very few guarantees for OpenShift Online and OpenShift Origin, and specifically disclaims most hosting-related items that organizations would deem important, including uptime, backup and recovery.
Even with the Silver plan, customers who are not happy with pretty much anything having to do with the service levels will not be entitled to credit for sums already paid. These “you’re on your own” disclaimers are not uncommon for open source offerings, as increasingly vendors view open source as a way to offer prospective customers a chance to fully evaluate products before committing to their commercial counterparts. This does not dampen our enthusiasm for open source, as the benefit of being able to freely and fully evaluate a product and study its architecture down to the core cannot be overstated. But it does require a healthy reality check when considering the use of open source outside a test environment.
Perschke is a web and database developer with 15+ years of industry experience. You can reach her at email@example.com.