Thursday, August 28, 2014

Elements of PaaS


PaaS (Platform as a Service) is a layer over IaaS (Infrastructure as a Service) that provides the following:

  1. Some kind of deployement interface
  2. coupled with a load balancer - HAProxy
  3. a service provisioning system 
  4. Scaling  in/out support
  5. Optional add-on services: 
    1. Backup and restore service 
    2. Patching
    3. Caching or data grid service
    4. Different DB types - relational, in-memory, no-sql 


The above is generally controlled by a service management layer that exposes all of the above operations of PaaS as REST endpoints. The implementation of the endpoints will use IaaS service endpoints to perform infrastructure related operations (like say adding/removing a VM etc).

Generally some devops toolkit like chef (solo)/puppet combined with some bash scripts are used to provision the platform (like say application server or database server) in the VM after the VM has been created.

The tenant user can either use the REST endpoints directly or through some SDK or CLI or through a web UI to request say, creation of platform instance(s).

Once the platform instance is created, user can deploy their applications on the platform through the platform specific administration tools (like tomcat admin console or a DB client).

Examples of PaaS:
Heroku (see my other posts summarizing the salient features of Heroku platform) 

Understanding Heroku


Deploy, run and manage Java application on Heroku:
  1. Application = source code for application + web or application server framework + dependencies on third party libraries + dependency description (pom.xml) that instructs a build system (maven) to download the needed dependencies from a repository in order to build the application + Procfile.
  2. Procfile - lists named commands that you may want executed.
     
web: java -jar lib/foobar.jar $PORT
queuty: java -jar lib/queue-processor.jar

Defines a 'web' process type and provides a command that needs to be executed in order to run it.
  1. Git - used as primary means for deploying applications on Heroku platform. When application is created on Heroku, a new git remote is associated typically named "heroku" with the local git repository for your application. To deploy, simply do a git push heroku master. Thus git acts as a transport mechanism to push local application to heroku platform (remote).
  2. When Heroku platfrom receives a git push, it builds the application - mvn clean install.
  3. Slug - a bundle of application source code + dependencies + JRE + binary o/p from mvn install. A slug is the application ready for execution.
  4. Dynos - Heroku executes the applications by running a command you defined in Procfile on a dyno (unix container like Docker) that has been preloaded with slug and config-vars and add-ons (together called a 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.
  1. To retain state information across dyno restarts use DB or message queues. The filesystem on a dyno are temporary.
  2. User can control the number of dynos: heroku ps:scale web=3 queuty=2 for example will run 5 dynos (3 for web and 2 for queuty process types).
  3. When a new version of application is pushed to heroku platform, currently executing dynos are killed and new ones are spawned to replace them with the new release.
  4. Application config-vars are set as:
heroku config:set ENCRYPTION_KEY= my_secret_launch_codes

These are exposed to application as environment vars.
  1. Release = version controlled ledger of (slug + config-vars + add-ons)
heroku releases - lists all changes deployed with their version id (internally they might be mapping version ids to git SHA ids)
Everytime you deploy, new slug is created and a release is generated.
Its thus very easy to rollback to a previous release.
Heroku releases:rollback v102
  1. Dyno manager - manages dynos across all applications deployed on heroku platform.
  2. Add-ons - are pluggable services like email service, Database service, queuing or caching services etc.

For example, a REDISTOGO_URL will be automatically added to your application when you provision the add-on. You can write code that connects to the service through the URL, for example:
uri = URI.parse(ENV["REDISTOGO_URL"])
REDIS = Redis.new(:host => uri.host, :port => uri.port, :password => uri.password)

  1. 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.
  2. HTTP Routing:

Heroku’s HTTP routers distributes incoming requests for your application across your running web dynos.

Tuesday, August 19, 2014

Book Review: The Giver by Lois Lowry

** spoiler alert ** The Giver is a science fiction about a special community which has attained a very peaceful and strictly disciplined lifestyle for its citizens by enforcing rules and cutting them off from any and all randomness of life. Everything is controlled - population, feelings, freedom to choose their own job. It makes one think about what living in such a time will be like where people just don't feel anything wrong in killing (called releasing in the book) because they have never thought about releasing being bad - as it is what they have learned to expect by living in their community. We can compare this kind of feeling with our times and come up with a lot of aspects in our lives that we believe are bad today but were being practiced just a few years ago by some communities. Overall a thought provoking story. I am looking forward to read the other books in this series.

Popular micro services patterns

Here are some popular Microservice design patterns that a programmer should know: Service Registry  pattern provides a  central location  fo...