Nowadays many organizations are heading towards numerous cloud solutions, while, even more, organizations are already there. In order not to negate advantages that cloud can provide us with, I would like to go through a methodology or rather a set of best practices designed to improve maintainability scalability and portability of applications created for cloud platforms.

1. WHAT IS A
12 FACTOR APP?Arch9: Amsterdam, The
Netherlands

2. HELLO!
I am Dmytro Panin
Found of Java, Cloud, IoT
⦿

3. CLOUD IS
EVERYWHERE
⦿

4. “Cloud - access to a pool of
computing resources
(servers, storage, networks,
services etc) that can be
rapidly provisioned and
made available with minimal
overhead”
⦿

5. ⦿

6. The 12 factors are
language and technology
agnostic
⦿

7. BENEFITS
OF THE 12
FACTORS
▸ Minimize time and cost for a
new developer joining the
project
▸ Maximum portability between
execution environments
▸ Scale up without significant
changes
⦿

8. 12 factors
Set of principles that prepare your app for the best experience
in cloud
⦿

9. CODEBASE
One codebase tracked in revision control, many deploys
1

10. One codebase per
application
1

11. Submodules if exist
should be separated
by VCS
1

12. DEPENDENCIES
Explicitly declare and isolate dependencies
2

13. System-wide
12 factor app never
relies on system-
wide dependenciesDEPENDENCIE
S
Isolated
dependencies are
declared explicitly
2

14. CONFIG
Store config in the environment
3

15. 12 FACTOR
CONFIG
Backing services
Resource handles
to the services
that are required
for the app
Example:
Database
Passwords
Credentials to
external services
Example:
Twitter
Per-deploy values
Values that differ
based on an
environment
Example:
Hostname
3

16. 12 FACTOR
CONFIG
Backing services
Resource handles
to the services
that are required
for the app
Example:
Database
Passwords
Credentials to
external services
Example:
Twitter
Per-deploy values
Values that differ
based on an
environment
Example:
Hostname
3

17. 12 FACTOR
CONFIG
Backing services
Resource handles
to the services
that are required
for the app
Example:
Database
Passwords
Credentials to
external services
Example:
Twitter
Per-deploy values
Values that differ
based on an
environment
Example:
Hostname
3

18. NOT 12
FACTOR
CONFIG
Configuration of a framework is not
12 factor app conf
Routes do not vary between deploys, thus, better stored in
code.
3

19. CONFIGURATION
FILES
3
Number of configuration
files that you have right
now for all of your
environments
Number of
environments may grow
over time as well as
number of configuration
files in your app’s
repository

20. CONFIG
The 12 factor app stores config in
environment variables3 ▸ OS-agnostic standard
▸ Little chance of committing into the repo
Having config separated helps to scale out easier

21. THE LITMUS
TEST
3

22. BACKING
SERVICES
Treat backing services as attached resources
4

23. RESOURCES
4

24. LOCAL OR
3rd PARTY
4 The code for a twelve-factor app
makes no distinction between local
and third-party services

25. BUILD, RELEASE, RUN
Strictly separate build and run stages
5

26. STAGES
5
BUILD RELEASE RUN
Strict separation between the stages

27. VERSIONING
Every release should always have a
unique release ID5 ▸ Timestamp
▸ Incrementing number
A release cannot be mutated once it is
created

28. PROCESSES
Execute the app as one or more stateless processes
6

29. STATELESS
6
Twelve-factor processes are stateless and share-nothing
Any data that needs to persist must be stored in a stateful
backing service

30. STICKY
SESSIONS
6
Sticky sessions are a violation of the twelve factors

31. PORT BINDING
Export services via port binding
7

32. SELF
CONTAINED
7
The 12 factor app is self-contained
▸ Do not require an application container
▸ Embeds a webserver library
The web app exports HTTP as a service by
binding to a port

33. SELF
CONTAINED
7
The 12 factor app is self-contained
▸ Do not require an application container
▸ Embeds a webserver library
The web app exports HTTP as a service by
binding to a port

34. SELF
CONTAINED
7
The 12 factor app is self-contained
▸ Do not require an application container
▸ Embeds a webserver library
The web app exports HTTP as a service by
binding to a port

35. CONCURRENCY
Scale out via the process model
8

36. VERTICAL
8
Scale up is not enough

37. HORIZONTAL
8
Scale out

38. PROCESS
MODEL
8 Microservices

39. DISPOSABILITY
Fast startup and graceful shutdown
9

40. DISPOSABILIT
Y
9
Maximize robustness
▸ Minimize startup time
▸ Shut down gracefully

41. RESILIENCE
9 Be robust against sudden death

42. DISPOSABILITY
9 Don’t be too attached to your servers
Servers are a commodity

43. DEV/PROD
PARITY
Keep dev, staging and prod as similar as possible
10

44. TOOLS
10
SQLite ≠ MySQL

45. TIME
10
Code is in production
a few hours after a
commit

46. PERSONNEL
10
Developers should
deploy their code

47. LOGS
Treat logs as event streams
11

48. LOGS
11

49. LOGS
11
12 factor app don’t route or storage its output stream

50. ADMIN
PROCESSES
Run admin/management tasks as one-off processes
12

51. ▸ Codebase
▸ Dependencies
▸ Config
▸ Backing services
▸ Build, release, run
▸ Processes
▸ Port binding
▸ Concurrency
▸ Disposability
▸ Dev/prod parity
▸ Logs
▸ Admin processes
LET’S
RECAP
⦿

52. DETAILS
http://12factor.net
⦿

53. QUESTIONS?