Replacing Heroku

For anyone still on Heroku and throwing addons at your application please stop and seriously reconsider what you are doing. Across the board things are getting a bit ridiculous for the average hobbyist / fincially conscious company. I used to be quite the Heroku fanboy but after my recent experience with Hosted Graphite I have changed my tone completely.

I was recently looking to add some Graphite metrics to a Heroku application that I’m working on and stumbled across a solution called Hosted Graphite. There was of course a starter package which shows off the beauty of Grafana and a few metrics to give you an idea of the potential. The current pricing can be found here (this prices do fluctuate quite regularly depending on the service); I’ve also gone ahead and added the current prices as of writing this below:

Each price point adds a few key features to the mix + increases your metric limit (this is a bullshit number stored by whatever service you are using so feel free to push it without too much fear. I’ll do a follow-up post on my experience with a MongoDB solution that had a document “limit”). The paid features for Hosted Graphite are as follows:

  • Daily Backups (>Tiny)
  • Data Retention (>Tiny)
  • Hosted StatsD (>Small)
  • Account Sharing (>Medium)

For most folks that are looking to use Graphite in their application they are probably looking to use some StatsD wrapper to report metrics. If you only have a few data points that you care about and can deal with the low retention rate / backup policy then maybe you could add an aditional worker to handle the task and not have to deal with a “hosted StatsD” solution. Even with that stretch of the imagination you are looking at a $19 monthly solution but most likely going to be suckered into a higher cost if you seriously start to add metrics.

Rather than paying for a plugable addon I’d highly recommend spinning up your own Digitalocean server for $10 bucks and get as much value as the Small package (this is being very generous..) being offered on Heroku. If you don’t know how to spin up a Graphite+StatsD server there is no excuse with the resources provided by DO alone:

Assuming that you can get through a basic set of steps then you should have a working Graphite+StatsD service at your disposal with 1/2 the monthly cost. The interface will be exactly the same (API key/namespace + service endpoint) and you will have the freedom to manage the server as you please. And when you are measuring things you sure as hell don’t want things to stop reporting because a reporting mechanism fails and you have no way to tell..

This is another major gripe that I have with Hosted Graphite; why would I pay for a service like “hosted statsD” when it will fall over and I have no debug info into why that might have happened. When testing with a Small instance of Hosted Graphite the StatsD endpoint would become unresponsive for minutes at a time while UDP/TCP were working as expected. On the other hand with a droplet you have the freedom of config (and Graphite, Carbon, and StatsD have a lot of configuration).

Configuration brings me to the final point I want to make. “Features” like Data retention length are nothing more than configuration that can be managed when setting up your Graphite instance. By configuring carbon you can set custom retention policies on different data points (regex matching FTW) and ensure that you have the policy in place that makes sense for the data being stored. This gives you the freedom of full flexibility inside of a problem-set that you are actively engaged in when adding measurements (naming new metrics). As a best practice you should set a reasonable default and add new metrics into the appropriate policies as needed.

Deploying Jekyll Site on Ubuntu VPS

Over the past few months Heroku has become an increasingly expensive option for projects that are starting to scale in any way (Addon price hikes, Dyno Sleeping and Charging, etc.). For ease of use and speed to spin-up up a prototype and have it running Heroku is still the leader and will continue to be my goto in times of need. But as soon as Dyno Charging becomes an issue I think it’s time to capify that app and use one of the many VPS hosting options out there.

For this project I wanted to migrate my simple static site to a $5 droplet on DigitalOcean. I’m sure you could get a better price on AWS but am fine paying the little bit extra for ease of use on DO.. After going through the initial server setup (groups, perms) it’s time to go though the actual server preperation.

Server Preperation

sudo apt-get update
sudo apt-get install nginx

Ensure that nginx is properly installed by visiting the public ip from the following command

ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'

If everything went correctly you should see the following nginx welcome screen (nginx will automatically start when installing on Ubuntu so there is no need to start the service before running the test):

For basic nginx service management use the following commands:

sudo service nginx restart
sudo service nginx stop
sudo service nginx start

Now that we have nginx ready to go on our server let’s install the final pieces to bring our Jekyll site to life.

sudo apt-get install git-core
curl -L | bash -s stable --ruby=2.1.2

After installing rvm there will be some information about the install process and some next steps that may be required to start developing. If you do not have access to rvm on the command line after install you may have to run the following or add to your ~/bash_profile:

source /usr/local/rvm/scripts/rvm

Once Ruby is running correctly go ahead and install jekyll and all it’s glorious dependencies.

gem install jekyll

Server Setup Compete

Now it’s time to set up your jekyll site for deploy. For this example we are going to use Capistrano 2.x

gem install capistrano
capify .

This will create a few config files but the one we want to concern ourselves with is config/deploy.rb

set :application, "blog"
set :repository, 'public'
set :scm, :none
set :deploy_via, :copy
set :copy_compression, :gzip
set :use_sudo, false

set :user, "deployer"

# the path to deploy to on your VPS
set :deploy_to, "/home/#{user}/blog"

# the ip address of your VPS
role :web, "XX.XX.XX.XXX"

before 'deploy:update', 'deploy:update_jekyll'

namespace :deploy do
  [:start, :stop, :restart, :finalize_update].each do |t|
    desc "#{t} task is a no-op with jekyll"
    task t, :roles => :app do ; end

  desc 'Run jekyll to update site before uploading'
  task :update_jekyll do
    # clear existing _site
    # build site using jekyll
    # remove Capistrano stuff from build
     %x(rm -rf public/* && rake generate)

Modify a few lines to suit your needs and you should be ready to cap deploy. To verify your new Capistrano deploy run the following; if both commands succeed without Warnings or Errors you will ready to deploy.

cap deploy:setup
cap deploy:check

Enjoy your Jekyll VPS