Dev/Architecture

Global server load balancing (GSLB) with DNS regional Load Balancers (src: Book_ release it! - Michael Nygard)

Pattern: split deployment view and runtime view Deployment view Transform sources into binaries Transform binaries into deplotments Runtime view Processes running on machines (src: Book_ release it! - Michael Nygard)

x-axis: horizontal duplication scale by cloning eg. load-balander + auto-scaling y-axis: functional decomposition scale by splitting different things eg. monolith -> microservices (compare with Model_ 5 service disintegrators #3 scalability and throughput) z-axis: data partitioning scale by splitting similar things “sharding” eg. split data per product-id (shard 1 = product-id 0 - 99, shard 2 = product-id 100 - 199, …) eg. split data per time (aka “archiving older data”)...

Distinction: events vs messages

Responsiveness time the user is waiting / blocked included: time for the response to return excluded: time continued in the background Performance time for all the work to be done included: time for the response to return time continued in the background excluded: /

Model: Data ownership (in microservice architecture) the owner is the one who writes to the table (1) Pattern: Single Ownership (2) Pattern: Common Ownership solution: create a service around the shared table (3) Pattern: Joint Ownership solution 1: table split pattern solution 2: data domain solution 3: delegation (1) Pattern: Single ownership (data ownership in microservices) (2) Pattern: Common Ownership (data ownership in microservices) solution: create a service around the shared table eg....

Granularity integrators (1) database transactions (2) data dependencies (3) workflow and choreography fault tolerance responsiveness and performance (Model_ 3 types of latency) reliability & data consistency (2) data dependencies axiom: service that writes data, owns it big ball of distributed mud (3) workflow and choreography a) fault tolerance dependency on other service over the network? network problems breaks your service (monolith did not have this problem) b) responsiveness and performance !...

Model: Data access patterns (in microservice architecture) (1) Pattern: interservice communication (2) Pattern: data schema replication (3) Pattern: in-memory replicated cache (4) Pattern: data domain (1) Pattern: interservice communication (data access in microservices) latency network 60-300 ms security secure endpoint re-authorize if expired data query own db query other db (2) Pattern: data schema replication (data access in microservices) keep them in sync: synchronous / asyncronous transaction?...

subjective: (1) service functionality: single responsibility measurable: (2) code volatility: how often does code change (3) scalability and throughput: scale/throughput, startup delay (4) fault tolerance: continue working if one part crashes (5) access control: separate sensitive data to a separate service (1) service functionality what is “single responsibility” is subjective… (2) code volatility (3) scalability and throughput scalability (requests / minute) startup time “mean time to startup (service)” !...

(1) network latency the time to make a call over the network eg. it takes 200ms to call that service (2) security latency eg. your token expired and you need to re-authenticate (3) data latency eg. you need to query a database Total latency Total latency is the sum of these parts. eg. I need to call another microservice to get it’s data network latency - my microservice get’s a call security latency - my microservice authenticates the call data latency - my own database query network latency - call another service security latency - the other service verifies my token data latency - the other microservice queries it’s database