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.

1. 12-Factor Applications
Modern Application Development Methodology
Siva Rama Krishna

2. @sivachunduru
linkedin.com/in/chunduru
slideshare.net/sivachunduru
2
Siva Rama Krishna – Solution Specialist

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

5. https://12factor.net
Adam Wiggins
Co-Founder
Heroku Cloud

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

7. 1. Codebase
One codebase tracked in revision control, many deploys
7

8. Codebase must be tracked in a VCS
8

9. Code Repository for Single Application
9
Root
Commit

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

13. 2. Dependencies
Explicitly declare and isolate dependencies
13

14. Common Dependencies
14
v 1.0
App 1 App 2 App 3
v 1.1
App 4
v 1.2

15. App 4App 3App 2
Isolation of Dependencies
15
App 1
v 1.0 v 1.0 v 1.1 v 1.2

16. Portability of Application
16
App
Linux Windows Docker PaaS

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

19. 3. Config
Store configuration values in the environment
19

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

25. 4. Backing Services
Treat backing services as attached resources
25

26. Treat external/internal systems as local ones
Swapping out the service(s) in each environment becomes easy.

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

29. 5. Build, Release, Run
Strictly separate build and run stages
29

30. Plan
Code
Build
Test
Package
Release
Deploy
Monitor
30
CI / CD
Plan
Code
Build
Test
Package
Release
Deploy
Monitor
Continuous
Integration
Continuous
Delivery
If Agile software development was the opening act to a great
performance, continuous delivery is the headliner.
- Kurt Bittner, Principle Analyst

31. 31
Release process
Build
Config
Release
v x.x.x

32. Code Change  Build + Release Config Change  Release
32
Release process against changes
Build
Config
Release
Build
Config
Release

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

35. 6. Processes
Execute the app as one or more stateless processes
35

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

40. 7. Port Binding
Export services via port binding
40

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.

42. Application serves its messages with routing technology
42

43. Enable communication even with polyglot
43

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

46. 8. Concurrency
Scale out via the process model
46

47. 47
Application Scalability

48. 48
Process of Scale
Law of diminishing returns

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

50. 9. Disposability
Maximize robustness with fast startup and graceful shutdown
50

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

53. 10. Dev/Prod Parity
Keep development, staging, and production as similar as possible
53

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

55. 11. Logs
Treat logs as event streams
55

56. Logs are written to streams

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

59. 12. Admin Processes
Run admin/management tasks as one-off processes
59

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

62. Beyond 12-Factors
Is there anything left out ?

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

65. Summary
65