• One-to-one correlation between codebase and app • Multiple codebases: not an app, it’s a distributed system. Each component is an app • Multiple apps sharing the same code NOT OK • Refactor into set of modules/libraries to be used by dependency manager
libraries • Never rely on implicit existence of system-wide packages • Use explicit dependency declaration • gemfile, pip/virtualenv, autoconf, npm • (Containers can really help here…)
(staging, production, dev) • e.g. username/passwords for backing services • Config should NOT be declared as constants in code • Note: This does not include internal app config • Config SHOULD be defined in environment variables*
resources • e.g. MySQL, RabbitMQ, Redis, SMTP • Whether they are local, remote, 3rd party • Resources should be able to be attached/detached from deploys at will • e.g. what happens if your db crashes?
to executable bundle • Fetches dependencies • Compiles binaries & assets 2. Release • Combines build with current config 3. Run • Application is run in the execution environment
unique ID • git-sha, timestamp, auto-incrementing number • Impossible to make changes to code at runtime • Builds triggered by developers when code is deployed
more processes • Processes should be stateless and share-nothing • Data persisted to stateful backing service • Memory/Filesystem cache OK for single- transaction cache • “Sticky Sessions” are a violation!
• e.g. php might run inside Apache, Java in Tomcat • Apache/Tomcat should be injected as a dependency as part of the application • Application should export HTTP as a service binding to a port • Or other protocol: XMPP, Redis, Mysql, etc • App can become a backing service for another app
Workloads handled by different process types (microservice!) • (Note: internal threads ok — e.g. VM or EventMachine) • Application must be able to span multiple processes running on multiple physical machines • e.g. Scale horizontally • Apps should never demonize or write PID files • Rely on the OS process managers
be started or stopped at any time • Processes should attempt to minimize startup time • Processes shut down gracefully on SIGTERM • Sudden death of process should be ok • Job queues FTW
continuous deployment • Time gap should be small between dev -> prod • Developers should be involved in deploy / monitoring production • Development and production environments should be as similar as possible
• Apps should not concern with routing or storage of its output stream • Use stdout • Production log stream captured by execution environment (routed via Fluent/Logstash/etc) • Logs should be indexed and capable of analysis • ElasticSearch/Splunk/Loggly/etc
rosskukulinski
coconala_engineer
nakasho
yajihum
manarobot
toru_kubota
.JPG){kind=avatar}
koh_naga
riyaamemiya
os1ma
wmsbill
macloud
tomorrowkey
smt7174
ammeep
destraynor
trallard
chrislema
jacobian
aleyda
dotmariusz
cassininazir
ddemaree
zenorocha
deanohume
ufuk
