Understanding Heroku

Based on - https://devcenter.heroku.com/articles/how-heroku-works

Deploy, run and manage Java application on Heroku:

1. Application = source code for application + web or application server framework + dependencies on third party libraries + dependency description (pom.xml) that instructs a build system (maven) to download the needed dependencies from a repository in order to build the application + Procfile.
2. Procfile - lists named commands that you may want executed.
    

web: java -jar lib/foobar.jar $PORT
queuty: java -jar lib/queue-processor.jar

Defines a 'web' process type and provides a command that needs to be executed in order to run it.

3. Git - used as primary means for deploying applications on Heroku platform. When application is created on Heroku, a new git remote is associated typically named "heroku" with the local git repository for your application. To deploy, simply do a git push heroku master. Thus git acts as a transport mechanism to push local application to heroku platform (remote).
4. When Heroku platfrom receives a git push, it builds the application - mvn clean install.
5. Slug - a bundle of application source code + dependencies + JRE + binary o/p from mvn install. A slug is the application ready for execution.
6. Dynos - Heroku executes the applications by running a command you defined in Procfile on a dyno (unix container like Docker) that has been preloaded with slug and config-vars and add-ons (together called a release).

Each dyno gets its own ephemeral filesystem - with a fresh copy of the most recent release. It can be used as temporary scratchpad, but changes to the filesystem are not reflected to other dynos.

7. To retain state information across dyno restarts use DB or message queues. The filesystem on a dyno are temporary.
8. User can control the number of dynos: heroku ps:scale web=3 queuty=2 for example will run 5 dynos (3 for web and 2 for queuty process types).
9. When a new version of application is pushed to heroku platform, currently executing dynos are killed and new ones are spawned to replace them with the new release.
10. Application config-vars are set as:

heroku config:set ENCRYPTION_KEY= my_secret_launch_codes

These are exposed to application as environment vars.

11. Release = version controlled ledger of (slug + config-vars + add-ons)

heroku releases - lists all changes deployed with their version id (internally they might be mapping version ids to git SHA ids)

Everytime you deploy, new slug is created and a release is generated.

Its thus very easy to rollback to a previous release.

Heroku releases:rollback v102

12. Dyno manager - manages dynos across all applications deployed on heroku platform.
13. Add-ons - are pluggable services like email service, Database service, queuing or caching services etc.

For example, a REDISTOGO_URL will be automatically added to your application when you provision the add-on. You can write code that connects to the service through the URL, for example:

uri = URI.parse(ENV["REDISTOGO_URL"])

REDIS = Redis.new(:host => uri.host, :port => uri.port, :password => uri.password)

14. Logplex automatically collates log entries from all the running dynos of your app, as well as other components such as the routers, providing a single source of activity.
15. HTTP Routing:

Heroku’s HTTP routers distributes incoming requests for your application across your running web dynos.