12 [Anti] Factors

Vamos falar sobre os 12-Factor, mas sob uma ótica diferente: o que não fazer. A ideia desta talk é expor algumas práticas que podem ajudar nossas aplicações a rodar em ambientes distintos seguindo alguns conceitos simples definidos pelos 12 Factors.

Transcript

1. 12 [Anti] Factors
2. { “name”: “Gabriel Ferreira”, “github”: “@gleopoldo” }
6. Chapter Evolução Tecnológica
7. 90.02% apps em EOL 1.9,3 2011-2015 2.0.0 2013-2016 2.1.0 2013-2017 2.2.0 2014-2018 2.3.0 2015-2019 2.4.0 2016-2020 2.5.0 2017-2021 2.6.0 2018-2022 2.7.0 2019-2023 2014 tecnologia de
8. 88.17% de 93 apps ruby em EOL 1.8.X 1.9.X 2.0.X 2.1.X 2.2.X 2.3.X 2.4.X 2.5.X 2.6.X 2.7.X 18% 24% 30% 36% 42% 19.35% 8.6% 10.75% 3.23% 39.78% 6.45% 11.83% 0% 0% 0% ruby <= 2.4 https://www.ruby-lang.org/en/downloads/branches/
9. 73.08% de 78 apps rails em EOL * 3.X 4.0.X 4.1.X 4.2.X 5.X 18% 24% 30% 36% 42% 29.49% 2,56% 6.41% 34.62% 26.92% rails <= 4.2 * 6.X 0% * https://guides.rubyonrails.org/maintenance_policy.html
10. 63.64% apps em debian no EOL * 6 (squeeze) 7 (wheezy) 8 (jessie) 9 (stretch) 10 (buster) 18% 24% 30% 36% 42% 11.57% 28,09% 23.96% 36.36% debian LTS <= 8 debian <= 9 (EOL em 06/07) * 0% * https://wiki.debian.org/DebianReleases
11. Ease of change!
13. systemd Tech-agnostic Heroku Terraform Kubernetes Rancher Systemd Ease of change
14. https://12factor.net/
15. 12 [Anti] Factors
16. I. codebase “one code base tracked in revision control, many deploys”
17. git blame your friends! [just kidding]
18. Same codebase through environments
20. The Milter Project Baseado no projeto https://github.com/sdgathman/pymilter Milter sender milter bounces milter ??? ??? single repo! SEND! BOUNCE!
21. The Milter Project Bounces Milter Sender Milter one project per repo SEND! BOUNCE! s.o.: debian A python: X.X.X s.o.: debian B python: Y.Y.Y The Bounces-Milter Project
22. II. dependencies “explicitly declare and isolate dependencies”
23. Declare and Isolate your dependencies
24. “I use bundler, by the way”
25. https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
27. Domain Driven Rails - RubyConf 2019
28. Avoid assumptions on environment
29. Always vendorize your deps
30. The Milter Project no bundler, no Pipfile python-redis python milter pycrypto pymilter deps management done in PROD \o/ package with only source code, no deps here... all deps loaded magically in the application probably running dev with different versions of deps
31. The Milter Project Pipfile + pipenv python-redis python pymilter milter pycrypto deps management done in Pipfile.lock package vendoring dependencies in CI all deps loaded through PYTHONPATH env var probably running dev with same versions of deps
32. III. config “store config in environment”
33. don’t check CONFIG files in git :(
34. use ENVIRONMENT variables (Greenpeace approves)
35. Keep sensible settings in separate config files
36. a DEBIAN example (with systemd)
37. # config/database.yml
38. # debian/my_service.service
39. # debian/my_service.default
40. use ENV vars use CONFIG files
41. IV. backing services “treat backing services as attached resources”
42. Backing-services loosely coupled My App no distinctions between 1st or 3rd owned services
43. Beware with API version end-of-life
44. V. build, release, run “strictly separate build and run stages”
45. 1: BUILD - vendoring gems - compiling assets - .deb package
46. 2: Release [the Kraken!] - installable package - environment config
47. 3: Run - run the release (config + package)
48. Immutable Servers: never change a running server
49. https://martinfowler.com/bliki/ImmutableServer.html
50. VI. processes “execute the app as one or more stateless processes”
51. Keep state in the database
52. Have one or more processes
53. Different background processes spawning several processes for fun: A young application server Can run in one host (VM) or multiple containers
54. Don’t store permanent DATA in filesystem
55. File doesn’t exist error :( what happens when your app... Important customer’s file ...uses local filesystem to save stuff... WTF?!?!?!
56. File doesn’t exist error :( what happens when your app... Important customer’s file ...uses local filesystem to save stuff... WTF?!?!?!
57. what happens when your app... Important customer’s file ...uses object storage to save stuff... External FileSystem HTTP request [POST] Found! :D HTTP request [GET] Temporary file saved in host
58. VII. port binding “export services via port binding”
59. The APP must listen requests in a port
60. socket port 3000 3000 6379 socket port 5432 5432 exposing app ports 7474 socket port 6379 socket port 9999 NO! port is closed
61. VIII. concurrency “scale out via the process model”
62. Processes share nothing
63. The application processes MUST scale
64. Scale-up Adding + processing power Scale-out Keep same amount of hosts The “internetz” Adding more instances of your application Distributed processing The cheaper way
65. HOST B: Splitting Critical Sidekiq Queues in different hosts ‘high’ priority ‘low’ priority ‘default’ priority HOST A: ‘high’ priority ‘low’ priority ‘default’ priority
66. HOST B: Splitting Critical Sidekiq Queues in different processes ‘high’ priority ‘low’ priority ‘default’ priority HOST A: ‘high’ priority ‘low’ priority ‘default’ priority
67. # debian/smtp-worker-sidekiq.service
68. # debian/smtp-worker-sidekiq-bounces.service
69. Don’t rely on PID files
70. IX. disposability “maximize robustness with fast start-ups and graceful shutdown”
71. Fast startups == Fast releases
72. Graceful Shutdown == Better Consistency
73. Your processes can be stopped at any time
74. Idempotent Workers ...or mathematically: f(x) = X f(f(x)) = X “input” “output” your function / worker always returns the same output, given an input
75. Reentrant Workers “input” atomicity guarantee your function / worker share-nothing scenario “input” in-memory “output” in-memory “output” thread-safe consistent shutdown
76. Reentrant Workers “input” your function / worker with one side-effect scenario “input” writing to same file (side-effect) first write wins strategy atomicity guarantee thread-safe consistent shutdown
77. Reentrant Workers “input” your function / worker with multiple side-effects scenario “input” writing to same file (side-effect) No all-or-nothing guarantee (not atomic) send SPAM (side-effect) atomicity guarantee thread-safe consistent shutdown
78. Reentrant Workers “input” your function / worker using single-database transactions scenario “input” several write queries in a transaction (side-effect) atomicity guarantee thread-safe consistent shutdown
79. Reentrant Workers “input” your function / worker using multi-database transactions scenario “input” PG transaction (side-effect) atomicity guarantee thread-safe consistent shutdown Push job to Sidekiq (side-effect)
80. CRASH-only software design
81. Let it CRASH! bad things will occur, be prepared to it instead of preventing it
82. # debian/smtp-worker-sidekiq.service
83. X. dev/prod parity “keep development, staging and production as similar as possible”
84. Use same versions as prod in your dev environment!
85. Make it easy to test new versions!
86. XI. logs “treat logs as event streams”
87. App shouldn’t care about logrotate
88. Stream logs to STDOUT, always!
89. # debian/smtp-worker-sidekiq.service
90. XII. admin processes “run admin/management tasks as one-off processes”
91. SPLIT admin tasks from main process
92. recapitulando… Ease of change!
93. Dúvidas? Gabriel Ferreira Github: @gleopoldo gabrielleopferreira@gmail.com https://www.linkedin.com/in/gabriel-leopoldo/