vault backup: 2023-09-26 15:32:01

4a1s/ASCN/T - Aula 1.md

@@ -1,27 +1,32 @@
 ---
 dg-publish: true
 ---
-🌫11 Setembro 2023 - #ASCN
+🌫 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
-  id:: 65120d55-d904-4ef5-bbbb-647bf02e05c9
-- Finding anomalies (performance, failures, ...) in complex applications and infrastructures
-- ## Agile Development
-  **Quick reaction to frequent small changes!**
+
+### 3. Monitoring + Benchmarking
+- 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:
@@ -29,20 +34,26 @@ dg-publish: true
 	- 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
@@ -53,7 +64,11 @@ dg-publish: true
 - Monitoring and evaluation
 	- Monitoring frameworks and metrics
 	- Benchmarking
-- ## Evaluation
+
+
+
+
+## Evaluation
 - **50%** - project
 	- min: 10 values
 	- checkpoint 1: 17/11/2023
@@ -63,11 +78,13 @@ dg-publish: true
 - **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]]

4a1s/ASCN/T - Aula 2.md

@@ -3,71 +3,81 @@ dg-publish: true
 ---
 🌫 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
-  id:: 65120d55-6bed-47db-bd53-cc4f627c33dc
+## 2. Distributed systems
 - 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.
@@ -75,7 +85,7 @@ dg-publish: true
 	- “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: