Heroku

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Heroku, Inc.
Subsidiary
Industry Cloud platform as 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 you build, run and scale applications in a similar manner across all the languages – utilizing the dependencies and Procfile. The Procfile exposes an architectural aspect of your application and this architecture helps you scale each part independently.

History[edit]

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.[4] 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.[5] 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.[6] That same month, Heroku added support for Node.js and Clojure. On September 15, 2011, Heroku and Facebook introduced Heroku for Facebook.[7] At present Heroku supports MongoDB and Redis databases[8][9] in addition to its standard PostgreSQL.[10]

What does the name mean[edit]

According to various sources:[11][12] 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.

How does Heroku Work[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 or dynos are spread across a "dyno grid" which consists of several servers. Heroku's Git server handles application repository pushes from permitted users.[13][14]

The working can be summarized into two major categories:

Deploy[15][16]

  • 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 your application along with all the dependencies, and the language runtime, and produce slugs. These are know as build-packs and are the means for the slug compilation process.
  • A slug is a combination/bundle of your 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 your 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 (your application), config vars and add-ons.
  • Heroku maintains a log know as the append-only ledger of releases you that make.

Runtime

  • The main unit which provides the run environment are the Dynos which are isolated, virtualized unix containers.
  • Your application’s dyno formation is the total number of currently-executing dynos, divided between the various process types you have 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 your local terminal. They’re loaded with your 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 your 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 you use a Gemfile, Python - arequirements.txt, Node.js in package.json, in Java a pom.xml and so on.

  • Knowing what to execute:

You 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 your application are runnable. You do this in a text file that accompanies your source code - a Procfile. Each line declares a process type - a named command that can be executed against your 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, you 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. Or you can use Dropbox Sync, which lets you deploy the contents of Dropbox folders to Heroku. Finally, you can also use the Heroku API to build and release apps.

Deployment then, is about moving your application from your 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 your 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 your prepared slug (in fact, with your release, which extends your slug, config vars and add-ons).

Its like running dyno[16] as a lightweight, secure, virtualized Unix container that contains your application slug in its file system. Heroku will boot a dyno, load it with your slug, and execute the command you’ve associated with the web process type in your 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 you deploy a new version of an application, a new slug is created and release is generated.

As Heroku contains a store of the previous releases of your application, it’s very easy to rollback and deploy a previous release. A release then, is the mechanism behind how Heroku lets you modify the configuration of your application (the config vars) independently of the application source (stored in the slug) - the release binds them together. Whenever you change a set of config vars associated with your 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 your 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 your applications is not just your slug and config vars; it’s your 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 your application across your 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.

Heroku 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 another 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 also forks, followers and dataclips

  • Heroku Redis

Heroku Redis is the customized 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 also use collaboration tools like Heroku Pipelines. It also provides delegated administration and centralized 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 synchronization between Heroku Postgres databases and Salesforce organizations

  • Heroku Elements

Heroku Elements provides users with Add-ons -Tools and services for developing, extending, and operating your app , Buildpacks-Buildpacks automate the build processes for your preferred languages and frameworks and Buttons -one-click provision, configure and deploy third party components, libraries and pattern app.

Alternatives for Heroku[edit]

References[edit]

  1. ^ Bay Area mergers and acquisitions, Dec. 13 (news article), SF Gate 
  2. ^ "Heroku". Crunchbase. Retrieved March 2, 2016. 
  3. ^ "About Heroku". Stack Overflow. Retrieved March 2, 2016. 
  4. ^ Ruby on Rails Startup Heroku Gets $3 Million, Tech Crunch, 2008-05-08 
  5. ^ SourceLabs' Byron Sebastian Joins Heroku as CEO, Venture Beat, 2009-10-14 
  6. ^ Ruby’s Creator, Matz, Joins Heroku (article), Ruby Inside, 2011-07-12 
  7. ^ Facebook Partners With Heroku to Offer Developers Free Sample Application Hosting, Social Times 
  8. ^ "Six Things to Consider When Using Redis on Heroku". Redis Labs. Retrieved March 2, 2016. 
  9. ^ NoSQL, Heroku, and You (weblog), Heroku, 2010-07-20 
  10. ^ "Rails Heroku Tutorial". RailsApps Project. Retrieved March 2, 2016. 
  11. ^ "The term is merger of "Hero" and "Haiku". | Hacker News". news.ycombinator.com. Retrieved 2016-08-05. 
  12. ^ "Douglas Drumond's answer to What does Heroku mean? - Quora". qr.ae. Retrieved 2016-08-05. 
  13. ^ Scalability: How does Heroku work?
  14. ^ Deploying application Node.js on Heroku
  15. ^ "Heroku Working Model". 
  16. ^ a b Heroku Cloud Application Development. Packt Publishing Ltd. 2014. 

External links[edit]