Building 12 factor apps with ASP.NET Core, Сергій Калинець
Download as PPTX, PDF0 likes1,101 views
The document discusses the 12 factors for building cloud-ready applications with .NET Core. The 12 factors are: I. Codebase, II. Dependencies, III. Config, IV. Backing services, V. Build, release, run, VI. Processes, VII. Port binding, VIII. Concurrency, IX. Disposability, X. Dev/prod parity, XI. Logs, XII. Admin processes. Following these principles helps make applications more scalable and resilient by separating concerns like code, runtime configuration, dependencies and backing services.
Building 12 factor apps with ASP.NET Core, Сергій Калинець
- 1. Building 12 Factor Apps with .NET Core. Serhiy Kalinets Steer73
- 2. About Me 17 years in the business In .NET since 2005 Love to code Technical Architect @ Steer73 @skalinets 2
- 3. @skalinets 3
- 4. Facebook Groups Lviv .NET User Group .NET Core Ukrainian User Group Kiev ALT.NET @skalinets 4
- 6. Here comes .NET Core @skalinets 6
- 7. Why Cloud Ready Apps? Cost-effective Failure-resilient @skalinets 7
- 8. Why Cloud Ready Apps? Reuse of existing infrastructure Works for non-cloud apps as well @skalinets 8
- 10. 12 Factor Apps Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; @skalinets 10
- 11. 12 Factor Apps Have a clean contract with the underlying operating system, offering maximum portability between execution environments; @skalinets 11
- 12. 12 Factor Apps Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; @skalinets 12
- 13. 12 Factor Apps Minimize divergence between development and production, enabling continuous deployment for maximum agility; @skalinets 13
- 14. 12 Factor Apps Can scale up without significant changes to tooling, architecture, or development practices. @skalinets 14
- 15. I. Codebase One codebase tracked in revision control, many deploys @skalinets 15
- 16. I. Codebase A codebase is any single repo A deploy is a running instance of the app The codebase is the same across all deploys @skalinets 16
- 17. II. Dependencies Explicitly declare and isolate dependencies @skalinets 17
- 18. II. Dependencies Use a package manager Never rely on implicit existence of system-wide packages Do not rely on the implicit existence of any system tools @skalinets 18
- 19. Package Manager: Paket Supports Nuget feeds Manages transient dependencies, locks out versions Considered to be faster than Nuget but in some cases is slower @skalinets 19
- 20. III. Config Store config in the environment @skalinets 20
- 21. III. Config An app’s config is everything that is likely to vary between deploys Does not include app internal config (routes, mappings etc.) @skalinets 21
- 22. Config litmus test An app has all config correctly factored out of the code is when The codebase could be made open source at any moment, without compromising any credentials. @skalinets 22
- 23. Configuration Files Avoid using appsettings.<env>.json. The only feasible use is to store your local dev stuff Transformations during deployment requires additional setup and is error prone Set of different configs per env scales badly @skalinets 23
- 24. Vendor Specific Configuration Source E.g. App settings, Key Vault in Azure Can simplify deployment and operations Violate 12 factor apps (vendor lock) @skalinets 24
- 25. Environment variables Easy to manage by devops Cannot be checked to source code OS / Platform agnostic Scale up smoothly @skalinets 25
- 26. .NET Core Configuration WebHost.CreateDefaultBuilder() contains AddJsonFile(…,"appsettings.json", …) AddUserSecrets() AddEnvironmentVariables() AddCommandLine() @skalinets 26
- 27. User Secrets cli tool Micosoft.Extensions.SecretManager.Tools dotnet user-secrets set "foo" "boo“ @skalinets 27
- 28. .NET Tips Use configuration objects as sessions Define baseline config in appsettings.json Override with env variables, app settings, user secrets @skalinets 28
- 29. IV. Backing services Treat backing services as attached resources @skalinets 29
- 30. IV. Backing services A backing service is any service the app consumes over the network as part of its normal operation Locally managed services should not be distinguished from third party services @skalinets 30
- 31. @skalinets 31
- 32. V. Build, release, run Strictly separate build and run stages @skalinets 32
- 34. Build Converts a code repo into an executable bundle known as a build Might (and should) include running tests, code analysis etc. @skalinets 34
- 35. Tools: FAKE (F# Make)/ Cake Build as a code (C# or F#), not XML or boxes with arrows Versioned. If new features need build procedure update, we just update and commit the build script No coupling to CI tool, can be run from anywhere, including devs’ machines @skalinets 35
- 36. Release A unique ID should be assigned to each release Releases are immutable, any change to environment should be done with a new release Use tools like Octopus / Jenkins Blue Ocean / VSTS etc. @skalinets 36
- 37. Run Handled by process managers / orchestrator, not humans Should have as few moving part as possible @skalinets 37
- 38. VI. Processes Execute the app as one or more stateless processes @skalinets 38
- 39. VI. Processes Should be stateless and “share nothing” Bundle assets during the build No shared memory / disks No sticky sessions @skalinets 39
- 40. VII. Port binding Export services via port binding @skalinets 40
- 41. VII. Port binding The twelve-factor app is completely self-contained and does not need web or other host Web server functionality is exposed by binding to a port @skalinets 41
- 42. Port binding in .NET WebHostBuilder().UseKestrel() @skalinets 42
- 43. VIII. Concurrency Scale out via the process model @skalinets 43
- 44. VIII. Concurrency Processes are a first class citizen Using the unix process model for running service daemons Processes are managed by process managers / orchestrators @skalinets 44
- 45. @skalinets 45
- 46. IX. Disposability Maximize robustness with fast startup and graceful shutdown @skalinets 46
- 47. IX. Disposability Strive to minimize startup time to provide more agility for the release process, scaling up and robustness Shut down gracefully when receive a SIGTERM signal from the process manager @skalinets 47
- 48. During Shutdown Web processes should not accept new request during shut down, finish current ones Worker processes should return unprocessed item back to the queue @skalinets 48
- 49. X. Dev/prod parity Keep development, staging, and production as similar as possible @skalinets 49
- 50. Gaps between dev and prod The time gap: 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 use other stack than is on producttion @skalinets 50
- 51. Minimizing Gaps The time gap: write code and deploy it to prod in hours or minutes The personnel gap: developers are involved in deploying and monitoring their code in prod The tools gap: use the same services on dev and prod @skalinets 51
- 52. X. Dev/prod parity All environments should have the same topology Size might differ (for cost efficiency) Use chocolatey / docker for running backing services locally @skalinets 52
- 53. XI. Logs Treat logs as event streams @skalinets 53
- 54. XI. Logs Logs provide visibility into the behavior of a running app Stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services @skalinets 54
- 55. XI. Logs A twelve-factor app never concerns itself with routing or storage of its output stream Write logs to stdout instead Execution environment captures, routes and stores logs @skalinets 55
- 56. Logging tips (not 12 factor apps ) Use structured logging (Serilog) In simple setups it’s might be OK to route logs from the app (Serilog AppInsights sink) Don’t save logs to your database @skalinets 56
- 57. XII. Admin processes Run admin/management tasks as one-off processes @skalinets 57
- 58. XII. Admin processes Examples: EF migrations with dotnet ef Should be bundled with release Source versions should match @skalinets 58