Zerigo sets perfect example of how not to raise rates on prepaid plans

Zerigo announced this morning they are replacing their $39/year DNS Essentials plan with a $63/month plan, effective January 31, 2014.

That’s a month’s notice for a 1,800 % price increase.

But the worst part is, the annual plans are pre-paid, yet they will not grandfather existing annual plans through the end of the term… they are terminating pre-paid plans mid-way, and replacing them with a drastically-higher price plan.

Here’s the rub: due to infrastructure enhancements the new price actually is probably okay. But I would never remain with a provider who breaks their deal in that manner. They absolutely should have grandfathered existing plans through to completion.

UPDATE: painlessly migrated to Amazon Route53.

Getting S3Object.exists? to work correctly with IAM policies

When we updated our Rails 3.2 apps to each use their own IAM users and policies (instead of sharing a root S3 key/secret), we found that the aws-s3 (0.6.3) gem was causing S3Object.exists?() to always return true.

Although an updated aws-s3 gem may eventually fix the issue, the quick wrokaround was to modify the IAM policy to include both BUCKET and BUCKET/* (normally we need just the latter). Specifically:

{ "Version": "2012-10-17", 
"Statement": [ 
   { "Sid": "Stmt1234567890", 
    "Effect": "Allow", 
    "Action": [ "s3:*" ], 
    "Resource": 
         [ "arn:aws:s3:::SOMEBUCKET", 
          "arn:aws:s3:::SOMEBUCKET/*" ] 
}  ] }

Avoid “rate limit” errors when Geocoding in a Heroku app, using QuotaGuard add-on

We added some geocoding to one of our Heroku apps recently, and it seemed to be working fine during development and testing. However, once in production our automatic app health monitoring detected sporatic failures (the worst kind!) in the geocoding process. The logged showed the Google api would suddenly stop returning geocoding results due to rate limiting.

We were aware of Google’s limits on the geocode API, but our app uses geocoding infrequently so we were surprised to see the limits kick in.

In retrospect, the reason was obvious – Google meters usage by IP address, our app is hosted at Heroku, and the zillons of Heroku apps all share a very small number of IP addresses. So even if our usage was trivially small, other Heroku apps were chewing up the geocoding allotment for each Heroku IP.

Fortunately, the folks at www.quotaguard.com offer an add-on (currently in beta) to handle the situation… the ‘test’ plan provides a proxy service good for up to 2500 Google maps API requests/day, so your Heroku app’s requests to the geocoding api come from an IP supplied by Quotaguard (instead of the default Heoku IPs).

Enabling it was a snap:

  1. Add the quotaguard:test addon to your app

heroku addons:add quotaguard:PLAN (quotaguard:test for example)

This will add a QUOTAGUARD_URL setting to your Heroku environment, which you can see via heroku config

  1. If you’re using the geocoder gem, add this to config/initializers/geocoder.rb

Geocoder.configure( :http_proxy => ENV['QUOTAGUARD_URL'].gsub(/^http:\/\//, ''), :timeout => 5 )