Slicehost, AWS, and Heroku: Looking back at two years of deploying independent Rails apps

I started writing independent Rails apps on my own two years ago this month. One of the key decisions I needed to make early on was where to deploy my apps. After two years using three of the biggest players (Slicehost - now part of Rackspace Cloud Hosting, Amazon Web Services, and Heroku) I give you my take on the experience and toolsets available.

Slicehost - my first Rails deployment environment

Slicehost has a bit of a cult following. I came onto their service after they'd already been acquired by Rackspace, but despite that I felt very connected to the developers and sysadmins that ran it. You could literally jump into an IRC chat with the sysadmins on duty if there was a problem, and get help from the experts immediately.

I ran an application on a VPS from them for 18 months, had only a single service issue (which was handled quickly and professionally), and I basically didn't have to do anything to fix it other than wait for the sysadmins to do their thing. I also spun up several differently sized slices during that time (some for just a day or two for testing), and also seamlessly migrated slices between various sizes. The last time I had a VPS with Slicehost was June 2011, but the experience was great, and I'd recommend them to anyone who wants to run their own server in the cloud without a lot of frills. It's just the developer, and their server: a simple partnership.

Heroku - the slickest app environment around

Heroku. It is by far the easiest way to deploy a Rails app without thinking about infrastructure. Their suite of plugins (and how ridiculously easy it is to add/remove them on the fly) has no match. They also after completely free hosting for small apps with simple needs: a basic database, and a single dyno (web server instance).

It took me a while to try Heroku, but when I did, I found their support documentation to be up to date, detailed, and straight forward. I had no trouble at all getting my first app running on Heroku in less than an hour.I currently run a small app (rpglogger.com) on Heroku, and basically haven't had any issues. That being said, one thing that new developers run into with Heroku is the occasional gem incompatibility or obscure application error. I haven't had too much trouble along these lines, but I have, once or twice, had to do a quick Google search on an application error that only happened after deploying to Heroku, only to find that the solution was very simple: change a config setting, or update a gem. There's a big community of developers on StackOverflow that deploy to Heroku, and pretty much any problem you might have on their platform is documented by someone else who already ran into said problem.

Amazon Web Services - ultimate control

I do quite a few small apps in my spare time, and I find that AWS reserved instances are perfect for this. Since I already had experience running my own server on Slicehost, it was a pretty easy decision to pay only $60 to get a reserved server instance for an entire year (I was paying $25/mo on Slicehost at the time for the smallest slice). Just one micro server on AWS is enough to run 2-4 small apps on the same machine, with multiple web server instances (vs. Heroku's one free dyno), and still have a little memory left over. It's also hard to beat the availability and global deployment footprint of AWS. Since you can get any size server, AWS works equally well for any number of systems, including the independent app on a single server.

On top of the initial cost for the reserved instance, I only have to pay for bandwidth and other AWS usage (S3 storage, for example). This makes AWS an amazing mix of ultimate scalability, great costs, and ultimate control.

Rackspace Cloud Hosting provides similar services, and they're probably comparable for most things. But if what you want is the Swiss army knife of cloud services (servers, load balancing, storage, database, VPN, and even NoSQL options), I think AWS is still way ahead of everyone else.

Conclusions - right tool, right job (no surprise)

So, I started on Slicehost, then tried AWS, then Heroku, and today I'm back on AWS for most of my work. I can't really say too many bad things about any of these services. I think they serve different priorities very well, and that all of these services deliver on what they say they can do:

• Slicehost for really simple VPS
• Heroku for the slickest app deployment in town
• AWS for all the power and flexibility you could want

Continuous Delivery reading and resource list

This is a re-post of an article I wrote for NUBIC:

My technical project for the year, I've decided, is to build a continuous delivery system inside the NUBIC dev team.

Here's a quick reading list of source materials that I'm using to learn how to do it (blog posts to follow as I document the process of building the system internally):

• The Continuous Delivery book
• The Continuous Delivery blog
• Eric Ries' 5-step primer to Continuous Deployment
• Case Study: Continuous deployment makes releases non-events
• IMVU’s Approach to Integrating Quality Assurance with Continuous Deployment
• A series on the principle of "The 5 whys"
• The Pareto principle, a.k.a. the 80/20 rule

These things couple very well with additional practices that NUBIC embraces as part of its software development process, including:

• Test Driven Development
• Behavior Driven Development
• Continuous Integration
• Releasing much of our code as open source
• Kaizen - continuous improvement philosophy
• Doing well on the "Joel Test"

Finally, ThoughtWorks Studios has a commercial product called Go for automated release management. A couple of people from ThoughtWorks also happen to be the authors of the book on continuous delivery.

The most expensive calls to make via Google Voice from the U.S.

From the bag of random...

A year or two ago, North Korea was the most expensive place to call via Google Voice from the U.S. A quick scan over the latest rates show some interesting options, such as Antarctica, and calling several satellite phone customers.

The most expensive places to call (per minute) via Google Voice, from the U.S.: 

• $6.90 - Satellite Service - Inmarsat
• $4.99 - Satellite Service - Thuraya
• $4.03 - Satellite Service - Iridium
• $2.29 - Netherlands - (paging service)
• $2.00 - Antarctica
• $1.90 - Ascension Island
• $1.70 - San Marino - Conference Services
• $1.39 - East Timor
• $1.30 - Diego Garcia
• $1.19 - Sao Tome and Principe
• $1.09 - Niue

Why RTFM doesn't work

This is a re-post of the article I originally wrote for NUBIC:

It's not the users' fault. Honestly, it's not.

When answering a technical support question, have you ever asked someone, "Did you read the manual?" Well, put away your superiority complex for a moment, and realize that your users are wondering why they need a manual in the first place.

Manuals stink, plain and simple, so stop using them whenever possible. If you've got a complex application, website (or really any training process whatsoever), and you feel that you aren't receiving the respect you deserve for writing that 900-page, 100% comprehensive training manual, stop spending time on trying to improve the manual, and instead change the system.

Here are a few things you can try that are very simple, and very effective:

• Ask why - first and foremost you need to understand why the user is having a problem with your application, then you need to correct the flaw that is causing the problem in the first place, thereby eliminating the need for the user to ask the question at all. A great method accomplishing this is 5 Whys. During the process of asking "why" it's important to always be gracious about honest feedback, and curious about how people arrive at their state of confusion. Once you've figured out what's at the root of the problem, it's usually a trivial thing to change it.
• Show, don't tell - create a short training video that shows people how to use it, rather than trying to explain it via text and pictures. If your training video can't correctly explain it in less than three minutes, your app is either too complex, or your video is trying to do too much. Either fix your app, or sharpen the focus of your video. Great examples of awesome instructional videos are the videos that introduce SquareSpace. They are short, focused on a single topic each, and (in the case of SquareSpace) linked directly from the pages in which the related question might be raised in the user's mind. A user is editing a webpage and wants to know how to add an image? The video for editing pages is linked from the page editing screen. Simple. It's true that they still maintain a searchable collection of videos that any user can simply watch, but the fact of the matter is that pretty much no one is going to go through this library and watch all the videos first. Users will typically try something, and only when they fail, will they ask for help.
• Protect users from accidents - There are many times that users will do things that they don't know are dangerous until it's too late, and they can't go back! Whenever possible, provide an "undo" function that allows users to fix mistakes with a simple click or keystroke. This method is often far superior then shifting all responsibility to the user, and presenting them with, "Are you sure?! You cannot undo this!" sorts of messages. Those messages make users fearful, cause them to stop and call you for help making a decision about what to do, and ultimately shift blame to the user when simply providing an "undo" function largely avoids the problem from happening the first place. Even the most seasoned users will occasionally make mistakes. These people aren't "dumb," and they're just human after all. Do you really want to have to recover lost data, or blame them for the mistake, when your system could simply protect users from such accidents in the first place?
• Automate it - sometimes people make mistakes when doing repetitive tasks, because humans aren't as good at doing highly repetitive things accurately 100% of the time, as compared to computers. This problem is exacerbated by processes that have multiple steps, where a mistake in any one of the steps can cause the whole process to break down. Try helping the users of your site or application by pre-filling in values for forms, automatically inserting reasonable default values, or better yet, just completely automate the process whenever possible. If there's no reason that a human really needs to be involved in a process, take them out of the loop and save everyone some time and energy.
• Language is imprecise - step-by-step instructions, no matter how detailed and precise, no matter how carefully worded, are difficult to follow. Users gets lost in lengthy instructions, misunderstand or misinterpret technical terms, and people simply don't want to read instructions anyway. Providing users with a glossary of terms (thinking that the manual should explain itself) isn't really the answer either. So, use pictures instead of words when possible, and video instead of pictures when possible. The complications of interpreting language is part of why IKEA's assembly instructions contain no words, only pictures.

 The introductory page that explains how to avoid damaging your new furniture during assembly, and what to do if you need help or are confused. Pretty clear, yes? (1) put a carpet or rug under the pieces while assembling them, (2) if you're confused, look in the manual for a picture that shows what to do, and (3) call IKEA. Note that the last picture isn't a person on a phone calling IKEA - it's literally a handset connected to IKEA. When I see this, I think only two words: "phone IKEA". The implication is uncomplicated, and clear. Also note this caption of those four pictures took an entire paragraph. Not very efficient, friendly, or helpful, is it?

SQLite3 locking and database busy messages

Here's an old, but good post on understanding SQLite3 concurrency, threading, and simultaneous writing issues. It's something that many developers, especially developers of embedded and Rails apps that haven't migrated to another database such as MySQL, PostgreSQL, etc., have run into time and again.

The most confusing part seems to be that SQLite defines "concurrency" support as trying to be really fast, and therefore not holding onto exclusive write locks more than a few milliseconds, but that's not really the same as true, concurrent writes across multiple threads.

I continue to get the occsaional up-vote on this post, so it appears to be providing some long-term insight and value. Although the question is tagged as iOS, the answer is applicable to any use of SQLite where multiple threads are involved.

I am actually a big fan of multi-threaded code and code libraries in general, but it's a thing best weilded after acquiring some real-world experience (and failing a few times in order to understand the complexity of it). Until then, if you need multi-threaded access to a database, swap out your DB with one that handles this for you, rather than trying to figure out how to make SQLite concurrent write capable. If swapping out the DB is, for some reason, not an option for you, and you're only viable option is SQLite, then you need to stop trying to do multiple concurrent writes (change to a single-threaded app), or you'll drive yourself insane.

And for some multi-threading laughs, this extranormal video is awesome!