#Devops

A forum foray into end-of-year management summaries (with ledger-cli) had a handful of people asking about my blog setup and its speed. I realized it’s changed significantly from posts three years back (and where I was using Jekyll and Gatsby), so time for an update post.

TLDR

The benefits of this setup are:

• very fast - due to static content and CDN (content delivery network)
• cheap - pennies-a-glass: it costs me ~$1 USD a month even for very large traffic amounts
• discovery - unlike other setups on managed providers like Github Pages etc, it’s SEO-friendly
• easy-to-operate - simple, easy commands to setup and execute deploys
• zero-maintenance - other than Amazon SSL cert updates (now automatic), have not touched it in nearly 3 years now

Despite the fact I was not the biggest Go fan at the time, I tried Hugo . Hugo was blazingly fast to build, has a heap of convenience features I really liked, and a nice ecosystem of plugins, along with some decent themes. Also, it compiles/comes as a single static binary to use. While Jekyll and Gatsby are both nice, both were dead slow to generate (additionally, every node update kept breaking Gatsby or its plugins when I was using it.). Hugo also takes care of your asset pipelining for you which can be a major headache with other static site generators.

Let’s Encrypt has done an amazing job of making https the new normal for web sites and helping create a more secure and private internet by giving away free, automatic ssl certificates to domain owners.

You should be encrypting your web traffic (and need to, to take advantage of new protocols like http/2. Some implementations have stated they will only support http/2 over an encrypted connection. And currently, no browser supports http/2 unencrypted afaik.). Add to this the fact Google will start penalizing non-secured sites in search results, and https is fast becoming the de facto standard.

Padrino works great on heroku with just a simple git push heroku master, but you can get a surprising bump in performance simply from using Puma in production rather than the default heroku web server.

That also goes for using it on your local development machine, but heroku uses Procfile based spinning up of apps, so you should also test locally on your dev box, using heroku’s handy foreman before pushing it live to heroku.

Strangely, one of the earliest things I learned in unix computing was crontab -e. In fact, it would not be an exaggeration to say, the reason I learned to use vim in the first place, was so I could fire off automated jobs in cron while I slept (Don’t ask. Mine was a complex childhood. :-) ).

I’ve never been a fan of Apple’s launchd replacement on the OSX operating system.

So, I got the call every techie dreads: 4.30am “OMG, we’re down!”

It was from Canada and I’m in Oz, so you know it was bad. As most people know now, Amazon’s US East Region was out and had taken down heroku where we host the main LeadNow site . We’re in the middle of spruiking democracy for the Canadian federal election and have been a central pivot for vote mobs and voter socials, so getting back up was really important ahead of the weekend.

Continuous integration is key to good development practices if you’re a team any larger than, well… one. But spinning up a CI server is still an exercise fraught with peril.

Add in getting one up for Rails that can deal with Cucumber and capybara testing (needing a browser for js testing) and rspec and if you don’t have someone with solid sysadmin skills, most teams throw up their hands. Also, if you’re doing this for short duration projects (yeah, I’m looking at you RailsRumble and Hack weekends), you really want something that you can spin up or down at will and not have serious iron dedicated to doing this. We chose to put ours on Amazon’s EC2. We chose Hudson, a rather excellent java CI server despite my personal feelings about java (and also the excellent hudson ruby gem that makes running it locally no effort at all).

Great list of paradoxes on the use of cloud computing from the always insightful O’Reilly Radar. We use cloud services heavily at GetUp, mostly because we have no real infrastructure and try to avoid long-term investment to stay lean, but these are excellent thought exercises to go through if you’re the CIO/CTO of your org.

1. Create flexibility by being less flexible
2. Determine the cost of an existing IT solution
3. Simplify the environment by introducing more complexity
4. Provide assurances of sustainability in a domain of uncertainty
5. Maintain security while reducing it

Details on each of the puzzles after the jump .

First off, I should probably tell you that I totally ♥ Heroku . I run a bunch of little apps off it and at work believe it’s production ready for our main platform. A while back someone posted a nice little snippet of how to get a static site working on it in two lines of code on heroku, however, with some change in heroku, gem packaging or the like (or fact I added in multiple custom domains for the site), these static served pages suddenly stopped working. Counterintuitive when looked at, and even @radar and I together looking at it couldn’t figure it out. Anyhow, I puzzled the following out. Probably a few of the gems can be removed but this definitely worked for me.

If you’re a CTO moving heavily into cloud services, one of the things that keeps you awake at night is what happens if one of your providers goes under or just becomes so unreliable you have to move. Let’s face it, lock in goes along with the cloud as the fact of the matter is you code to exploit a specific platform.

The amazing thing about Fog is that it acts as a universal interface in front of the cloud, allowing you to control a variety of cloud services though a unified API. It deals with both servers and storage already supporting EC2, Rackspace servers, vCloud and Slicehost and numerous cloud based storage vendors S3 and Rackspace Files.

I have to admit to have become more and more enamoured of heroku for production class hosting of Rails and Ruby applications. It makes things pretty painless (see my first post on gotchas for my first deploy there) and for Nunemaker’s rather strong sentiment, You’re An Idiot for Not Using Heroku .

It does kick ass if you’re getting stuff up fast, but if you’re moving into more serious production environments with multiple devs and you also need a staging environment, the simple git heroku push master gets to be too simple. You really need something capistrano -esque for managing deployment even to heroku.