Heroku Architecture and usage

  • Published on

  • View

  • Download

Embed Size (px)


Heroku Architecture and usage


  • Introduc)on to Heroku By Bhagwat Kumar

  • Agenda

    What and why Heroku? Dynos. Process Model. Deploy and manage your app. Advance features of Heroku. Restric@ons by Heroku Case study

  • How do you manage your QA/Prod servers Install java run-@me Install tomcat / setup webapp-runner setup services that you want to manage yourself

    Mysql/Postgres/Mongodb/Redis/Memcache/RabbitMQ etc Install OS tools that your app depends on.

    ImageMagic/curl/wget etc Setup version control if planning to build war here Write deploy script which

    Download latest war/ build war Stop tomcat and copy war file to tomcat/webapp Restart tomcat

    Write monitor script for restar@ng crashed services Write script for data and logs backup

  • What and why Heroku?

    A polyglot cloud applica@on plaLorm. Spend 100% of your @me on applica@on code in language of

    your choice. Forget managing servers, deployment, ongoing opera@ons, or


  • How it works?

    Deploy Just a git push

    Connect Add 3rd party resources

    Command Use CLI/Web interface

    Observe All ac@vi@es logged using Logplex

    Scale Independent scaling of components

    Relax Takes full responsibility for your app's health

  • What happens when you git push to Heroku remote?

    It ini@ates a build of the source applica@on. Installs language and framework needed to build the app retrieves the specified dependencies and caches it create necessary assets e.g. compile code or do compression All these are assembled into a slug

    a bundle of generated code Dependencies Language run@me Compiled/generated output of the build system Procfile defining process types

  • Running applica@on on Dynos

    Dynos are isolated, virtualized unix containers It provides required environment to run the app A dyno runs a single user-specified command/process Currently 3 types of Dynos are available(27-Jul-2014):

    Size RAM CPU share Price/dyno hour

    1X 512 MB 1x $ 0.05

    2X 1 GB 2x $ 0.10

    PX 6 GB 100 % (8 core) $ 0.80

  • Dyno Manifold

    Provides an environment for your app's dynos Distributed Fault tolerant Horizontally scalable

    Tasks Restar@ng faulty dyno Checking for idle dyno Restar@ng on config changes Restar@ng on new releases

  • Process Model

    The prototype using which one or more dynos are instan@ated Define Process types using Procfile A process type has a name and a command "Web" process type is special

    Heroku router routes HTTP requests to Web dynos only.

  • Procfile examples

    web: java -jar server/webapp-runner.jar --port $PORT target/*.war worker: java -jar server/webapp-runner.jar --port $PORT target/*.war

    web: node app.js worker: node workerApp.js scheduler: node schedulerApp.js

  • Demo Create and deploy heroku app

    heroku create mysample-app --remote staging git push staging master

    Monitor logs heroku logs t heroku logs t p

    Watch processes heroku ps

    Rescale heroku scale web=2 worker=1

    Play with configura@on heroku config heroku config:set KEY=VALUE

    Releases and rollback heroku releases heroku rollback

  • Advance features

    Blue green deployment Monitor CPU and memory usages Fork exis@ng Heroku app Managing mul@ple environments Pipeline push among various apps/environments

  • Blue green deployment

    hops://devcenter.heroku.com/ar@cles/labs-preboot heroku labs:enable preboot

  • Monitor CPU and memory usages

    hops://devcenter.heroku.com/ar@cles/log-run@me-metrics heroku labs:enable log-run@me-metrics

  • Fork exis@ng Heroku app

    hops://devcenter.heroku.com/ar@cles/fork-app heroku fork -a sourceapp targetapp

    #remote of new app not added automa@cally heroku info -a targetapp

    #to know git remote git remote add forked git@heroku.com:targetapp.git

  • Managing mul@ple environments : staging/uat/prod

    hops://devcenter.heroku.com/ar@cles/mul@ple-environments heroku create staging-todo --remote staging heroku create prod-todo --remote produc@on heroku logs -t -r produc@on

    You must specify heroku app remote or app name using a flag git config heroku.remote staging

    Make staging as default heroku app for heroku commands

  • Pipeline push among various apps/environments

    hops://devcenter.heroku.com/ar@cles/labs-pipelines heroku labs:enable pipelines heroku plugins:install git://github.com/heroku/heroku-

    pipeline.git heroku pipeline:add myapp

    #add target app for pipeline, source is current app heroku pipeline:diff heroku pipeline:promote

    No build phase is required on target app.

  • Heroku restric@ons to make it a beoer app

    Build must complete within 15 minutes. Web process must start listening to specified port within 60

    seconds. Request @meout page shown if request takes more than 30

    seconds to process. (Actual thread keeps running though). Max 100 dynos for 1x/2x process types and max 10 dyno per PX

    process types. Dynos are cycled at least once per day. If there are only one web dyno running, it will be idled out auer

    one hour of inac@vity

  • Checklist for Heroku ready apps

    Dynos execute in complete isola@on from one another File system dependency OS tools dependency Hop sessions Database connec@on pool Cache services Jobs

  • Case studies

    Mat.se www.mat.se grails

    Swedeponic.se hop://www.swedeponic.se nodejs

    Mewithyou.com www.mewithyou.com nodejs

    Stoot pusher service hop://stoot.herokuapp.com nodejs

  • Ques:ons?

  • Thank you. bhagwat@intelligrape.com