chmod (change mode) is a command in Linux and other Unix-like operating systems that allows you to change the permissions (read, write, execute) of files and directories.

In Linux, permissions are represented by three sets of characters: user (owner), group, and others. Each set consists of three characters representing the read (r), write (w), and execute (x) permissions. These permissions can be represented numerically as well, where read=4, write=2, and execute=1.

Let’s break down chmod 777 and chmod 421:

1. chmod 777: This command sets the file permissions to allow read, write, and execute for the user, group, and others.

   • The first digit (7) refers to the permissions for the user/owner.
   • The second digit (7) refers to the permissions for the group.
   • The third digit (7) refers to the permissions for others.

   Each digit is a sum of the permission values:

   • 4 for read
   • 2 for write
   • 1 for execute

   So, 7 represents read (4) + write (2) + execute (1), meaning all permissions are granted.

2. chmod 421: This command sets the file permissions differently.

   • The first digit (4) refers to the permissions for the user/owner.
   • The second digit (2) refers to the permissions for the group.
   • The third digit (1) refers to the permissions for others.

   These values mean:

   • For the user/owner: read (4)
   • For the group: write (2)
   • For others: execute (1)

So, chmod 421 grants read permission to the owner, write permission to the group, and execute permission to others.

Common numeric representations in chmod are used to set permissions on files and directories in Linux and other Unix-like operating systems. Here are some common ones:

1. chmod 777: This gives full permissions to the owner, group, and others.

   • The first digit (7) represents permissions for the owner (user).
   • The second digit (7) represents permissions for the group.
   • The third digit (7) represents permissions for others.
   • In binary, 7 translates to 111, indicating read (4) + write (2) + execute (1) permissions for each category.

2. chmod 755: This gives the owner full permissions and read/execute permissions to the group and others.

   • The first digit (7) represents permissions for the owner (user).
   • The second digit (5) represents permissions for the group.
   • The third digit (5) represents permissions for others.
   • In binary, 7 translates to 111 (read + write + execute), and 5 translates to 101 (read + execute).

3. chmod 644: This gives the owner full permissions and read-only permissions to the group and others.

   • The first digit (6) represents permissions for the owner (user).
   • The second digit (4) represents permissions for the group.
   • The third digit (4) represents permissions for others.
   • In binary, 6 translates to 110 (read + write), and 4 translates to 100 (read).

4. chmod 600: This gives the owner full permissions and no permissions to the group and others.

   • The first digit (6) represents permissions for the owner (user).
   • The second and third digits (0) represent no permissions for the group and others.
   • In binary, 6 translates to 110 (read + write), and 0 means no permissions.

5. chmod 755: This gives the owner full permissions and read/execute permissions to the group and others.

   • The first digit (7) represents permissions for the owner (user).
   • The second digit (5) represents permissions for the group.
   • The third digit (5) represents permissions for others.
   • In binary, 7 translates to 111 (read + write + execute), and 5 translates to 101 (read + execute).

chmod symbolic links

In addition to numeric representations, chmod in Linux also supports symbolic representations. These representations are more intuitive and easier to understand for some users, especially when making specific changes to permissions.

Here’s how symbolic representations work:

• u stands for user/owner.
• g stands for group.
• o stands for others.
• a stands for all (equivalent to ugo).

And the symbols for permissions are:

• r stands for read.
• w stands for write.
• x stands for execute.

Here are a few examples:

1. To give the owner read and write permissions:

   chmod u+rw filename
   

2. To remove execute permission from the group:

   chmod g-x filename
   

3. To give everyone execute permission:

   chmod a+x filename
   

4. To give the owner read and execute permissions, and the group write permission:

   chmod u+rx,g+w filename
   

5. To set all permissions to just read and write:

   chmod a=rw filename
   

So, instead of using numeric values like chmod 777 or chmod 421, symbolic representations allow you to specify the changes you want to make directly.

chmod exercise

Commands:

clear

ls -l

# Readable by all

chmod 444 class_notes.txt

ls -l

# Allow Owner to Write, readable by all

chmod 644 class_notes.txt

ls -l

# Allow owner to Execute, readable by all

chmod 744 class_notes.txt

ls -l

# Adding Execute Permissions for the Group

chmod 774 class_notes.txt

ls -l

# Revoking Write Access from the Group

chmod 754 class_notes.txt

ls -l

Results:

Module 3 - System Design and Architecture This module covered common architecture types (monolithic, microservices and serverless), Application Programmable Interfaces (APIs), Load Balancers and cloud storage options (object, block and file).

I’m only doing a short summary for the blog as I’m posting the architecture project below and it covers in detail all three architecture types, explains use cases and advantages and disadvantages for architecture type.

Part 1: Monolithic Architecture Design

Core Functionalities:

1. User registration
2. Product catalog
3. Shopping cart
4. Order processing

High-Level Architecture Diagram:

|------------------------|
|         Frontend       |
|------------------------|
            |
            v
|------------------------|
|    Business Logic      |
|      (Monolith)        |
|------------------------|
            |
            v
|------------------------|
|        Database        |
|------------------------|

Advantages:

• Simplicity and Uniformity: Easy to develop, deploy, and manage as everything is contained within a single codebase.
• Ease of Deployment: Deployment is straightforward as there’s only one unit to deploy.

Disadvantages:

• Scalability: Scaling the application can be challenging as all components are tightly coupled, making it difficult to scale individual parts independently.
• Flexibility: Changes or updates to one part of the application may require redeploying the entire monolith.
• Deployment: Scaling the monolith horizontally can be costly and inefficient.

Part 2: Refactoring into Microservices

Identified Microservices:

1. User Service
2. Product Service
3. Cart Service
4. Order Service

Updated Architecture Diagram:

|------------------------|
|         Frontend       |
|------------------------|
            |
            v
|------------------------|
|     User Service       |
|------------------------|
            |
            v
|------------------------|
|    Product Service     |
|------------------------|
            |
            v
|------------------------|
|     Cart Service       |
|------------------------|
            |
            v
|------------------------|
|    Order Service       |
|------------------------|
            |
            v
|------------------------|
|     Database(s)        |
|------------------------|

Advantages:

• Scalability: Each microservice can be scaled independently based on demand, allowing for more efficient resource utilisation.
• Flexibility: Changes or updates to one microservice can be made without affecting others, enabling faster development and deployment.
• Deployment: Each microservice can be deployed independently, facilitating Continuous Deployment/Continuous Integration (CI/CD) practices.

Challenges:

• Development Complexity: Managing multiple services can increase development complexity, especially in terms of communication between services.
• Deployment: Coordinating deployments across multiple services requires careful orchestration to maintain consistency and avoid service disruptions.
• Consistency: Ensuring consistency in data management and transactions across distributed services can be challenging.

Part 3: Incorporating Serverless Architecture

Identified Serverless Components:

1. User Authentication
2. Payment Processing

Updated Architecture Diagram:

|------------------------|
|         Frontend       |
|------------------------|
             |
             v
|------------------------|
|    User Authentication |  (Serverless)
|------------------------|
             |
             v
|------------------------|
|   Product & Order APIs |  (Microservices)
|------------------------|
             |
             v
|------------------------|
|   Payment Processing   |  (Serverless)
|------------------------|
             |
             v
|------------------------|
|     Database(s)        |
|------------------------|

Benefits of Serverless Architecture:

• Scalability: Serverless functions auto-scale based on demand, ensuring resources are efficiently utilised and reducing the risk of over-provisioning.
• Cost: Serverless architectures offer cost savings as you only pay for the resources consumed during execution, rather than provisioning fixed resources.
• Operational Management: Serverless providers handle server management, scaling, and maintenance, reducing operational overhead for the development team.

Challenges:

• Cold Start: Serverless functions may experience latency during cold starts, impacting the responsiveness of the application.
• Vendor Lock-in: Adopting serverless architectures may lead to vendor lock-in due to reliance on specific cloud providers’ services and APIs.
• Debugging and Monitoring: Debugging and monitoring serverless functions can be more challenging compared to traditional architectures.

Comparison Report:

1. Scalability:

   • Monolithic: Limited scalability due to tight coupling.
   • Microservices: Highly scalable, each service can be scaled independently.
   • Serverless: Autoscaling capabilities offer efficient resource utilisation.

2. Development Complexity:

   • Monolithic: Simple development but can become complex as the application grows.
   • Microservices: Increased complexity due to managing multiple services.
   • Serverless: Simplifies development by abstracting infrastructure management, but can be complex in orchestrating functions.

3. Deployment:

   • Monolithic: Simple deployment but requires redeployment of the entire application for updates.
   • Microservices: Requires careful orchestration for deployment across multiple services.
   • Serverless: Facilitates easy and rapid deployments of individual functions.

4. Maintenance:

   • Monolithic: Maintenance can be cumbersome, especially for large applications.
   • Microservices: Each service needs to be maintained individually.
   • Serverless: Reduces operational overhead as infrastructure management is handled by the provider.

5. Cost Implications:

   • Monolithic: Fixed infrastructure costs regardless of usage.
   • Microservices: Costs may vary based on the number of services and their usage.
   • Serverless: Cost-efficient as you only pay for actual usage.

Suitability for Different Projects:

• Monolithic: Suitable for small-scale projects with predictable usage.
• Microservices: Ideal for large-scale projects with complex requirements and variable loads.
• Serverless: Well-suited for projects with sporadic or unpredictable workloads and where cost optimisation is crucial.

Each architectural style has its strengths and weaknesses, and the choice depends on the specific requirements, scale, and constraints of the project.

Learnt about 3 main types of version control systems: 1. Local: All repositories/data are only held and accessible from a local machine, making it difficult to collaborate with others. 2. Centralised: The repository is kept on a main server, any updates have to be committed to the central server. 3. Distributed: Repositories are distributed across end users and servers. Any of the users or servers can act as the central repository.

GIT

• Set up a GitHub account, configured MFA and ssh access. Command to check that ssh is connected **ssh -T git@github.com
• Installed git in Windows and Linux and set up CLI access via ssh.
  • SSH encrypts the data flow between my machine and github, ensuring confidentiality in the transmission of data that I commit to the repo.

AWS CLI

• Installed the AWS CLI in Windows and Linux
• Added security keys in AWS console and installed them into AWS CLI. This now enables control of my AWS account through the CLI. The CLI is definitely faster than clicking and confirming through the console.
• Command structure: aws + service type + what you want to do, examples: aws + s3 service + list files = aws s3 ls aws + iam + list access keys = aws iam list-access-keys

Cloud Architecture & System Design

Front end vs back end

• Front end = user facing, interacts with the backend via API’s (Application Programming Interface).
• Back end = All of the infrastructure and applications that enables the front end to function.

Vertical vs Horizontal scaling

• Vertical scaling = increasing or decreasing the size of the hardware - such as EC2 t2.micro, t2.small, t2.medium etc. As the size increases additional hardware is provided such as more CPU cores and memory.
• Horizontal scaling = Instead of increasing hardware capacity as with vertical scaling, horizontal scaling instead increases the amount of instances. Instead of increasing from a t2.micro instance to a single t2.small instance, you could run 3 x t2.micro instances. This provides additional computing resources and also provides redundancy as there are now two extra compute instances in the event that one of them becomes unresponsive or crashes.

Load Balancing

These can be hardware or software that distributes data across your infrastructure. Is used to ensure that a server isn’t being overloaded while other servers are sitting idle. Can also decide which server is closest to the end user in order to reduce latency for their request.

High Availability and Fault Tolerance

• High availability = Redundancy within a network that enables standby infrastructure to take over in the event of the main services becoming unresponsive or crashing. Multiple instances can be used across different Availability Zones (AZ) to ensure continued operation even if an AZ experiences an outage. Use of health checks, auto scaling and load balancing to maintain high availability.
• Fault tolerance = The ability to continue providing services in the event of a fault, issue or outage. Intent is that faults do not impact the user experience.

Lab - Design a Web Application Architecture

Summary of Cloud Architecture for Web Application

This document outlines the purpose of each component and the rationale behind key architectural decisions in our cloud architecture for the web application.

Components:

• VPC (Virtual Private Cloud): Provides a secure and isolated environment for our application resources.
• Route 53: Routes incoming traffic to the application through a domain name.
• Public and Private Subnets: 
• Public Subnets:
  • Purpose: Host web servers that require internet access to serve content to users.
  • Reasoning: Enables users to access the application through the internet.
• Private Subnets:
  • Purpose: Host application servers and databases that don’t require direct internet access but need to communicate with web servers.
  • Reasoning: Enhances security by restricting access to critical components from the public internet.
• Web Servers and Application Servers: 
• Web Servers (EC2 Instances):
  • Purpose: Serve static content (HTML, CSS, JavaScript) and handle initial user requests.
  • Reasoning: Offloads static content serving from application servers, improving performance and scalability.
• Application Servers (EC2 Instances):
  • Purpose: Process application logic, interact with the database, and generate dynamic content.
  • Reasoning: Provides flexibility and scalability for handling application logic and database interactions.EC2 instances host the web application and application logic.
• Load Balancers: 
  • Purpose: Distribute incoming traffic evenly across multiple web and application servers.
  • Reasoning: Ensures high availability and prevents overloading individual servers, improving application performance and scalability.
• AWS WAF: Protects the web application from malicious attacks.
  • • Purpose: Filters and blocks malicious traffic attempting to exploit vulnerabilities in the web application.
  • Reasoning: Strengthens application security by mitigating common web attacks like SQL injection and cross-site scripting
• Amazon RDS (Relational Database Service): 
  • Purpose: Provides a managed, scalable, and highly available database service for storing application data.
  • Reasoning: Offers a reliable and secure solution for managing application data without the need for manual database administration.
• AWS S3: 
  • • Purpose: Stores static content like images, videos, and other application assets cost-effectively and efficiently.
  • Reasoning: Provides a scalable and cost-effective way to store and manage large amounts of static content, offloading storage from web servers and improving performance.

Architectural Decisions:

• Horizontal Scaling: Web and application servers are deployed in auto scaling groups for horizontal scaling. This allows automatic scaling up or down based on traffic demands, ensuring optimal performance and resource utilization.
• Redundancy: Deploying critical components like web servers, application servers, and databases across multiple availability zones within the VPC ensures continued operation even if one zone experiences an outage.
• Security: Utilizing a VPC with public/private subnets and a WAF strengthens the application’s security posture by isolating resources and filtering malicious traffic.

Week 1

To make my weekly summary, I start by making a list of topics/subjects that I study this week from my Obisidian note titles. Once I’ve compiled this list, I then test my recall by attempting to write down all the information I retained about the subject. I then input my summaries into Bard for a quality control/accuracy check and review the items that bard highlights against my Obsidian notes. Below is my summary for week 1:

Cloud Service Types

IAAS - Infrastructure as a Service - Compute, storage etc (EC2, S3) - Base infrastructure that you can build whatever you want on. PAAS - Platform as a Service - The underlying infrastructure is looked after by the service provider (hardware and OS), meaning you can focus on the service/app you are building/deploying (ex: Elastic Beanstalk, Lambda) SAAS - Software as a Service - Elastic, Adobe Photoshop, AI images, M365, Teams etc

1. Onprem - All physical infrastructure and services are provided “on premises”.
2. Cloud - All services are provided through the cloud. All hardware is through the providers Data Centre. Maintenance, security, power and cooling for the physical infrastructure is undertaken by the Service Provider.
3. Hybrid - Combination of both onprem and cloud infrastructure.

SDLC

Software Development Life Cycle DLC models: Waterfall and Agile

Sequential approach: Requirements (scope), Design, Development, Testing, Deployment, Maintenance.

AWS account creation

1. Created admin account
2. Added MFA to root and admin accounts
3. Set billing alerts

Virtualisation

Baremetal, type 1 hypervisors vs host based virtualisation Virtualisation of hardware (cpu and memory for O/S and compute tasks), storage (multiple disks seen as a single storage device)

The ability for a single server to act as multiple servers by allocating resources (cpu, memory etc) across virtual machines. Example 32 core CPU and 64GB of ram server can become 4 virtual machines/servers of 8 CPU cores and 16GB of ram. Resources do not need to be equal across VM’s and should reflect the amount resources required for the application/task.

Cloud networking

Introduction into networking engineering concepts of IP addressing, DHCP, DNS, NAT and protocols (TCP/IP, HTTP/HTTPS). Overview of networking hardware (routers and switches) and the ability to deploy virtual hardware in cloud deployments.

Operating Systems

Overview of three main O/S’s (Windows, Linux, macOS). Touched on the different Linux distros (CentOS, Redhat, Ubuntu, SELinux etc), that many are open source and low cost.

Databases

Databases were split into two main types, relational and nonrelational (nonSQL). Relational is used to for large datasets with similar inputs, such as maintaining the name, address, DOB etc for staff and students at a school/university. NonSQL is usually used when varied datasets will be ingested and flexibility is required. Can be column based, graph, key-value, document etc type database.

Captain CRUD: Create, Read, Update, Delete. Database strings/command types. Can be used on both Relational and NonSQL database types.

Labs/projects

1. AWS account setup - touched on above
2. Completed basic networking engineering commands such as ping, find ip address (ipconfig/ifconfig, web ip check), traceroute/tracert, curl requests.
3. Windows and macOS setups - Discovered Chocolatey, as package manager for Windows, I love it. Ubuntu - sudo apt-get install “program name”, I found the Chocolatey similar to Debian/Ubuntu advanced packaging tool (APT), apt-get install “program name” vs choco install “program name”.
   1. Install Choclatey in Powershell:
   2. Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(‘https://community.chocolatey.org/install.ps1'))
   3. Basic Chocolatey commands:
   4. choco install “program name”
   5. choco list - displays a list of installed packages
   6. choco search “package name” - searches for available packages
   7. choco outdated - will provide a list of outdated packages on the machine
   8. choco upgrade “package name” - upgrade the outdated packages identified in the previous command
   9. choco uninstall “package name”