The Heroku platform stack
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. Each of these releases has supported a different set of programming language runtimes. The currently available Ubuntu 10.04 Linux operating system-based flavor of the Heroku stack is called the Celadon Cedar stack. With the adoption of the Celadon Cedar stack, Heroku has matured into a solid polyglot platform that natively supports the most popular language runtimes for application development. From supporting Ruby in its initial release, Heroku now natively supports six programming languages, and the list is growing.
Over the years, Heroku has supported the following three distinct deployment stacks:
* MRI: Matz Ruby Interpreter
** REE: Ruby Enterprise Edition
Further details of Heroku's language support can be found at https://devcenter.heroku.com/categories/language-support.
The Celadon Cedar stack
Celadon Cedar is the default deployment stack for the Heroku platform going forward. Loads of applications deployed on Heroku may still be running the Badious Bamboo stack as Heroku supports it for backward compatibility. However, it is recommended that users migrate to the Cedar stack to leverage the latest features. It is also suggested that users should first test the application with the supported language runtime on a test (staging) environment before moving the entire application to production on Cedar.
The Cedar stack brings in many interesting enhancements to the Heroku deployment stack including the following stacks:
- Multi-language support: Cedar is a general purpose deployment stack, meaning it does not provide native support for any of the programming languages. It provides the ability to add support for a language virtually on demand through a build-time adapter mechanism called the buildpack. The buildpack can compile the application written in a particular programming language into a binary executable that is executable on the runtime provided by the Cedar deployment stack.
Officially, Cedar provides support for REE 1.8.7, MRI 1.9.2, Node.js, Clojure, Java, Python, and Scala; though you could add a new buildpack for a language of choice and virtually run an application written in most of the programming languages on the Heroku platform.
The ease of using these custom buildpacks has led to developers providing support for many popular languages such as PERL, Go, and Common LISP. Running applications with a custom buildpack is as easy as specifying an environment variable
BUILDPACK_URLand passing the buildpack URL at the application creation time like the following:$heroku create --buildpack <BUILDPACK_URL> - The new process model: The Cedar stack leverages the underlying UNIX process model to provide a seamless process execution environment that can scale on demand and provide fault tolerant application services. The process model framework provides detailed granularity to manage applications in a process execution environment that can span multiple machines. The process model introduces the concept of Procfile (short form for process file), which is a configuration file for your process formation. The various types of processes and how to run them can be specified in Procfile. The existence of Procfile gives great flexibility in choosing the right size of your application processes.
The process model also enables you to run one-off processes on the command line, hence provides greater flexibility when running utilities or application just this one time. You can scale particular process types to run more processes on the fly, and the underlying execution environment takes care of starting the new instances automatically.
The flexibility provided by Procfile also helps in replacing any executable with another, if an upgrade is required, for example, if you want to replace one web server with another due to application requirements.
- Finer troubleshooting: One extremely intelligent feature of the Heroku platform is its intuitive command reference to run, monitor, and manage application tasks. Unlike many other PaaS offerings, Heroku provides a UNIX-like command reference that is easier to learn and start using. Most common Heroku CLI commands on the Celadon Cedar stack are named after UNIX shell commands prefixed with Heroku to provide the distinction.
For example, a simple command to check your Heroku process status is shown in the following screenshot:
The output shows that currently two web processes are running for
3hand2mrespectively. The line with===shows the command being executed in the Heroku execution environment. Besides being close to the UNIX syntax whenever it can, Heroku also provides a straightforward syntax to manage processes. For example, to decrease the number of web process types and increase the worker process types, all that is needed is the following one liner:Use the
+(increment) and–(decrement) indicators to increase and decrease the number of respective Heroku processes, as shown in the following screenshot:
Checking the logs for troubleshooting applications or verifying the process flow is as simple as the following screenshot shows:
The last few (log tail) log statements can be viewed by the
heroku logs –tcommand.What's more, you can filter log messages for a particular process type. To filter log messages from the process
worker.1and list the corresponding log messages, use theheroku logs --ps worker.1 –tcommand.Here, the user is trying to filter log messages for the
worker.1process only. This flexibility is extremely powerful in troubleshooting a large process formation by specific process instances. - Release management: On new code deployment, whether it is configuration changes or modification (adding/removing) of resources, Heroku creates a new release and restarts the application automatically. Heroku provides the flexibility to list the history of releases and uses rollbacks to revert to prior releases, in case deployment or configuration went wrong. To list your releases, type what is shown in the following screenshot:
To demonstrate, how to modify your application, I have added a new configuration variable, as shown in the following screenshot:
Verify that a new release is added by Heroku, as shown in the following screenshot:
Finally, I rollback the changes to Version 2 as shown in the following screenshot:
