The document discusses the 12 factor app methodology for building scalable software-as-a-service applications. It begins with an introduction to 12 factor apps and their focus on principles like codebase, dependencies, configuration, backing services, build-release-run processes, port binding, concurrency and more. The rest of the document delves into each of the 12 factors in more detail, explaining their importance and providing examples.

1. 1 2 FA C T O R A P P
S O F T WA R E E N G I N E E R I N G PA T T E R N S

2. A B O U T M E
• Docker, 12 Factor Apps, Massive Cloud Scaling is a bit
new to me.
• Discovered this over the last 3 months through
researching new workflows with Docker.
• Know a thing or two but am no Linux guru.

3. 1 2 FA C T O R A P P ?

4. C O N C E P T S

5. C L O U D S C A L A B I L I T Y

7. C L O U D S C A L A B I L I T Y =
H O R I Z O N TA L S C A L A B I L I T Y

8. … A A S M O D E L S
… A S A S E R V I C E M O D E L S

9. AS A SERVICE MODELS

10. AS A SERVICE MODELS

11. – 1 2 FA C T O R A P P M A N I F E S T O
http://12factor.net

12. W H AT A R E T H E 1 2 FA C T O R S ?
• They are guidelines for writing scalable SaaS apps

13. W H AT I S A 1 2 FA C T O R A P P ?
• Manifesto written around 2012
• by Adam Wiggins
• Heroku ( Early cloud PaaS )
http://12factor.net

14. W H Y S H O U L D I C A R E ?

15. W H Y S H O U L D I C A R E ?
• Many start up apps get written quickly
• Limited scalability
• Tangled dependencies
• Need a rewrite to scale easily

16. O H A N D …

18. If you use docker in production you probably
already have a 12 factor app!

19. I W I S H I K N E W T H I S B E F O R E
I S TA R T E D W I T H D O C K E R !
L E S S O N S L E A R N T

20. T H E FA C T O R S

21. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

22. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

23. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

24. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

25. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

26. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

27. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

28. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

29. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

30. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

31. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

32. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

33. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

34. 1 . C O D E B A S E
O N E C O D E B A S E M A N Y D E P L O Y S

35. C O D E B A S E
• codebase = repo
• one repo - many deploys
• app != many repos
• many repos = distributed
system

36. 2 . D E P E N D E N C I E S
E X P L I C I T LY D E C L A R E A N D I S O L A T E

37. D E P E N D E N C I E S
Explicitly declare and isolate dependencies
1. Declare dependencies in a manifest
2. Use isolation tools
3. Specific versions are important
4. Avoid shelling to unbundled system tools.

38. D E P E N D E N C I E S
Examples:
Dependency Manifest = Gemfile
Isolation tools = bundle exec
gem "redis-rails", "~> 3.2.3"

39. 3 . C O N F I G
S T O R E I N T H E E N V I R O N M E N T

40. C O N F I G
• Config is the specific information required to host a
deployment of your codebase
• Does not include things like routes etc.
• Mainly database credentials, paths, resource urls etc.

41. C O N F I G
Store config in the environment.
• Keep your config outside the app
• No config in git
• Open source test

42. C O N F I G
Use environment vars
Can you make your repo open source
today?
ENV[‘DATABASE_URL’]

43. 4 . B A C K I N G S E R V I C E S
A S A T TA C H E D R E S O U R C E S

44. 4 . B A C K I N G S E R V I C E S
Treat backing services as attached resources
What’s a backing service?
• Datastore
• SMTP
• Caching systems
• Amazon S3
Make no distinction between local and third party
services

46. 5 . B U I L D R E L E A S E R U N
S T R I C T LY S E PA R A T E B U I L D & R U N S TA G E S

47. B U I L D , R E L E A S E , R U N
BUILD = codebase + dependencies + assets
RELEASE = BUILD + config
RUN = run process against RELEASE

48. B U I L D ,
R E L E A S E , R U N

49. B U I L D R E L E A S E R U N
• Strict separation between stages
• Cannot change code at runtime
• Rollback = just use the last release instead.
• Release has unique release ID

50. 6 . P R O C E S S E S
E X E C U T E T H E A P P A S O N E O R M O R E
S TA T E L E S S P R O C E S S E S

51. P R O C E S S E S
• Does the running of the release
• Is stateless
• Shares nothing with other processes
• Uses single transaction only caches
• Session db storage …over sticky sessions
• Asset pre-compilation …over runtime calculation

52. 7 . P O R T B I N D I N G
E X P O R T S E R V I C E S V I A P O R T B I N D I N G

53. P O R T B I N D I N G
http://192.168.123.45 : 5555
The contract with the executive environment is
binding to a port to serve requests.

54. P O R T B I N D I N G
E-Commerce System:
http:// 192.168.123.45 : 5555
Booking System:
http:// 23.123.65.48 : 3306

55. 8 . C O N C U R R E N C Y
S C A L E O U T V I A T H E P R O C E S S M O D E L

56. C O N C U R R E N C Y
• Scale out via the process model
• Processes are first class citizens.
• Assign work to a process type (web, db, worker etc.)
• Can then handle own multiplexing
• Processes don’t daemonize or write PID files.
• Instead, use system process manager

57. C O N C U R R E N C Y
Scale out by running multiple
processes of different types

58. 9 . D I S P O S A B I L I T Y
M A X I M I S E R O B U S T N E S S W I T H FA S T S TA R T U P A N D
G R A C E F U L S H U T D O W N

59. D I S P O S A B I L I T Y
Processes are disposable
• Start quickly
• Shut down gracefully
• Be robust against sudden death

60. D I S P O S A B I L I T Y
Example: Worker Process
• Return the current job to the job queue
• All jobs are reentrant
• Or at least idempotent

61. 1 0 . D E V P R O D PA R I T Y
K E E P D E V E L O P M E N T, S TA G I N G , A N D P R O D U C T I O N
A S S I M I L A R A S P O S S I B L E

62. D E V P R O D PA R I T Y
Gaps exist between development and production:
• Time (days to push)
• Personnel (dev vs ops)
• Tools

63. D E V P R O D PA R I T Y
Need to shorten the gaps!
• CI & deploy ASAP after writing code
• Get Developers involved in Operations
• Environments should be as similar as possible:
• Eg. Resist the urge to use different backing
services between development and production

64. 1 1 . L O G S
T R E A T L O G S A S E V E N T S T R E A M S

65. L O G S
Within your app treat logs as event streams
• Don’t route or store logs in files
• Stream to stout instead and be captured and handled
by the environment

66. 1 2 . A D M I N P R O C E S S E S
R U N A D M I N / M A N A G E M E N T TA S K S A S
O N E - O F F P R O C E S S E S

67. A D M I N P R O C E S S E S
One-off admin tasks include:
• Database migrations
• Console
• One-time scripts

68. A D M I N P R O C E S S E S
• Run as separate process
• Run against the same release
• Admin code ships with app code

69. T H E FA C T O R S
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Processes

70. W H AT M I G H T T H I S A L L
L O O K L I K E ?

72. T H A N K Y O U
Q U E S T I O N S ?