Twelve-Factor App: Software Application Architecture

Twelve-Factor App
Software Application Architecture

12-Factor App: Methodology for
building software applications.

Software applications that are:

Easy to Setup

Easy to Setup
Portable

Easy to Setup
Portable
Cloud Platform ready

Easy to Setup
Portable
CI/CD ready

Easy to Setup
Portable
CI/CD ready
Scalable

Twelve-Factor Application
[1] Codebase

Dev #1
QA #1
Staging
Production

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

[2] Dependencies

Code
Application
Bundle
Dependencies

Code
Application
Bundle
Dependencies
Binaries

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

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

requirements.txt => pip install

Development
Staging
docker run
Production

Dependencies: Explicitly declare and
isolate dependencies.

[3] Config

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

Development
Staging
Production

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."

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

Config: Store config in the
environment.

[4] Backing Services

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

• Data Stores

• Data Stores
• Messaging/
Queuing Systems

• Data Stores
• Messaging/
Queuing Systems
• SMTP Services

• Data Stores
• Messaging/
Queuing Systems
• SMTP Services
• Caching Systems

Twelve-Factor App: Software Application Architecture

Backing Services
localhost:27017

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

Backing Services: Treat backing
services as attached resources.

[5] Build, Release, Run

Build stage
Code
Dependencies
BUIILD

Release stage
+
Build Conﬁg
RELEASE

Run stage
+
RELEASE 1.1
+
RELEASE 1.2
+
RELEASE 1.3

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

[6] Processes

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

-
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.

-
Stateless Processes Backing
Services

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

[7] Port Binding

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

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

Port Binding: Export services via port
binding.

[8] Concurrency

Concurrency: Scale out via the
process model.

[9] Disposability

Process
PROCESSES should be DISPOSABLE.

Process
They can be started at a moment’s notice.
Fast Launch

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

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

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

Graceful
Shutdown
Wait for current
processes to ﬁnish

Container
Orchestration
Terminate Processes

Disposability: Maximize robustness
with fast startup and graceful
shutdown.

[10] Dev/Prod Parity

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

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

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

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

[11] Logs

Logs: Treat logs as event streams.

[12] Admin Processes

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

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.

Run admin processes just like other processes.

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

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

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

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

Twelve-Factor App: Software Application Architecture

More Related Content

What's hot (19)

Similar to Twelve-Factor App: Software Application Architecture (20)

Recently uploaded (20)

Twelve-Factor App: Software Application Architecture