Heroku: Up and Running (2013)

Chapter 4. Heroku Regions

These days, everything is global. Only 20 years ago a business may have limited its area of operation to only those places within a few hours’ travel. Today, however, it is possible to trade globally and instantly. As for your applications, this means that you can interact with anyone, anywhere (your user base might consist of people in the United States, Europe, Australia, and Asia all at once).

So, what difference does this make to you? All of those users can access your application and use it—everything’s fine, right?

Well, for starters, let’s consider latency. Data travels down the pipe pretty fast, but there is a noticeable delay when working at very large distances. For instance, an application hosted on the eastern seaboard of the United States accessed from the United Kingdom has a latency of around 100 ms. The same application hosted in Europe, which is around 3,000 miles closer, only has a latency of around 20 ms.

When you are trying to wring every bit of performance from your application, this latency is not to be sniffed at—it’s a sizable performance saving, and more or less for free. Just by changing where your application is physically can make a huge impact on your application performance and the happiness of your users.

So, what other reasons might there be for moving your application around the world? For instance, some nations or regions have laws in place to protect their citizens and limit what people can do with their data. For instance, an EU citizen is protected by laws that prevent companies from moving their personal data outside the jurisdiction of the European Union without that citizen’s express permission. Here’s an example: if a person living in the United Kingdom enters his data into an application whose data centers are in the United States, and he is not aware of this fact, the owner of the application in question would be in breach of these laws. Therefore, it is imperative in these instances that people consider where their application is hosted physically. The most common of this type of legislation is Safe Harbor, an agreement between the United States and the European Union. Note that, at the time of writing, Heroku is not a registered Safe Harbor participant.

In the past, there has just been the concept of the cloud, but these days it is ever more important to consider the physical locality of where your application is hosted.

Multiregion or Single?

So, which do you want? Do you want to host your application in a single region such as the United States, or duplicate it in two such as the United States and Europe?

If you’re looking to serve core customers in a different region from where your application resides, or there are legal data-hosting issues such as those described in this chapter, then you need to have a presence in that specific region.

In the past, this would have meant a significant headache. Not only would you have had to gather all the infrastructure required to host your application, as well as maintaining it going forward, but you’d then be required to do it all again in another region, but dealing with infrastructure partners who were, quite literally, foreign to you. This introduced even more complexity, as well as a whole load more challenges such as managing servers potentially thousands of miles away.

The Heroku Way

How does Heroku handle this problem? Simply put, Heroku is able to clone itself in new regions and provide the complete native stack in exactly the same way as in the original U.S.-East region. What’s more, as all of Heroku is still controlled via a single API, there is almost nothing for you to do.

How to Deploy in a New Region

Let’s look at the traditional process for creating an application using the Heroku command-line interface:

$ heroku create my_great_app

Creating my_great_app…done, stack is cedar.

http://my_great_app.herokuapp.com/ | git@heroku.com:my-great-app.git

Git remote heroku added

On its own, this command provisions your application on the Heroku platform in the default region of the United States and sits there ready for a deploy.

Now, let’s take a look at how you might do this for deployment of an application to the EU region:

$ heroku create my_great_app --region eu

Creating my_great_app…done, stack is cedar.

http://my_great_app.herokuapp.com/ | git@heroku.com:my-great-app.git

Git remote heroku added

As you can see, this is almost identical. The simple addition of the region argument to your command changes where this application ends up, and where it serves from. What’s more, this is identical in its functionality to its U.S. cousin.

NOTE

At the time of writing, the available regions for deployment were limited to the United States and Europe.

So, how can you find out where an application is now that it is deployed? The region is shown in the application’s info:

heroku info

=== calm-ocean-1234

Git URL: git@heroku.com:calm-ocean-1234.git

Owner Email: user@test.com

Region: eu

Repo Size: 164M

...

NOTE

Applications always deploy to the same region that they were created in. At the time of writing, there is no way to move applications between regions once created.

Forking an Application

So, what about existing applications? How can we get those into Europe (or vice versa)?

Well, this is why Heroku provides fork, a simple way of cloning an application from one location into another:

$ heroku fork -a neilmiddleton neilmiddleton-eu-region --region eu

Creating fork neilmiddleton-eu-region... done

Copying slug... done

Adding openredis:micro skipped (This app is in region eu, openredis:micro is only

available in region us.)

Adding newrelic:standard... done

Copying config vars... done

Fork complete, view it at http://neilmiddleton-eu-region.herokuapp.com/

And that’s it. This command copies your application across to a new application in the European Union, provisions all the add-ons you have, including databases, and copies your configuration to your new application.

NOTE

Not all add-ons are available in Europe. Fork will inform you of this, as in the previous example.

Your new app won’t be scaled past a single web dyno as per normal for new apps, and the fork won’t have any of the domains attached to your old application. You’re free to try out and test your new app at your leisure until you want to make it live yourself.

Constraints

Given that these processes are very similar regardless of where you are deploying from, what things do you need to be aware of when using this functionality? Luckily not much, and those that you do need to be aware of are simple to work around.

Latency

Latency is always something to consider when building global applications and something that needs to be factored into your application architecture when using regional deployments.

For instance, a common use of regions is to create a localized clone of your main production application in a region closer to a chunk of your user base. For example, you may have an application hosted in the United States that receives 40% of its traffic from Europe. In this case, it would make a lot of sense to create a localized version.

While this may initially sound simple, the application side is easier than dealing with data. Unless your application has a neat data structure that can be split, both regions are going to want access to the same dataset. This means that you need to make a decision about where to host your data.

Initially, your biggest problem is that hosting your data in one region will induce some latency for all of the other regions having to communicate back to your database in your primary region.

Read/write architecture

A way around these problems is to use a read/write architecture. In these systems, all of your database write queries go to one database, and all of your read queries go to another. This is commonly used in scaling applications where one master will be receiving writes, and the reads are distributed among multiple followers.

In terms of using this with Heroku regions, you can achieve much of the same thing; you can create a master database in the United States, and create a follower for that database in Europe:

$ heroku addons:add heroku-postgresql:ronin --follow --region eu-west-1 \

HEROKU_POSTGRESQL_CHARCOAL_URL

Adding heroku-postgresql:ronin to sushi... done, v71 ($200/mo)

Attached as HEROKU_POSTGRESQL_WHITE

Follower will become available for read-only queries when up-to-date

Use 'heroku pg:wait' to track status

If you’ve followed along, you’ll have a primary database in the United States, and a follower in Europe, which—after a period of syncing latency—will contain the same data. Therefore, for EU customers, by sending all of our write queries to the U.S. database (which are generally infrequent for most applications) and our read queries to the EU follower, we are able to reduce the transatlantic latency for the majority of queries.

Note, though, that this is a very inexact science and depends heavily on the dynamics of your particular application. Some applications can separate their data entirely, thus removing all latency issues. Some applications will be very write heavy, thus increasing the problems with using a geographic follower.

In essence, the solution here is to experiment with different ways of structuring your application and determining what is acceptable for your own use case. Only then will you be able to appreciate where your application problems lie and how you might be able to solve them.

Add-Ons

One further consideration that you must take when carrying out regional deployments is that of add-on availability. As add-ons are provided by third parties, it is up to them to determine the locality of their services. Some add-on providers will provide their add-on locally to your application, some will choose to allow you to access them cross-region, while others will choose not to offer their add-on in specific regions at all. At the time of writing, most latency sensitive add-ons (e.g., databases, Redis, etc.) are available in both the US and EU regions, and nearly all non-latency-sensitive add-ons are available in both regions also.

The advice here is to check with the current state of add-on availability with Heroku at the time of making any decisions that this availability may affect.