Developed in July 2007, Heroku is a cloud Platform-as-a-Service (PaaS) supporting several programming languages and being used as a Web Application Deployment model. Heroku was acquired by Salesforce.com in 2010. Heroku, one of the first cloud platforms, has been in development after June 2007, when it supported only the Ruby programming language, but now supports Java, Node.js, Scala, Clojure, Python, PHP, and Go. Therefore, Heroku is said to be a polyglot platform as it lets the developer build, run and scale applications in a similar manner across all the languages – utilising the dependencies and Procfile. The Procfile exposes an architectural aspect of the application and this architecture aims to help the developer scale each part independently.
Heroku was initially developed by James Lindenbaum, Adam Wiggins, and Orion Henry, for supporting projects that were compatible with the Ruby programming platform known as Rack. The prototype development took around six months. Later on, Heroku faced drawbacks because of lack of proper market customers as a large number of app developers used their own tools and environment. In Jan 2009 a new platform was launched which was built almost from scratch after a three-month effort. In October 2009, Byron Sebastian joined Heroku as CEO. On December 8, 2010, Salesforce.com acquired Heroku as a wholly owned subsidiary of Salesforce.com. On July 12, 2011, Yukihiro "Matz" Matsumoto, the chief designer of the Ruby programming language, joined the company as Chief Architect, Ruby. That same month, Heroku added support for Node.js and Clojure. On September 15, 2011, Heroku and Facebook introduced Heroku for Facebook. At present Heroku supports MongoDB and Redis databases in addition to its standard PostgreSQL.
According to various sources: The term is merger of "Heroic" and "Haiku". The Japanese theme is a nod to Matz for creating Ruby and the word doesn't have a meaning because the creators didn't want the word to have a meaning, when it reached Japan.
Applications that are run from the Heroku server use the Heroku DNS Server to direct to the application domain (typically "applicationname.herokuapp.com"). Each of the application containers, or dynos, are spread across a "dyno grid" which consists of several servers. Heroku's Git server handles application repository pushes from permitted users.
The working can be summarised into two major categories:
- The main content of the development are the source code, related dependencies if they exist, and a Procfile for the command.
- The application is send to the to Heroku using either of the following: The git, GitHub, Dropbox, or via an API.
- There are packets which take the application along with all the dependencies, and the language runtime, and produce slugs. These are known as build-packs and are the means for the slug compilation process.
- A slug is a combination/bundle of the source code, built dependencies, the runtime, and compiled/generated output of the build system which is ready for execution.
- Next is the Config vars which contain the customizable configuration data that can be changed independently of the source code.
- Add-ons are third party, specialized, value-added cloud services that can be easily attached to an application, extending its functionality.
- A release is a combination of a slug (the application), config vars and add-ons.
- Heroku maintains a log know as the append-only ledger of releases the developer makes.
- The main unit which provides the run environment are the Dynos which are isolated, virtualized unix containers.
- The application’s dyno formation is the total number of currently-executing dynos, divided between the various process types the developer has scaled.
- The dyno manager is responsible for managing dynos across all applications running on Heroku.
- Applications that use the free dyno type will sleep after 30 minutes of inactivity. Scaling to multiple web dynos, or a different dyno type, will avoid this.
- One-off Dynos are temporary dynos that run with their input/output attached to the local terminal. They’re loaded with the latest 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 aren't reflected to additional dynos.
- Logplex automatically collates log entries from all the running dynos of the app, as well as additional components such as the routers, providing a single source of activity.
- Scaling an application involves varying the number of dynos of each process type.
A detailed description of the architecture involves-
- Define the application:
The definition of the application i.e. the source code and the description is built on the framework provided by Heroku which converts it into an application. The dependency mechanisms vary across languages: for Ruby the developer uses a Gemfile, in Python a requirements.txt, in Node.js a package.json, in Java a pom.xml, and so on.
- Knowing what to execute:
Developers don’t need to make a large number of changes to an application in order to run it on Heroku. One requirement is informing the platform as to which parts of the application are runnable. This is done in a text file that accompanies the source code - a Procfile. Each line declares a process type - a named command that can be executed against the built application.
- Deploying applications:
Application development on Heroku is primarily done through the GIT. The application gets a new git remote typically named as Heroku along with its local git repository where the application was made. Hence to deploy heroku application is similar to using the git push command.
There are a large number of additional ways of deploying applications too. For example, developers can enable GitHub integration so that each new pull request is associated with its own new application, which enables all sorts of continuous integration scenarios. Dropbox Sync lets developers deploy the contents of Dropbox folders to Heroku, or the Heroku API can be used to build and release apps.
Deployment then, is about moving the application from a local system to Heroku.
- Building applications:
The mechanism for the build is usually different for different languages, but follows the consistent pattern of retrieving the specified dependencies, and creating any necessary assets (whether as simple as processing style sheets or as complex as compiling code).The source code for the application, together with the fetched dependencies and output of the build phase such as generated assets or compiled code, as well as the language and framework, are assembled into a slug.
- Running applications on dynos:
Applications in Heroku are run using a command specified in the Procfile, on a dyno that’s been preloaded with a prepared slug (in fact, with the release, which extends the slug, configuration variables and add-ons).
Its like running dyno as a lightweight, secure, virtualized Unix container that contains the application slug in its file system. Heroku will boot a dyno, load it with the slug, and execute the command associated with the web process type in the Procfile. Deploying a new version of an application kills all the currently running dynos and new ones (with the new release) are started to replace them - preserving the existing dyno formation.
A customization of the existing configuration is possible as the configuration is done not within the code but in a different place outside the source code. This configuration is independent of the code currently being run. The configuration for an application is stored in config vars.
At runtime, all of the config vars are exposed as environment variables - so they can be easily extracted programatically. A Ruby application deployed with the above config var can access it by calling ENV["ENCRYPTION_KEY"]. All dynos in an application will have access to exactly the same set of config vars at run-time.
The combination of slug and configuration is called a release. Every time a new version of an application is deployed, a new slug is created and release is generated.
As Heroku contains a store of the previous releases of the application, it’s designed to make it easier to rollback and deploy a previous release. A release then, is the mechanism behind how Heroku lets the developer modify the configuration of the application (the config vars) independently of the application source (stored in the slug) - the release binds them together. Whenever the developer change a set of config vars associated with the application, a new release will be generated.
- Dyno manager:
Dyno manager help maintain and operate the dynos created. Because Heroku manages and runs applications, there’s no need to manage operating systems or additional internal system configuration. One-off dynos can be run with their input/output attached to the local terminal. These can additionally be used to carry out admin tasks that modify the state of shared resources, for example database configuration - perhaps periodically through a scheduler.
Dynos don't share file state, and so add-ons that provide a few kind of storage are typically used as a means of communication between dynos in an application. For example, Redis or Postgres can be used as the backing mechanism in a queue; then dynos of the web process type can push job requests onto the queue, and dynos of the queue process type can pull jobs requests from the queue. Add-ons are associated with an application, much like config vars - and so the earlier definition of a release needs to be refined. A release of the applications isn't just the slug and config vars; it’s the slug, config vars as well as the set of provisioned add-ons.
- Logging and monitoring:
Heroku treats logs as streams of time-stamped events, and collates the stream of logs produced from all of the processes running in all dynos, and the Heroku platform components, into the Logplex- a high-performance, real-time system for log delivery. Logplex keeps a limited buffer of log entries solely for performance reasons.
- HTTP routing:
Heroku’s HTTP routers distribute incoming requests for the application across the running web dynos. A random selection algorithm is used for HTTP request load balancing across web dynos - and this routing handles both HTTP and HTTPS traffic. It additionally supports multiple simultaneous connections, as well as timeout handling.
- The Heroku Platform
- The Heroku network runs the customer's apps in virtual containers which execute on a reliable runtime environment, heroku calls these containers Dynos. These Dynos can run code written in Node, Ruby, PHP, Go, Scala, Python, Java, Clojure. Heroku additionally provides custom buildpacks with which the developer can deploy apps in any additional language. Heroku lets the developer scale the app instantly just by either increasing the number of dyno or by changing the type of dyno the app runs in.
- Heroku Postgres
- Heroku Postgres is the Cloud database (DBaaS) service form Heroku based on PostgreSQL. Heroku Postgres provides features like continuous protection, rollback and high availability and additionally forks, followers and dataclips
- Heroku Redis
- Heroku Redis is the customised Redis from Heroku to provide a better developer experience, it is fully managed and is provided as a service by Heroku. It helps in managing instances with a CLI, associate data with Postgres to gain business insights using SQL tools and lets customer gain performance visibility
- Heroku Teams
- Heroku Teams is a team management tool which provides collaboration and controls to bring customer's developers, processes and tools together in order to build better software. With Heroku Teams, teams can self-organize, add and manage members, get fine grained control with app-level permissions and additionally use collaboration tools like Heroku Pipelines. It additionally provides delegated administration and centralised billing.
- Heroku Enterprise
- Heroku Enterprise provides services to large companies which help them to improve collaboration among different teams. It provides a set of features like fine grained access controls, identity federation and private spaces, to manage their enterprise application development process, resources and users.
- Heroku Connect
- Heroku Connect lets users to Heroku apps that can easily integrate with Salesforce deployments at scale. This is done by having a seamless data synchronisation between Heroku Postgres databases and Salesforce organizations
- Heroku Elements
- Heroku Elements provides users with Add-ons -Tools and services for developing, extending, and operating the app , Buildpacks-Buildpacks automate the build processes for the preferred languages and frameworks and Buttons -one-click provision, configure and deploy third party components, libraries and pattern app.