Docker, Kubernetes, .NET Core

Presented at .NET Conf 2019 (Microsoft Turkey, Istanbul). It's about how to develop modernized, cloud-native .NET Core applications according to 12 factors.

Transcript

1. Docker, Kubernetes, .NET Core
2. SELÇUK USTA Software Development Manager @ /in/selcukusta selcukusta.com selcukusta ustasoglu selcukusta (at)gmail.com
3. cloud-native vs cloud-enabled
4. cloud-native applications have microservice-oriented design All applications are segmented into micro/nano-services.
5. cloud-enabled applications have monolithic design An application combines various services in a single package.
6. cloud-native applications are containerized Each application is born, lived and died in its own package.
7. cloud-enabled applications designed to be locally hosted An application is moved to cloud but it’s developed for traditional data centers.
8. cloud-native applications are dynamically orchestrated Containers are actively scheduled and managed to optimize resource utilization.
9. cloud-enabled applications needs reserved resources You may have much more unused resources and it's not a cost-effective solution.
10. If your application tightly coupled to environment and infrastructure…
11. If your application takes a long time to deploy any stage…
12. If your application has a low reflex to improvements and/or bad situations…
13. If your application needs manual operations to handle much more requests…
14. …and it is live on any cloud platforms; it means cloud- enabled
15. ..but…
16. According to IDC*, by 2022, 90% of all apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code; 35% of all production apps will be cloud-native. (*) https://www.idc.com/getdoc.jsp?containerId=prUS44417618
17. ..so…
18. How can be cloud-native?
19. How can be cloud-native? evolve from enabled to native?
21. 1 registry.hub.docker.com/selcukusta/openhack-core:2.0.0 prod -e ASPNET_ENVIRONMENT=Production pilot -e ASPNET_ENVIRONMENT=Pilot dev -e ASPNET_ENVIRONMENT=Development One codebase in VCS, many deploy
22. 1 registry.hub.docker.com/selcukusta/openhack-core-dev:2.0.0 registry.hub.docker.com/selcukusta/openhack-core-pilot:2.0.0 registry.hub.docker.com/selcukusta/openhack-core-production:2.0.0 One codebase in VCS, many deploy
23. 1 One codebase in VCS, many deploy registry.hub.docker.com/selcukusta/openhack-core:2.0.0-dev registry.hub.docker.com/selcukusta/openhack-core:2.0.0-pilot registry.hub.docker.com/selcukusta/openhack-core:2.0.0-production
24. 2 Explicitly declare and isolate dependencies
25. 2 Explicitly declare and isolate dependencies
26. 2 Use GAC (Global Assembly Cache) <ProjectReference Include=“..\AnotherFolder\AnotherApp\AnotherApp.csproj” /> Explicitly declare and isolate dependencies
27. 3 Configuration management Requires strict separation of config from codebase.
28. 3 Configuration management Requires strict separation of config from codebase. Use environment variables or secret products of the container orchestration tool.
29. 3 Configuration management Requires strict separation of config from codebase. Use environment variables or secret products of the container orchestration tool. Use Key Vault products such as Azure Key Vault, Hashicorp Vault, etc.
30. 3 Configuration management Requires strict separation of config from codebase. Use environment variables or secret products of the container orchestration tool. Use Key Vault products such as Azure Key Vault, Hashicorp Vault, etc. Should be platform/OS agnostic!
31. 3 Configuration management
32. 3 Configuration management
33. 3 Configuration management
34. 3 Configuration management
35. 3 Configuration management
36. 3 Configuration management (*) https://github.com/selcukusta/dotnetconf-19
37. 4 Backing services registry.hub.docker.com/selcukusta/openhack-core:2.0.0 { "AuthService.Url" : "https://auth" } { "ConnectionStringKey" : "VaultKey" }
38. 4 Backing services A backing service is any service the app consumes over the network as part of its normal operation.
39. 4 Backing services A backing service is any service the app consumes over the network as part of its normal operation. Application should access to backing services via URL and/or credentials stored in the config.
40. 4 Backing services A backing service is any service the app consumes over the network as part of its normal operation. Application should access to backing services via URL and/or credentials stored in the config. Use local disk!
41. 4 Backing services A backing service is any service the app consumes over the network as part of its normal operation. Application should access to backing services via URL and/or credentials stored in the config. Attach the resource to the executable! Use local disk!
42. 5 Build, Release, Run Strictly separate all stages.
43. 5 Build, Release, Run Strictly separate all stages. Create immutable images when you’re in BUILD stage.
44. 5 Build, Release, Run Strictly separate all stages. Create immutable images when you’re in BUILD stage. Create execution environment (set environment variables, check backing services, etc.) when you’re in RELEASE stage.
45. 5 Build, Release, Run Strictly separate all stages. Create immutable images when you’re in BUILD stage. Create execution environment (set environment variables, check backing services, etc.) when you’re in RELEASE stage. Run the container without any changes in the environment when you’re in RUN stage.
46. 6 Execute the app as one or more stateless processes Use memory cache!
47. 6 Execute the app as one or more stateless processes Use memory cache! Save any physical files in the environment!
48. 6 Execute the app as one or more stateless processes Use memory cache! Save any physical files in the environment! Use sticky session!
49. 6 Execute the app as one or more stateless processes Use memory cache! Save any physical files in the environment! Use sticky session! Containers are ephemeral. They're built, they're released, they're deployed and they're destroyed!
50. 7 Export services via port binding The application should be completely self-contained and should not dependence out to any webserver to get the request.
51. Export services via port binding The application should be completely self-contained and should not dependence out to any webserver to get the request. The exposed port should be stored on the environment. 7
52. Export services via port binding The application should be completely self-contained and should not dependence out to any webserver to get the request. The exposed port should be stored on the environment. The exposed port should be documented absolutely and clearly (TCP/UDP). 7
53. 8 Scale out via the process model The application should never daemonize (work as a background process)!
54. Scale out via the process model The application should never daemonize (work as a background process)! Use process manager such as systemd, supervisord, etc. 8
55. Scale out via the process model The application should never daemonize (work as a background process)! Use process manager such as systemd, supervisord, etc. Horizontally scaling by adding new instance. 8
56. Scale out via the process model .NET Core 3.0 - Run the application as a worker 8
57. 9 Disposability Keep minimum startup and shutdown time.
58. Disposability Keep minimum startup and shutdown time. This facilitates fast elastic scaling, rapid deployment of code or config changes. 9
59. Disposability Keep minimum startup and shutdown time. This facilitates fast elastic scaling, rapid deployment of code or config changes. Use IApplicationLifetime interface for graceful shutdown. 9
60. Disposability 9 kubernetes-manifest.yaml Program.cs
61. 10 Dev/Prod Parity The application should consume the same backing services in all environments.
62. 10 Dev/Prod Parity The application should consume the same backing services in all environments. The same topology should be used in all environments.
63. 10 Dev/Prod Parity The application should consume the same backing services in all environments. The same topology should be used in all environments. The same products should be used for monitoring, logging and tracing in all environments.
64. 11 Treat logs as event streams
65. 12 Admin processes Admin management tasks should be run in the same environment and against the same codebase and configuration as the web/worker application.
66. 12 Admin processes Admin management tasks should be run in the same environment and against the same codebase and configuration as the web/worker application. registry.hub.docker.com/selcukusta/openhack-core-migration:1.0.0 registry.hub.docker.com/selcukusta/openhack-core-seed:1.0.0
67. 12 Admin processes
68. 12 Admin processes
69. /in/selcukusta selcukusta.com selcukusta ustasoglu selcukusta (at)gmail.com Thank you…