Professional Heroku Programming

Chapter 2

Architectural Considerations

WHAT’S IN THIS CHAPTER?

• Building twelve-factor apps
• Managing your app portfolio with pace layering
• Ensuring security and compliance
• Understanding redundancy and reliability
• Securing your Heroku app
• Encrypting communications
• Storing static assets and using content delivery networks

Although developing on Heroku is not very different from developing on any scalable architecture, some architectural considerations should be taken into account. Heroku’s architecture is stateless and temporary, which makes it highly scalable. Dynos are ephemeral, so they should be considered temporary. This means that apps need to be written to be scaled horizontally, which enables them to be easily architected to solve big problems and load faster. However, because of its temporary nature, Heroku is not well suited for apps that are stateful on the server level or for apps for which sessions are stored locally on each server.

You must carefully consider the overall architecture of the system you want to build, which typically is broken down into the following three parts:

• Language and framework: Skilled craftspeople have a selection of tools in their toolbelt, allowing them to choose the best one for the job. Heroku’s polyglot nature enables a broad choice of languages and frameworks to choose from, allowing you to select whichever best fit the job at hand. You can use one of Heroku’s many pre-built, readily available, and fully supported languages and framework ...