The document discusses the 12 Factor App methodology for building scalable software-as-a-service applications. The 12 factors are: use one codebase tracked in version control; declare and isolate dependencies; store config in the environment; treat backing services as attached resources; separate build and run stages; execute the app as stateless processes; export services via port binding; scale out via processes; maximize robustness with fast startup and graceful shutdown; keep development, staging, and production environments similar; treat logs as event streams; and run admin/management tasks as one-off processes.

1. Hello Cloud
GIREESH KUMAR

2. Topics
 The DHARMA Principles

3. DHARMA Principles
 Documented (just enough)
 Highly cohesive/loosely coupled (all the way down)
 Automated from commit to cloud
 Resource aware
 Monitored thoroughly
 Antifragile

4. 12 Factor App
Guidelines for writing scalable SaaS apps
http://12factor.net/

5. 12 Factor App
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release Run
6. Process
7. Port Binding
8. Concurrency
9. Disposability
10.Dev/Prod Parity
11.Logs
12.Admin Process

6. 12 Factor App
Codebase
one codebase, multiple deploys

7. 12 Factor App – Codebase
One codebase, multiple deploys
 Use version control like ‘git’
 If there are multiple codebases, it’s not an app – it’s a
distributed system
 Multiple apps sharing the same code is a violation of
twelve-factor
 The codebase is the same across all deploys, although
different versions may be active in each deploy

8. 12 Factor App
Dependencies
Explicitly Declare and isolate

9. 12 Factor App – Dependencies
Explicitly Declare and isolate
 Declare dependencies in a manifest
 Use isolation tools
 Specific version are important
 Never rely on implicit existence of system wide packages
 Eg. nodejs ‘package.json’ / Ruby Gem file etc

10. 12 Factor App
Config
Store in the environment

11. 12 Factor App – Config
Store in the environment
 Information required to host a deployment of your codebase
 Mainly DB Credentials, path, resources etc
 Should be strictly separated from code
 Configuration belongs in the environment not in the application
 No config in git
 Use Environment vars (like ENV['DATABASE_URL'] )

12. 12 Factor App
Backing Services
As Attached resources

13. 12 Factor App – Backing Services
As attached resources
 Backing Services
 Data store
 SMTP
 Cache
 Amazon S3
 Twitter
 Make no distinction between local and third party services

14. 12 Factor App
Build, Release, Run
Strictly separate build & run stage

15. 12 Factor App – Build, Release, Run
Strictly separate build & run stage
BUILD = Codebase + dependencies + assets
RELEASE = Build + config
RUN = Run process against Release
 Strict separation between stages
 Cannot change code at runtime
 Rollback = use the last release instead
 Every release should always have a unique release ID

16. 12 Factor App
Processes
Execute the app as one or more stateless process

17. 12 Factor App – Processes
Execute the app as one or more stateless process
 Does the running of the release
 Is stateless
 Share nothing with other process
 Use single transaction only caches
 No sticky sessions - Use session state data with memcached/redis
 Asset pre-compilation instead of over runtime calculation

18. 12 Factor App
Port Binding
Export services via port binding

19. 12 Factor App – Port Binding
Export services via port binding
The contract with the execution environment is binding to a port to serve request .
App is completely self-contained
Booking
http://192.168.123.45:5555
Shop
http://23.123.34.54:5505

20. 12 Factor App
Concurrency
Scale out via the process model

21. 12 Factor App – Concurrency
Scale out via the process model
 Scale out via the process model (by running multiple process of different types)
 Process are the first class citizens
 Assign to work to a process type (web, db, worker etc)
 Can then handle own multiplexing
 Process don't demonize or write PID files
 Instead using system process manager

22. 12 Factor App
Disposability
Maximize robustness with fast startup and graceful shutdown

23. 12 Factor App – Disposability
Maximize robustness with fast startup and graceful shutdown
 Process are disposable (they can be started or stopped at a moment’s notice)
 Start quickly
 Shutdown gracefully
 Be robust against sudden death

24. 12 Factor App
Dev Prod Parity
Keep development, staging and production as similar as possible

25. 12 Factor App – Dev Prod Parity
Keep development, staging and production as similar as possible
 Gaps
 The time gap: A developer may work on code that takes days, weeks, or even months to go into production.
 The personnel gap: Developers write code, ops engineers deploy it.
 The tools gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses
Apache, MySQL, and Linux.
 Make the time gap small: a developer may write code and have it deployed hours or even just minutes
later.
 Make the personnel gap small: developers who wrote code are closely involved in deploying it and
watching its behavior in production.
 Make the tools gap small: keep development and production as similar as possible.

26. 12 Factor App
Logs
Treat logs as event streams

27. 12 Factor App – Logs
Treat logs as event streams
 Dont route or store logs in files
 Stream to stout instead and be captured and handled by environment

28. 12 Factor App
Admin processes
Run admin/management tasks as one-off processes

29. 12 Factor App – Admin processes
Run admin/management tasks as one-off processes
 Database migration
 Console view
 Running one time scripts
 Run as seperate process
 Run against the same release
 Admin code ships with app code

31. Next