Tweet
Tweet

Slide 1

Slide 1 text

Docker, Kubernetes, .NET Core

Slide 2

Slide 2 text

SELÇUK USTA Software Development Manager @ /in/selcukusta selcukusta.com selcukusta ustasoglu selcukusta (at)gmail.com

Slide 3

Slide 3 text

cloud-native vs cloud-enabled

Slide 4

Slide 4 text

cloud-native applications have microservice-oriented design All applications are segmented into micro/nano-services.

Slide 5

Slide 5 text

cloud-enabled applications have monolithic design An application combines various services in a single package.

Slide 6

Slide 6 text

cloud-native applications are containerized Each application is born, lived and died in its own package.

Slide 7

Slide 7 text

cloud-enabled applications designed to be locally hosted An application is moved to cloud but it’s developed for traditional data centers.

Slide 8

Slide 8 text

cloud-native applications are dynamically orchestrated Containers are actively scheduled and managed to optimize resource utilization.

Slide 9

Slide 9 text

cloud-enabled applications needs reserved resources You may have much more unused resources and it's not a cost-effective solution.

Slide 10

Slide 10 text

If your application tightly coupled to environment and infrastructure…

Slide 11

Slide 11 text

If your application takes a long time to deploy any stage…

Slide 12

Slide 12 text

If your application has a low reflex to improvements and/or bad situations…

Slide 13

Slide 13 text

If your application needs manual operations to handle much more requests…

Slide 14

Slide 14 text

…and it is live on any cloud platforms; it means cloud- enabled

Slide 15

Slide 15 text

..but…

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

..so…

Slide 18

Slide 18 text

How can be cloud-native?

Slide 19

Slide 19 text

How can be cloud-native? evolve from enabled to native?

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

2 Explicitly declare and isolate dependencies

Slide 25

Slide 25 text

2 Explicitly declare and isolate dependencies

Slide 26

Slide 26 text

2 Use GAC (Global Assembly Cache) Explicitly declare and isolate dependencies

Slide 27

Slide 27 text

3 Configuration management Requires strict separation of config from codebase.

Slide 28

Slide 28 text

3 Configuration management Requires strict separation of config from codebase. Use environment variables or secret products of the container orchestration tool.

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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!

Slide 31

Slide 31 text

3 Configuration management

Slide 32

Slide 32 text

3 Configuration management

Slide 33

Slide 33 text

3 Configuration management

Slide 34

Slide 34 text

3 Configuration management

Slide 35

Slide 35 text

3 Configuration management

Slide 36

Slide 36 text

3 Configuration management (*) https://github.com/selcukusta/dotnetconf-19

Slide 37

Slide 37 text

4 Backing services registry.hub.docker.com/selcukusta/openhack-core:2.0.0 { "AuthService.Url" : "https://auth" } { "ConnectionStringKey" : "VaultKey" }

Slide 38

Slide 38 text

4 Backing services A backing service is any service the app consumes over the network as part of its normal operation.

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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!

Slide 41

Slide 41 text

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!

Slide 42

Slide 42 text

5 Build, Release, Run Strictly separate all stages.

Slide 43

Slide 43 text

5 Build, Release, Run Strictly separate all stages. Create immutable images when you’re in BUILD stage.

Slide 44

Slide 44 text

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.

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

6 Execute the app as one or more stateless processes Use memory cache!

Slide 47

Slide 47 text

6 Execute the app as one or more stateless processes Use memory cache! Save any physical files in the environment!

Slide 48

Slide 48 text

6 Execute the app as one or more stateless processes Use memory cache! Save any physical files in the environment! Use sticky session!

Slide 49

Slide 49 text

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!

Slide 50

Slide 50 text

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.

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

8 Scale out via the process model The application should never daemonize (work as a background process)!

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Scale out via the process model .NET Core 3.0 - Run the application as a worker 8

Slide 57

Slide 57 text

9 Disposability Keep minimum startup and shutdown time.

Slide 58

Slide 58 text

Disposability Keep minimum startup and shutdown time. This facilitates fast elastic scaling, rapid deployment of code or config changes. 9

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Disposability 9 kubernetes-manifest.yaml Program.cs

Slide 61

Slide 61 text

10 Dev/Prod Parity The application should consume the same backing services in all environments.

Slide 62

Slide 62 text

10 Dev/Prod Parity The application should consume the same backing services in all environments. The same topology should be used in all environments.

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

11 Treat logs as event streams

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

12 Admin processes

Slide 68

Slide 68 text

12 Admin processes

Slide 69

Slide 69 text

/in/selcukusta selcukusta.com selcukusta ustasoglu selcukusta (at)gmail.com Thank you…