EZF-004. Networking & Content Delivery services in AWS, Azure, GCP, and OCI; Multi-Master Replication; SOAP API Architecture style; Linux File System structure; OAuth 2.0 and OpenID Connect (OIDC)

Recap on system design for this week:

• Networking & Content Delivery services in AWS, Azure, GCP, and OCI

• Multi-Master Replication

• SOAP API Architecture style

• Linux File System Structure

• OAuth 2.0 and OpenID Connect (OIDC)

1. Networking & Content Delivery services in AWS, Azure, GCP, and OCI

Networking & Content Delivery services in AWS: Approximate match rating with corresponding services in Azure, GCP, and OCI.

Networking & Content Delivery services play pivotal roles in ensuring seamless, secure, and efficient operations.

❓ How do these services align with corresponding services in Azure, Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI), and to what extent?

Some services have a direct equivalent, others might not have a one-to-one match, and the degree of match is based on the closest functionality.

🔘 Amazon API Gateway:
A service for developers to create, secure, and manage APIs, facilitating access to back-end services.

🔘 Amazon #CloudFront:
A global CDN delivering data and apps with low latency. Seamlessly integrated with AWS and offers flexible pricing.

🔘 Amazon Route 53:
A cloud DNS service translating domain names to IP addresses, enhancing connectivity to AWS resources.

🔘 AWS Verified Access:
Provides secure application access for corporate users without a VPN, based on user and device data.

🔘 Amazon #VPC:
Enables creation of a private AWS Cloud segment with a customizable virtual network.

🔘 Amazon VPC Lattice:
Manages service-to-service connectivity with defined policies for traffic and access.

🔘 AWS App Mesh:
Standardizes and controls AWS microservices communication, ensuring application reliability.

🔘 AWS Cloud Map:
Tracks and updates the location of dynamic resources, bolstering application uptime.

🔘 AWS Direct Connect:
Forms a dedicated connection between user premises and AWS, optimizing costs and bandwidth.

🔘 AWS Global Accelerator:
Boosts global application performance by routing traffic via the AWS network.

🔘 AWS PrivateLink:
Secures data by preventing public internet exposure and offers private AWS connectivity.

🔘 AWS Private 5G:
Integrates cellular technology into networks, with AWS supplying essential components.

🔘 AWS Transit Gateway:
Links Amazon VPCs and on-site networks via a central gateway, streamlining operations.

🔘 #AWS #VPN:
Combines AWS Site-to-Site and Client VPN, ensuring secure connections across the AWS ecosystem.

Approximate Match Rating (1-5) with equivalent services in #Azure, #GCP, #OCI.
1 = "Not a Direct Match, but Closest Available"
2 = "Somewhat Similar"
3 = "Moderately Similar"
4 = "Very Similar"
5 = "Almost Identical"

2. Multi-Master Replication

Multi-master replication is a database replication method where multiple nodes or computers store data and can update it. All nodes can respond to data queries. The system ensures data modifications made by one node are propagated to others, maintaining data consistency. It contrasts with primary-replica replication, where only one "master" node can modify data, and failover clustering, where only one server actively interacts with clients.

🌟 2.1. Advantages:

1. 🔄 Availability: Continuous operation even if one master fails.

2. 🌍 Distributed Access: Nodes can be geographically distributed, reducing latency.

3. ⚖️ Load Sharing: Handles more write traffic than a single node.

4. 🛡️ No Single Point of Failure: Multiple masters ensure continuous operation.

5. ⚡ Low Latencies: By placing nodes closer to users, write latencies are minimized.

6. 🔧 Database Upgrades: Facilitates upgrades without significant downtime.

😕 2.2. Disadvantages and Concerns:

1. 📉 Consistency Issues: Asynchronous replication can lead to eventual consistency, compromising ACID guarantees.

2. 🐢 Performance Concerns: Data synchronization can strain network bandwidth, leading to sluggish performance.

3. ⚠️ Conflict Resolution: Simultaneous updates can lead to data conflicts. Handling these conflicts becomes crucial in a multi-master setup.

4. 🧩 Complexity: Setting up and managing multi-master replication can be more complex than other replication methods.

🛠️ 2.3. Implementations:

1. 📂 Directory Services: Many use #LDAP and implement multi-master replication, such as Active Directory, #OpenDS/#OpenDJ, #OpenLDAP.

2. 🗃️ Database Management Systems: #Amazon #Aurora, #Apache #CouchDB, #ArangoDB, #Cloudant, #eXtremeDB Cluster, #Oracle, #Microsoft #SQL, #MySQL, #MariaDB, #PostgreSQL, #Ingres.

📌 2.4. Use Cases Examples:

1. 🤝 Collaborative Tools: Google Docs, where multiple users edit simultaneously.

2. 📴 Offline Databases: Clients work offline and sync when online.

Multi-master replication offers scalability, availability, and geographical distribution advantages. However, it also presents challenges like conflict resolution, consistency issues, and potential performance degradation. It's crucial to consider these factors based on specific needs and use cases.

❓ What challenges are you encountering with multi-master replication?

3. SOAP API Architecture style

SOAP, a protocol from the early days of web services, remains relevant in specific scenarios. Remember when banking systems relied heavily on SOAP for secure, reliable communication? 🏦 Financial institutions are using SOAP for transactions due to its robust security features.

3.1. Message formats:

• XML

3.2. ✅ Advantages:

1. 🔗 Standardized Protocol: Protocol-agnostic

2. 🚫 Error Handling: Integrated mechanisms

3. 🔒 Security: Adheres to WS-Security standards

4. 💾 ACID Transactions: Guarantees data integrity

5. 💡 Stateful Operations: Retains state

6. 🔍 Extensibility: Compatible with WS-* standards

7. 🌍 Language Neutral: Compatible across all languages.

3.3. ❌ Disadvantages

1. 📜 Verbosity: Large XML payloads

2. ❌ Complexity: More challenging to implement than REST

3. 🔗 Tight Coupling: Modifications can disrupt integrations

4. 🐢 Performance: Reduced speed because of XML parsing

5. 🔒 Less Flexibility: Rigid standards

6. 🎓 Learning Curve: Not the same as REST

7. 📉 Declining Popularity: Limited contemporary tools/resources.

3.4. 📋 Use cases

1. 🏢 Enterprise Solutions: Integration for expansive enterprise systems.

2. 💰 Financial Sector: Safe and ACID-adherent banking transactions. 📡 Telecommunications: Management of network devices.

3. 🩺 Healthcare: Exchange of medical records.

4. ✈️ Airline Services: Flight reservations and information systems.

5. 🌐 Web Solutions: Uniform public APIs.

6. 👥 CRM Platforms: Integration of customer management tools.

7. 💳 Payment Channels: Protected payment transactions.

8. 📦 Delivery Services: Shipment tracking and details.

9. 💾 Legacy System Adaptation: Contemporary interface for dated, intricate systems.

❓ What API architecture style are you guys currently utilizing in your system?

4. Linux File System structure

The Filesystem Hierarchy Standard (FHS) outlines the structure for Unix-like systems. Popularized by Linux distributions, it's also adopted by other Unix-like systems and maintained by the Linux Foundation. The latest version, 3.0, was released on 3 June 2015.

• 🌳 Rooted at /, the FHS organizes files and directories, even if they reside on different devices.

• 📁 Presence of certain directories depends on specific subsystems.

• 🐧 While many directories are common across Unix-like systems, the FHS descriptions are specific to Linux.

❓ Following the FHS, where should Linux app binaries and user-specific config files reside?

5. OAuth 2.0 and OpenID Connect (OIDC)

5.1. OAuth 2.0:

• 🎯 Purpose: OAuth 2.0 is primarily an authorization framework that allows third-party applications to obtain limited access to a user's resources without exposing their credentials. It's designed for token-based authorization.

• 🔑 Tokens: Uses access and refresh tokens.

• 🔄 Flows: Authorization Code Flow, Implicit Flow, Client Credentials Flow, Resource Owner Password Credentials Flow.

5.2. OAuth 2.0 Authorization Code Flow (on the image):

1️⃣ User Resource Request
2️⃣ Client Redirect
3️⃣ User Login & Permission Grant
4️⃣ Authorization Code Issuance
5️⃣ User Provides Authorization Code
6️⃣ Access Token Request
7️⃣ Access Token Response
8️⃣ Resource Request with Access Token
9️⃣ Resource Response

5.3. OpenID Connect (OIDC):

• 🎯 Purpose: OIDC is a simple identity layer built on top of the OAuth 2.0 protocol. While OAuth 2.0 is about resource access and sharing, OIDC is about user authentication. It provides apps with a way to get basic profile information about the authenticated user.

• 🆔 ID Token: OIDC introduces a new type of token - the ID Token. This token is a JWT (JSON Web Token) and contains information about the authenticated user.

• 📋 UserInfo Endpoint: OIDC provides a standard endpoint where apps can retrieve claims (user attributes) about the authenticated user.

• 🔄 Flows: OIDC supports the same flows as OAuth 2.0 but adds authentication steps to them. The most commonly used flow in OIDC is the Authorization Code Flow with the addition of the ID Token.

• 📜 Standard Claims: OIDC defines a standard set of claims (user attributes). Examples include sub (subject identifier), name, email, and more.

5.4. OAuth 2.0 + OIDC:

• 🛠️ OIDC is built on top of OAuth 2.0. In essence, while OAuth 2.0 provides the framework for access delegation, OIDC adds an identity layer on top, allowing for user authentication in addition to the OAuth 2.0 authorization functionalities.

• 🌐 It's common for modern applications to use both OAuth 2.0 for authorization and OIDC for authentication. This combination allows apps to both authenticate users and request permissions to access resources on their behalf.

❓ How are you implementing and utilizing OAuth 2.0 and OIDC in your applications?