Heroku has a dashboard where you can easily manage your application. Through this dashboard, you can manage your resources, dynos, workers, add-ons, metrics, activity log, access permissions, and settings. In this chapter, you will learn to better understand these items.

Heroku Dashboard

Heroku also provides a command-line client to manage your applications. This client is called Heroku Toolbelt and is available at https://toolbelt.heroku.com. It is available for Mac OS X, Windows, Debian/Ubuntu, or in standalone mode. Heroku Toolbelt is a set of tools for managing and displaying the information about your applications. Most developers prefer to use Heroku Toolbelt instead of Heroku Dashboard because of the command-line facilities, in addition to offering a broader set of information. In the following chapter, you will understand how it works.

Heroku Toolbelt

The first item you need to understand is how the deploy process happens. An application is a collection of code with its associated dependencies. In the case of Ruby on Rails, these dependencies are found in Gemfile in Python requirements.txt, in Node.js package.json, and in Java pom.xml. This gives further information on how Heroku should work with your code.

If you use Ruby, Node.js, Python, or Java, Heroku can easily identify how to make your code executable, through the conventions that these languages adopt. For example, in the case of Ruby on Rails, Heroku knows it needs to run the Rails server to run your application.

If Heroku cannot run your application, you need to show how to do it. You must do so through the creation of a Procfile in your project, which contains instructions on how to run your application, as follows:

web: java –jar lib/my_app.jar $PORT

Heroku has adopted a very simple way to send your code to deploy. Each application built on Heroku has a Git repository, you should do a git push heroku master to start the deploy process. In the next chapter, you will deploy your first application and understand it better.

Heroku handles your code and dependencies by generating an optimized slug of your application. This slug is placed in each dyno that you have and each slug contains a compressed copy of your application. The slug is created by the slug compiler and its core is a collection of scripts called a buildpack. For each language supported by Heroku, there is one buildpack available. You can find more information about each of them in their repositories on GitHub:

The dyno manager is responsible for managing each dyno with your application slug.

Heroku's architecture is very robust and equipped to work with small applications such as blogs, personal websites, and large applications with a lot of users, such as Ello and Toyota.

This architecture serves the entire operation flow of its application, providing the mechanism to deploy your code until the management and scalability of your application.

The following diagram shows this architecture:

The Heroku platform receives HTTP requests coming from the entry point herokuapp.com or by your custom domain, and forwards these requests to the load balancer, then to the routing mesh that distributes it for each dyno. The routing mesh is a personalized solution developed in Erlang based on MochiWeb (https://github.com/mochi/mochiweb). Each dyno has its own queue of requests to be processed. When a dyno is available, it picks up a request from its queue and the application inside the dyno processes it.

Heroku HTTP routing

The Dyno Manager is responsible for maintaining the dynos running. When some dyno presents a problem, it is automatically replaced by a new dyno and the application information is loaded through the slug generated during the deploy. Because of the Dyno Manager, you do not need to make any changes to the operating system or other internal settings. Everything is done in an automated way.

The traditional approach is setting the configuration variables in the source code of your application; this approach is not useful, especially when you have many environments such as production, development, and test. The safer approach is creating environment variables. Heroku works with environment variables called config vars.

Config vars are necessary to run your application. Some of these variables are provided by Heroku and others are provided by add-ons that you have installed. You can also add your own config vars. For example, for Postgres add-on the config vars are provided credentials to access the database. All the provided dynos have the same set of config vars. These variables are copied automatically when you create a new dyno.

A dyno is a single virtualization in a Unix container. This container contains the slug of your application created during the deploy and you can add more dynos at anytime for scaling your application. The dyno does not persist changes in the filesystem and does not contain a database. To save files, you need to use a shared service such as Amazon AWS S3 (Simple Storage Service), and use the data store's add-ons such as Heroku Postgres, ClearDB MySQL Database, MongoLab (MongoDB), Redis Cloud, GrapheneDB, or others to share a database data between your dynos. You can see all the available data stores' add-ons at https://addons.heroku.com/#data-stores.

Heroku Dynos

Workers are responsible for running background jobs in your applications hosted on Heroku. This is a key feature for building really scalable web applications. Through the workers, your applications can resize images, perform data upload to other servers, fetch API data, send e-mail, and perform many other tasks in the background. Your web requests always return immediately improving the user experience. On Heroku, the workers are scalable, so you can increase or decrease the quantity at anytime.

Heroku has a marketplace of add-ons. The idea of these add-ons is to provide integration with third-party services simply and seamlessly into your applications hosted on Heroku. Currently, there is a wide variety of add-ons that are divided in categories: Data Stores, Mobile, Search, Logging, e-mail, SMS, Workers and Queueing, Analytics, Caching, Monitoring, Media, Utilities, and Payments. Add-ons include Heroku Postgres, PG Backups, MemCachier, AirBrake, New Relic APM, Logentries, Deploy Hooks, Heroku Scheduler, Zerigo DNS, SSL, Websolr, SendGrid, Mandrill by MailChimp, and Codeship. You can meet these add-ons at https://addons.heroku.com/.

PostgreSQL is provided on Heroku via an add-on called Heroku Postgres. This add-on has a number of plans that vary in their features such as cache size, storage limit, limit of simultaneous connections, and the ability to work with forks and followers. In the Choosing the right Heroku Postgres plan section, you will understand more about these differences.

Logplex is a distributed log collector, able to merge and redistribute multiple input streams to individual subscribers. Logs are collected from your app and other components of the Heroku platform. You can query this information through the Heroko Toolbelt or using the public API Logplex. These logs are collected from all the dynos and components that you have on Heroku.

The Heroku platform API allows you to create automated tasks, such as creating applications, collecting information from applications, managing add-ons, or performing other tasks programmatically, which previously could only be done through the Heroku dashboard. For example, Heroku Toolbelt uses Heroku API to perform its tasks.