revert

ASCN/ASCN - T - Aula 1.md

@@ -0,0 +1,70 @@
+🌫 11 Setembro 2023 - #ASCN
+
+- ## Complex Structures: Challenges
+- ### 1. Deployment
+- Multiple components with specific requirements
+- Heterogeneous hardware, software and services (e.g., cloud computing services
+- ### 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!**
+- 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
+- Manual provisioning and configuration
+- Informal communication between qualification and production stages
+- Consequences:
+	- Not repeatable or reproducible
+	- Configuration drift
+	- “Snowflake” servers (don't even look at it…)
+	- Subjective monitoring
+- ## 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!**
+- Development and deployment are self-documenting and versioned
+- Deployment is reproducible and repeatable
+- Servers are disposable and consistent
+- ## Roadmap
+- Distributed systems architectures & deployment
+	- Common distribution patterns
+	- Reliability and scalability
+	- Automatic provision and configuration
+- Cloud computing
+	- Services and abstractions
+	- Infrastructure management (virtualization, storage, ...)
+- Monitoring and evaluation
+	- Monitoring frameworks and metrics
+	- Benchmarking
+- ## Evaluation
+- **50%** - project
+	- min: 10 values
+	- checkpoint 1: 17/11/2023
+	- checkpoint 2: 07/12/2023
+	- final report: 19/12/2023
+	- presentation: 08-12/01/2024 (week)
+- **50%** - written exam
+	- min: 8 values
+	- 12/12/2023
+- ## 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/ASCN - T - Aula 2.md

@@ -0,0 +1,83 @@
+🌫 18 Setembro 2023 - #ASCN
+
+- ## Why distributed systems?
+- Modularity, decoupling different concerns.
+- Performance.
+- Dependability
+- ## 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
+- Main distribution concerns:
+  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
+- Architecture: [[Replication.excalidraw]]
+- Multiple copies  of the same data and functionality
+- Addresses resilience and scale-out
+- ### 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
+- Architecture: [[SOA.excalidraw]]
+- Addresses scale-out and modularity.
+- Example: micro-services.
+- #### 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
+- 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
+- Architecture: [[proxy.excalidraw]]
+- Multiple servers can be used transparently.
+- The proxy is a performance and availability bottleneck.
+	- E.g. MongoDB
+- ### 3. Master Server
+- Architecture: [[master.excalidraw]]
+- Scale out!
+	- E.g. HDFS
+- ### 4. Server Group
+- Architecture: [[server-group.excalidraw]]
+- All servers can process requests.
+- Coordination may be necessary.
+- Resiliency!
+	- E.g. ZooKeeper
+- ### 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
+- Architecture: [[multi-tier.excalidraw]]
+- Each server acts as a client of the next tier.
+- Allows independent deployment and scaling of different functionality.
+- E.g. AS + DBMS:
+	- “protocol A” == Web (e.g.)
+	- “Stub B” == Database Driver!
+	- “protocol B” uses SQL
+- #### 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:
+	- Web browser
+- Transient / cached state in middle tiers:
+	- Application server
+- Persistent state at lower tiers:
+	- Database