a service founded 2007 2007 founder james lindenbaum adam wiggins orion henry headquarters san francisco california key people tod nielsen ceo products heroku platform heroku postgres heroku redis heroku enterprise heroku teams heroku connect heroku elements parent salesforce.com website heroku.com 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 . 1 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 . 2 3 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 utilizing the dependencies and procfile . 4 the procfile exposes an architectural aspect of the application and this architecture aims to help the developer scale each part independently . contents 1 history 2 etymology 3 architecture 4 products 5 alternatives 6 references 7 external links history edit heroku was initially developed by james lindenbaum 5 adam wiggins 6 and orion henry 7 for supporting projects that were compatible with the ruby programming platform known as rack . 8 the prototype development took around six months . later on heroku faced drawbacks because of lack of proper market customers as all the real app developers used their own tools and environment . heroku had another drawback that it was based on the idea of a broader scope but now heroku is narrowed to specific supporting tools . 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 . 9 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 . 10 that same month heroku added support for node.js and clojure . on september 15 2011 heroku and facebook introduced heroku for facebook . 11 at present heroku supports mongodb and redis databases 12 13 in addition to its standard postgresql . 14 etymology edit according to various sources 15 16 the term is merger of heroic and haiku . the japanese theme is a nod to matz for creating ruby and the word does not have a meaning because the creators did not want the word to have a meaning when it reached japan . architecture edit a diagrammatic view of the working of heroku platform 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 17 or dynos 18 are spread across a dyno grid which consists of several servers . heroku s git server handles application repository pushes from permitted users . 19 20 the working can be summarized into two major categories deploy 21 22 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 . runtime 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 are not reflected to other dynos . logplex automatically collates log entries from all the running dynos of the app as well as other 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 python arequirements.txt node.js in package.json in java a pom.xml and so on . knowing what to execute 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 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 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 . 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 22 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 . configurations 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 . releases 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 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 . add ons 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 . 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 also supports multiple simultaneous connections as well as timeout handling . products edit 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 also provides custom buildpacks with which the developer can deploy apps in any other 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