|Industry||Cloud platform as a service|
|Founder||James Lindenbaum, Adam Wiggins, Orion Henry|
|Headquarters||San Francisco, California|
|Tod Nielsen (Former CEO)|
|Products||Heroku Platform, Heroku Postgres, Heroku Redis, Heroku Enterprise, Heroku Teams, Heroku Connect, Heroku Elements|
Heroku is a cloud platform as a service (PaaS) supporting several programming languages that is used as a web application deployment model. Heroku, one of the first cloud platforms, has been in development since June 2007, when it supported only the Ruby programming language, but now supports Java, Node.js, Scala, Clojure, Python, PHP, and Go. For this reason, 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. Heroku was acquired by Salesforce.com in 2010 for $212 million.
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 many 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 Redis databases in addition to its standard PostgreSQL.
The name "Heroku" is merger of "heroic" and "haiku". The Japanese theme is a nod to Matz for creating Ruby. The creators of Heroku did not want the name of their project to have a particular meaning, in Japanese or any other language, and so chose to invent a name.
This section contains instructions, advice, or how-to content. (November 2016)
This section needs editing for compliance with Wikipedia's Manual of Style. (October 2016) (Learn how and when to remove this template message)
Applications that are run on Heroku typically have a unique domain (typically "applicationname.herokuapp.com") used to route HTTP requests to the correct dyno. 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 summarized into two major categories:
A detailed description of the architecture involves-
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.
Developers don't need to make many 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 Procfile, a text file that accompanies the source code. Each line of the Procfile declares a process type -- a named command that can be executed against the built application.
Application development on Heroku is primarily done through 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 many other 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.
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.
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).
It's 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 starts new ones (with the new release) 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 roll back 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 changes a set of config vars associated with the application, a new release will be generated.
Dyno manager help maintain and operate the dynos created. Because Heroku manages and runs applications, there's no need to manage operating systems or other internal system configuration. One-off dynos can be run with their input/output attached to the local terminal. These can also be used to carry out admin tasks that modify the state of shared resources, for example database configuration, perhaps periodically through a scheduler.
Dynos do not share file state, and so add-ons that provide some kind of storage are typically used as a means of communication between dynos in an application. For example, Redis or Postgres could 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 is not just the slug and config vars; it's the slug, config vars as well as the set of provisioned add-ons.
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.
Heroku's HTTP routers distribute incoming requests for the application across the running web dynos. A random selection algorithm is used for HTTP/HTTPS request load balancing across web dynos. It also supports multiple simultaneous connections, as well as timeout handling.
This section contains content that is written like an advertisement. (October 2016) (Learn how and when to remove this template message)
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your IT knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.