The twelve-factor app methodology is a set of best practices for building scalable, maintainable, and portable software applications. It emphasizes aspects such as strict separation of code and configuration, dependency declaration, stateless processes, and treating logs as event streams. By adhering to these principles, developers can create cloud-native applications that are easy to deploy and manage across different environments.

1. Twelve-Factor App
Software Application Architecture

2. 12-Factor App: Methodology for
building software applications.

3. Software applications that are:

4. Software applications that are:
Easy to Setup

5. Software applications that are:
Easy to Setup
Portable

6. Software applications that are:
Easy to Setup
Portable
Cloud Platform ready

7. Software applications that are:
Easy to Setup
Portable
Cloud Platform ready
CI/CD ready

8. Software applications that are:
Easy to Setup
Portable
Cloud Platform ready
CI/CD ready
Scalable

9. Twelve-Factor Application
[1] Codebase

10. Code

11. Code Version Control

12. Code Version Control Server

13. Dev #1
QA #1
Staging
Production

14. Codebase: One codebase tracked in
revision control, many deploys.

15. Twelve-Factor Application
[2] Dependencies

16. Application
Bundle

17. Code
Application
Bundle

18. Code
Application
Bundle
Dependencies

19. Code
Application
Bundle
Dependencies
Binaries

20. Code / Dependencies

21. Code / Dependencies
-
Anti-Pattern: Reliance on implicit
existence of system-wide packages
Declares all dependencies, completely and exactly,
via dependency declaration manifest.

22. Dependency Isolation:
Application deployments should carry
all their dependencies with them
Staging
Production

23. package.json => npm install

24. requirements.txt => pip install

25. Code
Dependencies

26. Dockerfile => docker build

27. Development
Staging
docker run
Production

28. Dependencies: Explicitly declare and
isolate dependencies.

29. Twelve-Factor Application
[3] Config

30. Credentials to external services
(e.g. Twitter, Amazon S3)
Per deploy values
(e.g. CName, URL)
Config
Handling of backing services.
(e.g. Database, Memcached)

31. Development
Staging
Production

32. Development
Staging
Production
-
Anti-Pattern: Strict separation of
config from code.
"A litmus test for whether an app has all config
correctly factored out of the code is whether the
codebase could be made open source at any
moment, without compromising any credentials."

33. Development
Staging
Production

34. Twelve-Factor apps stores config in
environment variables
import os
ENV = os.environ[‘ENV’]
SECRET = os.environ[‘SECRET’]
[development]
> docker run -e “ENV=development” -e “SECRET=HIMIG” myApp
[production]
> docker run -e “ENV=production” -e “SECRET=MALAYA” myApp
[development] my.env
ENV=development
SECRET=HIMIG
[production] my.env
ENV=production
SECRET=MALAYA
OPTION #1
APPLICATION
CODE
OPTION #2

35. Config: Store config in the
environment.

36. Twelve-Factor Application
[4] Backing Services

37. A backing service is any service the app consumes
over the network as part of its normal operation.

38. A backing service is any service the app consumes
over the network as part of its normal operation.
• Data Stores

39. A backing service is any service the app consumes
over the network as part of its normal operation.
• Data Stores
• Messaging/
Queuing Systems

40. A backing service is any service the app consumes
over the network as part of its normal operation.
• Data Stores
• Messaging/
Queuing Systems
• SMTP Services

41. A backing service is any service the app consumes
over the network as part of its normal operation.
• Data Stores
• Messaging/
Queuing Systems
• SMTP Services
• Caching Systems

43. Backing Services
localhost:27017

44. Backing Services
localhost:27017
https://auth@dynamodb.aws.com

45. Backing Services

46. Backing Services: Treat backing
services as attached resources.

47. Twelve-Factor Application
[5] Build, Release, Run

48. Build stage
Code
Dependencies
BUIILD

49. Release stage
+
Build Config
RELEASE

50. Run stage
+
RELEASE 1.1
+
RELEASE 1.2
+
RELEASE 1.3

51. Build, Release, Run: Strictly separate
build, release and run stages.

52. Twelve-Factor Application
[6] Processes

53. The application is executed in the environment as
one or more processes.

54. Stateful Processes

55. Scale down

56. Scale up

57. -
Anti-Pattern: Processes should be
stateless and share nothing.
Any data that needs to persist must be stored in a
stateful backing service
Database: Durable store of truth.
Cache: Fast, temporary state store.

58. -
Stateless Processes Backing
Services

59. -
Backing
Services
Scale down

60. -
Backing
Services
Scale up

61. Processes: Execute the app as one or
more stateless processes.

62. Twelve-Factor Application
[7] Port Binding

63. http://localhost:27017
http://localhost:3000
http://localhost:8080
e.g. mongodb access
e.g. python backend api
e.g. web server

64. /api/user/loginUser
Port 8000
Port 3000
Port 8001
Port 52617
Port 27017

65. Port Binding: Export services via port
binding.

66. Twelve-Factor Application
[8] Concurrency

67. Web API Worker

68. Web
API
Worker

69. Hosts Processes

70. Hosts Processes

71. Large Host
Small Host

72. Concurrency: Scale out via the
process model.

73. Twelve-Factor Application
[9] Disposability

74. Process
PROCESSES should be DISPOSABLE.

75. Process
PROCESSES should be DISPOSABLE.
They can be started at a moment’s notice.
Fast Launch

76. Process
Graceful
Shutdown
PROCESSES should be DISPOSABLE.
They can be started at a moment’s notice.
They can be stopped at a moment’s notice.
Fast Launch

77. Process
Graceful
Shutdown
FAST LAUNCH.
Scale up faster in response to spikes.
Ability to move processes to another host.
Replaced crashed processes faster.
Fast Launch

78. Process
Graceful
Shutdown
GRACEFUL SHUTDOWN.
1. Refuse new requests.
2. Allow any current requests to finish.
3. Exit.
Fast Launch

79. Container
Orchestration

80. Fast Launch
Add processes.

81. Fast Launch
Add servers

82. Graceful
Shutdown
Wait for current
processes to finish

83. Container
Orchestration
Terminate Processes

84. Disposability: Maximize robustness
with fast startup and graceful
shutdown.

85. Twelve-Factor Application
[10] Dev/Prod Parity

86. Development Production

87. TIME GAP.
Developer may work on code that takes days,
weeks, or even months to go into production.

88. PERSONNEL GAP.
Developers write code, ops engineers deploy it.

89. TOOLS GAP.
Developers may be using a stack like Nginx,
SQLite and OS X, while the production deploy
uses Apache, MySQL and Linux.

90. Development
Staging
Production

91. Dev/Prod Parity: Keep development,
staging and production as similar as
possible.

92. Twelve-Factor Application
[11] Logs

93. Process

94. Process Logs

95. Process Logs

96. Process Logs

97. Process Logs

101. Logs: Treat logs as event streams.

102. Twelve-Factor Application
[12] Admin Processes

103. - Migrate database
- Repair some
broken data.
- Running one-time
scripts
Admin / Management Tasks

104. Admin / Management Tasks

105. Admin / Management Tasks
-
Anti-Pattern: Deployments should be
immutable.
Servers are never modified after they’re
deployed. If something needs to be updated,
fixed, or modified, new servers should be
deployed to replace the old ones.

106. Web Admin / Mgt WorkerAPI

107. Run admin processes just like other processes.

108. Admin Processes: Run admin/
management tasks as one-off
processes.

109. TWELVE-FACTOR APPLICATION
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

110. References:
1. Twelve-Factor App Website https://
12factor.net/
2. Building Microservices with 12 Factor App
on AWS https://www.youtube.com/watch?
v=2SxKKDXKrXQ
3. Hackernoon. https://hackernoon.com/
4. Medium. https://medium.com

111. SIGFRED B. BALATAN JR.
▸ [Email] sj.balatan@gmail.com
▸ [Mobile] +63 915 253 3212
▸ [Profile] https://www.linkedin.com/in/sjbalatan26/
▸ [Slides] https://www.slideshare.net/SJBalatan