Rails: 3 big options for hosting your apps

If you're new to Rails, be sure to check out our tutorial on getting started with the popular framework. 

So, you’ve finished your app and now you want to make it accessible to everybody on the wonderful, wild world of the Internet. In order to do that, you’ll need to deploy it by using a hosting service provider for your app. Luckily, there are a few choices to select from, depending on the priorities of your needs or your users’ anticipated needs.

Cloud technologies and VPNs

In the most basic of terms, cloud technologies (or cloud computing) refers to the means of developing, testing, and storing code and data -- and accessing it over the Internet instead of keeping everything stored on your local hard drive. In other words, “cloud” is another way of saying Internet. Cloud computing includes app development in which the app’s data is synchronized with other information over the Internet. Examples include things like software-as-a-service (SaaS) and platform-as-a-service (PaaS). Salesforce.com is an example of cloud computing where a business subscribes to an application that is deployed live on the Internet. Examples of PaaS include Appendra for .NET and Java developers, or Red Hat OpenShift.

A virtual private network (VPN), on the other hand, is a method of adding a layer of security and privacy to both private and public networks, like WiFi Hotspots and the Internet. VPNs are mainly used by businesses to protect sensitive data like medical records, which are subject to HIPPA regulations.

Heroku, AWS and Digitial Ocean

What you need from a hosting provider will determine how you deploy your app. New options are being made available as Ruby on Rails gains popularity for Web app development, but for current Ruby on Rails developers, there are three main hosting providers (which are cloud platforms). These include AWS, Digital Ocean and Heroku. Let's take a look at the pros and cons of each.

Pricing

Heroku is very popular in the Ruby community and offers a free starter tier that can’t be beat for the developer  who's just starting out. You get one Linux instance (or container),called a “dyno” for your app and, again, it’s free. Not a bad deal for upcoming software developers who just want to host one website showcasing their developer portfolio. But beware: Once you hit the limits, Heroku will hit you back with a hard restart (without warning), which is not good for any Web app.

AWS also has a free tier—the Amazon EC2 t2.micro instance—but it’s only good for an introductory 12 month period, provided that you sign up. After the initial period expires, or after your usage exceeds 750 hours per month, your bank card or credit card will be billed.

DigitalOcean has no free starter accounts, however, pricing starts at around $5 per month (there are no hidden fees for add-ons and fixed IP addresses). DigitalOcean's most popular plan for one Linux container (or “droplet”) offers 1 GB memory, 1 core processor, 30 GB SSD disk, and 2 TB transfer for about $10 per month, while the $5 per month plan gives you just 512 MB, 1 processor, 20 GB SSD disk, and 1TB transfer. It’s important to note that DigitalOcean imposes monthly limits on your bandwidth usage, meaning you may have to upgrade your pricing tier to deal with sporadic traffic spikes. However, the price for DigitalOcean may be worth it when you consider that AWS gives you a t2.small instance for $10 per month (the same cost of DigitalOcean’s most popular plan).

Setup and provisioning

Beginner developers and small developers (who might not have the time to sink into tedious dev ops tasks) need look no further than Heroku. As far as setup and provisioning, it’s by far the easiest and requires no dev opps skills; it's a full-service cloud platform that spares you from the headaches and hassles of provisioning a server. Heroku lets you deploy a Rails app by pushing from a Git repository and offers a developer-friendly interface. Even better, it's optimized for Ruby on Rails apps from the get-go. When you push an app up onto one of Heroku’s servers, it takes care of any system dependency issues. Basically, it does for your deployed and hosted app what Homebrew does for you when you install RVM and the Heroku toolbelt and PostgreSQL. The most difficulty you’ll run into is with installing and setting up Postgres and Heroku if you’re on a Linux instead of a Mac. But after that hurdle, deploying on Heroku is a cinch.

With AWS, you can also get things up and running quickly (within as little as 20 minutes). Like Heroku, AWS has a user-friendly graphical interface, but it's recommended for the intermediate to advanced developer. While it does seem to cater to PHP apps, AWS offers great Ruby support; Ruby gems available to add SES or S3 support. AWS Elastic Beanstalk is an easy-to-use service for deploying Ruby on Rails apps on familiar serves like Apache and Nginx. With Amazon Relational Database Service (Amazon RDS), you can easily provision a MySQL, PostgreSQL, or Oracle instance on the cloud. Elastic Beanstalk provisions and operates the infrastructure and manages the application stack for you, so you don't have to spend the time or develop the expertise -- instead, you can focus on writing code.

Advanced developers, on the other hand, may want to check out DigitalOcean, which claims you can be up and running in less than 55 seconds. DigitalOcean is great for Linux developers, as well, though some have found provisioning a server with DigitalOcean tedious and difficult. In some cases, experienced developers found that they spent too much babysitting a Rails app deployed to their live virtual private server (VPS). They reported having to grapple with SSL certificates and email issues. And although you can ease some of the pain of setup and provisioning on DigitalOcean by using tools like Puppet and Chef, it also takes time to learn how to use those tools.

Scalability

Heroku is not very scalable in terms of pricing cost to the developer, but it does handle configuring the architecture for scaling. In a nutshell, Heroku allows you to focus on developing the website, not maintaining its infrastructure. It uses a routing system that decides which instance to allocate to the request, and makes sure to intelligently spread the workload across all instances at all times. But once your app grows, you’ll be hit with a price markup as high as 600 percent. So, while Heroku does offer scalability that you don’t have to configure yourself, you could end up paying through the nose for it; it's not very practical for developers with high-traffic apps.

Both DigitalOcean and AWS are very scalable from a cost standpoint. With DigitalOcean, scaling is a bit complicated and requires you to run some shell scripts and figure out how you need to scale. You have to know whether you need to scale vertically or horizontally -- and do it yourself. AWS, on the other hand, takes care of that for you with Auto Scaling and Elastic Load Balancing services. Auto Scaling enables you to follow the demand curve for your applications closely, reducing the need to manually provision Amazon EC2 capacity in advance. AWS also offers a treasure trove of developer resources, including articles and tutorials for making the best use of its services.

To put it simply, AWS offers more services than DigitalOcean. With DigitalOcean, you’re essentially on your own; it’s a leaner structure for economizing your hosting needs, but what you save in charges you can lose in time devoted to deep-diving dev ops tasks (time you could be spending writing code).

Preparing a system for scalability involves a lot of decoupling, because it's essential to have smaller servers with fewer responsibilities instead of one giant, all-inclusive server. This is really the essence of horizontal scaling, which is usually the most reliable and efficient method of scalability (but it's not as trivial as vertical scaling). Breaking the application down into parts will also help you measure and identify potential bottlenecks. Overall, the main challenges of scaling Web applications is keeping all the nodes in a cluster updated and synchronized.

One way to tackle scalability with DigitalOcean (with less pain) is to set up one droplet as an admin droplet that has its public key on all the other droplets. This would allow you to push webpage updates with rsync, as well as issue commands to other droplets, and query them for Nagios, NRPE and SNMPD vitals. You would need to create your own level of logic to determine how and when you wish to scale things. For example, if a server reached 85 percent CPU usage, you would double the RAM (vertical scaling) or create a clone (horizontal scaling).

As for vertical scaling, it's accomplished by increasing system resources, like adding more memory and processing power. Resizing a Droplet, for instance, is vertical scaling. While this can work as an immediate solution, it might be hiding the real problems underneath your application, and there's no guarantee a server twice as powerful will run your app twice as fast. Horizontal scaling, as briefly mentioned, is accomplished by adding more servers to an existing cluster (which is a group of servers). A load balancer distributes the workload between the servers in a cluster. At any point, a new Web server can be added to the existing cluster to handle more requests from users accessing your application; this is horizontal scaling. The load balancer has a single responsibility: deciding which server from the cluster will receive a request that was intercepted. It basically acts like a reverse proxy, making the process seamless to the user.

Restrictions on app workflows

As with most service providers, there are restrictions to keep in mind when choosing the one that's right for your app. Heroku, for one, requires that you use its build packages. For example, it also does not play well (or really, at all) with MySQL databases. You need to use PostgreSQL for your Rails app’s database when deploying on Heroku. With AWS, however, you can use PostgreSQL and MySQL. And with DigitalOcean you can use PostgreSQL, MySQL, Oracle and NoSQL.

Technical support and downtime

With Heroku and AWS, the dynos have an ephemeral file system (DigitalOcean has a persistent file system). An ephemeral file system means that you never know when files written to disk will disappear. If a dyno stops or is restarted, the files are gone. And that means that any applications hosted in Heroku shouldn't rely on any sort of local storage in order to work because, at the drop of a hat, that storage might be gone and there’s nothing you can do about it. Heroku also has limited locations, meaning there’s no regional redundancy. If you’re running an application on the US East location, and there’s a US East outage where a server goes down, there’s no backup servers that will allow your application to keep running, and so your application will experience that outage. Can you afford that kind if a hit? If not, your best bet is to go with DigitalOcean, which guarantees you 99 percent up-time -- and, if it fails to deliver, it will credit you for any downtime that the service was unavailable.

Takeaway

As we’ve seen, there are several options for deploying your app and sharing it with the rest of the world. Take a little time to weigh the pros and cons of these three hosting service providers and decide which makes the most sense for your (and your users’) needs.