Book Notes: Heroku Up and Running

my notes
portrait of a young boy taking notes

Some time ago I read an early release of the O’reilly book Heroku Up and Running  by Neil Middleton. Here are my impressions and notes that struck me from the book for whatever reason.

The book is a nice overview of Heroku

It covers the history of Heroku, the Heroku philosophy, and gives many insights into how it all works and why it works that way.  The ebook is only $8 and available right now. I found it worth the money. The formal release was scheduled for October 2013. 

As a casual user of Heroku, this book helped fill in many blanks and give me a more solid footing for visiting the Heroku developer site. The hard-core documentation is left to that developer site.

Contents

The following are the chapter titles with some of my own comments in parentheses.

  1. What is Heroku?
  2. How Heroku Works
  3. Understanding Performance and Scale
  4. Heroku Regions
  5. Heroku Postgres
  6. Deployment
  7. When it goes wrong (debugging Heroku apps and getting support)
  8. Buildpacks (extending Heroku to support even more binaries)

Notes and Highlights

Notes and highlights from reading the book.  Take it for what it’s worth.

Kindle Location

Highlighted Text

My Commentary

96

I switched back to using Heroku and found that those things I couldn’t do once, I had no desire to do anymore. What once seemed like arbitrary limitations, now showed as well seasoned advice from an opinionated platform.

Heroku is an opinionated platform. It’s forcing you to build apps that scale well horizontally.

269

Heroku idles any applications running a single dyno when not in use to free resources for other applications.

Since 1 dyno per app is free, they reserve the right to idle it. This means you will sometimes have to wait many seconds for your app to come back up. If this is a problem, run at least 2 dynos and they won’t idle you.

292

the router processing the request will only wait for 30 seconds before returning a timeout error to the end user.

30 seconds is an eternity in web land.

294

Once that first byte of response is returned, the router will then set a 55 second rolling window before an error is returned.

You can still stream things using Heroku.

337

release comprises a combination of your application code (or slug), and the configuration around it.

Heroku tracks all the releases your app has ever had.

414

Once your application is up and running its dynos are silently cycled automatically once a day to ensure that the dyno image version they are running is the latest available runtime (your slug will stage the same) You can see this in your application logs as Cycling against a particular dyno. Therefore, if you were to deploy an application to HEroku and leave it for several months, it would be no more out of date than on deployed a day ago.

Woah! Nice!

Also means your dynos aren’t running for hundreds of hours in a row. Might hide endurance problems like memory leaks.

420

A dyno can be thought of like a container for UNIX processes.

If it runs on linux, and you can get it to run on a small AWS instance, you can probably get it running on Heroku.

428

You can also schedule one-off background tasks with Heroku’s scheduler. This is like a worker, bot only runs a specific command for a given interfal. This is very similar to how you might schedule a task to be run with Cron. Tasks run by scheduler are only charged for the time they use.

Heroku makes it easy for you to run your worker processes as cheaply as possible.

452

Heroku does not provide log files per se, but offers this stream.

Instead of copying down a huge log file, you direct a stream to a log analytics service like log entries. In our case, we “drain” our logs to Splunk.

483

Heroku Postgres.

Heroku provides it’s own postgres add-on. It is pretty tricked out. We don’t need it here, but it was a very interesting read nonetheless.

484

If you are deploying using a popular database backed web framework, such as Ruby on Rails, then Heroku will provision and configure the PostgreSQL add-on for your application.

Automatically.

499

You can push into other branches if you wish, but these will only be stored on Heroku and not deployed as the platform will only ever deploy the master branch.

To deploy code, you push it to master.

503

Heroku takes your code and identifies it [using build packs].

Buildpacks are what allowed heroku to become a “polyglot” platform. In this paragraph, they function as links in a chain of responsibility–automatically sensing the type of project being deployed. The can do much more, too.

507

Buildpacks are provided by the Heroku operations team, but also by other opensource developers.

 

517

All of the default buildpacks can be seen on GitHub here: https://github.com/heroku

 

556

Heroku uses “ephemeral” disks, that are cleared at least once every 24 hours.

Just don’t use the disk.

587

Heroku does not auto scale your app for you.

They have a pretty decent rationale for why they don’t provide autoscaling and why they have no plans to do it in the future. You have to manually change the dyno count.

599

Heroku can give you access to the tools in order to measure and make scaling easier than ever, but there should be a few eyes on the process.

 

618

When a request arrives, it is randomly sent to one of your applications and available dynos for processing. Should a dyno be unavailable for some reason, it is dropped from the pool of dynos receiving request automatically. However, remember that while this is happening, the router processing the request is counting down from 30 seconds before returning an error to the user. Therefore, it is important to monitor your application’s queue length to see if more resources are required to handle the load.

 

649

Heroku’s Cedar stack has no Nginx or Apache layer to serve static files.

For performance, use a CDN.

705

Frameworks such as Rails have the ability to “auto explain” any queries that run over a given threshold while in development.

Nifty!

742

While this strategy can work well for development and prototyping it scales horribly. The more entries you have in your database the worst speed and relevancy will be.

Apropos using text search in the database for implementing a search feature. They recommend using a dedicated search technology like Lucene.

754

don’t ship your “search” feature powered by a like query.

 

760

If you’re interested in getting real world performance measurements, there are two ways to keep track of your app. Use in app performance analytics services and use external load and performance testing tools.

 

787

One simple, yet useful tool for this is “YSlow,” which will attempt to “rank” the front end performance of your app and give you general advice on how to improve.

 

842

At the time of writing the available regions for deployment were US and EU only.

 

850

Heroku have provided fork, a simple way of cloning an application from one location into another:

Heroku tries to make it easy to set up your app in multiple availability zones.

947

Heroku will do everything aside from architect and optimize your database. There is no need to worry about patching for security or stability, and there is no need to worry about backups; everything is taken care of for you. All that is left for you to do is to worry about your data and how to store it efficiently.

That is, if you use their PostgreSQL add-on.

1261

Running on rolled-back code is meant as a temporary fix to a bad deployment. If you are on rolled-back code and your slug is recompiled (for any reason other than a new deployment) your app will be move back to running on the most recent release. Subscribing to a new add-on or adding/removing a config var will result in your slug being recompiled.

Important caveats to the roll-back feature.

1273

A simple way of improving [the size of your slug] is via the .slugignore file.

Just like .gitignore. You can use it to strip test resources from your slug, for example.

1277

.slugignore uses exactly the same format as .gitignore.

 

1372

when setting up your own DNS, it is always a good idea to use CNAME’s to alias your domain to the herokyapp.com domain

of course, we use a reverse proxy.

1379

Some companies such as DNSimple now offer their own custom types of records in your DNS that allow you to alias apex domains the same way as a CNAME.

 

1410

The Heroku DevCenter can be found at http://devcenter.heroku.com

Mkay!

1427

checking http://status.heroku.com can save you a bot of headache if the issue isn’t on your end.

yup

1434

You can subscribe to notifications and wait for it to come back online.

… if Heroku is down.

1439

making sure config, add ons and any labs features are on par across both servers: $ heroku config ; heroku addons:list ; heroku labs:list.

Useful when cloning apps for debugging.

1444

trick for forcing a deploy is to add a blank commit in your project $ git commit –allow-empty -m “debugging”

We do that a lot around here.

1454

pull out the big guns and use a custom debugging for of the buildpack.

Very powerful technique for when you just can’t figure out why the deploy won’t work.

1462

In the compile step of a buildpack anything sent to the standard out will display in the build process.

 

1476

point the BUILDPACK_URL of your staging app to your repo, check that your changes were pushed correctly to the repo specified in the BUILDPACK_URL.

The BUILDPACK_URL config variable can force Heroku to use a particular buildpack for your app. Set it to your debugging fork when debugging the deploy.

1478

simply remove the BUILDPACK_URL from your staging app’s configuration vars

when you are done debugging

1481

deploys shouldn’t take too long.

Otherwise you lose a lot of the benefits of continuous delivery, which is a basic part of the Heroku philosophy. It also slows you down when scaling up.

1484

the timeout may change in the future, it will likely stay somewhere around the 10 minute mark.

Heroku limits how long your build can take.

1513

To help out with notifying team members and building deploy related applications Heroku offers a Deploy Hooks addon: $ heroku addons:add deployhooks:email

 

1538

It is a good idea to run performance metrics once or more a week to determine if your application’s data stores are running out of capacity.

 

1556

You can attach an unbounded number of log drains to a Heroku application without impacting the performance of your Heroku app.

We currently drain to Splunk.

1560

If your application has a logged in user state and there is a restricted admin flag on users, it can be helpful to use dynamic error pages.

These pages can show fault details to developers, but vanilla error messages to users.

1571

Since many [exception notification services] group related exceptions it can be very useful for determining the issues that affect the most users.

 

1771

Once you’ve got [your own] simple buildpack you can leverage the existing Heroku maintained buildpacks along with another community maintained buildpack called “heroku-buildpack-multi”

You can create buildpacks that add elements to the runtime environment and feather them all together with standard buildpacks using the multi buildpack.

1776

Instead of deploying using someone else’s buildpack off of GitHub, you should fork it and deploy using your own copy.

Since the build process is so important for replicating results, the author urges you to keep your own copy of custom buildpacks.

By Tyler Peterson

Web Developer and a hiring manager at an established technology company on Utah's Silicon Slopes in Lehi.