No more Deployment PainPaaS with Heroku

Content

- SaaS < PaaS < IaaS

- Toolchain as a Service

- About Heroku

- The Twelve Factor App

- Heroku architecture

- Terminology- Heroku Toolbelt

- Buildpack

- Confix vars

- Dyno

- Logplex

- Add-ons

- Preboot

- Pipelines

- Demo

SaaS < PaaS < IaaS

Software as a Service

Platform as a Service

Infrastructure as a Service

Toolchain as a Service- Manage your project

- Trello, Jira, PivotalTracker, ...

- Creating your code- Koding.com, ...

- Host your code- GitHib, BitBucket, ...

- Build you code- Travis CI, GreenHouse, ...

- Test your code- BrowserStack, Souce Labs, Blitz, ...

- Distribute your code- Maven Central, Docker Hub, npm, Bintray, ...

Heroku

- Developed since 2007- acquired by Salesforce.com in 2010

- One of the first PaaS providers

- Built on top of Amazon`s IaaS

- Started as Ruby platform- currently a polyglot platform

- Base OS started with Debian- currently runs Ubuntu stack

- Wide variety of add-ons- data tores, cachking, logging, monitoring, hypermedia processing, payments,...

Heroku Terminology- Application

- Procfile

- Deployment

- Buildpack

- Slug

- Dyno

- Config var

- Release

- Add-on

- Logplex

Heroku architecture- Reverse Proxy by nginx

- terminates SSL

- forwards to cache layer

- HTTP Cache by Varnish- returns cached pages immediately

- forwards to routing mest

- 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

Set up Heroku

Set up Heroku

Heroku Toolbelt- Heroku Client

- CLI tool for creating and managing Heroku apps

Stack, Buildpack, Slug compiler- Stack

- Operating System image (Ubuntu)

- Buildpack- collection of scripts, knows how to build and execute your app

- Slug compiler- build you app with buildpack, on the given stack

- creates slug, an image / binary, ready to be executed on Dyno

Config variables- 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 at runtime

- Add-ons might expose config vars

- 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

- Dynos are ephemeral- shared state requires external data store

- Dyno manager- managed running dynos according to the defined ps

- sleeps dyno after 1 hour of inacitivity (for single 1X and 2X)

Dyno and Dyno Management

Logplex- 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 add-ons

Add-ons

- Provided as services by Heroku and third parties

- add-ons available from market place

- starting from free plans to monthly subscriptions

- Add-on providers are responsible for their add-ons

- integrate via config vars

- some contain external web user interface

Preboot

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

Pipelines

- 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

- I. Codebase - One codebase tracked in revision control, many deploys

- II. Dependencies - Explicitly declare and isolate dependencies

- III. Config - Store config in the environment

- IV. Backing Services - Treat backing services as attached resources

- V. Build, release, run - Strictly separate build and run stages

- VI. Processes - Execute the app as one or more stateless processes

- VII. Port binding - Export services via port binding

- VIII. Concurrency - Scale out via the process model

- IX. Disposability - Maximize robustness with fast startup and graceful shutdown

- X. Dev/prod parity - Keep development, staging, and production as similar as possible

- XI. Logs - Treat logs as event streams

- XII. Admin processes - Run admin/management tasks as one-off processes

The Twelve-Factor App - 12factor.net

Demo - Deploy BrainDev Spring Boot app

1. Create App Heroku

a. heroku apps:create braindev-demo-staging --remote staging ---buildpack https://github.com/heroku/heroku-buildpack-scala

b. git remote add staging https://git.heroku.com/braindev-demo-staging.git

2. Publish

a. git push staging master

3. See log

a. heroku logs -t

4. Set config

a. heroku config:set MY_ENV=staging -a braindev-demo-staging

b. heroku config:set MY_ENV=prod -a braindev-demo-prod

5. Pipeline

a. heroku plugins:install heroku-pipelines

b. heroku pipelines:create -a braindev-pipeline

c. heroku apps:create braindev-demo-prod --remote prod

d. heroku pipelines:add -a braindev-demo-prod braindev-pipeline

Thank you