The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small. For example, make the time gap small, make the personnel gap small & make the tools gap small. Learn more about how a Cloud vendor must provide a platform for 12-factor / Cloud Native development and deployment with identified anti-patterns.
3. Need for 12-Factor App
To better address Scalability, Maintainability and Portability
3
4. Lot of Moving Parts
Fat Clients Web/Native Apps Modular Web Apps
Monolithic Backend on heavy weight
middleware
Backend services and Managed cloud
services
MicroServices
Physical Infra + Bare Metal Servers VMs + Public/Private Cloud Multi-Cloud + Containerization
10^1 10^2 10^3
6. 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 dev, staging and prod as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
The 12 Factors
10. 10
Multiple deploys with Single Codebase
Environments
Production Non-Production
Branches
Feature
Branches
Avoid staging deploys
11. Codebase is tracked in a VCS
Code repo contains a single application
with a common root commit.
Multiple environments are handled
through multiple deploys
11
Codebase - Summary
PRODUCTION
STAGING
DEV 1
DEV 2
Codebase
Deploys
12. 12
Codebase – Anti-Patterns
PRODUCTION
STAGING
DEV 1
DEV 2
Codebase
App-1 Deploys
PRODUCTION
STAGING
DEV 1
DEV 2
Codebase
App-2 Deploys
PRODUCTION
STAGING
DEV 1
DEV 2
App-1 Deploys
Different Codebases Different Applications
17. Dependencies - Summary
• No implicit system-wide packages.
• Declare all dependencies using a dependency declaration manifest.
• Most languages have dependency declaration and management tools.
17
Language Manifest
Java Maven
Node NPM
Ruby Gems
Python Pip
18. • Many dependencies
• Long chains of dependencies
• Conflicting dependencies
• Circular dependencies
• Package manager dependencies
18
Dependencies – Anti-Patterns
Dependency Hell
20. Configuration includes all values needed
by application that are specific to the
target environment
20
${TCP_PORT}
${HTTP_PROXY}
${HTTP_PORT}
${DB_SID}
${DB_SERVICE}
${LOG_PATH} ${ENV_TAG}
${NODE_ENV} ${HOST_NAME}
${ADMIN_URL}
21. App must be FREE from -
• Hardwiring Credentials data
– DB credentials
– External service credentials
• Hardwiring Environmental info.
– OS level variable like PROXY
– Network location
• Hardwiring internal URLs
21
No hardwiring of configuration data
22. Application must fetch from -
• External Service
• Environment Variable(s)
• User provided Service(s)
22
How to source configuration data?
23. Config - Summary
23
Application
Config
manifest.json
Launch command and
app version info
All application binaries
and resources
Application
Archive
deployment.jsonEnvironment Variables,
Service Bindings,
Memory,
Instances
• Config is everything that is likely
to vary between deploys like,
– Resource handles to the DB,
Memcached & other backing services
– Credentials to external services like
Amazon S3 or Twitter
• Apps sometimes store config as
constants in the code. This is a
violation.
• Config varies substantially across
deploys, code does not.
24. • Ensure every time, when an
application is deployed, the
supplied configuration matches to
what is expected
• Don’t run the configuration
management inside your container
images.
– Immutability matters a lot
24
Config – Anti-Pattern
27. • A backing service is any service the
app consumes over the network as
part of its normal operation.
Examples include,
- data stores
- messaging/queueing systems
- SMTP services for email
- caching
27
Backing Services - Summary
28. • No local disk
– Connect to network attached services
using connection information from
environment
28
Backing Services – Anti-Pattern
33. Build, Release, Run - Summary
Build Release Run
33
• Convert a code repo
into an executable
bundle known as a
build
• The build stage fetches
vendor dependencies
and compiles binaries
and assets.
• Takes the build and
combines it with the
deploy’s config.
• The resulting release
contains both the
build and the config
and is ready for
immediate execution.
• Runs the app in the
execution
environment, by
launching some set
of the app’s
processes against a
selected release.
34. Install on Deploy
• Build immutable images then run those
images
34
Build, Release, Run – Anti-Pattern
36. Process Centric View
System Administrator Developer Application Administrator
Looks @ Processes Applications
Single AppServer hosting many
Applications
1 Process
(AppServer itself)
Many Applications
Single App decomposed into
multiple processes
Multiple Processes Multiple Processes
(Applications)
ROLE NOT REQUIRED
sh ./helloWorld
37. Stateless processes – Memory specifics
• Single threaded memory usage
• Short lived memory usage
– leverage cache technologies
• Leverage DB or Cache for long term memory needs
37
38. • Processes are stateless and share-
nothing.
• Data that needs to persist must be
stored in a stateful backing service
like database.
• Web systems rely on “sticky
sessions”
– a violation of 12-factor
– session state data is a good candidate
for a data store that offers time-
expiration
38
Processes - Summary
39. If multiple web servers are used,
don’t just use locally uploaded files.
– Use internal storage host like NFS
(or)
– external one such as AWS S3.
39
Processes – Anti-Pattern
41. Application’s port mapped to non-standard port
Communication protocol usually bind on a non-standard port,
allowing it to run in a container in an isolated fashion.
44. • The app exports HTTP as a service
by binding to a port, and listening
to requests coming in on that port.
• Implemented by using dependency
declaration to add a webserver
library to the app like Jetty for Java.
• This happens entirely within the
app’s code. The contract with the
execution environment is binding
to a port to serve requests.
44
Port Binding - Summary
45. Don’t hardcode the ports the
software runs on
– Get the ports from environment
variables
45
Port Binding – Anti-Pattern
49. • The process model truly shines
when it comes time to scale out.
• The share-nothing, horizontally
partitionable nature means that
adding more concurrency is a
simple and reliable operation.
49
Concurrency - Summary
51. • App’s processes are disposable,
meaning they can be started or
stopped at a moment’s notice.
• This facilitates fast elastic scaling,
rapid deployment of code or config
changes, and robustness of
production deploys.
51
Disposability - Summary
Security Scalability Fault Tolerance
52. Hug of Death
– you want to make sure you have bad,
corrupt, or lost data.
52
Disposability – Anti-Pattern
54. • App is designed for continuous
deployment by keeping the gap
between DEV and PROD small.
– Make the time gap small: a developer
may write code and have it deployed
hours or even just minutes later.
– Make the personnel gap small:
developers who wrote code are closely
involved in deploying it and watching
its behavior in production.
– Make the tools gap small: keep DEV
and PROD as similar as possible.
54
Dev/Prod Parity - Summary
57. • App never concerns itself with
routing or storage of its output
stream.
• It should not attempt to write to or
manage log files.
• Instead, each running process
writes its event stream, un-
buffered, to stdout.
57
Logs - Summary
58. Random log files all over the file
system
58
Logs – Anti-Pattern
60. • One-off admin processes should be
run in an identical environment as
the regular long-running processes
of the app.
• They run against a release, using
the same codebase and config as
any process run against that
release.
• Admin code must ship with
application code to avoid
synchronization issues.
60
Admin Processes - Summary
61. • Custom containers for tasks
– Reuse application images with specific
entry points for tasks
61
Admin Processes – Anti-Pattern
Identical environments
63. More Factors
• API First
– Work against each other’s public contracts
• Telemetry
– Application Performance Monitoring
– Domain specific Telemetry
– Health and System Logs
• Security
– Authentication
– Authorization