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.
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
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
Editor's Notes
When things aren’t repeatable, any change or reaction to change is risky.
Litmus test
-How often do you troubleshoot problems that “work in the other environment?”
-Are your deployments risky?
-Are there deployment steps other than installing the application?
-Does a production change give you anxiety?
-How hard would it be for someone from another team to learn your deployments and configs? (12-factor can bring uniformity to cross cutting concerns across teams)
When things are tightly coupled, unrelated changes have a ripple effect on each other…
Litmus Test
If a person changes teams, how much ramp up time is required for them to learn application-specific deployment steps or dependencies? (learning the couplings)
How much do changes happening to the filesystem or OS outside of your app directly affect the function of your app? (examples apache web server and jboss web server…. Same binaries/deployables can behave different ways)
When things aren’t scalable or disposable, a lot of manual effort is
Litmus Test(s)
Does your application rely on sticky HTTP sessions?
Does your application store any state or data on the local OS?
Would it create adverse effects or destabilize your app if instances were added or removed with no notice?
Now, tying it all back to the 12 factors from 12factor.net…
Each factor supports one or more of the design goals.
Meeting each of the design goals enables us to handle different types of change.
Next, we will dive into a specific example.
Factor #3 says to store configuration in the environment.
This literally means environment variables.
If you follow the lines on the previous slide, I’ve asserted that storing config in the environment ultimately enables:
Human Change
Technology Change
Runtime Change.
How does storing config in the environment enable change any more than storing in a config file?
