Introduction to PaaS and Heroku

Freelance Software Consultant at Spathi Systems
Mar. 25, 2015

More Related Content

Slideshows for you(20)


Introduction to PaaS and Heroku

  1. Introduction to PaaSIntroduction to PaaS and Herokuand Heroku
  2. Tapio RautonenTapio Rautonen @trautonen software architect Building software for the cloud together with great people.
  3. Cloud computing characteristicsCloud computing characteristics On-demand self-service Consumer can provision computing capabilities without requiring human interaction Broad network access Capabilities are available over the network and accessible by heterogeneous clients Resource pooling Provider's computing resources are pooled to serve multiple consumers dynamically Rapid elasticity Capabilities can be elastically provisioned and appear unlimited for the consumer Measured service Automatically controlled and optimized resources by metering capabilities
  4. SaaS < PaaS < IaaSSaaS < PaaS < IaaS ● Software as a Service – applications for end-users delivered on-demand ● Platform as a Service – operating system, runtime environment and middleware ● Infrastucture as a Service – servers, virtualization, storage and networking SaaSSaaS PaaSPaaS IaaSIaaS
  5. Service modelsService models
  6. Platform as a ServicePlatform as a Service ● Services that help develop and test apps – infrastructure is maintained by the provider ● Reduced infrastructure complexity – more effective overall application development ● Runtime environments are usually lock-in free – but might create lock-ins to provider specific infrastructure ● Usually simple network topology and access control – build your services as they would be open to the Internet ● The features and services provided vary a lot – from simple customizable runtime (CloudFoundry) to full marketplace of services (Heroku)
  7. There are plenty to choose fromThere are plenty to choose from ● Google App Engine   – go, java, php, python ● Pivotal Web Services   – go, groovy, java, node, ruby, scala, ... ● IBM Bluemix    – go, java, node, php, python, ruby, ... ● Heroku   – clojure, groovy, java, node, php, python, ruby, scala, ... Built in scaling options  vertical scaling,  horizontal scaling,  autoscaling
  8. Toolchain as a ServiceToolchain as a Service ● Manage your project – Trello, Jira OnDemand,, PivotalTracker, ... ● Create your code – Cloud9, Koding, Nitrous, ... ● Host your code – GitHub, Bitbucket, ... ● Build your code – Codeship, Travis CI, CloudBees, Drone, ... ● Test your code – BrowserStack, Sauce Labs, Xamarin Test Cloud, Blitz, ... ● Distribute your code – npm, Bintray, Maven Central, PyPI, Docker Hub, ...
  9. HerokuHeroku ● Developed since 2007 – acquired by in 2010 ● One of the first PaaS providers ● Built on top of Amazon's IaaS (US and EU regions) ● Started as a Ruby platform – currently a polyglot platform ● Base OS started with Debian – currently runs Ubuntu stack ● Wide variety of add-ons – data stores, caching, logging, monitoring, hypermedia processing, payments, ...
  10. TerminologyTerminology ● Application source code and description of any dependencies ● Procfile list of process types – named commands to be executed ● Deployment sending application to Heroku using git or dropbox ● Buildpack compilation process that creates a slug from application ● Slug bundle of application, language runtime and compilation output ● Dyno isolated, virtualized Linux container for application runtime ● Release append-only ledger of slugs, config vars and add-ons ● Config var configuration data hosted independently of source code ● Add-on easily attachable third party cloud services ● Logplex collates logs from all running dynos and other components
  11. Heroku architectureHeroku architecture by David Feng / CC BY-NC-SA 2.0 ● Reverse Proxy by nginx – terminates SSL – forwards to cache layer ● HTTP Cache by Varnish – returns cached pages immediately – forwards to routing mesh ● Routing Mesh written in Erlang – routes to an existing dyno – spawns a dyno if none available ● Dyno Grid ('railgun' servers) – AWS hosted EC2 instances – multiple dynos per server Architecture based on unconfirmed information!Architecture based on unconfirmed information!
  12. PerformancePerformance ● Works on my machine is beyond wrong at Heroku scale ● CPU is not usually bound on web applications ● Beware of the memory consumption! – Node.js can hog up a lot of memory – JVM might require tuning ● Adopt proper microservices architecture Dyno SizeDyno Size MemoryMemory CPU ShareCPU Share ThreadsThreads MultitenantMultitenant ComputeCompute Price / dyno-hourPrice / dyno-hour 1X 512MB 1x 256 yes 1x-4x $0.05 2X 1024MB 2x 512 yes 4x-8x $0.10 PX 6GB 100% (8C) 32768 no 40x $0.80
  13. PricingPricing ● Pay as you grow ● 750 free dyno-hours for each application per month – single 1X dyno free of charge for an entire month – single 2X dyno 375 hours per month ● Usage computed from wall-clock time – sleeping dyno continues to accrue usage – all costs are prorated to the second ● Three available support plans – from free to premium technical account manager ● Add-ons priced by monthly subscriptions – selectable plans available
  14. LimitsLimits ● Web dyno must bind its $PORT within 60 seconds ● Processes must stop within 10 seconds on SIGTERM ● HTTP requests must send data within 30 seconds – each byte resets a rolling 55 second window ● Config vars data is limited to 16kB each app ● Maximum slug size is 300MB – compilation is limited to 15 minutes ● Unverified account can create 5 apps – 100 for verified account ● Soft limit for network bandwidth is 2TB/month ● Log history stores the last 1500 lines
  15. Heroku ToolbeltHeroku Toolbelt ● Available for MacOS X, Windows and Linux ● Heroku Client – CLI tool for creating and managing Heroku apps ● Foreman – an easy option for running your apps locally ● Git – revision control and pushing to Heroku $ heroku login Enter your Heroku credentials. Email: Password (typing will be hidden): Authentication successful.
  16. BuildpackBuildpack ● Defines a slug compiler – collection of shell scripts ● No native language or framework support – all runtimes are implemented as buildpacks ● Heroku managed and third party buildpacks – use as is or fork and use – based on git, supports git revisions $ heroku buildpack:set $ heroku create myapp --buildpack
  17. Config varsConfig vars ● Variable configuration between environments – never store sensitive configuration in source repository ● Will be exposed as environment variables at runtime ● All dynos see the exact same set of variables ● Add-ons might expose config vars $ heroku config:set GITHUB_USERNAME=trautonen Adding config vars and restarting myapp... done, v12 GITHUB_USERNAME: trautonen $ heroku config GITHUB_USERNAME: trautonen $ heroku config:unset GITHUB_USERNAME Unsetting GITHUB_USERNAME and restarting myapp... done, v13
  18. Dyno managementDyno management ● Dyno is an isolated lightweight Linux container ● Three types of dynos – web dyno, can receive HTTP traffic – worker dyno, used for background, queuing and timed jobs – one-off dyno, can run a command in a temporary dyno ● Dyno manager – manages running dynos according to the defined ps – sleeps dyno after 1 hour of inactivity (for single 1X and 2X) $ heroku ps $ heroku ps:scale web=2 $ heroku ps:scale web+5 $ heroku ps:stop web
  19. LogplexLogplex ● Collates and distributes log entries – all application dynos – add-ons and other components ● Routes messages from sources to drains – source: any process that might want to emit log entries – drain: any network service that want to consume log entries ● Limited log entry buffer – integrate to log-processing and managent addons $ heroku logs -t 2015-04-15T07:44:42.259823+00:00 heroku[web.1]: State changed from down to starting 2015-04-15T07:44:42.259421+00:00 heroku[web.1]: Unidling
  20. Add-onsAdd-ons ● Provided as services by Heroku and third parties – add-ons available from marketplace – starting from free plans to monthly subscriptions ● Dynos are ephemeral – shared state requires external data store ● Add-on providers are responsible for their add-ons – integrate via config vars – some contain external web user interface $ heroku addons:add newrelic:standard Adding newrelic:standard on myapp...done, v27 (free) $ heroku addons:remove newrelic:standard Removing newrelic:standard from myapp...done, v27 (free)
  21. PrebootPreboot Production cloud application without zero downtime deployments. . . ● Changes the dyno start behavior to 'blue - green' – ensures new dynos are started and ready to receive traffic – requires at least 2 dynos – two versions of application dynos running at the same time $ heroku features:enable -a myapp preboot Enabling preboot for myapp... done
  22. PipelinesPipelines ● Experimental Heroku Labs feature subject to change ● Pipelines help to solve complexity of multi-environment – dev, test, staging, production, … ● Pipeline manages application slug – diff between current and downstream app – promote slug to downstream target myapp-dev ---> myapp-staging ---> myapp $ heroku pipeline:diff -a myapp-staging Comparing myapp-staging to myapp...done, myapp-staging ahead by 2 commits: $ heroku pipeline:promote -a myapp-staging Promoting myapp-staging to myapp...done, v2
  23. The Twelve-Factor AppThe Twelve-Factor App ● SaaS architecture methodology – declarative formats for setup and runtime automation – clean contract with infrastructure for maximum portability – cloud platform deployments, obviating the need for ops – tooling, architecture and dev practices support scaling ● 12 factors for building apps which run as a service – contributed by people highly involved in Heroku platform – synthesizes experiences and observations in the wild
  24. Complex MicroservicesComplex Microservices ● Microservices architecture introduces new problems – service discovery and orchestration – fault tolerancy and circuit breaking – configuration management – interface versioning – ... ● The power of PaaS, Spring Framework and NetflixOSS – Heroku – Spring Cloud Netflix
  25. Thank youThank you