vault backup: 2023-09-25 23:59:20
This commit is contained in:
parent
c8551e05ff
commit
a5cba9b794
7 changed files with 6904 additions and 122 deletions
|
|
@ -1,29 +1,24 @@
|
|||
🌫 11 Setembro 2023 - #ASCN
|
||||
|
||||
## Complex Structures: Challenges
|
||||
### 1. Deployment
|
||||
- ## Complex Structures: Challenges
|
||||
- ### 1. Deployment
|
||||
- Multiple components with specific requirements
|
||||
- Heterogeneous hardware, software and services (e.g., cloud computing services
|
||||
|
||||
### 2. Management + Configuration
|
||||
- ### 2. Management + Configuration
|
||||
- Specific to each software/hardware component
|
||||
- Optimal configurations will change over time...
|
||||
|
||||
### 3. Monitoring + Benchmarking
|
||||
- Finding anomalies (performance, failures, ...) in complex applications and infrastructures
|
||||
|
||||
|
||||
## Agile Development
|
||||
**Quick reaction to frequent small changes!**
|
||||
|
||||
- ### 3. Monitoring + Benchmarking
|
||||
id:: 65120d55-d904-4ef5-bbbb-647bf02e05c9
|
||||
- Finding anomalies (performance, failures, ...) in complex applications and infrastructures
|
||||
- ## Agile Development
|
||||
**Quick reaction to frequent small changes!**
|
||||
- Rests on formal (versioned) source, binary and documentation repositories
|
||||
- Unambiguous current state
|
||||
- Ability to back track
|
||||
- Automated build and test
|
||||
- Fast feedback
|
||||
- Fast iterations
|
||||
|
||||
## Operations
|
||||
- ## Operations
|
||||
- Manual provisioning and configuration
|
||||
- Informal communication between qualification and production stages
|
||||
- Consequences:
|
||||
|
|
@ -31,26 +26,20 @@
|
|||
- Configuration drift
|
||||
- “Snowflake” servers (don't even look at it…)
|
||||
- Subjective monitoring
|
||||
|
||||
## Infrastructure as Code
|
||||
**Include infrastructure scripts in agile process!**
|
||||
|
||||
- ## Infrastructure as Code
|
||||
**Include infrastructure scripts in agile process!**
|
||||
- Hardware provisioning with scripts
|
||||
- In contrast to: physically unboxing and plugging
|
||||
- Software provisioning with scripts
|
||||
- In contrast to: clicking through setup wizards
|
||||
- Configuration with scripts
|
||||
- In contrast to: clicking through control panels
|
||||
|
||||
|
||||
## DevOps
|
||||
**Supports fast, frequent, small changes!**
|
||||
|
||||
- ## DevOps
|
||||
**Supports fast, frequent, small changes!**
|
||||
- Development and deployment are self-documenting and versioned
|
||||
- Deployment is reproducible and repeatable
|
||||
- Servers are disposable and consistent
|
||||
|
||||
## Roadmap
|
||||
- ## Roadmap
|
||||
- Distributed systems architectures & deployment
|
||||
- Common distribution patterns
|
||||
- Reliability and scalability
|
||||
|
|
@ -61,11 +50,7 @@
|
|||
- Monitoring and evaluation
|
||||
- Monitoring frameworks and metrics
|
||||
- Benchmarking
|
||||
|
||||
|
||||
|
||||
|
||||
## Evaluation
|
||||
- ## Evaluation
|
||||
- **50%** - project
|
||||
- min: 10 values
|
||||
- checkpoint 1: 17/11/2023
|
||||
|
|
@ -75,13 +60,11 @@
|
|||
- **50%** - written exam
|
||||
- min: 8 values
|
||||
- 12/12/2023
|
||||
|
||||
|
||||
## Team
|
||||
- ## Team
|
||||
- João Paulo - jtpaulo@di.uminho.pt
|
||||
- Francisco Maia - fmaia@di.uminho.pt
|
||||
- Tânia Esteves - d12729@di.uminho.pt
|
||||
- Cláudia Brito – d13235@di.uminho.pt
|
||||
|
||||
|
||||
[[ASCN/T - Aula 2|Next class: T - Aula 2]]
|
||||
|
||||
|
||||
[[ASCN/T - Aula 2|Next class: T - Aula 2]]
|
||||
|
|
@ -1,80 +1,70 @@
|
|||
🌫 18 Setembro 2023 - #ASCN
|
||||
|
||||
## Why distributed systems?
|
||||
- ## Why distributed systems?
|
||||
- Modularity, decoupling different concerns.
|
||||
- Performance.
|
||||
- Dependability
|
||||
|
||||
|
||||
## How to distribute?
|
||||
### 1. Monolythic system
|
||||
- ## How to distribute?
|
||||
- ### 1. Monolythic system
|
||||
- Architecture: [[Monolithic system.excalidraw]]
|
||||
- Multiple services for multiple targets in the same server
|
||||
## 2. Distributed systems
|
||||
- ## 2. Distributed systems
|
||||
id:: 65120d55-6bed-47db-bd53-cc4f627c33dc
|
||||
- Main distribution concerns:
|
||||
1. Replication
|
||||
2. Partitioning
|
||||
3. Service-orientation
|
||||
1. Replication
|
||||
2. Partitioning
|
||||
3. Service-orientation
|
||||
- All of these address scaling out a service/application.
|
||||
- Not mutually exclusive, can be combined.
|
||||
|
||||
### 2.1 Replication
|
||||
- ### 2.1 Replication
|
||||
- Architecture: [[Replication.excalidraw]]
|
||||
- Multiple copies of the same data and functionality
|
||||
- Addresses resilience and scale-out
|
||||
### 2.2 Partitioning
|
||||
- ### 2.2 Partitioning
|
||||
- Architecture: [[Partitioning.excalidraw]]
|
||||
- A server is split horizontally (Sharding).
|
||||
- Addresses scale-out.
|
||||
- Can be applied to computation, data, ...
|
||||
### 2.3 SOA - Service-Oriented Architecture
|
||||
- ### 2.3 SOA - Service-Oriented Architecture
|
||||
- Architecture: [[SOA.excalidraw]]
|
||||
- Addresses scale-out and modularity.
|
||||
- Example: micro-services.
|
||||
#### 2.3.1 Microservices
|
||||
- #### 2.3.1 Microservices
|
||||
- Each service implements specific functionality.
|
||||
- Services can scale independently.
|
||||
- Decomposition may be troublesome: how micro is micro?
|
||||
- Consistency.
|
||||
- Complex deployment and testing
|
||||
|
||||
|
||||
|
||||
## Distributed architectures
|
||||
### 1. Client-server
|
||||
- Complex deployment and testing
|
||||
- ## Distributed architectures
|
||||
- ### 1. Client-server
|
||||
- Architecture: [[client-server.excalidraw]]
|
||||
- Functionality and data are in the server.
|
||||
- A stub runs embedded in the client.
|
||||
- The stub is part of the server software package
|
||||
- E.g., the Web (“protocol” is HTTP)
|
||||
|
||||
### 2. Proxy Server
|
||||
- ### 2. Proxy Server
|
||||
- Architecture: [[proxy.excalidraw]]
|
||||
- Multiple servers can be used transparently.
|
||||
- The proxy is a performance and availability bottleneck.
|
||||
- E.g. MongoDB
|
||||
|
||||
### 3. Master Server
|
||||
- ### 3. Master Server
|
||||
- Architecture: [[master.excalidraw]]
|
||||
- Scale out!
|
||||
- E.g. HDFS
|
||||
|
||||
### 4. Server Group
|
||||
- ### 4. Server Group
|
||||
- Architecture: [[server-group.excalidraw]]
|
||||
- All servers can process requests.
|
||||
- Coordination may be necessary.
|
||||
- Resiliency!
|
||||
- E.g. ZooKeeper
|
||||
|
||||
### 5. Bus
|
||||
- ### 5. Bus
|
||||
- Architecture: [[bus.excalidraw]]
|
||||
- The bus routes messages.
|
||||
- Participants publish and consume messages to/from the bus.
|
||||
- Decouples producers from consumers.
|
||||
- **Flexibility!**
|
||||
- E.g. Kafka
|
||||
|
||||
### 6. Multi-tier
|
||||
- ### 6. Multi-tier
|
||||
- Architecture: [[multi-tier.excalidraw]]
|
||||
- Each server acts as a client of the next tier.
|
||||
- Allows independent deployment and scaling of different functionality.
|
||||
|
|
@ -82,7 +72,7 @@
|
|||
- “protocol A” == Web (e.g.)
|
||||
- “Stub B” == Database Driver!
|
||||
- “protocol B” uses SQL
|
||||
#### 6.1 State in multi-tier
|
||||
- #### 6.1 State in multi-tier
|
||||
- Persistent state is harder to replicate and shard.
|
||||
- Computation is easier to replicate and shard.
|
||||
- No state in upper tiers:
|
||||
|
|
@ -90,4 +80,4 @@
|
|||
- Transient / cached state in middle tiers:
|
||||
- Application server
|
||||
- Persistent state at lower tiers:
|
||||
- Database
|
||||
- Database
|
||||
Loading…
Add table
Add a link
Reference in a new issue