Heroku Cloud Application Development: A comprehensive guide to help you build, deploy, and troubleshoot cloud applications seamlessly using Heroku.

Heroku is a platform, that is, an environment that provides you with the foundation to run your applications without worrying about the nitty-gritty of how it all works under the hood. You build an application, push it to Heroku, and voila, the slug compiler builds your source into an executable and ready-to-run application. What's more, it also creates a URL for the application to use. While all this magic works for you in no time, there is a robust, highly available, scalable, and failure-proof foundation underneath that makes all this possible. The core element of the Heroku platform is the Heroku stack—a combination of the operating system, language runtime, and associated libraries that provide a complete execution environment for users to run applications of varying workloads and scale seamlessly.

In the deployment stack, the operating system defines the base technology used by the Heroku platform, and it has varied across various releases of the Heroku stack...

In the current deployment stack, an app named myapp will have the default hostname of myapp.herokuapp.com. The herokuapp.com domain routes any request to Heroku via the routing mesh and provides a direct routing path to the corresponding web processes. This allows for advanced HTTP uses such as chunked responses, long polling, and using an asynchronous web server to handle multiple responses from a single web process.

The routing mesh is responsible for directing a request to the respective dyno in the dyno manifold. The routing mesh uses a round robin algorithm to perform the distribution of requests to the dynos as shown in the following diagram:

The HTTP request follows a timeout (30 sec) for the web process to return its response data to the client. If the web process fails to return the response within this time, the corresponding process log registers an error. After the initial communication, a larger (55 sec) time window is set for client or the server to...

The Logplex system forms the foundation of the Heroku logging infrastructure. It collates and distributes log messages from the application and other parts of the Heroku infrastructure. These entries are made available through a public API and the Heroku command-line tool. Due to the distributed nature of the Heroku platform, trying to manually access log messages across different application components and making sense out of those is practically infeasible. You cannot get a unified view of the entire system behavior if you collate these messages manually and try to troubleshoot problems. The Logplex integrated logging system provides an alternative in this case.

The Logplex system acts like a conduit that routes messages from log entry sources, that is, the producer of the log messages (for example, an application running on the dyno, the Heroku platform itself) to log entry drains, that is, consumers of log messages (for example, archival...

Add-ons are one way to extend the capabilities of a Heroku application. The user can add a new service such as caching or data storage to the app by provisioning an add-on and consuming the service offered. Heroku users have two ways to provision the add-ons:

The entire process of add-on provisioning and consumption is shown in the following diagram:

The following steps describe how a new add-on is provisioned and consumed by the Heroku app:

With Heroku Platform API, Heroku provides you with the ability to call the Heroku platform services to do virtually anything you need to do on Heroku—creating an application, checking the release history of your app, or plugging new add-ons in to your application. All this and more just by using simple HTTP. The following diagram depicts the interaction between a simple Heroku API client and the Heroku platform services. An API client can use the Heroku API to interact the core platform services of Heroku using a well-defined interface.

The Heroku Platform API allows you to do almost everything you can do with the Heroku command line or dashboard. This API is a powerful tool for application developers to leverage the capabilities of Heroku's features and gain complete control of their apps, from creating to monitoring them.

A Heroku application is a collection of processes that run on the Heroku dyno manifold. Whether you are running a local process or a remote one on a distributed cluster of machines, a Heroku application is essentially a set of processes, each consuming resources like a normal UNIX process.

To add flexibility and have better control over how you define your process configuration, Heroku defines the concept of process type. Each process that you run as a dyno can be classified as a web process or a worker process type depending on whether it handles HTTP requests or does some background processing. You could also define a custom process type to add flexibility to your application definition.

How often have we faced issues in the production environment that fail to reproduce in the development environment? Hence, it is critical that when developing and debugging an application, the code in a local development environment is executed in the same manner as the remote environment. This ensures that any differences between the two environments and bugs that hard to find are intercepted before deploying the code to production.

In a local development environment, you can run a small-scale version of your application by launching one process for each of the two process types: web and worker.

Foreman is a command-line tool used to run Procfile-based applications locally. It is installed automatically by the Heroku toolbelt (Heroku client package), and is also available as a gem.

If you don't have foreman installed, use the gem install foreman command to install it from the prompt.

Starting foreman is easy as shown in the following screenshot:

Since the Procfile...

Variables saved in the .env file of a project directory will be added to the environment when run by foreman.

For example, we can set SRCPATH_ENV to development in your environment, as shown in the following screenshot:

The command in the preceding screenshot runs the interactive shell and sets the value of the SRCPATH_ENV environment variable to SMS.

You can use the .env file for the local configuration as it has settings specific to your local environment. It does not need to be checked in or committed to Heroku.

Each application's set of running processes on the dyno manifold are known as its process formation.

The default formation for a simple application will be a single web process, whereas more complex applications may consist of multiple copies of web and worker process types. You can scale the process types on demand as your application needs increase.

For example, if the application already has a process formation of three web processes, and you run the heroku ps:scale worker=3 command, you will now have a total of six processes: three web processes and three worker processes.

Heroku's process architecture enables you to run a group of processes (process formation) or a standalone one-off process. On your local machine, you can cd into a directory with your app, then type a command to run a process. On Heroku's Cedar stack, you can use heroku run to launch a process against your deployed app's code on Heroku's dyno manifold.

To run the date command on Heroku as a standalone dyno, type the code as shown in the following screenshot:

The command displays the date on the terminal by running a standalone dyno with process ID 2963. Each of these commands is run on a fresh, stand-alone dyno running in different physical locations. Each dyno is fully isolated, starts up with a clean copy of the application's ephemeral filesystem, and the entire dyno (including the process, memory, and filesystem) is discarded when the process launched by the command exits or is terminated.

You can pretty much run anything on the Heroku platform. If you need additional features for your web app, you can use the supported add-ons and consume the add-on services from your app and provide newer capabilities such as monitoring (of the app) or data storage in your application. The possibilities are endless.

Let's say you want to swap the web server and worker system used for your Rails application and use Unicorn and Resque respectively instead.

You just need to change the Gemfile and Procfile, and that's it. You are ready to go!

The Gemfile changes are as follows:

gem 'unicorn'
gem 'resque'
gem 'resque-scheduler'

The Procfile changes are as follows:

web:     bundle exec unicorn -p $PORT -c ./config/unicorn.rb
worker:  bundle exec rake resque:work QUEUE=*
urgworker: bundle exec rake resque:work QUEUE=urgent

The urgworker is a new custom process type defined to signify tasks with an urgent QUEUE type. You get the flexibility of scaling these process types independent...

In this chapter, we delved deeper into the various components that form the Heroku platform. We understood the foundation of the Heroku platform, its stack, and how the currently supported Celadon Cedar provides different capabilities that help build and scale web apps seamlessly. We also looked at how user requests gets routed and finally executed in the Heroku execution environment. We briefly covered Heroku's Logplex logging infrastructure that helps trace the internal proceedings of your web app. We also looked at Heroku's add-on architecture that helps developers extend the Heroku platform and build newer capabilities for their apps. We learned how to programmatically execute Heroku operations by leveraging the Heroku Platform API and finally we reviewed the process architecture of Heroku—the single most important subsystem of the Heroku platform.

Now that we have the required foundational understanding of the Heroku platform, we will start learning how to build real, robust...