CSC/ECE 517 Fall 2013/ch1 1w30 ps

Ruby on Rails Web Hosting Services

Introduction

A web hosting service is a type of Internet hosting service that allows individuals and organizations to make their website accessible via the World Wide Web. Typically, while hosting web applications, it becomes essential to host the core website component, databases and other resources necessary for running the application. There are many web hosting options available like free web hosting, shared hosting, dedicated server, and the list goes on. Today, many companies provide services for hosting web application where they manage the infrastructure along with maintenance and the application developer needs to focus only on the actual application development. The service charges depend upon the factors like disk space, bandwidth, email account or FTP access. Nowadays, many companies provide Platform-as-a-Service(PaaS) to deploy and scale applications in Cloud.

Some popular PaaS providers are:

• Amazon Web Service

Not a platform in the traditional sense, Amazon's AWS Elastic Beanstalk changes how developers push their apps into Amazon's cloud. Developers upload the app and Elastic Beanstalk handles the deployment details, capacity provisioning, load balancing, auto-scaling and app health monitoring.

• Heroku

Heroku is a cloud platform as a service (PaaS) supporting building, deployment and scaling of applications using several programming languages like Ruby, Java, Python,Node.js ,Clojure, PHP and Perl.

• Engine Yard

Engine Yard's platform offers simple, automated Rails deployment and management that makes for easy app migration.

• Google App Engine

The developer platform that lets users build and host Web apps in the cloud in an effortless fashion.

• GridGain

Open-source cloud application platform helps developers build scalable applications that can work natively on managed infrastructure, from a Google Android device to large grids and clouds. The software supports major OSes and provides native support for Java and Scala.

---

Heroku

Heroku, one of the first cloud platforms, has been in development since June 2007, when it supported only the Ruby programming language, but has since added support for Java, Node.js, Scala, Clojure and Python and (undocumented) PHP and Perl. The base operating system is Debian

History

---

James Lindenbaum, Adam Wiggins, and Orion Henry founded Heroku supporting Rack-compatible projects<ref>http://techcrunch.com/2008/05/08/ruby-on-rails-startup-heroku-gets-3-million</ref>. In October 2009 Byron Sebastian joined Heroku as CEO<ref>http://venturebeat.com/2009/10/14/sourcelabs-byron-sebastian-joins-heroku-as-ceo</ref>. 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 month, Heroku included support for Node.js and Clojure.On September 15, 2011 Heroku and Facebook introduced Heroku for Facebook<ref>https://developers.facebook.com/blog/post/558</ref>. Heroku now supports Cloudant, Couchbase Server, MongoDB and Redis, besides the standard PostgreSQL, both as part of the platform and as a standalone service.

Architecture

---

The high-level architectural components of the Heroku platform consist of following components.

Dynos and dyno Manager

1. A dyno is a lightweight container running a single user-specified command.The commands run within dynos include web processes, worker processes (such as timed jobs and queuing systems), and any process types declared in the app’s Procfile. Dynos are available in 1X or 2X sizes and are allocated 512MB or 1024MB respectively.
2. Your application’s dynos run in a a distributed, fault-tolerant, and horizontally scalable execution environment. The dyno manager manages many different applications via the the process model and keeps dynos running automatically. The dyno manager restarts all your app’s dynos whenever you create a new release by deploying new code, changing your config vars, changing your add-ons.

Logplex

In a distributed system such as Heroku, manually accessing logs spread across many dynos provides a very disjointed view of an application’s event stream and omits relevant platform-level events.Logplex collates and distributes log entries from your app and other components of the Heroku platform.

The Process Model

The process model gives us a unique way to think about dividing our workloads and scaling up over time. The Heroku Cedar stack uses the process model for web, worker and all other types of dynos. The process model is a generalized approach to managing processes across a distributed environment. It allows you to specify a custom list of process types in a Procfile and provides for very granular management of an application’s components.

Process Type

Web apps typically have two or more entry points. Each of these entry points can be called a process type which run a specific command. A process type is the prototype from which one or more dynos are instantiated. The process types are declared in Procfile.

Stack

A stack is a complete deployment environment including the base operating system, the language runtime and associated libraries. Heroku uses Celadon Cedar Stack. Celadon Cedar is Heroku’s default runtime stack and is a flexible, polyglot environment with robust introspection and erosion-resistance capabilities.

Procfile

A Procfile is a text file named Procfile placed in the root of your application, that lists the process types in an application. Each process type is a declaration of a command that is executed when a dyno of that process type is started. All the language and frameworks on the Cedar stack declare a web process type, which starts the application server. Rails 3 has the following process type :

   web: bundle exec rails server -p $PORT
   web:     node web.js
   worker:  node worker.js
   reports: node report.js
   General command 
   <process-type> : <command>

Slug

A slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system - ready for execution.

---

How Heroku Works

Running an application on Heroku involves following points

1. Defining an application: The source code for your application, together with the dependency file, should provide enough information for the Heroku platform to build your application, to produce something that can be executed.
2. Knowing what to execute: If you’re using some established framework, Heroku can figure it out. For example, in Ruby on Rails, it’s typically rails server and in Node.js it’s the main field in package.json. If you want to execute some other process as well declare it in Procfile.
3. Deploying application: The Heroku platform uses git as the primary means for deploying applications.

When you create an application on Heroku, it associates a new git remote, typically named heroku, with the local git repository for your application.As a result, deploying code is just the familiar git push, but to the heroku remote instead :

  $ git push heroku master

1. Building an application: When the Heroku platform receives a git push, it initiates a build of the source application. The build mechanism is typically language specific, but follows the same pattern, typically retrieving the specified dependencies, and creating any necessary assets.
2. Running application on Dynos:Heroku executes applications by running a command you specified in the Procfile, on a dyno that’s been preloaded with your prepared slug.

Reference

<references />