The 12-Factor App methodology defines best practices for building software-as-a-service (SaaS) apps. It promotes apps that are highly scalable and portable by being self-contained and having their dependencies explicitly defined. The 12 factors cover aspects like codebase, dependencies, configuration, backing services, build and release processes, concurrency, disposability, development and production parity, and administrative tasks. Following the methodology helps apps maximize agility, reliability, and developability.

1. 12-Factor App
A Methodology for Building
SaaS Apps
MM Meetup, September 2015, Ankara
/Abdullah Cetin CAVDAR @accavdar

2. Me :)
Software Engineer
Continuous Reader / Learner
Runner / Rider
Snooker Lover
Headbanger m/
@udemy

3. 12factor.net

4. What's 12-Factor
App?

5. It's a methodology for building
SaaS apps

6. Why do we care?

7. Tries to define the systematic
problems in app development

8. Tries to offer a set of broad
conceptual solutions to those
problems

9. What are the
properties of an
app?

10. Uses declarative format for
setup automation
to minimize time and cost for new developers joining the project

11. Has a clean contract with the
underlying operating system
offering maximum portability between execution environments

12. Is suitable for deployment on
modern cloud platforms
no need for servers and systems administration

13. Minimizes divergence between
development and production
enabling continuous deployment for maximum agility

14. Can scale up
without significant changes to tooling, architecture, or
development practices

15. The 12-Factors

16. 1. Codebase
One codebase tracked in revision control,
many deploys

17. codebase == code repo == repo

18. tracked in a version control
system: , , etc.git mercurial svn

19. one repo, many deploys

20. app != many repos
many repos = distributed system

21. 2. Dependencies
Explicitly declare and isolate dependencies
PS: Think about new developers :)

22. Never rely on implicit existence of packages

23. Dependency Declaration
Declare all dependencies, completely and
exactly, via a dependency declaration
manifest

24. Dependency Isolation
Ensure that no implicit dependencies "leak
in" from the surrounding system

25. pip

26. virtualenv

27. source ~/udemy-py3-env/bin/activate &&
pip install -r requirements/dev.txt

28. Do not rely on the implicit
existence of any system tools
Bundle them with your app

29. 3. Config
Store config in the environment

30. What's config?
Everything that is likely to vary
between deploys

31. Resource Handles (db, memcache, backing services, ...)
Credentials to external services (twitter, AWS, ...)
Per-deploy values (canonical hostname, ...)
PS: It does not include internal app config (config/routes.rb, bean
config, ...)

32. Can you make
your repo open
source?

33. Store config in Environment
Variables
Keep your config outside the app
Env vars are easy to change between deploys
No secret in version control

36. You may use Environments
but 12-Factor App recommends Env Vars
dev
test
staging
prod
...

37. It's also called Profiles

38. 4. Backing Services
Treat backing services as attached resources

39. A backing service is any service
the app consumes over the
network
Data Store (MySQL, MongoDB, AWS S3...)
Messaging/Queueing Systems (RabbitMQ, Kafka, ...)
Caching Systems (Redis, Memcached, ...)
SMTP Services (Postfix, ...)

40. No distinction between local
and third party services

41. They are Attached Resources
accessed via a URL or other
locator/credentials stored in the config

43. They are loosely coupled with the deployed app
They are easily swap out without any changes to the app’s code
Microservices?

44. 5. Build, Release,
Run
Strictly separate build and run stages

45. A codebase is transformed into
a deploy through three stages
Build
Release
Run

46. Build
Converts a code repo into an
executable bundle
Build = Dependencies + Binaries + Assets

47. Release
Get the build and combine it
with the current config
Release = Build + Config

48. Run
Run the app in the execution
environment
Run = Run process against release

50. Strict separation between the
build, release, and run stages
For example, it is impossible to make
changes to the code at runtime

51. Use tools to easily rollback to previous release

52. Version your releases with unique release ids (ex: v101)
Any change must create a new release

53. 6. Processes
Execute the app as one or more stateless
processes

54. Processes are stateless and
share-nothing
Any data that needs to persist must be
stored in a stateful backing service

55. Never assume that anything cached in memory or on disk will be
available on a future request or job
Never use or rely on sticky sessions, use a data store that offers time-
expiration, such as Memcached or Redis

56. 7. Port Binding
Export services via port binding

57. App is completely self-contained
The web app exports HTTP as a service by binding to a port

58. Use dependency declaration to
add a web server library
Tornado for Python
Thin for Ruby
Jetty or Tomcat for Java

59. Use it not only for HTTP
Any kind of service runs via a process binding to a port, i.e Redis
Port-binding approach means that one app can become the backing
service for another app

60. 8. Concurrency
Scale out via the process model

61. Processes are a first class citizen
Developers can architect their app to handle diverse workloads by
assigning each type of work to a process type
HTTP requests may be handled by a web process
Long-running background tasks handled by a worker process
...

63. Each process can handle its own multiplexing
Threads in runtime VM (Java, ...)
Async/Event model (Twisted, node.js, ...)
Use system process managers (i.e Upstart) to
Manage process
Respond to crash process
Handle user initiated restarts and shutdowns

64. Scale Out?

65. with share-nothing, horizontally partitionable nature of app processes
Simple and Reliable Concurrency

66. 9. Disposability
Maximize robustness with fast startup and
graceful shutdown

67. Processes are disposable
meaning they can be started or stopped at
a moment’s notice
fast elastic scaling
rapid deployment of code and config changes
robustness of production deploys

68. Minimize startup time
more agility for the release process and scaling up
aids robustness

69. Shut down gracefully when
they receive a SIGTERM
Cease to listen on the service port, allow any current requests to
finish, and then exit (Web Process)
Return the current job to the work queue (Worker Process)
Try to make all jobs reentrant or
Make the operation idempotent

70. Be robust against sudden death
Use a robust queueing backend
RabbitMQ
Beanstalkd
Redis

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

72. Development vs Production
Gaps

73. Time Gap
A developer may work on code that takes
days, weeks, or even months to go into
production

74. Personnel Gap
Developers write code, ops engineers
deploy it

75. Tools Gap
Stack like Nginx, SQLite, and OS X in dev,
Apache, MySQL, and Linux in prod

76. Design for continuous
deployment
Keep the gap between development and
production small

77. Make the time gap small
A developer may write code and have it
deployed hours or even just minutes later

78. Make the personnel gap small
Developers who wrote code are closely
involved in deploying it and watching its
behavior in production

79. Make the tools gap small
Keep development and production as
similar as possible
Resist to use different backing services between development and
production
Chef, Puppet, ...
Docker, Vagrant, ...

81. 11. Logs
Treat logs as event streams

82. Never concern itself with
routing or storage of its output
stream
Each running process writes its event
stream, unbuffered, to stdout

83. Index and analyse (splunk,
hive/hadoop, ...) your event
streams to
Finding specific events in the past
Large-scale graphing of trends (such as requests per minute)
Active alerting according to user-defined heuristics

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

85. One-off administrative or
maintenance tasks for the app
Running DB migrations
Running a console (REPL shell)
Running one time script

86. Run them in an identical environment as the regular app
Ship with application code to avoid synchronization issues
Favor languages which provide a REPL shell out of the box

87. Also check:
Microservices
Reactive Manifesto
Containerization ( , ,
)
LXC Docker
CoreOS

88. Thank you :)

89. Questions?

90. THE END
by Abdullah Cetin CAVDAR / @accavdar