Cloud Knowledge Base

LLM:
- Kernal memory: https://github.com/microsoft/kernel-memory
- Kernal memory: https://github.com/microsoft/kernel-memory
- X-shot prompting

Data Concepts

BI Tools (Tableau):
- Key capabilities: Data visualization, dashboarding, data connections
- Best practices: Proper data modeling, optimization for performance
- Integration with various data sources
NAS (Network Attached Storage):
- Dedicated file storage device accessible over network
- Benefits: Centralized storage, easy backup, file sharing
- Key features: RAID support, file-level access, protocol support (NFS/SMB)
Kubernetes Components:
- Control Plane:
  - API Server: Central management point
  - Scheduler: Pod placement
  - Controller Manager: State management
  - etcd: Configuration store
- Node Components:
  - Kubelet: Node agent
  - Container Runtime
  - Kube-proxy: Network rules
- Namespace
  - Resource isolation and organization
  - Has Service
    - Network abstraction for pod access
    - Load balancing between pods
    - Types: ClusterIP, NodePort, LoadBalancer
    - Has *ReplicaSet/Deployment:
      - Manages multiple pod replicas
      - Ensures desired number of pods are running
      - Handles updates/rollbacks
      - Has Pod:
        Smallest manageable unit in K8s
        Group of one or more containers
        E.g. nginx + web api
        Has container:
        Runs a single application process

Databases (Relational vs NoSQL):

Relational:
- Pros: ACID compliance, structured data, complex queries
- Cons: Scaling complexity, schema rigidity

NoSQL:

Pros: Horizontal scaling, schema flexibility, high performance
Cons: Eventual consistency, complex querying
Partitioning: Logical (Range, Hash, List)
Sharding: Physical (Distributing data across nodes)

E.g.: ```txt Partition by Date → Shard by Customer ID

      Data Organization:
      ├── Partition 2023
      │   ├── Shard 1 (Customer ID 1-1000)
      │   ├── Shard 2 (Customer ID 1001-2000)
      │   └── Shard 3 (Customer ID 2001-3000)
      ├── Partition 2024
      │   ├── Shard 1 (Customer ID 1-1000)
      │   ├── Shard 2 (Customer ID 1001-2000)
      │   └── Shard 3 (Customer ID 2001-3000)
  ```

Database Caching:
- Types: Query cache, buffer cache, result cache
- Strategies: Write-through, write-back, cache-aside

Data processing systems

Database management systems for storing and processing data in large volumes.
Used for business intelligence/analytics
Focused on data processing rather than just storage.
OLTP/OLAP refer to workloads or use cases not to specific technologies
A database could be used for OLTP or OLAP, depending on its design.
OLTP (Online Transaction Processing):
- Goal: Fast, reliable data entry and retrieval.
- Transaction processing, real-time operations
- E.g. Processing a customer order
- Characteristics:
  - Transactions (high volume, often relational sometimes NoSQL such as MongoDB)
  - Rapid
  - Many small updates
  - Current data
  - Row-oriented operations
- E.g. PostgreSQL, Oracle, MariaDB, Azure SQL Server
- Use-cases: ATMs, store purchases, hotel reservations
OLAP (Online Analytical Processing):
- Goal: In-depth analysis and insights over large, historical datasets.
- Analytical processing, historical analysis
- E.g. Sales trends over past 5 years
- Characteristics:
  - Long, complex queries
  - Large data aggregations
  - Historical data
  - Column-oriented operations
- Use-cases:
  - Data mining
  - Business intelligence: Financial analysis, budgeting
  - Complex calculations
- E.g. Databricks, Snowflake, Azure Cosmos DB

Data Normalization vs Denormalization

Relational database design to optimize data structure for different purposes
Normalization
- Dividing large tables into smaller ones and defining relationships between them
- Good when data integrity and efficient updates are critical
- Pros:
  - Reduced Redundancy: Saves storage space.
  - Consistency: Prevents anomalies during insert, update, or delete operations.
  - Data Integrity: Maintains logical relationships between data.
- Cons:
  - Complex Queries: Requires joining multiple tables to retrieve data.
  - Performance Overhead: For read-heavy operations, normalized structures can slow down retrieval times.
Denormalization
- Combining smaller tables into larger ones
- Pros:
  - Improved Performance
  - Simplified Queries
- Cons:
  - Increased Redundancy: Consumes more storage
  - Risk of Inconsistency: Redundant data
  - Complex Updates
- Good when analytical systems or read-heavy applications where fast query performance is a priority

Data Storage Paradigms

Feature	Data Warehouse	Data Lake	Data Lakehouse	Data Mart	ODS	Data Mesh	Data Fabric
Primary Purpose	Business analytics & reporting	Store raw data	Combine lake + warehouse benefits	Specific business unit analytics	Operational reporting	Distributed data ownership	Unified data access
Data Structure	Highly structured	Raw, unstructured/semi-structured	Both structured and unstructured	Highly structured	Structured	Domain-dependent	Any
Schema	Schema-on-write	Schema-on-read	Flexible schema	Fixed schema	Fixed schema	Domain-specific	Dynamic
Processing	Processed, transformed	Raw	Both raw and processed	Highly processed	Minimally processed	Domain-processed	Any
Historical Data	Long-term history	Complete history	Complete history	Limited history	Current/recent only	Domain-dependent	Any
Query Performance	High	Low-Medium	High	Very High	High	Varies	Varies
Cost	Higher	Lower	Medium	Higher	Medium	Varies	Higher
ACID Compliance	Yes	No	Yes	Yes	Yes	Varies	Varies
Primary Users	Analysts, Business Users	Data Scientists	Both	Business Users	Operations Teams	Domain Teams	Enterprise-wide
Examples	Snowflake, Redshift	S3, ADLS	Delta Lake, Iceberg	Department DBs	OLTP Systems	Domain Data Products	Enterprise Data Platforms

Design a data warehouse

Requirements gathering and design
- Identify data sources
- Define schema (star/snowflake)
- Establish SLAs and performance requirements
Implement:
- Set up staging area
- Create ETL/ELT pipelines
- Implement partitioning strategy
- Configure monitoring and optimization

Data Lake vs Data Warehouse

Data Lake: Raw data, multiple formats, schema-on-read
Data Warehouse: Structured data, optimized for analysis, schema-on-write

ELT vs ETL

Extract: Collect any (structured or unstructured) data from any source
Transform: Change data to format you want (e.g. eliminate duplicates)
Load: Load into database, e.g. to data lake or data warehouse
Tools e.g. (can ETL + ELT):
- Azure Data Factory (easily build pipelines)
- Synapse Analytics (ETL, data warehousing, and big data analytics)
- Bigger platforms:
  - Snowflake => cloud data warehouse, but can ETL/ELT
  - (Azure) Databricks => lakehouse, but can ETL/ELT
ETL (Extract, Transform, Load):
- Traditional approach where data is transformed before loading into target
- Best with structured data.
- Better for IoT because it can provide
  - Edge processing for direct action (i.e. stop in red light) instead of waiting for cloud processing
  - Send less data: IoT devices often operate on limited or metered network connections
ELT (Extract, Load, Transform):
- Modern cloud-native approach where raw data is loaded first, then transformed
  - Cloud allows storing raw data at scale and analyze later as required
- You transform it as needed while in the target system
- Can handle structured, unstructured, and semi-structured data.
- ELT advantages: Faster than ETL data, leverages cloud scalability, more flexible for multiple transformations

Object vs block

Object storage/Object store
- Flat structure, each with a unique identifier (URL/key)
- You rewrite entire object
- E.g. AWS S3, Azure Blob storage (Blobs)
- Common use cases:
  - Image & Video Storage
  - Backup Archives
  - User Uploads
  - Static Website Hosting
  - Data Lakes
  - Email Archives
- UNSTRUCTURED at the storage level
  - No internal organization of the data within objects
  - Cannot modify part of an object - must replace the entire object
Block store/block storage
- Stores data in fixed-size blocks, like a traditional hard drive
- Best for: When you need fast, consistent performance and frequent updates to data
- You send changes to change the blob, can update incrementally as data is split into chunks.
- Can be mounted as a drive and used with file systems
- Common use-cases:
  - Operating Systems & Boot Volumes
  - Databases (MySQL, PostgreSQL)
  - Virtual Machine Disks
  - High IOPS Applications
  - Low-latency workloads
- E.g. Azure Blob storage (Blocks), Azure Managed Disks, Amazon EBS
- STRUCTURED at the storage level:
  - Data is split into evenly sized blocks
  - Each block has a specific address
File store/file storage:
- Hierarchical structure with folders/directories
- Built on top of block storage
- Accessed through standard file operations (read, write, delete)
- Supports file-level locking and concurrent access
- Includes file-level metadata (permissions, dates, attributes)
- Best for: Shared access to application data
  - Example: Multiple web servers sharing content files
  - Access: File-level operations through file system
- Use-cases:
  - Shared Team Documents
  - Website Content Files
  - Application Log Files
  - Shared Print Servers
  - Home Directories (mount employee directories on their computers)
- Usually accessed via NFS or SMB protocols
- E.g. Amazon EFS (Elastic File System), Azure Files
- Structure: Hierarchical (folders/files)

Data Catalog

Inventory of all data assets within an organization
Metadata management tool
CEO sales pitch:
- Save hours searching for trusted data
- Protect org. from regulatory fines due to improper data handling
  - GDPR: Not required, but helps with reqs such as tracking access/documenting etc.
  - EU Data Act: requires data processing docs, metadata about data shared
  - NIS2 Directive: requires tracking data flows with vendors, requires doc of all IT assets, requires data backup/incident response
  - DORA: Requires data asset inventory, tracking shared data
- Make data an “asset”
  - No longer liability
  - But competitive advantage
Users/roles:
- Data Engineer wants
  - Easy to add/profile info
  - Any dirty data? Can clean before user display.
- Data Steward wants
  - Librarian for catalog
  - Organizes data, set KPIs (data quality, usage etc.), tags
  - Data lineage: Where data come from (e.g. before data catalog)
  - Governance: Who can get what data
- Data Consumer wants:
  - Like online shopping experience, get data
  - Remove need for IT tickets etc.
Cloud-based Data Catalogs (e.g. Microsoft Purview):
- Integrates with storage offerings
- Automated metadata extraction
Can be automated by using data pipeline:
- Pipelines can update catalog after replicating data etc.

Networking Concepts

DNS

DNS = Domain Name System
Port: 53 over UDP/TCP
Map user-friendly names to their IP addresses.
- E.g. contoso.com might map to IP address of the load balancer at the web tier, 40.65.106.192.

DNS Flow from Browser

Summary:
- Browser Cache → 2. OS Cache → 3. Recursive Resolver → 4. Root DNS Server → 5. TLD DNS Server → 6. Authoritative DNS Server → 7. IP Address Returned → 8. HTTP/HTTPS Request.
Steps:
1. Browser Cache Check
2. Operating System Cache Check
3. (if missing cache) Query the Recursive Resolver (ISP or Custom DNS)
  - Send a request to your configured DNS resolver (usually provided by your ISP).
  - DNS resolver checks its cache
  - (if missing cache) DNS resolver:
    - Contacts a root nameserver (.) to find the nameserver for the top-level domain (.com)
    - Contacts the TLD Nameserver (.com) to find the nameserver for example.com
    - Contacts the Authoritative Nameserver (example.com) nameserver to get the IP address for www.example.com
    - Returns the IP address to your computer
4. Once the browser has the IP address:
  - Opens a TCP connection to the server
  - Performs TLS handshake if using HTTPS
  - Sends an HTTP/HTTPS request for the webpage
  - Downloads HTML, CSS, JavaScript, and other resources
  - Renders the page
Time-To-Live (TTL) value in a DNS record telling caches when to delete it

DNS lookup

DNS query types:
- Recursive Query: Client requires recursive resolved to do all work
- Iterative Query: Client accepts partial responses
- Non-Recursive Query: Client asks for cached result
Tools: nslookup, dig
Flow
- Query Initiation
- Recursive Resolver Contact (ISP or private/public DNS)
  - Resolver:
    - Root DNS Server Query:
      - Queries root DNS server (there are 13, mostly in USA)
      - The root server responds with the IP address of the appropriate TLD nameserver.
    - TLD Nameserver Query:
      - The resolver then queries the TLD nameserver for the domain (e.g., .com for example.com).
      - The TLD nameserver responds with the IP address of the authoritative nameserver for the domain.
    - Authoritative Nameserver Query:
      - The resolver queries the authoritative nameserver, which has the actual DNS records
      - The authoritative server returns the IP address associated with the domain name.
  - Response to Client

Reverse DNS lookup

Use one of IP addresses that’s listed as an A
host 13.33.17.159
- Returns 159.17.33.13.in-addr.arpa domain name pointer server-13-33-17-159.arn53.r.cloudfront.net.
Multiple IP addresses can be tied to same domain
- multiple domain addresses that are tied to the same IP

DNSSec

Provides:
- Chain of trust
- Tampering protection
Chain of trust: txt Root Zone (.) ↓ Signs ICANN TLD (.com) ↓ Signs Domain Zone (example.com) ↓ Signs Subdomain (mail.example.com)
- Data Origin Authentication:
  1. Each record signed by zone’s private key
  2. Signature verified using public key
  3. Chain of trust validates key authenticity
Good to combine with DoT (DNS over TLS) and DoH (DNS over HTTPS) txt └── DNSSec (authentication, DNS level) └── DoT (transport encryption, OS level) └── DoH (application privacy, app/browser level)

IP

Common ports

Port	Protocol	Service
23	TCP	telnet
25	TCP	SMTP (Simple Mail Transfer Protocol)
53	TCP/UDP	DNS (Domain Name System)
80	TCP/UDP	HTTP3 over UDP, rest over TCP
135	TCP/UDP	Microsoft RPC Endpoint Mapper
443	TCP/UDP	HTTPs3 over UDP, rest over TCP
514	UDP	syslog, used for system logging
3268	TCP/UDP	Global Catalog Service

IP Address classes

Class A: 1-126 (Large networks)
Class B: 128-191 (Medium networks)
Class C: 192-223 (Small networks)

IPv4

Version 4 Internet Protocol
used to identify and locate devices on networks
32-bit addressing: 3 billion unique addresses
IPv4 loopback address (localhost of your own machine) is 127.0.0.1

IPv6

IPv6 uses a 128-bit address instead of the 32-bit IPv4 version
Represented as eight groups of four hexadecimal digits separated by colons
- E.g. 2001:0db8:85a3:0000:0000:8a2e:0370:7334
Leading zeros can be removed e.g.
- Original: 2001:0001:0002:0003:0004:0005:0006:0007
- Short: 2001:1:2:3:4:5:6:7
The loopback address is ::1
- Shortened version of 0000:0000:0000:0000:0000:0000:0000:0001

CIDR

Method of the representing IP address (single or ranges)

Exists in both Ipv4 and IPv6

Feature	IPv4 CIDR	IPv6 CIDR
Format	`a.b.c.d/n`	`x:x:x:x:x:x:x:x/n`
Example	`192.168.1.0/24`	`2001:db8::/32`
Prefix Length Range	0 to 32 bits	0 to 128 bits
Notation	Decimal with dots	Hexadecimal with colons
Common Subnet Size	`/24 (256 hosts)`	`/64 (2^64 hosts)`
Typical ISP Assignment	`/24` to `/22`	`/48 to /32`
Address Bits	32 bits total	128 bits total
Address Representation	4 octets	8 groups of 16 bits
Prefix Example Bits	`/24` = 24 network bits	`/64` = 64 network bits
Host Bits Example	`/24` = 8 host bits	`/64` = 64 host bits

Easy way to find out CIDR ranges, remember: /24 255.255.255.0 256
- So /24 gives 256 IP addresses, /25 gives 128, /26 gives 64 and so on.
IPv4 Notation
CIDR Range Total IP Addresses Subnet mask
/32 0 255.255
/30 4 .225.252
/28 16 .255.240
/26 64 .255.192
/24 256 .255.0
/22 1024 .248.0
/20 4096 .240.0

CIDR Range	Total IP Addresses	Subnet mask
`/32`	0	`255.255`
`/30`	4	`.225.252`
`/28`	16	`.255.240`
`/26`	64	`.255.192`
`/24`	256	`.255.0`
`/22`	1024	`.248.0`
`/20`	4096	`.240.0`

TCP

TCP connection

Three-way handshake

Also known as • 3-way handshake • three-way handshake • 3 way handshake • three way handshake
Establishes a TCP connection
Sender: SYN → Receiver: SYN ACK → Sender: ACK
ACK is then set in every packet sent after the handshake

Termination

Sender: FIN → Receiver: ACK FIN → Sender: ACK

TCP flags

Used to indicate a particular connection state or provide additional information
Size of each flag is 1 bit being either 0 or 1
Flag types
- Synchronization (SYN)
  - Also known as synchronization flag.
  - Synchronize sequence numbers
  - First step of connection establishment (3-way handshake)
  - ❗ Only the first packet sent from each end should have this flag set
- Acknowledgement (ACK)
  - Confirms successful packet retrieval
- Push (PSH)
  - Tells receiver to process packets instead of buffering them
- Urgent (URG)
  - Process packets directly before others, even if they’re not complete
- Finish (FIN):
  - 1 indicate connection termination requests
  - Used in the last packet sent from the sender.
- Reset (RST)
  - 1 aborts the connection in response
  - Sent from the receiver to the sender when a packet is sent to a particular host that was not expecting it.
  - Also used as
    - DDoS attack, see RST attack
    - Scanning technique, see RFC 793 scans

Finish (`FIN`) vs Reset (`RST`)

`FIN`	`RST`
Gracefully termination	Sudden termination
Only one side of conversation is stopped	Whole conversation is stopped
No data loss	Data is discarded
Receiver of `FIN` can choose to continue communicating	Receiver has to stop communication

Push (`PSH`) vs Urgent (`URG`)

`PSH`	`URG`
All data in buffer are pushed	Only urgent data is pushed immediately
Data is delivered in sequence	Data is delivered out of sequence

TCP/IP sessions

TCP uses stateful sessions
Connection establishment must be done before data transfer
Session initiation
1. Source sends SYN packet
2. Destination responds with SYN/ACK packet
3. Source sends ACK packet
- Connection stays open until closed with FIN or RST packets.
Session termination

TCP vs UDP

Characteristic	TCP	UDP
Connection Type	Connection-oriented	Connectionless
Reliability	Guaranteed delivery with acknowledgments	No guarantee of delivery
Ordering	Maintains message order	No ordered delivery
Error Checking	Extensive error checking and acknowledgment	Basic error checking only
Speed	Slower due to overhead	Faster due to minimal overhead
Header Size	20 bytes	8 bytes
Usage Examples	Web browsing (HTTP), email (SMTP), file transfer (FTP)	Video streaming, online gaming, DNS lookups
Flow Control	Yes - prevents buffer overflow (prevents sender from sending too quick)	No flow control
Handshake	Three-way handshake required	No handshake required
Data Format	Stream of bytes	Individual datagrams

Transmission Types

Applies to both IPv4 and IPv6 (also Ethernet/MAC, Wi-Fi, Bluetooth, Mobile Networks)
TCP can only do Unicast
UDP can multicast and broadcast
Types:
- Unicast
  - One sender, one receiver (one-to-one)
  - E.g. 192.168.1.5 sending data directly to 192.168.1.10
- Multicast
  - One sender, multiple specific receivers (one-to-many)
  - E.g. 224.0.0.0 to 239.255.255.255 (CIDR: 224.0.0.0/4)
- Broadcast
  - One to all (every on network)
  - Two types:
    - Limited broadcast
      - Delivered to every system inside a domain using:
        IP: 255.255.255.255
        MAC: FF:FF:FF:FF:FF:FF
      - Ignored by routers
    - Directed broadcasts
      - Sent to all devices on subnet
      - Use subnets broadcast address
        E.g. if subnet is 192.168.17.0/24 then it uses 192.168.17.255
      - Routers may take action on the packets.
- Anycast
  - One sender to NEAREST
  - BGP (Border Gateway Protocol) handles route advertisements
  - Based on routing metrics:
    - Lowest latency
    - Hop count
    - Network cost
    - Server load
  - Example uses:
    - DNS root servers
    - CDN edge servers
    - Load balancing
    - DDoS protection

Network Architecture Models

Define how network communication systems should be organized and operated
RFC 3439 considers layering “harmful”

OSI model

Conceptual model that characterizes and standardizes the communication functions
Uses seven abstraction layers:
1. Physical (bits)
  - Media, signal & binary transmission
  - E.g. • Cables (fiber) • Fiber • Wireless • Hubs • Repeaters
2. Data link (frames)
  - Physical addressing: MAC & LLC
  - E.g. • Ethernet • PPP (Point-to-Point) Protocol • Switch • Bridge
3. Network (packets)
  - Path determination & IP
  - E.g. • IP • ICMP (ping) • IPSec • IGMP
4. Transport (segments)
  - End-to-end connections and reliability
  - E.g. • TCP • UDP
5. Session (data)
  - Sync & send to ports, inter-host communication
  - E.g. • API’s • Sockets • WinSock
6. Presentation (data)
  - Syntax layer
  - Encrypts/decrypts if needed
  - E.g. • SSL/TLS (not entirely) • SSH • IMAP • FTP • MPEG • JPEG
7. Application (data)
  - End User Layer: network process to application
  - E.g. • HTTP • FTP • IRC • SSH • DNS • SMTP

TCP/IP model

Also known as TCP/IP Stack
TCP/IP model defines four levels:
1. Link layer: • ARP • PPP • MAC
2. Internet layer: • TCP • UDP • DCCP • SCTP …
3. Transport layer: • IP • ICMP • ECN • IPSec …
4. Application layer: • DNS • HTTP • HTTPS • FTP • SSH) • SMTP …
❗ OSI model does not match well TCP/IP
- RFC 3439 considers layering “harmful”
❗ E.g. SSL/TLS does not fit in any of OSI or TCP/IP layers
- In OSI it’s in layer 6 or 7, and, at the same time, in layer 4 or below.
- In TCP/IP it’s in between the transport and the application layers.

TCP/IP vs OSI model

TCP/IP	Protocols and services	OSI model
Application	• HTTP • FTP • Telnet • NTP • DHCP • PING	• Application • Presentation • Session
Transport	• TCP • UDP	Transport
Network	• IP • ARP • ICMP • IGMP	Network
Network interface	• Ethernet • PPTP	• Data Link • Physical

CDN

Components:
- Origin servers
- Edge locations
- Distribution network
Caching Strategies:
- TTL management
- Cache invalidation
- Dynamic vs static content

Bidirectional communication

WebSockets

Run over TCP/IP
- Over 443 (HTTPs) or 80 (HTTP)
Two-way communication
Better than “Long polling” (i.e. connection on, client waits for server)
- No need for constant polling
Standardized by the IETF in RFC 6455
Reliable but not delivery guaranteed (not confirmation for sent messages)
- Best way to send “I received!” response to the other party
E.g.
- online leaderboard
- chat
- collaborative document editing
Default URI:
- Port 80: ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
- Port 443: wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
Can send text/binary
Masking:
- Protects against caching (respond from cache)
- Frame = Payload + Mask (Payload is masked via Mask using XOR)
- Only from server side
Fragmentation =>
- Can send big payload using parts
Steps:
1. Handshake (relies on HTTP to do handshake):
  1. Client sends Upgrade: websocket HTTP request
    - Security:
      - Sec-WebSocket-Protocol: custom name e.g. chat
      - Sec-WebSocket-Version: protocol supported by client
      - Sec-WebSocket-Key: Used by server to verify handshake
        Prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection
  2. Server responds: 101 Switching Protocol response
  - Sec-WebSocket-Accept:
    - Proves client it confirmed, validates WebSocket client, not malicious actor requesting connection
    - Based on Sec-WebSocket-Key using hash
2. Connection stays open until one drops off
  - Called full-duplex
    - Telecom word where both parties can talk at same time
  - Socket.io library both on back-end and client:
    - Listen: socket.on(message, (message) => ...)
    - Send: socket.send(...)
  - Other libraries: Google Firebase
Has good SDKs to use for GraphQL queries/mutations
- E.g. AWS AppSync
APIs that may replace WebSockets in future:
- WebRTC for better latency for video/audio
- WebTransport
- Server-side Events
  - Still not bidrectional (Client => GET text/event-stream) then server can respond with multiple text/event-stream
- HTTP2 in combination with SSE
  - Does not “obsolete” WebSockets
  - RFC 7540:
    - HTTP/2 push isn’t enforceable and might be ignored by proxies, routers, other intermediaries or even the browser
    - HTTP/2 connections can be terminated by servers when idle
    - No built-in automatic reconnection mechanism, requires app-level handling
    - Tab/window-specific persistent connections missing
      - They share same connection by default
      - But this can be done using different IDs
    - it does not binary data from the server to a JS webclient
  - However it does:
    - HTTP2 provides superior features such as multiplex requests, stream prioritization
      - WebSocket can’t multiplex
    - It’s as fast or faster on other use-cases
- gRPC
  - Adds serialization + RPC routing on top of HTTP/2
  - Has limited browser support; good for service to service communication

Server-Sent Events

Use-cases: Live feed, showing client progress, logging, ChatGPT uses it
Flow:
1. Client sends GET text/event-stream
2. Server can write to stream using text/event-stream header
Pros:
- Lightweight
- HTTP, HTTP2 compatible
Cons:
- Client cannot terminate connection
- Stateful
  - Difficult to horizontally scale
  - L7 L/B challenging

WebTransport

New experimental
Based on HTTP/3
- Uses QUIC protocol (layer 4)
  - QUIC runs over UDP
Secure, multiplexed, realtime transport
Can send data reliably and unreliably
- Reliable
  - Sender is notified of the success or failure of the data transmission
  - Transmissions are usually resent until they succeed before next packet
- Unreliable
  - No confirmation of transmission success
  - Good for streaming videos
Uses QUIC protocol
- Layer 4,
WebSockets vs WebTransport
- WebSockets: single stream per connection
- WebTransport: multiple streams over a single connection
  - Less resource intensive, and delays

HTTP

HTTP/0.9 => GET only
HTTP/1.0 => More methods such as HEAD, POST, each request => new connection
HTTP/1.1 => Keep-Alive header to keep single TCP connection
HTTP/2 =>
- Backwards-compatible
- Allows multiple streams
  - Supports multiplexing => Each frame contains an stream ID
  - Streams can have different priorities
- Header caching via IDs + compression
- Full binary (HTTP/1.1 was text-based)
- 70% of Internet runs it
HTTP/3 =>
- Runs on QUIC that runs over UDP (others run seldom over UDP, often TCP)
- Same request methods, status codes, and message fields
- Encodes them and maintains session state differently
- Has lower latency and loads more quickly in real-world
- Supported by 95% of major web browsers, 31% internet runs it.
- Solves HTTP/2 head of line blocking:
  - Head-of-line:
    - If a single packet is lost, TCP has in-order delivery requirement
    - All subsequent packets must wait until that lost packet is retransmitted and received
      - Even if those later packets contain data for completely different streams.
    - E.g. 3 images must be loaded, image 1 packet gets lost, TCP will not deliver Images 2 and 3
  - Solves by running over QUIC (UDP-based)

gRPC

Binary request/response schema using HTTP
More efficient than REST
Runs over TCP
- API/Protocol on top of HTTP/2
- Experimental support for HTTP/3 (QUIC), not official
Reliable
- Over TCP
- Throws exception if the connection breaks.
grpc+protobuf =>
- The binary is serialized with protobuf schema
- Uses compression
- Has concepts of “contracts”; API is strictly defined with schemas
Can duplex (bidirectional)/mutiplex (multiple connections)
Flow:
- Opening a socket
- Establishing TCP connection
- Negotiating TLS
- Starting HTTP/2 connection
- Making the gRPC call
It requires
- gRPC server
- gRPC stubs (stubs communicate over server)
gRPC vs WebSockets:
- gRPC has limited browser support; good for service to service communication
- gRPC requires more complex set-up
- Use case: microservice intercommunication framework

WebRTC

RTC = Real Time Communication
Over UDP
Focus on “Browser-to-browser”
- E.g., video/voice
Almost always requires a signaling server to setup the connections
Complex and multilayered browser API
P2P
Can support multiplexing, using MediaStream.id
The signalling for WebRTC is not defined: can be SIP, HTTP, JSON or any text / binary message.
Can utilize TURN vs. STUN server:
- Allow different devices to find and communicate with each other using WebRTC
- STUN stands for Session Traversal Utilities for NAT
  - Like a phone operator => IP to IP
  - Allows each device to ask for the other’s identifying information
  - Each device’s router uses its own network address translation (NAT) process to share its IP address
- TURN stands for Traversal Using Relays around NAT:
  - Works with hidden or private IP address
    - Can work around firewalls
    - Works around security measures that hide IP addresses and stop the STUN server from creating a connection
    - Receives packages of data from one device, then re-packages and sends it to another device
  - Alternative when the STUN server can’t initiate the connection
WebRTC vs WebSockets
- Using WebRTC instead of Websocket is better latency
- WebSockets can stream audio and video over WebSocket
  - technology and APIs are not inherently designed for efficient, robust streaming like WebRTC

Media Protocols

Comparison:

Protocol	Browser Support	Latency	Server Complexity	Cost/Bandwidth	CDN Support	Scale	Notable Features
WebRTC	Can broadcast from browser	Very low (sub-second)	High complexity	Expensive	Limited/No	Difficult	Great for interactive applications
RTSP	No browser support	Very low (sub-second)	Medium	Medium	No	Medium	Common in security cameras/IoT
RTMP	No native browser support	Low (2-5s)	Low	Low	Yes	Good	Industry standard for ingestion
HLS	Works everywhere	High (15-30s)	Low	HTTP Server (Low)	Yes	Easy	Industry standard, great device support
DASH	Limited iOS support	High (15-30s)	Low	Low	HTTP Server (Low)	Easy	Similar to HLS, more flexible format options

Youtube/Twitch reference architecture
- A common modern streaming setup may use:
  - RTMP for ingestion (creator → server)
  - HLS/DASH for delivery (server → viewers)
  - This combines the benefits of:
    - RTMP’s good broadcast software support, low latency
    - HLS/DASH’s excellent scalability and device compatibility
- Flow:
  1. Creator sends stream to ingestion server (e.g. Azure Media Services)
    - Uses broadcasting software (like OBS)
    - uses RTMP for ingestion (lower latency)
  2. Platform processes the stream through transcoding servers that:
    - Convert the stream to different quality levels
    - Package it in HLS or DASH format, sends an event (e.g. Azure Event Grid)
  3. Handlers (e.g. Azure functions) save it in storage (e.g. blob storage)
  4. It’s distributed through a CDN (Content Delivery Network)
  5. Viewers on different devices receive the appropriate quality stream via HLS or DASH

RTMP

Purpose: streaming media
Uses TCP
Enables live streaming and video on demand (VOD) services
Persistent connections and allows for low-latency communication
Latency: 2-5 seconds
No CDN support
Newer tech replacing it:
- HLS
- DASH (Dynamic Adaptive Streaming over HTTP)
- WebRTC: However costly to scale for a lot of viewers (requires server)
Common Uses:
- Live streaming to platforms
- Broadcasting live events
- Gaming livestreams

HLS

Works almost everywhere.
Works over HTTP.
Cheeper bandwidth due to CDN
Higher latency than other options.

VoIP

Not a protocol, technology or method relying on SIP/RTP
Real-time, interactive communication (audio/video) or signaling (SIP)
SIP:
- Often used for handling call setup, management, and teardown.
- Allows chatting
RTP:
- Handles the actual transmission of audio or video during the call.
Can run or TCP or UDP
- UDP: Default choice as its low-latency and lightweight nature.
- TCP: For signaling (SIP)
Can support both multiplexing (group chat) and full duplex (both can speak+hear)

High Availability

Disaster Recovery

DR Objectives:
- RTO = Recovery Time Objective (e.g. up after 4 hours)
  - Solutions: SSD, object storage with high-performance tiers
- RPO = Recovery Point Objective (e.g. max data loss up to 1 hour)
  - Solutions: real-time data replication ^{zero RPO} or frequent snapshot schedules.
DR strategies:
Name RPO/RTO Cost
Backup & Restore Hours $
Pilot Light Many Minutes $$
Warm Standby Few Minutes $$$
Multi-Site Real-Time $$$$

Name	RPO/RTO	Cost
Backup & Restore	Hours	$
Pilot Light	Many Minutes	$$
Warm Standby	Few Minutes	$$$
Multi-Site	Real-Time	$$$$

Choosing solutions:

Solution	RTO	RPO
Multi-region and multi-zone deployments	✅
Load balancing	✅
Auto-scaling	✅
Automated backups		✅
Geographically distributed backups		✅
Incremental backups		✅
Disaster Recovery (Pilot Light ^{active-active}, Warm/Hot Standby)	✅	✅
Real-time replication	✅	✅
Stateless applications	✅
Monitoring and alerting	✅
Regular testing and validation	✅	✅
Optimized data storage (e.g., SSDs)	✅
Frequent snapshots		✅
Cloud-native services (e.g., AWS Backup)	✅	✅
Traffic rerouting (Global Accelerator)	✅
Tiered recovery plans	✅

Redundancy

Deploy multiple instances of each component
Use active-passive or active-active configurations
Use load balancers
Maintain database replicas for failover
Use auto-scaling

Geographic Distribution

Deploy across multiple availability zones
Use multiple regions for disaster recovery
Use global load balancing
Create regional data replicas

Load Balancing

Configure automatic failover
Implement health checks

Data Management

Implement database replication
Use read replicas for scaling
Maintain regular backups

Performance

Use CDN for static content
Use caching layers

DR testing

Regular failover testing
Chaos engineering practices
Load testing
Disaster recovery drills

RAID

RAID 0: Striping (performance)
RAID 1: Mirroring (redundancy)
RAID 5: Striping with parity
RAID 10: Combination of 0+1

Security Concepts

Encryption

Encryption types:
- Symmetric: Single key (AES, DES)
- Asymmetric: Public/private keys (RSA)
- PGP (Pretty Good Privacy): Software combining both for security and performance

Architecture Concepts

Three tier

Known as 3-tier or 3 tier
Presentation + Application + Data
Presentation Tier:
- Auto-scaling groups
- Load balancer
- CDN
Application Tier:
- Containerized services
- API Gateway
- Microservices architecture
Data Tier:
- Multi-AZ database
- Read replicas
- Backup strategy
Security: IAM, encryption, network isolation
Reliability: Multi-AZ, auto-scaling
Performance: Caching, optimization
Cost: Right-sizing, reserved instances
Operational Excellence: Monitoring, automation

Well-Architected Framework

Pillars:
- Operational Excellence
  - Think DevOps best practices
  - Examples: Infrastructure as code, automated deployments, observability
  - Business value: Faster, more reliable deployments with fewer errors
- Security
  - Comprehensive security at every layer
  - Examples: Encryption at rest/transit, least privilege access, automated security testing
  - Business value: Protect customer data and company reputation
- Reliability
  - Systems that work consistently and recover gracefully
  - Examples: Auto-scaling, multi-AZ deployments, disaster recovery
  - Business value: Higher uptime, better customer experience
- Performance Efficiency
  - Using resources effectively to meet requirements
  - Examples: Right-sizing instances, caching strategies, serverless where appropriate
  - Business value: Lower costs while maintaining speed
- Cost Optimization
  - Avoiding unnecessary expenses
  - Examples: Reserved instances, auto-scaling down, resource tagging
  - Business value: Better margins without sacrificing quality
- Sustainability
  - Minimizing environmental impact
  - Examples: Right-sizing resources, using newer efficient hardware
  - Business value: Brand reputation, Lower energy costs, better EU Corporate Sustainability Reporting Directive (CSRD) compliance

Cloud architecture models

CSA Enterprise Architecture

Methodology and set of tools
Helps to assess operational status of internal IT security and cloud provider controls
Uses requirements from Cloud Controls Matrix (CCM)
Combines four architecture paradigms into a comprehensive approach to cloud security:
- TOGAF
- ITIL
- SABSA
- Jericho
Cloud Security Alliance (CSA)
- promotes cloud security best practices
- organizes cloud security professionals
👀 Sources: CSA Enterprise Architecture Reference Guide • Enterprise Architecture

Sherwood Applied Business Security Architecture (SABSA)

Methodology for developing business-driven, risk and opportunity focused security architectures
Covers both enterprise and solutions level
Helps to traceably support business objectives
Free use, open source, global standard
Used for
- Information Assurance Architectures
- Risk Management Frameworks
- aligning and seamlessly integrating security and risk management into IT Architecture methods and frameworks
Provides components that can be used independently or as an holistic integrated enterprise solution:
- Business Requirements Engineering Framework (known as Attributes Profiling)
- Risk and Opportunity Management Framework
- Policy Architecture Framework
- Security Services-Oriented Architecture Framework
- Governance Framework
- Security Domain Framework
- Through-life Security Service Management & Performance Management Framework

IT Infrastructure Library (ITIL)

Collection of papers and concepts setting vision for for IT Service Management (ITSM).
Five main publications form the core of ITIL:
- ITIL ServiceStrategy
- ITIL Service Design
- ITIL ServiceTransition
- ITIL Service Operation
- ITIL Continual Service Improvement

The Open Group Architecture Framework (TOGAF)

Offers a high-level design approach
Provide a common framework for architecture design that teams can leverage for a standardized approach.
It helps teams avoid common pitfalls: proprietary lock-in, and communication problems during design and implementation phases as well as throughout the lifecycle of a system.
Provides:
- Common language and communications
- Standardizing on open methods and technologies to avoid proprietary lock-in
- Demonstrating return on investment

7 Rs of Cloud Migration

AWS 57 Rs:

Rehost: lift-and-shift
Refactor/re-architect: E.g. aaS
Replatform: lift and reshape (move then migrate a bit, like SQL to Azure SQL)
Repurchase (drop and shop): Go SaaS
Retain: Do not migrate
Retire: Decomission/remove
Relocate: hypervisor-level lift and shift

DevOps

CI/CD

CI/CD benefits

Improved Development Speed: automated testing and deployment
Enhanced Quality and Reliability: detect failures early
Faster Time-to-Market: rapid innovation
Reduced Risk: smaller changes
Improved Team Collaboration: DevOps (encourages collaboration, breaks down silos)
Scalability: working in parallel on different features
Cost Savings: Automation, early detection
Customer Satisfaction: Frequent updates, showing responsiveness to customer feedback.
Business Continuity: Blue/Green and Canary deployments minimizes downtime
Innovation: Experiment with new features more confidently via tests
Data-Driven Insights: metrics

Continuous Integration

Developers push the code to a code repository often
A testing / build server checks the code as soon as it’s pushed
- The developer gets feedback about the tests and checks that have passed / failed
- Allows detect issues & bugs early on in development lifecycle
Best-practices:
- Run tests as soon as developer makes a commit to repository
- Based on a schedule that runs e.g. every day
Helps
- Find bugs early, fix bugs
- Deliver faster as the code is tested
- Deploy often
- Happier developers, as they’re unblocked
Tools:
- E.g. Jenkins, Atlassian Bamboo, TeamCity, Azure Pipelines

Continuous Delivery

Ensure that the software can be released reliably whenever needed.
Ensures deployments happen often and are quick
Automated deployment -> Shift away from e.g. “one release every 3 months” to 5 releases a day.

CD most commonly refers to Continuous Delivery

However, CD may refer to Continuous Deployment

Aspect	Continuous Delivery	Continuous Deployment
Deployment Trigger	Manual approval for production deployment	Fully automated; no manual approval
Automation Level	Up to staging is automated; production is manual.	Entire process is automated.
Risk Level	Lower (manual before prod)	Higher if automated tests not robust
Speed	Slower (waits for manual approval)	Faster, as changes are deployed immediately.
Control	More control over production releases	Surrenders control for speed and agility

Compliments your continuous integration process.
Automates deployment of your changes after build.
Track of your release process quality
- Visualizations about the quality of all the releases pipeline. e.g. adding a dashboard widget which shows the status of every release.
Release Notes, functional and technical documentation
- Generate Release Notes Build Task (VSTS)
- WIKI Updater Tasks (VSTS)
- 💡 Treat release documentation & manuals as source-code
  - When the product changes, the documentation needs to change as well
Multi-configuration deployments
- e.g. for different geographic regions.

Deployment Patterns

Feature Flags

Or Feature toggles
Booleans in code that activates or deactivates a feature in run-time
Allows you to separate your functional release from your technical release
Decide to have a feature on runtime; enable/disable a feature based on a boolean
💡 Use it a good way to increase your confidence in a new version

Deployment rings

Gradually deploying and validating changes in production
Impact
- Also called blast radius
- evaluated through observation, testing, analysis of telemetry, and user feedback
E.g.:
- Canaries* who voluntarily test bleeding edge features as soon as they are available.
- Early adopter* who voluntarily preview releases, considered more refined than the canary bits.
- Users who consume the products, after passing through canaries and early adopters.

Blue/Green Deployment

Deploying all at once
Two identical production environments:
- reducing downtime and risk during updates (allows testing)
- can wait for green to warm up
- Easy rollbacks in case of failure
Green=new, blue=current environment
Vendor names:
- Azure App Service: Deployment slots
- AWS Elastic Beanstalk: Environment Cloning
Allows you to create a multiple deployments for the web app.
App content and configurations elements can be swapped between deployments
Use-cases:
- Create staging environment easily
  - Validate in staging before swapping to production
- Can have zero downtime deployment with automatic swap

Canary Deployments

Deploying incrementally
Deploys in small, incremental steps, and only to a small group of people
It is about to get an idea of how new version will perform
- E.g. integration with other apps, CPU, memory, disk usage, etc.

Rolling deployment

Slowly replaces currently running instances of the application with newer ones.
Best-practice: The old one is removed only when the new has passed health checks

Success Metrics

Metric	Continuous Integration	Continuous Delivery	Continuous Deployment	Description
Build Time	✓	✓	✓	Time taken to compile and build the code
Build Success Rate	✓	✓	✓	Percentage of successful builds
Test Coverage	✓	✓	✓	Percentage of code covered by automated tests
Unit Test Pass Rate	✓	✓	✓	Percentage of unit tests passing
Integration Test Pass Rate	✓	✓	✓	Percentage of integration tests passing
Code Quality Metrics	✓	✓	✓	Static analysis results, code smells, complexity
Lead Time to Changes		✓	✓	Time from commit to ready for production
Deployment Frequency		✓	✓	How often releases are deployed
Change Failure Rate		✓	✓	Percentage of changes causing failures
Time to Recovery (MTTR)		✓	✓	Time to recover from failures
Release Time		✓		Duration of manual release process
Deployment Success Rate			✓	Percentage of successful automated deployments
Time to Production			✓	Total time from commit to production
Production Incidents			✓	Number of production issues post-deployment
Rollback Rate			✓	Percentage of deployments requiring rollback
Pipeline Duration	✓	✓	✓	Total time through entire pipeline
Environment Stability	✓	✓	✓	Uptime of test/staging environments
Feature Flag Usage		✓	✓	Number and effectiveness of feature flags
Mean Time Between Failures		✓	✓	Average time between production issues
Code Review Time	✓	✓	✓	Time taken for code review completion
Security Scan Results	✓	✓	✓	Number of security vulnerabilities found
Dependencies Health	✓	✓	✓	Status of project dependencies

DORA

Set of key performance indicators (KPIs) used to measure the performance and efficiency of DevOps teams
Developed by the DevOps Research and Assessment (DORA) group
Categorizes performers in: Elite (multiple deployments per day/low failure), High (weekly/daily), Medium (monthly), Low
Why good?
- Benchmarking: Helps teams compare their performance with industry standards.
- Continuous Improvement: Identifies bottlenecks and areas for improvement in the DevOps pipeline.
- Business Value: Demonstrates the impact of DevOps practices on overall business outcomes.
- Reliability: Balances speed with stability, ensuring fast delivery without compromising quality.
Metrics
- Deployment Frequency
  - How often code is deployed to production or released to end-users
- Lead Time for Changes
  - Measures the time it takes from committing code to deploying it in production.
- Change Failure Rate
  - Measures the percentage of deployments that result in a failure in production (e.g., incidents, rollbacks, or hotfixes).
- Time to Restore Service
  - Measures the time it takes to restore service after a production incident or failure.

GenAI (LLM)

Prompt Engineering vs Fine-tune vs RAG

Techniques:

Prompt Engineering
Retrieval-Augmented Generation (RAG)
- Grants generative AI models information retrieval capabilities
Fine Tuning
- Retraining pre-trained models
  - Not training foundation model
- Use cases:
  - First evaluate Prompt Engineering/RAG
    - Choose if it fails.
    - E.g. “Return always SQL” => Returns incorrect syntax. There are benchmarks. Then try to fine-tune and compare performance.
  - Choose if information/prompt needed to steer the model does not fit into the prompt window.
  - Get good at one task: E.g. classification/summarization/same format/tone
  - Can reduce costs:
    - Smaller model can perform as good as big with fine-tuning
- Costs depends on based model:
  - Around $34/hour vs $102/hour
- Azure Open AI Fine-Tuning
  1. Upload training data
    - Format: System prompt/User prompt/Expected output
    - The more training examples you have, the better, hundreds/thousands
    - Have highest quality examples: Or model cna perform worse
  2. (optional) Upload validation data
    - Should be same type of example conversations as you are training on
    - Used for benchmarking/scoring after each batch
    - Good to test that model is not over-trained
  3. Configure parameters:
    - batch-size
      - Larger works better better for larger datasets
      - Number of training examples used to train a single forward and backward pass
      - Larger means = Model params updated less frequently, with lower variance
    - learning_rate_multiplier
      - Larger often perform better with larger batch sizes
      - Smaller = Avoid overfitting
      - Microsoft recommends between 0.02 to 0.2 and test
    - n_epochs: one full cycle through the training dataset
    - seed: Same seed/often same results
  4. Checkpoints:
    - Created when each training epoch completes
    - Good to test against overfitting

Zero-Shot, One-Shot, and Few-Shot Prompting

Zero-shot prompting
- Only task
- Example: Classify this review as positive or negative: This movie was a complete waste of time
- Pros:
  - Less tokens = cheaper
  - Tests model’s true understanding of instructions
  - Can be more creative/less constrained by examples
- Cons:
  - Higher chance of misunderstanding the task
  - Could require more back-and-forth corrections
  - Struggles with complex or ambiguous tasks
  - Less control over output format/style

One-shot prompting

Single example + task

Example:

  Example: 
  Review: "The food was amazing!" 
  Classification: Positive

  Now classify this: "This movie was a complete waste of time"

Multi-shot prompting

Multiple examples +task