So, you’ve had an idea for an app, paid someone to create it, and now, you’ve been told it needs to live somewhere. Apparently, it needs to be “hosted”. What’s this even mean? How do I make it happen? And, how do I make it happen so it doesn’t keep me up at night worrying? Here at reinteractive we know what it takes to host and maintain an application.
An Introduction to Hosting Ruby on Rails Apps
When you view web content in your web browser, the content arrives to your computer from another computer (also known as a ‘host’).
In fact it’s most likely a group or ‘cluster’ of computers (hosts) working together to put together the content you requested.
And, in a fraction of a second it will be painted on the back of your retinas as you stare into your web browser.
This cluster of computers might include web servers, database servers, load balancers, firewalls, caches and a host of other possible servers. One of these computers will be the “server that executes the code for your application.
Collectively this cluster of servers, each performing its own critical task, is your web ‘host’.
At its simplest, a hosting service is simply computers or shared access to computers for rent. These hosting services generally have internet connections that allow you and your users to reach them. And they might have pre-installed software to perform the tasks users require. This might be database software, web services software, firewalls or even Minecraft services - it’s really anything you might need. You then rent the configured server as a hosted service.
A well engineered Ruby on Rails application hosting set-up consists of many of these services working together. For example: a load balancer to route traffic to your servers, several “application servers” and/or “web servers” to execute your code, a database server and perhaps “worker” or “async” servers for background tasks. You might add a secondary database server for availability or backups. To support that, you may also need a server to run scheduled jobs, often called cron. As your application scales up and reaches more users perhaps a cache server for bits of content that get reused often. There will be a DNS ( domain name system) server involved, probably servers to share static assets (for images) and to store up loads. For high traffic loads you will also add “edge servers” to cache static content in different geographic regions (also known as a Content Delivery Network).
Each of those component server types are a speciality in their own right; separate to the specialisation of handing Ruby on Rails, which is again separate to the task of connecting all of these services together. Each must do so in a way that is secure, maintainable and that will not break as your traffic grows.
How to Configure your Ruby on Rails Hosting
The options to take these services and connect them correctly to run your Ruby on Rails code are varied. You could read a great number of blog posts and divine your way through. Or you can pay someone else to do the same. I mean, surely your 14 year old nephew who ran his own Minecraft servers could sort it for you right?
The truth is, he probably could. But, who will watch your app closely and intervene when a disk gets full and the database crashes. Or be aware when a memory issue causes the web server to fail. Better yet, will he see these things coming days, weeks or months in advance and proactively prevent them?
In short, who do you want to rent reliable computer power from? Who do you trust to have it correctly configured to run each the various subsystems, plumb them together, configure more computer power with your rails app to talk to those subsystems in to a complete “rails hosting” solution, and do it in away that it can be scaled, AND THEN… monitor this potential ganglion of connectivity to ensure it stays up and running?
At reinteractive we’ve spent a lot of time dissecting this problem and offer a couple of solutions.
The Best Providers for Ruby on Rails Hosting
Amazon Web Services (AWS)
AWS is like a bucket of lego, there is always the right piece and colour needed that is just right for the job and it all snaps together to build your masterpiece. It’s perfect for any size operation from a one-man band to an organisation spanning the planet. Amazon offers pre-built solutions for several of the components above; databases, cache servers, DNS, and a boggling array of highly reliable, performant, well configured secure on reliable managed hardware.
It doesn’t solve the ‘how do I host my Rails application’ problem for you, however it does look after the first two tiers - where to rent reliable hardware and setting up the managed services like databases, networking and so on.
Heroku
Heroku is a great host for startups as adding services can be done incredibly simply allowing you to focus on developing your codebase. Heroku is part of the suite of services provided by Salesforce, so you can grow with Heroku and expand into the other Salesforce products.
Heroku runs their service on AWS, leaving it to Amazon to solve the “reliable hardware hosting” problem. Heroku takes this a step further offering managed database, network and routing and other services, and they have the how to execute Ruby on Rails software fairly well. So it’s very easy for any developer to push Ruby on Rails code and have its execution environment configured and running.
However this doesn’t solve the issue of monitoring the app, or ensuring it’s up and running. It also doesn’t respond to issues as they arise. Heroku looks after much of the hosting maintenance necessary, however there is maintenance the owner of the application is responsible for. Heroku is a fantastic service, but it’s incomplete from a view point of bringing complete peace of mind.
Why we prefer AWS Hosting for Ruby on Rails
-
AWS has dedicated itself to global support spanning 245 countries and territories ensuring you get your product to wherever you need it to be addressing concerns of sovereignty and perhaps of latency.
-
AWS has comprehensive security measures for your application, infrastructure, endpoints, identity and access, including encryption of data, global compliance requirements, and including automation of the manual security tasks.
-
End-user satisfaction - that is to say speed, latency and performance - is adequately handled by AWS global endpoints and specific measures taken within each of their products, especially those that store data in any way.
-
And to highlight my earlier lego comment, the product range is singularly impressive and is still growing. Here is a sample of the categories of services they provide: Storage, Migration & Transfer, Developer Tools, Robotics, Blockchain, Quantum Technologies, Management & Governance, Media Services, Machine Learning, Analytics, Security, Identity, & Compliance, AR & VR, Application Integration, Game Development.
reinteractive’s OpsCare - Managed Hosting & Support
OpsCare takes the hardware and other services and assembles its custom hosting service and hardware to offer a managed hosting service specialising in Ruby on Rails apps. Backed by AWS core services and the professional staff at OpsCare you get peace of mind that your app is always available to your customers and end-users.
Let’s look a little deeper into what OpsCare is under the hood.
When you sign up for OpsCare here is what happens:
-
You provide a new AWS Account with an IAM user administrator so the OpsStaff can build in the infrastructure for your Ruby on Rails application. Even though you are holding the root credentials, the OpsCare staff are a little protective of their stack and prefer that you let them handle all matters to do with the infrastructure, if you are like me and are a bit of a hands on guy then this may ruffle your feathers a little, but anyone willing to take all responsibility is refreshing.
-
Your app is prepared for the OpsCare stack. We comply with Heroku’s 12 factor principles https://12factor.net/ - which offers a structured way to think about how you organise the components of your app and how they interact with the world. This makes it readily deployable and scalable without ‘how the app is written’ causing unneeded complications and limitations to the hosting. We collaborate with you to ensure this takes place during onboarding.
-
We install the OpsCare gem which facilitates the installation of deploy hooks, and dependent gems for Skylight and Bugsnag, to which you are entitled to receive a login should you desire so. These two gems are to monitor rails controllers and report crashes that may occur. OpsCare staff use these so they can debug any problems that may occur during their tenure.
-
During the onboarding, the staff become aware of the app and its purpose so we can decide on best courses of action to take in the case of emergencies.
-
Domain delegation. Once the app is up and running OpsCare staff will attach a temporary domain so that the app has an internet presence and can be tested. The next step, then, is to set up a custom domain for your app. Either you will have a top level domain for the app, or, under your existing top level domain you will have a sub-domain. This has two benefits: all routing is accessible by OpsCare staff and thus any issues can be dealt with quickly, and of course centralisation of all things related to this app.
-
Our standard OpsCare stack includes two environments for your app, arbitrarily called
stagingandproduction. The purpose of the staging is to test upgrades and other server features for both our OpsCare staff and for your development team that will be implemented over time. Your development staff can use this to test code “in the wild” before deploying it to theproductionenvironment. Further, you can request extra environments be spun up should you desire it. -
When building the stack for the first time, the initial server instances are based on a recent Ubuntu AMI from amazon, then all the Ruby on Rails supporting services are installed including any specific services your app requires. Finally the latest release of your app is installed and then that instance is saved to an AMI ready to deploy to the stack. When you deploy your next iteration of code - an instance is created from that initialised AMI, the latest app source re-installed and then that instance is saved to a new AMI replacing the previous one. These AMI’s are saved sequentially so rollback can occur if required. Regularly, at least once per month, your saved AMI’s are updated for the latest service patches and updates.
Key Takeaways
Hosting a Ruby on Rails application with low volumes can be done quite simply on platforms like Heroku or by following a few blogs readily available on . This is quite effective for small-scale applications that are not mission critical.
Where applications increase in complexity, traffic and scale, a robust hosting architecture is needed so your application is available to users when they need it. Or if you have mission critical needs for your application, a professional hosting service is recommended.
With applications deployed on our OpsCare stack, you have the peace of mind of an app running on AWS hardware, using AWS services, with reinteractive taking responsibility for its uptime and availability. The operating environment is routinely brought up to date ensuring security patches are in place. Your system is monitored for issues and someone else is wearing the pager while you have peace of mind.
