.NET meetup of Open Tech Week by Sigma Software, Lviv 2018

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

5. Monolith vs Microservices
@skalinets 5

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

9. Pets vs Cattle
@skalinets 9

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

33. Codebase Deployment Stages
Build
Release
Run
@skalinets 33

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

59. Thanks!
kalinets@gmail.com
@skalinets
https://skalinets.github.io
@skalinets 59