You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- microservices architecture shifts complexity from the space of code design and implementation into system operations
5
5
- pushing the complexity from one place (software design and development) to another (operations) is just like hiding some tricky parts in somewhere else
6
6
- k8s lets you to automate things and solve the problems easily
7
+
- istio gives the rest of the needed tools
8
+
- use helm to automate things
7
9
8
10

9
11
10
12
# Problems
11
13
14
+
## Communication
15
+
16
+
### Direct communication
17
+
- client never calls the service
18
+
- use API gateway
19
+
- handle auth, etc
20
+
21
+
### Slow communication
22
+
- use cache for GET
23
+
- fail fast when POST, PUT, DEL
24
+
- envoy will be sidecar which can be configured somehow
25
+
26
+
### Security (NEED TO TEST)
27
+
- kubernetes has NetworkPolicy
28
+
- whats does istio give for us?
29
+
- ingress/egress
30
+
31
+
## Improve reliability
32
+
33
+
### Healthz
34
+
- proper timeouts
35
+
36
+
### Graceful start / shutdown
37
+
- tear down connections in the good order (to avoid data loss)
38
+
- idempotency
39
+
- avoid draining connection pool -> graceful stop is important
40
+
41
+
### Circuit breaker & rate limitation (NEED TO TEST)
42
+
- limit the impact of failures, latency spikes, and other undesirable network effects
43
+
12
44
## Change management
13
-
- rapid provisioning of new resources
14
45
- services can come and go
46
+
- rapid provisioning of new resources
15
47
- should be able to deploy a new service quickly
48
+
- automate everything (repo, ci, deployment)
49
+
- use helm to pack/deploy apps
16
50
17
51
### Deployment strategies
18
52
- k8s deployment `.spec.strategy.type==Recreate` will kill all pods before new ones are created
19
53
- 0 downtime deployment - `.spec.strategy.type==RollingUpdate` controls the process with `maxUnavailable` and `maxSurge`
20
54
- blue/green
21
-
- canary
22
-
23
-
### Bootstrapping
24
-
- graceful start / shutdown (app skeleton)
25
-
- automate setup (repo, ci, deployment)
26
-
27
-
## Communication
28
-
29
-
### Slow communication
30
-
- use cache for GET
31
-
- fail fast when POST, PUT, DEL
32
-
33
-
### Direct communication
34
-
- client never calls the service
35
-
- use API gateway
36
-
37
-
### + Scaling
38
-
- persistent problem for MS and monoliths
39
-
- HPA
40
-
- heapster
41
-
- rate limitation
55
+
- canary (monitoring needed, allows to test in production, dark launch -> flippers)
56
+
- use versioned deployments with istio request routing
42
57
43
-
### Monitoring
58
+
### Monitoring (NEED TO TEST)
44
59
- loosely-coupled services collaborating
45
60
- detect serious problems
61
+
- fail and detect problems fast -> write test where it is necessary
0 commit comments