12 factor app

Nowadays many organizations are heading towards numerous cloud solutions, while, even more, organizations are already there. In order not to negate advantages that cloud can provide us with, I would like to go through a methodology or rather a set of best practices designed to improve maintainability scalability and portability of applications created for cloud platforms.

1. WHAT IS A 12 FACTOR APP? Arch9: Amsterdam, The Netherlands

2. HELLO! I am Dmytro Panin Found of Java, Cloud, IoT ⦿

3. CLOUD IS EVERYWHERE ⦿

4. “ Cloud - access to a pool of computing resources (servers, storage, networks, services etc) that can be rapidly provisioned and made available with minimal overhead ” ⦿

5. ⦿

6. The 12 factors are language and technology agnostic ⦿

7. BENEFITS OF THE 12 FACTORS Minimize time and cost for a new developer joining the project M aximum portability between execution environments Scale up without significant changes ⦿

8. 12 factors Set of principles that prepare your app for the best experience in cloud ⦿

9. CODEBASE One codebase tracked in revision control, many deploys 1

10. One codebase per application 1

11. Submodules if exist should be separated by VCS 1

12. DEPENDENCIES Explicitly declare and isolate dependencies 2

13. System-wide 12 factor app never relies on system-wide dependencies DEPENDENCIES Isolated dependencies are declared explicitly 2

14. CONFIG Store config in the environment 3

15. 12 FACTOR CONFIG Backing services Resource handles to the services that are required for the app Example: Database Passwords Credentials to external services Example: Twitter Per-deploy values Values that differ based on an environment Example: Hostname 3

16. 12 FACTOR CONFIG Backing services Resource handles to the services that are required for the app Example: Database Passwords Credentials to external services Example: Twitter Per-deploy values Values that differ based on an environment Example: Hostname 3

17. 12 FACTOR CONFIG Backing services Resource handles to the services that are required for the app Example: Database Passwords Credentials to external services Example: Twitter Per-deploy values Values that differ based on an environment Example: Hostname 3

18. NOT 12 FACTOR CONFIG Configuration of a framework is not 12 factor app conf Routes do not vary between deploys, thus, better stored in code. 3

19. CONFIGURATION FILES 3 Number of configuration files that you have right now for all of your environments Number of environments may grow over time as well as number of configuration files in your app’s repository

20. CONFIG The 12 factor app stores config in environment variables 3 OS-agnostic standard Little chance of committing into the repo Having config separated helps to scale out easier

21. THE LITMUS TEST 3

22. BACKING SERVICES Treat backing services as attached resources 4

23. RESOURCES 4

24. LOCAL OR 3rd PARTY 4 The code for a twelve-factor app makes no distinction between local and third-party services

25. BUILD, RELEASE, RUN Strictly separate build and run stages 5

26. STAGES 5 BUILD RELEASE RUN Strict separation between the stages

27. VERSIONING Every release should always have a unique release ID 5 Timestamp Incrementing number A release cannot be mutated once it is created

28. PROCESSES Execute the app as one or more stateless processes 6

29. STATELESS 6 Twelve-factor processes are stateless and share-nothing Any data that needs to persist must be stored in a stateful backing service

30. STICKY SESSIONS 6 Sticky sessions are a violation of the twelve factors

31. PORT BINDING Export services via port binding 7

32. SELF CONTAINED 7 The 12 factor app is self-contained Do not require an application container Embeds a webserver library The web app exports HTTP as a service by binding to a port

33. SELF CONTAINED 7 The 12 factor app is self-contained Do not require an application container Embeds a webserver library The web app exports HTTP as a service by binding to a port

34. SELF CONTAINED 7 The 12 factor app is self-contained Do not require an application container Embeds a webserver library The web app exports HTTP as a service by binding to a port

35. CONCURRENCY Scale out via the process model 8

36. VERTICAL 8 Scale up is not enough

37. HORIZONTAL 8 Scale out

38. PROCESS MODEL 8 Microservices

39. DISPOSABILITY F ast startup and graceful shutdown 9

40. DISPOSABILITY 9 Maximize robustness Minimize startup time Shut down gracefully

41. RESILIENCE 9 Be robust against sudden death

42. DISPOSABILITY 9 Don’t be too attached to your servers Servers are a commodity

43. DEV/PROD PARITY Keep dev, staging and prod as similar as possible 10

44. TOOLS 10 SQLite ≠ MySQL

45. TIME 10 Code is in production a few hours after a commit

46. PERSONNEL 10 Developers should deploy their code

47. LOGS Treat logs as event streams 11

48. LOGS 11

49. LOGS 11 12 factor app don’t route or storage its output stream

50. ADMIN PROCESSES Run admin/management tasks as one-off processes 12

51. Codebase Dependencies Config Backing services Build, release, run Processes Port binding Concurrency Disposability Dev/prod parity Logs Admin processes LET’S RECAP ⦿

52. DETAILS http://12factor.net ⦿

53. QUESTIONS?