Enter the world of cloud computing and software development with PaaS. What it takes to create a production ready application with Heroku and how to run it?
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
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
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)
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
http://www.paasify.it/vendors
Toolchain as a ServiceToolchain as a Service
● Manage your project
– Trello, Jira OnDemand, Sprint.ly, 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, ...
HerokuHeroku
● Developed since 2007
– acquired by Salesforce.com 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, ...
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
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!
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
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
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
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: tapio@example.com
Password (typing will be hidden):
Authentication successful.
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 https://github.com/heroku/heroku-buildpack-ruby
$ heroku create myapp
--buildpack https://github.com/heroku/heroku-buildpack-ruby
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
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
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
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)
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
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
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
http://12factor.net/
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
https://blog.heroku.com/archives/2015/3/3/managing_your_microservices_on_heroku_with_netflix_s_eureka
http://getprismatic.com/story/1426533701900