How 12-Factor methodology helps you design for change, even if you aren't building SaaS or "cloud native" applications.

1. Twelve-Factor
Application Design
Eric Wyles
Lead Architect - Southwest Power Pool
https://www.linkedin.com/in/ericwyles/
1

2. Agenda
• What is Twelve-Factor?
• Why is this important?
• A practical example.
2

3. Twelve-Factor Methodology
• Originally published by Heroku in 2011.
• Published as a guideline for developing “cloud-native”
applications, but there are benefits even if you aren’t developing
for the cloud.
• Can be applied to apps written in any programming language.
 It’s tells “what” to do, but not “how” to do it.
• Completely documented at https://12factor.net and there is a
free ebook available for download.
• Describes 12 application design best practices. (The 12
Factors)
3

4. The Twelve Factors
4
Factor Name Description
1 Codebase One codebase tracked in revision control, many deploys.
2 Dependencies Explicitly declare and isolate dependencies.
3 Config Store config in the environment.
4 Backing Services Treat backing services as attached resources.
5 Build, release, run Strictly separate build and run stages.
6 Processes Execute the app as one or more stateless processes.
7 Port binding Export services via port binding.
8 Concurrency Scale out via the process model.
9 Disposability Maximize robustness with fast startup and graceful shutdown.
10 Dev/prod parity Keep development, staging, and production as similar as possible.
11 Logs Treat Logs as event streams
12 Admin Processes Run admin/management tasks as one-off processes.

5. The Twelve Factors
5
Why does this matter?

6. Why is this important?
6

7. Change
• Commonly we think of changing business requirements.
 Design application code to adapt to future business needs.
• But there are other types of change. Some examples:
• Human Changes
 Reorgs
 Handoffs
 Reassignments
• Technology Changes
 Dependencies
 Technology Stack
 Security Patches
 Infrastructure
• Run-time Changes
 Component Failures (Hardware or Software)
 Increases and Decreases in application load
 Locations of backing services
7

8. Some Ways To Handle Change
• React to the change with manual effort. (manually take an
action)
• Automate the manual effort required to react to the change
(automatically take an action)
• Where possible Design for change
 Processes (SDLC, Pipelines, etc)
 Code
 Environment
 Etc
• Following 12-factor helps design for change
• Design applications and processes to be resilient to changes in
order to enable change
8

9. Designing For Change
Today we are focusing on the following three design goals in
order to design for change:
1. Consistency and Repeatability
2. Loose Coupling (App/Environment)
3. Scalability and Disposability
9

10. • Establishing consistency and repeatability related to:
 Application Codebase / Development
 Application Configuration
 Administrative tasks
 Application dependencies
 Development/Runtime environments
10
Consistency and Repeatability

11. • Design so that application does not need to know specific
details about the underlying platform.
• Design so that environment does not need to provide
application specific dependencies
 Directories
 Configuration Files
 Libraries
 Etc
• Design so that the administrator does not need to know
application specific details in order to:
 Locate log files
 Start/Stop the application
 Change configuration values
11
Loose Coupling
(App/Environment)

12. • Design the application in a way that the application can be
scaled up or down on demand.
• Interact with resources and manage application state in a way
that instances of the application tier can be created or destroyed
at will and the application still functions correctly.
12
Scalability And Disposability

13. 13
Consistency/
Repeatability
Loose
Coupling
Scalability /
Disposability
Human Change
Technology
Change
Runtime Change
Factor Design Goal Change
supports… enables…
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

14. A practical example
14

15. 15
Consistency/
Repeatability
Loose
Coupling
Human Change
Technology
Change
Runtime Change
Factor Design Goal Change
supports… enables…
3 - Config
Example: 3 - Config
3 – Config – Store config in the environment

16. 16
Config – Before Twelve Factor
MyApp
Props.load(/u01/app/myapp/myapp.prop)
File System
/u01/app/myapp/myapp.propTight Coupling
• Application has a hard dependency on a specific file system path
• The app can only run somewhere that can supply the path
 How do you run on Windows?
 How do you execute from your IDE?
 How do you run multiple instances with different configs?
• How do you automate password changes or distribution of configuration
changes?
 Use case: Passwords are stored in a vault (like Cyberark) and you want to
automatically rotate passwords and deliver them to applications.

17. 17
Password Automation – Before
Twelve Factor – Option 1
MyApp
Props.load(/u01/app/myapp/myapp.prop)
File System
/u01/app/myapp/myapp.propTight Coupling
?
CyberArk
Fetch Password
Persist Password
Restart App
This thing is application-
specific Spackleware
• Human Change: Application-specific
learning curve
• Technology Change: Vault and OS-specific
integration. Can’t change the vault without
rewriting app specific integrations.

18. 18
Password Automation – Before
Twelve Factor – Option 2
MyApp
Props.load(/u01/app/myapp/myapp.prop)
File System
/u01/app/myapp/myapp.propTight Coupling
CyberArk
?
Fetch Password This is application specific tight
coupling to the password vault. You
can’t change the vault without
changing the app.
And the app still has the filesystem
coupling as well.

19. 19
Config – Twelve Factor
• Application can receive config from anywhere that can supply
environment variables
 Can run on any OS
 Can execute from any modern IDE
 Can run multiple instances with different configs
 The app does not need any code for finding configs. No need to bootstrap the
app with config location.
• Let’s revisit the password automation example now…
MyApp
ENV_VARIABLES

20. 20
Password Automation –Twelve
Factor
?CyberArk
Fetch Password
This is a generic mechanism that is
application-agnostic.
• Human Change: Nothing in this picture is application specific.
• Human Change: Passwords can be completely unknown to humans.
No need to rotate passwords in response to reorgs or reassignments.
• Technology Change: If you change the vault you only need to change
the integration piece and all 12-factor apps using the vault are handled.
• Run-time Change: Enables password changes to be treated as run-time
changes that happen automatically. They can be scheduled.
MyApp
ENV_VARIABLES

21. 21
Password Automation –
CyberArk/Conjur/Summon
CyberArk (via Conjur)
MyAppSummon
ENV_VARIABLES
Summon is created and maintained by CyberArk
https://cyberark.github.io/summon/
Fetches secrets from a swappable provider and provides them as
Environment variables to your application
You execute summon as a wrapper around your app – summon launches
your app after secrets are obtained
Fetch Password
[user@host ~]$ summon --provider conjur -f secrets.yml MyApp

22. Conclusion
• The configuration example is just 1 example use case that
pertains to 1 of the 12 factors.
• If you develop, support, or maintain apps or servers, please go
read https://12factor.net
• Let’s have a conversation
• If we follow best practices, tools already exist to help your app
and administrators with common concerns/changes.
22