Comparing Ruby-on-Rails Cloud Platforms: Public vs. Private Options

by Michael FedotovJuly 10, 2010
This article explains how to choose a cloud platform for Ruby on Rails and explores three vendor offerings available today for RoR engineers.

Executive summary

Gartner predicts that 20% of businesses will own no IT assets by 2012. They will prefer to operate in the cloud, saving on setting up and maintaining their own data servers. On the other hand, according to Evans Data, Ruby-on-Rails usage has increased by 40% in 2009 alone. The company predicts that an even higher increase is to be expected in 2010.

It seems only natural that the number of Ruby-on-Rails apps running in the cloud has been augmenting. So has the number of public and private cloud solutions for Ruby on Rails. Choosing between them, and, first of all, choosing between a public and a private cloud, can be difficult.

This article was written to help you make the choice. It explores when you can benefit from running your Ruby-on-Rails app in the cloud, explains the differences between a public and a private cloud, and helps you choose between the two.


Ruby on Rails in the сloud

Cloud computing may have been successful in proving its claims to be the new paradigm shift. However, are Ruby on Rails and cloud computing a good match? There are two fundamental reasons that make us think they are, indeed.

Reason 1. Scalability making up for higher resource consumption

Ruby is a language known for its relative computational expensiveness. Given that, Ruby-on-Rails development can benefit significantly from scalability that cloud computing offers. By enabling you to expand your resources effortlessly whenever it is necessary, cloud computing relieves you of concerns about whether your current amount of resources will suffice.

On the other hand, Ruby on Rails offers a multitude of scaling strategies that can be used in the cloud.

  • Capacity expansion. This is what usually crosses one’s mind first when they hear of scaling. The possibility to increase productivity by assigning more resources is one of the fundamental benefits of cloud computing. Yet, it is even more efficient when used in bundle with other strategies and optimizations.
  • Caching. Using toolkits, such as jQuery, effective browser-side caching can minimize requests to the server. Taking advantage of such technologies as action and fragment caching can significantly reduce server and database load.
  • Function partitioning. This one is about partitioning independent functions across multiple databases that enables individual databases to scale independently. One example is making a copy of a reporting database from a production database.
  • Workload segregation. Tasks that can be performed after a web request has been fulfilled (i.e., sending confirmation e-mails) might be better-off moved to a background job processor, such as Navvy.
  • Using non-relational data stores. Non-relational data stores, such as Tokyo, Redis, and Riak, can be used to offload your main database. Besides, they typically demonstrate better performance than relational databases, and they scale better.

Reason 2. Focus on efficiency

Ruby (and the Ruby-on-Rails framework specifically) is widely known for the high developer productivity it facilitates. Below are only some of the reasons for it.

  • Programmer, rather than a computer-oriented approach to development, saving hours of developers’ time.
  • Simplified, yet powerful and fast app deployment, relying on Phusion Passenger for automatically managing back end, Capistrano for automation, etc.
  • Ruby on Rails is a perfect fit for agile development, auspicious for test- and behavior-driven development and the Don’t Repeat Yourself approach. With Ruby on Rails, even small programmer teams can achieve tremendous efficiency.

The focus on efficiency is evident. Similarly, cloud computing is technology-oriented in increasing productivity by relieving enterprises of concerns over implementation and operation (we will demonstrate it later). It means that in terms of productivity, Ruby on Rails and cloud computing work fundamentally in the same vein. They aim to leave the developers to actually develop, not wallow in an incomprehensible code soup or ponder on available resources. For a company or an enterprise that stresses efficiency, Ruby on Rails in the cloud, therefore, is a definite winner.


A public vs. private cloud

As two forms of fundamentally the same computing model, public and private computing have much in common. These essential common features include:

  • A broad network. Cloud computing capabilities are available over a network.
  • An on-demand self-service. A customer can provision computing capabilities automatically, without interacting with a service provider in person.
  • Rapid elasticity. Computing capabilities can be rapidly scaled in or out whenever needed. For a customer, it often means that elasticity of computing resources available is practically limitless.
  • A measured service. Resource use is measured and optimized automatically, offering transparency to both a customer and a service provider.

The difference between the two models, however, is still considerable. It is, arguably, best represented in the definitions of public and private computing proposed by the U.S. National Institute of Standards and Technology (NIST).

NIST defines public cloud computing as a form of cloud computing where “the infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.”

Private cloud computing, by contrast, is characterized by its infrastructure being “operated solely for an organization. It may be managed by the organization or a third party and may exist on premises or off premises.”

As can be deduced from the two definitions, the principal difference between a public and a private cloud is who the cloud infrastructure is running for. If access to the same infrastructure is provided to a multitude of customers, one would hardly be mistaken to call it a public cloud. If the infrastructure (whether it is owned by the company or the service provider) is usable specifically by a single customer, this is unmistakably a private cloud.

Public clouds dramatically simplify implementation and reduce setup costs, allowing saving both on initial setup and management. The access to the external infrastructure is typically billed based on usage.

Unlike public clouds, with private ones, the initial setup and, often, operational costs are still there. Yet, a significant economy can be achieved by saving on maintaining physical servers and reduced delivery time enabled by the cloud model. Furthermore, operating in a private cloud means no privacy and stability concerns and more control over the infrastructure than with the public cloud.

A public cloud
A private cloud
Infrastructure customersMultipleSingle
Infrastructure typeExternalExternal/internal (depending on a specific solution)
Implementation costs+
Maintainance and operational costs–/+ (depending on a specific solution
Billing by usage+
Control over infrastructureLimitedFull


Engine Yard AppCloud™ and xCloud™

Engine Yard is one of the most popular cloud computing services, and there is a good reason for that. Offering great flexibility, Engine Yard makes it possible for small companies and enterprises alike to make the most of cloud computing. Let us see what key features Engine Yard has to offer for Ruby-on-Rails cloud development, focusing on AppCloud, an affordable public cloud solution, and xCloud, Engine Yard’s enterprise public cloud offering.

1. Ease of use and accelerated development

Engine Yard AppCloud provides you with a preintegrated, pretested Ruby-on-Rails technology stack. This includes web, application, and database servers, built-in monitoring and process management, a Rails-optimized Linux distribution, in-memory caches, etc. Not only does that take the burden off your shoulders while setting up and configuring an infrastructure to meet your requirements, but it also allows for accelerating development by 10–20% or even more by saving the time your team would otherwise have to spend on deployment.

2. Scalability

Engine Yard claims to provide limitless scalability. Verisimilar, considered that some of the world’s biggest Ruby-on-Rails websites run on Engine Yard xCloud, including CafePress, Howcast, kgb, RepairPal, and others.

Scalability in xCloud is achieved by using slices, one slice being a 2.6 Ghz Xeon machine with 768 MB RAM, 10 GB of local slice storage, 45 GB shared filesystem, and up to two MySQL/Postgre databases. The minimum order is 1 production slice and 1 staging slice. At the other end of the scale, Engine Yard is offering those with higher demands a dedicated cluster whose minimum configuration includes 2 Coraid SAN shelves 24 disks per unit, 3 compute nodes with 8 CPU cores, and 32 GB RAM each. Plenty of room for scaling, as you can see, especially keeping in mind that you can use up to 672 instances.

3. Cost-effectiveness

You can start with a small instance and get 10 hours for as little as $1. You pay only for what you use, meaning that you don’t need to pay for a resource once you have stopped using it. Considered the pricing and scalability, one really cannot get much more cost-effective than this.

4. Reliability

Reliability is always a major concern for those planning to migrate to or already operating in the cloud. Engine Yard makes every effort to ensure their customers’ data is always safe, with remote backups running every 24 hours and remote monitoring testing your website every 5 minutes. Should anything arise (like, for example, your application needing additional capacity), the monitoring system will provide a timely notification. In case there is any unexpected downtime, the Engine Yard support team will also be alerted immediately.

5. Customizable hardware environments

Many applications have unique requirements that most service providers fail to meet, offering infrastructures that are more generally oriented. The Engine Yard xCloud, however, is claimed to be flexible enough to incorporate specific hardware or appliance requirements that its customers might have.

6. Cloning and app templates

Engine Yard AppCloud lets you clone your full production environment in a single click, regardless of how many instances and databases it is using. Or, if necessary, you can just as simply shut the production environment down. Another peculiarity of the AppCloud is that all information required to reproduce application capacity is stored in a configuration management system. Whenever you need, you can effortlessly reuse it. This means that the Don’t Repeat Yourself Approach now reaches out beyond the level of a single Ruby application.

7. Challenges

For all their inarguable advantages, Engine Yard’s solutions (and most public cloud solutions for that matter) still have a number of downsides. In certain cases, operating in a public cloud could generate such amounts of data that providing the network bandwidth to cope with it would simply be unreasonable cost-wise. Another thing is that a public cloud does not necessarily provide much economy when running large-scale applications. In fact, for some very large enterprises with a huge own IT resource pool outsourcing to a public cloud can turn out to be a more expensive option.

A few more problems arise from having to share the servers with other users. If just one of the companies operating in the cloud, say, inflicts an attack on the server, it is everyone who suffers. Likewise, if one of the issues results in the service address being blocked by spam filters, none of the e-mail sent from the server will be able to get through. Privacy concerns are yet another factor discouraging many from choosing a public cloud. For all the pains providers take to ensure maximum security, a public cloud is not a place to put confidential or sensitive information.

These considerations and the desire to be in full control lead many companies to consider migration to a private cloud.


Terremark’s Enterprise Cloud™

Terremark is a leader in virtualized, VMware-based infrastructure services, and its Enterprise Cloud probably enjoys more popularity than any other private cloud solution in the niche. The fact that the US federal government uses the Enterprise Cloud is a point in case. With the Enterprise Cloud, you get access to a straightforward, yet powerful web-based interface that provides access to Terremark’s data centers that host your virtual machine.

A sample Terremark dashboard (Image credit)

1. Scalability

Unlike most contending services, the Enterprise Cloud is based on resources, not server units or slices. This allows for more precision when scaling, and more economy, too, since you do not have to pay for the part of an additional server unit that is actually idle. It also makes it considerably easier to scale than with many other services. However, there is no downgrading.

2. Burst Mode

One of the Enterprise Cloud’s greatest features is Burst Mode that enables you to get access to a pool of additional resources to deal with peaks in usage. The great thing about it is that it allows you to buy a package that suits your average use and leave the bursting mode to deal with your peak use.

3. Easiness-to-use

Terremark prides itself on its easy-to-use web console, which is employed for creating and managing virtual servers. With the help of this console, you can also control load balancers and firewall resources allocated to your environment without any special knowledge.

4. Role-based access and security

The Enterprise Cloud allows customers to create user accounts and define roles and responsibilities for different users. Such an approach is helpful in terms of boosting usage efficiency and workflow management, and it is also a great feature, security-wise.

The standards of security in the Enterprise Cloud are high and comply with modern certification requirements, such as SAS70 Type II, PCI-DSS, and Safe Harbor. The security system features a firewall, an encryption system, a logging system, intrusion detection and prevention mechanisms, and other features, such as file integrity monitoring.

5. Flexible integration

You can easily create a hybrid environment by integrating your existing private network with the Enterprise Cloud, and Terremark will handle the configuration and security concerns for you.

It is also possible to combine your Enterprise Cloud with a dedicated server. The operation of exposing a physical server to your private cloud only takes a few minutes, and afterwards you can control both using Terremark’s web-based interface.

With these features, you can increase productivity by extending your cloud and creating a seamless hybrid environment.

6. Challenges

There are still a few downsides of the Enterprise Cloud. The lack of configurability for the built-in load balancer is one of the most conspicuous. In fact, it cannot be configured at all, as the traffic is distributed automatically. However, Terremark can provide its customers with a hardware load balancer if they find it necessary.

It should also be noted that although VMware’s ESX, which the Enterprise Cloud runs on, has a feature to limit resources for each virtual machine, you cannot use this feature for your virtual machines (VM) in the cloud. So, you can only rely on the built-in limitation mechanisms to watch that none of the VMs consumes too many resources.


Rackspace’s Private Cloud™

Rackspace’s Private Cloud is another popular and even more versatile private cloud solution. The offer is as follows: you get a number of physical servers with the freedom to virtualize whatever you need on them. Rackspace manages the physical servers, while you get full access to the virtual machines on them.

1. Flexibility

Rackspace’s solution is probably as flexible as cloud computing can get, and certainly more flexible than any public cloud offering. Since you have full access to your virtual machine, you are free in using it the way you need and the physical management is taken care of for you.

2. Control

With the Private Cloud, you are fully in control of things. First, you, as has already been mentioned, can do anything you think necessary with your virtual machine. You know exactly what is running and you run exactly what you want. Second, the physical servers on which the machine is run are used exclusively by you.

Rackspace Cloud’s control panel (Image credit)

3. Scalability

Rackspace’s Private Cloud does not fail to deliver one of the fundamental advantages of cloud computing. Here, scalability is achieved almost as simply as within a public cloud. If you need to scale, you hire another physical server or reconfigure one of the existing machines.

4. Privacy, security, and reliability

You do not have to share the physical servers with anyone, so you can rest assured that your data is as safe as if the servers were your own. The servers are also protected with a firewall, and the monitoring is consistent and efficient.

5. Customizable hardware environments

With the private cloud, your hardware is customizable more than ever to meet your needs. Since the hardware is provided specifically for your use, Rackspace will be willing to customize it to any possible degree. Their team will also take care of the deployment process.

6. Challenges

It has to be kept in mind, however, that the costs of using the private cloud are considerably higher than those of operating within a public cloud. This is especially true given Rackspace’s recommendation to have a certain surplus of computing power lest one of your servers fail. If it happens, your other servers must be able to take over its load. However, unless the failure actually takes place, you will be paying some 30 to 40 percent overhead.

For all the flexibility of the Private Cloud, the reverse of the coin is that while Rackspace partially takes care of deployment, the setup and configuring of the environment is still left to you. This means, you won’t be able to save as much on the setup costs with the private cloud, as you would if you were using a public cloud. Moreover, maintaining the environment is also essentially left to you, which is a contrast to Engine Yard’s preconfigured and ready-to-use environment.


Making the choice

The choice between a private and a public cloud can be a tough one for many to make. If you are one of those yet undecided about which type of cloud suits your needs better, these guidelines will hopefully help you make a weighted decision. Below are a few points to consider before everything else.

  • The scale of your application. Do the size and complexity of your application justify going for a private cloud? Or is it a relatively small application that can run perfectly within the infrastructure of a public cloud?
  • Costs. In many cases, the cost is what actually defines the choice between the private and a public cloud. Smaller companies often find a public cloud to be much more affordable, given both the lack of setup and operational costs, as well as modest pricing. It is worth keeping in mind, however, that for larger applications, a private cloud can, in fact, be more economical.
  • Bandwidth. If you plan to operate in a public cloud, how much data will your application generate? Can you deal with that data without having to expand your bandwidth beyond reason?
  • Flexibility and control. What is more important for your business: having full control over the environment or being able to get started quickly and effortlessly? Do you have the staff to take care that the environment is functioning properly?
  • Custom hardware. Do you really need custom hardware that a public cloud cannot provide? Have you actually contacted the service provider directly to confirm that it really cannot?

Typically, smaller businesses find a public cloud to be better suited for their needs, while enterprises often opt for a private cloud as a more rational and more powerful architecture. However, there might be considerations in specific cases that lead executives to choose differently.

Even once the choice between the public and a private cloud has been made, it is still necessary to decide on the specific service provider. The table below illustrates the pros and cons of the three cloud solutions reviewed in this white paper.

Special features
Engine Yard AppCloud, xCloud

  • A preintegrated, pretested Ruby-on-Rails technology stack.
  • Don’t repeat yourself with application templates.

  • You share a public cloud with other customers.
  • Not suitable for storing particularly delicate information.

Terremark’s Enterprise Cloud

  • The burst mode helps you to deal with unexpected peaks in usage.
  • Seamless integration with your private network or dedicated hardware.

  • A built-in load balancer is not configurable.
  • Cannot manually limit resources for your virtual machines.

Rackspace’s Private Cloud

  • Full control over virtualization on dedicated hardware.
  • Customizable hardware environments.

  • More expensive than public cloud offerings.
  • You have to essentially maintain the environment by yourself.



Operating in the cloud helps to make up for the comparative computation expensiveness Ruby on Rails is known for. It is also a great way to stress efficiency and get the most of Ruby on Rails’s high productivity potential.

Public cloud options are perfectly suited for medium-sized Ruby-on-Rails apps, allowing for easy scaling. Apart from the simple capacity expansion, Ruby-on-Rails developers can use a number of other scaling strategies for maximum efficiency. However, certain kinds of data are just too delicate to be stored in a public cloud.

If this is the case, a private cloud is the better option if your application is particularly data-heavy. Running such an application in a public cloud would mean unreasonable bandwidth expenses. With such solutions as Terremark’s Enterprise Cloud, a private cloud is also easier to integrate with your internal infrastructure, while Rackspace’s Private Cloud provides you with external dedicated hardware.

Choosing between Ruby-on-Rails cloud solutions involves a lot of factors, but if the choice is made wisely, it can help you save dramatically and boost your productivity.


Further reading

This blog post was written by Michael Fedotov, Alex Khizhniak, and Renat Khasanshyn.