Forem: Alexin

How I Built My First Production-Grade AWS Infrastructure (And Almost Lost My Mind)

Alexin — Sun, 15 Feb 2026 11:45:45 +0000

A brutally honest walkthrough of my AltSchool Cloud Engineering exam project

The Assignment That Humbled Me

I'm a student at AltSchool Africa studying Cloud Engineering, and for our semester 2 exam, we got this assignment where we had to roleplay as a Junior Cloud Engineer hired by a company. The task? Deploy a secure, highly available web application on AWS.

I thought "how hard could it be?"

Spoiler alert: Pretty hard.

But I learned more in those two days than I did in weeks of watching tutorials. This is my story of building real cloud infrastructure, breaking things, fixing them, breaking them again, and eventually getting it right.

What I Had to Build

The assignment was clear:

1 Bastion Host in a public subnet
2 Web Servers in a private subnet (NO public IPs)
Everything automated with Ansible
An Application Load Balancer distributing traffic
All access through the load balancer only

The catch? Web servers couldn't be directly accessible from the internet. Everything had to go through proper security layers.

Here's what I ended up building:

Day 1: "This Should Be Easy"

Starting with Security Groups

I started by creating security groups because I figured I'd need those first. Three of them:

bastion-sg - For my jump box

Allow SSH from my IP
That's it

webserver-sg - For the application servers

Allow SSH from bastion-sg only
Allow HTTP from alb-sg only
No direct access from internet

alb-sg - For the load balancer

Allow HTTP from anywhere (0.0.0.0/0)
This is the only thing exposed to the internet

This part actually went smoothly. I was feeling confident. Too confident.

Launching EC2 Instances

Next up: spinning up instances. I created an SSH key pair (saved it as cloud-assignment-key.pem) and launched:

Bastion Host - Ubuntu 24.04, t2.micro, in a public subnet with a public IP
Web-Server-1 - Ubuntu 24.04, t2.micro, NO public IP
Web-Server-2 - Ubuntu 24.04, t2.micro, NO public IP

Here's where I made my first mistake: I put all three instances in the same subnet. I didn't think about the fact that a subnet is either public OR private, not both. This came back to bite me later.

Setting Up SSH Access

I tested SSH to the Bastion - worked fine:

ssh -i ~/.ssh/cloud-assignment-key.pem ubuntu@<bastion-public-ip>

But I needed to access the web servers through the Bastion. This is where ProxyJump saved my life. I created an SSH config file:

Host bastion
    HostName <BASTION_PUBLIC_IP>
    User ubuntu
    IdentityFile ~/.ssh/cloud-assignment-key.pem
    ForwardAgent yes
    StrictHostKeyChecking no

Host webserver1
    HostName <WEB_SERVER_1_PRIVATE_IP>
    User ubuntu
    IdentityFile ~/.ssh/cloud-assignment-key.pem
    ProxyJump bastion
    StrictHostKeyChecking no

Host webserver2
    HostName <WEB_SERVER_2_PRIVATE_IP>
    User ubuntu
    IdentityFile ~/.ssh/cloud-assignment-key.pem
    ProxyJump bastion
    StrictHostKeyChecking no

Now I could just type ssh webserver1 and it would automatically jump through the Bastion. Magic.

Day 1 Evening: The Ansible Disaster

Okay, time for automation. I installed Ansible on my laptop and created an inventory file:

[webservers]
webserver1 ansible_host=172.31.x.x
webserver2 ansible_host=172.31.y.y

[webservers:vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/cloud-assignment-key.pem
ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyJump=bastion'

Tested connection:

ansible webservers -i inventory.ini -m ping

Success! Both servers responded:

webserver1 | SUCCESS
webserver2 | SUCCESS

Great, I thought. Time to run the actual playbook. Here's what it looked like:

- name: Deploy Web Application
  hosts: webservers
  become: yes
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Install NGINX
      apt:
        name: nginx
        state: present

    - name: Start and enable NGINX
      systemd:
        name: nginx
        state: started
        enabled: yes

    - name: Get instance hostname
      shell: hostname
      register: instance_hostname

    - name: Get private IP
      shell: hostname -I | awk '{print $1}'
      register: private_ip

    - name: Deploy custom HTML page
      copy:
        dest: /var/www/html/index.html
        content: |
          <!DOCTYPE html>
          <html lang='en'>
          <head>
              <meta charset='UTF-8'>
              <title>Cloud Assignment - Alexin</title>
              <style>
                  body {
                      font-family: 'Segoe UI', sans-serif;
                      max-width: 800px;
                      margin: 50px auto;
                      padding: 20px;
                      background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
                      color: white;
                  }
                  .container {
                      background: rgba(255, 255, 255, 0.1);
                      padding: 40px;
                      border-radius: 15px;
                      backdrop-filter: blur(10px);
                  }
                  .info { 
                      background: rgba(255, 255, 255, 0.2); 
                      padding: 15px; 
                      border-radius: 8px; 
                      margin: 20px 0; 
                  }
              </style>
          </head>
          <body>
              <div class='container'>
                  <h1>🚀 Cloud Assignment</h1>
                  <div class='info'>
                      <p><strong>Name:</strong> Alexin</p>
                      <p><strong>Instance:</strong> {{ instance_hostname.stdout }}</p>
                      <p><strong>Private IP:</strong> {{ private_ip.stdout }}</p>
                  </div>
                  <div class='about'>
                      <h2>About Me</h2>
                      <p>Backend engineer from Lagos, Nigeria. This was deployed with 
                      Ansible through a Bastion Host to demonstrate Infrastructure as Code.</p>
                  </div>
              </div>
          </body>
          </html>
        mode: '0644'
      notify: Restart NGINX

  handlers:
    - name: Restart NGINX
      systemd:
        name: nginx
        state: restarted

Ran it:

ansible-playbook -i inventory.ini deploy-webserver.yml

IT FAILED.

The playbook started running, got to the "Install NGINX" task, and just... timed out. Connection errors everywhere. The servers were reachable via SSH, Ansible could ping them, but they couldn't download anything.

TASK [Install NGINX] *****
fatal: [webserver1]: FAILED! => {"changed": false, "msg": "Failed to update apt cache"}
fatal: [webserver2]: FAILED! => {"changed": false, "msg": "Failed to update apt cache"}

I spent an hour debugging this. Turns out my web servers couldn't reach the internet to download packages. They could talk to Ansible (via the Bastion), but they couldn't reach Ubuntu's package repositories.

The Internet Access Problem

Here's what I learned the hard way: My servers needed internet access to run apt update and apt install nginx. They were technically reachable via SSH, but they couldn't initiate outbound connections to the internet.

The proper solution? NAT Gateway.

But I was already tired and the deadline was approaching, so I did a "quick fix": I kept everything in the same public subnet (with Internet Gateway access) so the servers could download packages. Not best practice, but it worked for getting Ansible running.

After that fix, the playbook ran perfectly:

PLAY RECAP *****
webserver1: ok=8 changed=6 unreachable=0 failed=0
webserver2: ok=8 changed=6 unreachable=0 failed=0

Both servers configured in under 2 minutes. This is when I understood why everyone talks about automation - imagine doing this manually on 10 or 100 servers.

Why Ansible Changed Everything

Before this project, I'd always SSH'd into servers and ran commands manually. Copy-paste from StackOverflow, hope it works, repeat on the next server.

Ansible made me realize:

Consistency - Both servers got the EXACT same config
Speed - 2 minutes vs 30 minutes of manual work
Documentation - My playbook IS my documentation
Repeatability - I can run it again tomorrow and get the same result

The playbook grabs the hostname and private IP dynamically with shell commands, then injects them into the HTML template. Each server shows different info, proving load balancing works later.

Day 2: Load Balancer Time

Creating the Target Group

First, I created a target group:

Name: webserver-tg
Protocol: HTTP, Port: 80
Registered both web servers
Health checks: HTTP GET to /

Creating the ALB

Then the Application Load Balancer:

Name: web-app-alb
Internet-facing
Selected multiple availability zones
Security group: alb-sg
Forwarded traffic to: webserver-tg

Waited for health checks... and both targets went healthy!

Accessed the ALB DNS name in my browser:

http://web-app-alb-xxxxxxxxx.eu-north-1.elb.amazonaws.com

IT WORKED!

But I noticed it kept showing the same server. Turns out that's normal - it's called "sticky sessions". The load balancer keeps you on the same server for consistency. I verified it was actually load balancing by using curl:

for i in {1..10}; do curl http://alb-dns-name | grep "Instance:"; done

And boom - I saw both server hostnames appearing. Load balancing confirmed.

Why a Bastion Host?

At first, I didn't get why we needed a Bastion Host. Why not just SSH directly to the servers?

Here's what I learned:

Without Bastion (Bad):

Every server exposed to the internet
More attack surface
Hard to control who accesses what
Each server needs its own public IP

With Bastion (Good):

Only ONE server exposed to internet
Single point of entry I can monitor and secure
Web servers hidden in private subnet
I can log every SSH session
If someone compromises the Bastion, web servers are still protected

Real companies use this because:

Compliance - Many regulations require it
Security - Defense in depth
Auditing - Know who accessed what and when

The Bastion is like a security checkpoint. Everything goes through it, nothing bypasses it.

Load Balancer vs Direct Access: Why It Matters

When I started, I thought "why not just give each server a public IP and call it a day?"

Here's why that's a terrible idea:

Direct EC2 Access (What NOT to Do):

Single Point of Failure - Server goes down? Your app is offline
No Failover - Users get errors until you manually fix it
Security Risk - Servers exposed directly to attacks
Hard to Scale - Adding servers means changing DNS
No Health Checks - You won't know a server died until users complain

Load Balancer Access (The Right Way):

High Availability - One server dies? Traffic goes to the other
Automatic Failover - Load balancer detects failures and reroutes
Better Security - Servers stay in private subnet
Easy Scaling - Add/remove servers without DNS changes
Health Monitoring - Load balancer constantly checks if servers are healthy
SSL Termination - Handle HTTPS at the load balancer, not on each server

In my setup, if Web-Server-1 crashes, the load balancer immediately stops sending traffic to it. Users never notice. That's production-grade architecture.

The "Oh Shit" Moment: Realizing I Needed to Rebuild

Later, I realized something: I had put all my instances in the same subnet. But the assignment specifically said "private subnet" for web servers.

A subnet is either public (routes to Internet Gateway) or private (routes to NAT Gateway). You can't have both in the same subnet.

So I had to:

Create a NAT Gateway (in a public subnet)
Create a Private Route Table (routes outbound traffic through NAT)
Associate that route table with a private subnet
Terminate my web servers
Launch new ones in the private subnet WITHOUT public IPs
Update my inventory and SSH config
Run Ansible again
Update the target group

This took another hour, but it was the right way to do it.

The NAT Gateway Confusion

Here's something that confused me: If web servers are in a private subnet with NO internet access, how do they download packages?

Answer: NAT Gateway.

A NAT Gateway allows outbound-only internet access:

Web Server: "I need to apt install nginx"
    ↓
Private Subnet Route Table: "Send to NAT Gateway"
    ↓
NAT Gateway: "I'll translate your private IP to my public IP"
    ↓
Internet: "Here's nginx"
    ↓
NAT Gateway: "I remember who asked, sending back to Web Server"
    ↓
Web Server: "Got it, thanks!"

The key: Outbound connections work, but the internet CANNOT initiate connections to your private servers. They're truly isolated.

Without NAT Gateway, private servers are completely offline. Can't download anything, can't reach APIs, nothing.

All The Things That Went Wrong

Issue 1: "Connection Timed Out"

Problem: Ansible couldn't connect to web servers. Ping returned UNREACHABLE.

Why: Web servers had no internet access to download packages. They were in a public subnet, but they had no IP addresses themselves.

Solution: Quick fix - made the instances public. Later rebuilt properly with NAT Gateway.

Lesson: Private instances = NO internet unless you add NAT Gateway.

Issue 2: All Instances in Same Subnet

Problem: Assignment required private subnet for web servers, but I had everything in the same subnet.

Why: I didn't understand that subnets are either public OR private, not both.

Solution: Created separate private subnet with route table pointing to NAT Gateway. Launched new web servers there.

Lesson: Network architecture planning matters. Can't just throw everything anywhere.

Issue 3: Can't curl from Bastion to Web Servers

Problem: Tried to test web servers from Bastion using curl. Connection refused.

Why: Security group webserver-sg only allowed HTTP from alb-sg, not from bastion-sg.

Solution: Skipped this test. Verified through the load balancer instead.

Lesson: Security groups are strict. They block everything not explicitly allowed.

Issue 4: Load Balancer Only Shows One Server

Problem: Refreshing the page kept showing the same server. Thought load balancing was broken.

Why: Sticky sessions - the load balancer uses cookies to keep you on the same server.

Solution: Used curl in a loop to verify both servers were getting traffic. They were.

Lesson: Sticky sessions are a feature, not a bug. Keeps user sessions consistent.

Issue 5: Target Group Shows "Unused"

Problem: After registering web servers in target group, status showed "Unused" with message "Target is in an Availability Zone that is not enabled for the load balancer"

Why: My web servers were in AZ eu-north-1c in a private subnet, but my load balancer wasn't configured to use that AZ since it couldn't use private subnets.

Solution: Created a public subnet in AZ 1c and added it to the load balancer's network mapping.

Lesson: Load balancers need to span the availability zones where your targets are.

Issue 6: NAT Gateway Not Appearing in Route Table

Problem: When trying to add route 0.0.0.0/0 => NAT Gateway, it wasn't showing up in the dropdown.

Why: NAT Gateway was still in "Pending" status. Hadn't finished creating yet.

Solution: Waited 2-3 minutes for status to become "Available", then refreshed the page.

Lesson: AWS resources take time to provision. Be patient.

Issue 7: New Subnet Not Showing in ALB Config

Problem: Created a new public subnet for the ALB, but it didn't appear in the subnet dropdown.

Why: New subnet wasn't associated with a route table that has Internet Gateway route.

Solution: Associated the subnet with the public route table (one with IGW route). Refreshed page.

Lesson: Subnets need proper route table associations to be recognized correctly.

What I Learned About Cloud Security

This project taught me security is about layers:

Layer 1: Network Segmentation

Public subnet: Only Bastion, NAT, Load Balancer
Private subnet: Application servers

Layer 2: Security Groups

Each component has its own firewall rules
Rules reference each other by security group ID
Principle of least privilege

Layer 3: No Public IPs on App Servers

Can't be attacked if they're not reachable
All traffic forced through load balancer

Layer 4: SSH Keys, Not Passwords

Cryptographic authentication
Keys never leave my laptop

Layer 5: Bastion Host

Single auditable entry point
Can log all SSH sessions
Additional barrier

This is what "defense in depth" means. You don't rely on one security measure, you stack them.

If I Did It Again

Things I'd add for a real production system:

1. HTTPS

Right now it's just HTTP. In production, I'd:

Get a free SSL cert from AWS Certificate Manager
Configure ALB to handle HTTPS on port 443
Redirect HTTP to HTTPS

2. Auto Scaling

Currently just 2 fixed servers. I'd add:

Auto Scaling Group
Scale up when CPU > 70%
Scale down when CPU < 30%
Minimum 2 instances for availability

3. Multiple Availability Zones for Web Servers

Right now both servers are in AZ 1c. For true high availability:

Put Web-Server-1 in AZ 1b (since Bastion is in 1a)
Put Web-Server-2 in AZ 1c
Protected against entire data center failures

4. Database Layer

Currently no database. I'd add:

Amazon RDS in private subnet
Separate database security group
Automated backups

5. Monitoring

Zero visibility right now. I'd add:

CloudWatch alarms (CPU, memory, disk)
CloudWatch Logs (application logs)
SNS notifications for alerts

6. CI/CD Pipeline

Manual deployments don't scale. I'd add:

GitHub Actions or AWS CodePipeline
Automated testing
Blue/green deployments

7. Infrastructure as Code

I clicked through the console for everything. Better approach:

Terraform or CloudFormation
Version control entire infrastructure
Reproducible across environments

Real Talk: Was It Worth It?

Two days. Countless errors. Almost gave up multiple times.

But here's what I got out of it:

Technical Skills:

Actually understand VPCs, subnets, route tables now
Know how security groups work
Can write Ansible playbooks
Understand load balancer concepts

Problem-Solving:

Learned to read error messages carefully
Know how to debug connection issues
Can think through network architecture

Confidence:

Built something real, not a tutorial
Can explain this in interviews
Know I can figure things out when stuck

The assignment said "If you can explain this project clearly, you can explain 70% of junior cloud interviews."

They weren't lying. This project covers:

Cloud networking fundamentals
Security best practices
Infrastructure automation
High availability patterns
Real-world troubleshooting

For Anyone Doing This Assignment

If you're an AltSchool student reading this:

Do's:

Start early. This takes longer than you think
Read error messages carefully
Draw your architecture before building
Test each component before moving to the next
Take screenshots as you go (you'll need them)
Ask for help when stuck

Don'ts:

Don't put everything in the same subnet
Don't skip the NAT Gateway (private servers need it)
Don't give web servers public IPs (assignment requires private)
Don't forget to delete resources after submission (AWS bills add up!)
Don't just copy commands without understanding them

Key Resources:

AWS Documentation
Ansible Documentation
This article (seriously, refer back to it)

Final Architecture Checklist

Before submitting, verify:

3 EC2 instances running (1 Bastion, 2 Web Servers)
Only Bastion has public IP
Web servers in different subnet than Bastion
NAT Gateway created and available
Private route table routes through NAT Gateway
Can SSH: laptop => bastion => web servers
Ansible playbook runs successfully
Both web servers show different hostnames/IPs
Application Load Balancer is active
Both targets healthy in target group
ALB DNS shows your page
Refreshing shows different servers (use curl to verify)
RESOURCES DELETED AFTER SUBMISSION

That last one is critical. NAT Gateway alone costs ~$32/month if you forget it.

Closing Thoughts

This assignment kicked my ass, but in the best way possible.

I went from "I've watched AWS tutorials" to "I've built AWS infrastructure". That's a huge difference.

The frustration when Ansible couldn't connect. The confusion about subnets. The moment when the load balancer finally showed both servers. The relief when all health checks turned green.

That's real learning.

If you're reading this because you're about to start this assignment: good luck. You'll need it. But you'll also learn more than you expect.

If you're reading this because you finished: congrats! We survived.

If you're a recruiter: this is what I know now. Want to see if I can build something for you?

How I Built My First Production-Grade AWS Infrastructure (And Almost Lost My Mind)

Alexin — Sun, 15 Feb 2026 11:45:45 +0000

A brutally honest walkthrough of my AltSchool Cloud Engineering exam project

The Assignment That Humbled Me

I thought "how hard could it be?"

Spoiler alert: Pretty hard.

What I Had to Build

The assignment was clear:

1 Bastion Host in a public subnet
2 Web Servers in a private subnet (NO public IPs)
Everything automated with Ansible
An Application Load Balancer distributing traffic
All access through the load balancer only

The catch? Web servers couldn't be directly accessible from the internet. Everything had to go through proper security layers.

Here's what I ended up building:

Day 1: "This Should Be Easy"

Starting with Security Groups

I started by creating security groups because I figured I'd need those first. Three of them:

bastion-sg - For my jump box

Allow SSH from my IP
That's it

webserver-sg - For the application servers

Allow SSH from bastion-sg only
Allow HTTP from alb-sg only
No direct access from internet

alb-sg - For the load balancer

Allow HTTP from anywhere (0.0.0.0/0)
This is the only thing exposed to the internet

This part actually went smoothly. I was feeling confident. Too confident.

Launching EC2 Instances

Next up: spinning up instances. I created an SSH key pair (saved it as cloud-assignment-key.pem) and launched:

Bastion Host - Ubuntu 24.04, t2.micro, in a public subnet with a public IP
Web-Server-1 - Ubuntu 24.04, t2.micro, NO public IP
Web-Server-2 - Ubuntu 24.04, t2.micro, NO public IP

Here's where I made my first mistake: I put all three instances in the same subnet. I didn't think about the fact that a subnet is either public OR private, not both. This came back to bite me later.

Setting Up SSH Access

I tested SSH to the Bastion - worked fine:

ssh -i ~/.ssh/cloud-assignment-key.pem ubuntu@<bastion-public-ip>

But I needed to access the web servers through the Bastion. This is where ProxyJump saved my life. I created an SSH config file:

Host bastion
    HostName <BASTION_PUBLIC_IP>
    User ubuntu
    IdentityFile ~/.ssh/cloud-assignment-key.pem
    ForwardAgent yes
    StrictHostKeyChecking no

Host webserver1
    HostName <WEB_SERVER_1_PRIVATE_IP>
    User ubuntu
    IdentityFile ~/.ssh/cloud-assignment-key.pem
    ProxyJump bastion
    StrictHostKeyChecking no

Host webserver2
    HostName <WEB_SERVER_2_PRIVATE_IP>
    User ubuntu
    IdentityFile ~/.ssh/cloud-assignment-key.pem
    ProxyJump bastion
    StrictHostKeyChecking no

Now I could just type ssh webserver1 and it would automatically jump through the Bastion. Magic.

Day 1 Evening: The Ansible Disaster

Okay, time for automation. I installed Ansible on my laptop and created an inventory file:

[webservers]
webserver1 ansible_host=172.31.x.x
webserver2 ansible_host=172.31.y.y

[webservers:vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/cloud-assignment-key.pem
ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyJump=bastion'

Tested connection:

ansible webservers -i inventory.ini -m ping

Success! Both servers responded:

webserver1 | SUCCESS
webserver2 | SUCCESS

Great, I thought. Time to run the actual playbook. Here's what it looked like:

- name: Deploy Web Application
  hosts: webservers
  become: yes
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Install NGINX
      apt:
        name: nginx
        state: present

    - name: Start and enable NGINX
      systemd:
        name: nginx
        state: started
        enabled: yes

    - name: Get instance hostname
      shell: hostname
      register: instance_hostname

    - name: Get private IP
      shell: hostname -I | awk '{print $1}'
      register: private_ip

    - name: Deploy custom HTML page
      copy:
        dest: /var/www/html/index.html
        content: |
          <!DOCTYPE html>
          <html lang='en'>
          <head>
              <meta charset='UTF-8'>
              <title>Cloud Assignment - Alexin</title>
              <style>
                  body {
                      font-family: 'Segoe UI', sans-serif;
                      max-width: 800px;
                      margin: 50px auto;
                      padding: 20px;
                      background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
                      color: white;
                  }
                  .container {
                      background: rgba(255, 255, 255, 0.1);
                      padding: 40px;
                      border-radius: 15px;
                      backdrop-filter: blur(10px);
                  }
                  .info { 
                      background: rgba(255, 255, 255, 0.2); 
                      padding: 15px; 
                      border-radius: 8px; 
                      margin: 20px 0; 
                  }
              </style>
          </head>
          <body>
              <div class='container'>
                  <h1>🚀 Cloud Assignment</h1>
                  <div class='info'>
                      <p><strong>Name:</strong> Alexin</p>
                      <p><strong>Instance:</strong> {{ instance_hostname.stdout }}</p>
                      <p><strong>Private IP:</strong> {{ private_ip.stdout }}</p>
                  </div>
                  <div class='about'>
                      <h2>About Me</h2>
                      <p>Backend engineer from Lagos, Nigeria. This was deployed with 
                      Ansible through a Bastion Host to demonstrate Infrastructure as Code.</p>
                  </div>
              </div>
          </body>
          </html>
        mode: '0644'
      notify: Restart NGINX

  handlers:
    - name: Restart NGINX
      systemd:
        name: nginx
        state: restarted

Ran it:

ansible-playbook -i inventory.ini deploy-webserver.yml

IT FAILED.

TASK [Install NGINX] *****
fatal: [webserver1]: FAILED! => {"changed": false, "msg": "Failed to update apt cache"}
fatal: [webserver2]: FAILED! => {"changed": false, "msg": "Failed to update apt cache"}

The Internet Access Problem

The proper solution? NAT Gateway.

After that fix, the playbook ran perfectly:

PLAY RECAP *****
webserver1: ok=8 changed=6 unreachable=0 failed=0
webserver2: ok=8 changed=6 unreachable=0 failed=0

Both servers configured in under 2 minutes. This is when I understood why everyone talks about automation - imagine doing this manually on 10 or 100 servers.

Why Ansible Changed Everything

Before this project, I'd always SSH'd into servers and ran commands manually. Copy-paste from StackOverflow, hope it works, repeat on the next server.

Ansible made me realize:

Consistency - Both servers got the EXACT same config
Speed - 2 minutes vs 30 minutes of manual work
Documentation - My playbook IS my documentation
Repeatability - I can run it again tomorrow and get the same result

The playbook grabs the hostname and private IP dynamically with shell commands, then injects them into the HTML template. Each server shows different info, proving load balancing works later.

Day 2: Load Balancer Time

Creating the Target Group

First, I created a target group:

Name: webserver-tg
Protocol: HTTP, Port: 80
Registered both web servers
Health checks: HTTP GET to /

Creating the ALB

Then the Application Load Balancer:

Name: web-app-alb
Internet-facing
Selected multiple availability zones
Security group: alb-sg
Forwarded traffic to: webserver-tg

Waited for health checks... and both targets went healthy!

Accessed the ALB DNS name in my browser:

http://web-app-alb-xxxxxxxxx.eu-north-1.elb.amazonaws.com

IT WORKED!

for i in {1..10}; do curl http://alb-dns-name | grep "Instance:"; done

And boom - I saw both server hostnames appearing. Load balancing confirmed.

Why a Bastion Host?

At first, I didn't get why we needed a Bastion Host. Why not just SSH directly to the servers?

Here's what I learned:

Without Bastion (Bad):

Every server exposed to the internet
More attack surface
Hard to control who accesses what
Each server needs its own public IP

With Bastion (Good):

Only ONE server exposed to internet
Single point of entry I can monitor and secure
Web servers hidden in private subnet
I can log every SSH session
If someone compromises the Bastion, web servers are still protected

Real companies use this because:

Compliance - Many regulations require it
Security - Defense in depth
Auditing - Know who accessed what and when

The Bastion is like a security checkpoint. Everything goes through it, nothing bypasses it.

Load Balancer vs Direct Access: Why It Matters

When I started, I thought "why not just give each server a public IP and call it a day?"

Here's why that's a terrible idea:

Direct EC2 Access (What NOT to Do):

Single Point of Failure - Server goes down? Your app is offline
No Failover - Users get errors until you manually fix it
Security Risk - Servers exposed directly to attacks
Hard to Scale - Adding servers means changing DNS
No Health Checks - You won't know a server died until users complain

Load Balancer Access (The Right Way):

High Availability - One server dies? Traffic goes to the other
Automatic Failover - Load balancer detects failures and reroutes
Better Security - Servers stay in private subnet
Easy Scaling - Add/remove servers without DNS changes
Health Monitoring - Load balancer constantly checks if servers are healthy
SSL Termination - Handle HTTPS at the load balancer, not on each server

In my setup, if Web-Server-1 crashes, the load balancer immediately stops sending traffic to it. Users never notice. That's production-grade architecture.

The "Oh Shit" Moment: Realizing I Needed to Rebuild

Later, I realized something: I had put all my instances in the same subnet. But the assignment specifically said "private subnet" for web servers.

A subnet is either public (routes to Internet Gateway) or private (routes to NAT Gateway). You can't have both in the same subnet.

So I had to:

Create a NAT Gateway (in a public subnet)
Create a Private Route Table (routes outbound traffic through NAT)
Associate that route table with a private subnet
Terminate my web servers
Launch new ones in the private subnet WITHOUT public IPs
Update my inventory and SSH config
Run Ansible again
Update the target group

This took another hour, but it was the right way to do it.

The NAT Gateway Confusion

Here's something that confused me: If web servers are in a private subnet with NO internet access, how do they download packages?

Answer: NAT Gateway.

A NAT Gateway allows outbound-only internet access:

Web Server: "I need to apt install nginx"
    ↓
Private Subnet Route Table: "Send to NAT Gateway"
    ↓
NAT Gateway: "I'll translate your private IP to my public IP"
    ↓
Internet: "Here's nginx"
    ↓
NAT Gateway: "I remember who asked, sending back to Web Server"
    ↓
Web Server: "Got it, thanks!"

The key: Outbound connections work, but the internet CANNOT initiate connections to your private servers. They're truly isolated.

Without NAT Gateway, private servers are completely offline. Can't download anything, can't reach APIs, nothing.

All The Things That Went Wrong

Issue 1: "Connection Timed Out"

Problem: Ansible couldn't connect to web servers. Ping returned UNREACHABLE.

Why: Web servers had no internet access to download packages. They were in a public subnet, but they had no IP addresses themselves.

Solution: Quick fix - made the instances public. Later rebuilt properly with NAT Gateway.

Lesson: Private instances = NO internet unless you add NAT Gateway.

Issue 2: All Instances in Same Subnet

Problem: Assignment required private subnet for web servers, but I had everything in the same subnet.

Why: I didn't understand that subnets are either public OR private, not both.

Solution: Created separate private subnet with route table pointing to NAT Gateway. Launched new web servers there.

Lesson: Network architecture planning matters. Can't just throw everything anywhere.

Issue 3: Can't curl from Bastion to Web Servers

Problem: Tried to test web servers from Bastion using curl. Connection refused.

Why: Security group webserver-sg only allowed HTTP from alb-sg, not from bastion-sg.

Solution: Skipped this test. Verified through the load balancer instead.

Lesson: Security groups are strict. They block everything not explicitly allowed.

Issue 4: Load Balancer Only Shows One Server

Problem: Refreshing the page kept showing the same server. Thought load balancing was broken.

Why: Sticky sessions - the load balancer uses cookies to keep you on the same server.

Solution: Used curl in a loop to verify both servers were getting traffic. They were.

Lesson: Sticky sessions are a feature, not a bug. Keeps user sessions consistent.

Issue 5: Target Group Shows "Unused"

Problem: After registering web servers in target group, status showed "Unused" with message "Target is in an Availability Zone that is not enabled for the load balancer"

Why: My web servers were in AZ eu-north-1c in a private subnet, but my load balancer wasn't configured to use that AZ since it couldn't use private subnets.

Solution: Created a public subnet in AZ 1c and added it to the load balancer's network mapping.

Lesson: Load balancers need to span the availability zones where your targets are.

Issue 6: NAT Gateway Not Appearing in Route Table

Problem: When trying to add route 0.0.0.0/0 => NAT Gateway, it wasn't showing up in the dropdown.

Why: NAT Gateway was still in "Pending" status. Hadn't finished creating yet.

Solution: Waited 2-3 minutes for status to become "Available", then refreshed the page.

Lesson: AWS resources take time to provision. Be patient.

Issue 7: New Subnet Not Showing in ALB Config

Problem: Created a new public subnet for the ALB, but it didn't appear in the subnet dropdown.

Why: New subnet wasn't associated with a route table that has Internet Gateway route.

Solution: Associated the subnet with the public route table (one with IGW route). Refreshed page.

Lesson: Subnets need proper route table associations to be recognized correctly.

What I Learned About Cloud Security

This project taught me security is about layers:

Layer 1: Network Segmentation

Public subnet: Only Bastion, NAT, Load Balancer
Private subnet: Application servers

Layer 2: Security Groups

Each component has its own firewall rules
Rules reference each other by security group ID
Principle of least privilege

Layer 3: No Public IPs on App Servers

Can't be attacked if they're not reachable
All traffic forced through load balancer

Layer 4: SSH Keys, Not Passwords

Cryptographic authentication
Keys never leave my laptop

Layer 5: Bastion Host

Single auditable entry point
Can log all SSH sessions
Additional barrier

This is what "defense in depth" means. You don't rely on one security measure, you stack them.

If I Did It Again

Things I'd add for a real production system:

1. HTTPS

Right now it's just HTTP. In production, I'd:

Get a free SSL cert from AWS Certificate Manager
Configure ALB to handle HTTPS on port 443
Redirect HTTP to HTTPS

2. Auto Scaling

Currently just 2 fixed servers. I'd add:

Auto Scaling Group
Scale up when CPU > 70%
Scale down when CPU < 30%
Minimum 2 instances for availability

3. Multiple Availability Zones for Web Servers

Right now both servers are in AZ 1c. For true high availability:

Put Web-Server-1 in AZ 1b (since Bastion is in 1a)
Put Web-Server-2 in AZ 1c
Protected against entire data center failures

4. Database Layer

Currently no database. I'd add:

Amazon RDS in private subnet
Separate database security group
Automated backups

5. Monitoring

Zero visibility right now. I'd add:

CloudWatch alarms (CPU, memory, disk)
CloudWatch Logs (application logs)
SNS notifications for alerts

6. CI/CD Pipeline

Manual deployments don't scale. I'd add:

GitHub Actions or AWS CodePipeline
Automated testing
Blue/green deployments

7. Infrastructure as Code

I clicked through the console for everything. Better approach:

Terraform or CloudFormation
Version control entire infrastructure
Reproducible across environments

Real Talk: Was It Worth It?

Two days. Countless errors. Almost gave up multiple times.

But here's what I got out of it:

Technical Skills:

Actually understand VPCs, subnets, route tables now
Know how security groups work
Can write Ansible playbooks
Understand load balancer concepts

Problem-Solving:

Learned to read error messages carefully
Know how to debug connection issues
Can think through network architecture

Confidence:

Built something real, not a tutorial
Can explain this in interviews
Know I can figure things out when stuck

The assignment said "If you can explain this project clearly, you can explain 70% of junior cloud interviews."

They weren't lying. This project covers:

Cloud networking fundamentals
Security best practices
Infrastructure automation
High availability patterns
Real-world troubleshooting

For Anyone Doing This Assignment

If you're an AltSchool student reading this:

Do's:

Start early. This takes longer than you think
Read error messages carefully
Draw your architecture before building
Test each component before moving to the next
Take screenshots as you go (you'll need them)
Ask for help when stuck

Don'ts:

Don't put everything in the same subnet
Don't skip the NAT Gateway (private servers need it)
Don't give web servers public IPs (assignment requires private)
Don't forget to delete resources after submission (AWS bills add up!)
Don't just copy commands without understanding them

Key Resources:

AWS Documentation
Ansible Documentation
This article (seriously, refer back to it)

Final Architecture Checklist

Before submitting, verify:

3 EC2 instances running (1 Bastion, 2 Web Servers)
Only Bastion has public IP
Web servers in different subnet than Bastion
NAT Gateway created and available
Private route table routes through NAT Gateway
Can SSH: laptop => bastion => web servers
Ansible playbook runs successfully
Both web servers show different hostnames/IPs
Application Load Balancer is active
Both targets healthy in target group
ALB DNS shows your page
Refreshing shows different servers (use curl to verify)
RESOURCES DELETED AFTER SUBMISSION

That last one is critical. NAT Gateway alone costs ~$32/month if you forget it.

Closing Thoughts

This assignment kicked my ass, but in the best way possible.

I went from "I've watched AWS tutorials" to "I've built AWS infrastructure". That's a huge difference.

The frustration when Ansible couldn't connect. The confusion about subnets. The moment when the load balancer finally showed both servers. The relief when all health checks turned green.

That's real learning.

If you're reading this because you're about to start this assignment: good luck. You'll need it. But you'll also learn more than you expect.

If you're reading this because you finished: congrats! We survived.

If you're a recruiter: this is what I know now. Want to see if I can build something for you?

[Boost]

Alexin — Mon, 28 Jul 2025 18:23:33 +0000

Abubakersiddique771

Jul 16 '25

7 Habits That Quietly Made Me a 10x Developer (No, Not ChatGPT)

#programming #java #ai #productivity

154

Comments 1

4 min read

Technical Debt: The Hidden Cost Of Shipping Fast And Thinking Later

Alexin — Mon, 16 Jun 2025 13:00:00 +0000

Ever shipped a tiny change and somehow broken six unrelated features you didn’t even touch? That, dear friends, is tech debt doing what it does best: lurking in the corners of the codebase you refused to refactor. You know exactly what I mean; those files stuffed with spaghetti logic, the ancient functions no one fully understands, that one part of the product that "just works" (but no one knows how - the code is unreadable). Have you ever spent hours tracing a bug, only to realize the real issue was a shortcut someone took nine months ago under deadline pressure? You’re not alone. Most of us have wrestled with tech debt left behind by old teammates, past versions of ourselves, or a product roadmap that prized speed over sustainability. Tech debt is the compounding interest of rushed decisions, and today, we’re unpacking what it is, why it doesn’t totally suck, and why it’s way more dangerous than most engineers realize.

What Is Technical Debt, really?

Technical debt is the cost of choosing speed over long-term code quality. It happens when teams ship fast by making subpar technical decisions, knowing their process isn’t ideal. In the short term, this helps hit deadlines and prove value. But over time, the code becomes harder to understand, slower to change, and more expensive to maintain, just like financial debt accrues interest if you don’t pay it back.

Ward Cunningham, who coined the term technical debt back in 1992, said:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt.

In plain English, when you create tech debt in your codebase, you're buying time to ship features faster. This quick-and-dirty code is fine if you revisit and fix it soon. When you don't, however, problems start to pile up. The longer you leave that messy code in place, the more time and effort you waste working around it.

Not all tech debt is created equal. Sometimes, you create intentional debt. This is the kind you take on knowingly - sprinting through features on an MVP checklist, building a demo overnight, or hacking together a prototype for a pitch. You know the code isn't great, but you accept the tradeoff to move fast, planning (hopefully) to clean it up later. Accidental debt, on the other hand, creeps in when no one's looking. It's what happens when specs change mid-sprint, when junior devs copy outdated patterns for core modules, or when your app is still running on a framework the internet forgot. One is strategic. The other is the programming equivalent of finding mold behind your wall.

Picture this: your team needs to ship a new onboarding flow by Friday. The designer mocks up a slick multi-step signup form, and the backend team realizes they’ll need to touch one ancient login module, written four years ago by someone who’s since moved to Canada and started a farm.

Ideally, this is the moment to refactor the login logic: separate concerns, clean up those 300-line functions, maybe even add some tests. But there’s no time. So instead, someone hacks in a workaround. It works for the deadline. But every new feature added to auth starts to break something else: session handling gets messy, error states become unpredictable, and adding social login becomes a full-blown crisis.

Months later, that one decision to “just patch it” means every auth-related ticket takes three times longer, and new engineers onboard with a warning: “DON'T TOUCH THE LOGIN SERVICE!” That’s tech debt in a production codebase in today's world.

How Tech Debt Happens

You don't just owe a bank 4x the amount you borrowed right off the bat (at least, I'd like to think so). You end up heavily in debt when you allow loans to rack up interest without paying them off in time. Similarly, in software production, tech debt slowly rises, disguised as "just one more quick fix" or a // TODO: clean this up comment. Over time, these small decisions start compounding, until you’re debugging a system that feels more like an archaeological excursion than a codebase. Here’s how it usually happens:

Ship-or-die deadlines: You had five days to do three weeks of work, so you cut corners to ship on time. The shortcut worked. The code stayed. No one circled back like they said they would.
Missing docs and tests: What starts as “we’ll document this later” quickly becomes a game of telephone, where future devs are forced to reverse-engineer your decisions from vague commit messages and test cases that haven't been updated in months.
Team churn and knowledge silos: The one engineer who understood how the invoicing system worked just rage-quit and joined a fintech startup. Now you’re stuck with brittle logic, zero documentation, and multiple Slack threads that end in “nevermind, fixed it” and no explanation on what the code does.
Partial migrations: Half your service uses Paystack, the other half uses Flutterwave, and now someone’s suggesting “let's try Monnify” for virtual accounts. Meanwhile, your original payment logic is still tangled up in custom webhook handlers from 2020. No tests, no docs, and no one brave enough to refactor it during working hours.
Copy-paste cargo culting: You found a working snippet on StackOverflow and dropped it in. It solved your problem, but now no one knows what it actually does. Worse, it’s breaking edge cases that nobody tested for.
Technical or Requirements Constraints: Not all tech debt is born from poor decisions. Sometimes, it’s the result of working within immovable limits. Maybe you’re forced to use an outdated API because the vendor hasn’t released v2 yet. Maybe the infrastructure team won’t approve a new database engine, so you’re stuck bending your current one into unnatural shapes. Or maybe the product spec just changed again mid-sprint, and your only option was to duct-tape the new logic onto whatever already existed.

The Many Faces of Tech Debt

Not all debt is code and not all of it is your fault. Tech debt can show up in different layers of your system:

Debt Type	What It Looks Like
Architecture Debt	Sluggish performance, fragile systems, and bottlenecks baked into your foundations.
Build Debt	Builds that take forever, randomly fail, or require arcane rituals to pass.
Code Debt	Spaghetti logic, inconsistent naming, and functions that do too much.
Defect Debt	Known bugs that no one has time to fix until they trigger outages.
Design Debt	Inheritance gone wild, singletons used like global duct tape.
Documentation Debt	README files that are out of date or simply nonexistent.
Infrastructure Debt	Deploy pipelines that break if you breathe wrong, or environments that drift constantly.
People Debt	One person knows how this works and they’re going on leave.
Process Debt	Clunky sprint planning, manual QA, or unclear review workflows.
Requirement Debt	Half-baked features that “technically shipped” but don’t meet user needs.
Service Debt	External services that need replacing but are too entwined to remove.
Test Automation Debt	Tests are manual, flaky, or missing for critical paths.
Test Debt	Planned test cases that were skipped or tools that can’t support new functionality.

Tech debt isn’t just messy code. It’s every inefficiency your team pays for, over and over again.

Spotting Tech Debt

Tech debt isn't always apparent. Unlike loan apps threatening your entire lineage if you don't pay up, tech debt often hides in plain sight, quietly draining your team’s velocity and morale until you realize you’ve spent three days fixing a bug that should’ve taken twenty minutes. You just had to fix one more thing, one more broken module that the original one was dependent on, until you ended up rewriting the entire feature, and you missed the deadline. So how do you know when your codebase is quietly screaming for help?

Quantitative Red Flags
- Pull requests that drag on forever: If simple changes start taking days (or weeks) to finish, chances are you're wrestling with hidden messes under the hood.
- Code that’s too complex to follow: When a single function has so many “if this, then that” cases, it feels like reading a legal contract. That’s a sign the logic has gotten out of hand.
- Barely any tests: If less than half your code is covered by automated tests, you're flying without a safety net. Every new change becomes a gamble.
Qualitative Smells
- “Don’t touch that part of the system.” If your team avoids certain files because they always break something, you’ve got serious baggage there.
- TODO comments from the BC Era: Notes left behind like “fix this later” that were never touched again, usually by people who’ve already left the company.
- Code reviews full of confusion: When teammates constantly ask, “What does this even do?” or “Why was it written this way?”, you’re probably looking at bad code that needs an update.
Tools That Help
- Code scanners (like SonarQube or DeepSource) that point out messy areas automatically.
- Health scores that rank your files based on how hard they are to maintain.
- Decision logs that explain why something weird was built that way (instead of guessing).
- Incident history that shows which parts of your system are always breaking at the worst times.

Real-World Impact of Technical Debt on Software Systems

Tech debt isn’t just an “engineering problem.” It’s a business problem. Left unmanaged, it silently bleeds time, money, morale, and momentum across the entire organization. The features get slower to build. The bugs get harder to trace. The outages get more frequent. And the developers? They start burning out. Here’s what that looks like in real life:

Slower Development: New features start taking forever, not because your team isn’t skilled, but because every change means wading through a minefield of brittle, undocumented code. You want to add a “forgot password” feature, but it turns into a three-day saga because it touches legacy auth logic that hasn’t been touched since 2019.
More Outages: Remember that one cron job nobody understood but everyone hoped would keep working? It didn’t. Tech debt creates fragile systems that break at the worst times, usually on weekends, during a promo launch, or when your lead dev is on vacation. Suddenly, your team is spending more time fixing fires than actually shipping features.
Higher Costs: Every patch, workaround, and unexplained bug adds up. Engineers burn more hours. Customers encounter more issues. Infra teams over-provision to compensate for bloated, inefficient logic. That’s real money leaking out of the product, disguised as "normal delays."
Team Burnout: No one enjoys working on a broken foundation. When your smartest engineers are spending half their time fixing the same parts of the system over and over, they’ll either check out or check LinkedIn. Tech debt is the silent morale killer that makes even small wins feel exhausting.
Business Blockers: Sometimes, the tech debt is so bad you simply can’t build what the business wants. “We can’t add multi-currency support yet” or “That will take three months instead of two weeks” becomes a regular thing in product planning. And no matter how strong the roadmap looks, delivery suffers.

Strategies to manage and repay tech debt

Tech debt isn’t the root of all evil. But like any loan, you have to track it, manage it, and eventually pay it down. Here’s how to do that while still staying on top of your roadmap.

Start a Debt Register: You can’t fix what you don’t track. Maintain a running list of known debt across the codebase - what it is, where it lives, how often it causes problems, and how painful those problems are. Think of it like a credit card statement, but for your repo. High-interest debt (frequent bugs, blockers) should always rise to the top.
Follow the Boy Scout Rule: Whenever you touch a file, refactor a little. Rename variables. Break down bloated functions. Add a comment. Leave it cleaner than you found it. These micro-improvements compound over time and help shift the codebase from survival mode to sustainable.
Refactor Within Features: Don't schedule refactoring for "someday." When working on a feature that touches janky code, bake cleanup into the story. That way, you get new functionality and better maintainability in one go, and no one has to justify a separate “tech debt ticket” that product will ignore.
Schedule Dedicated Debt Time: Set aside regular time to tackle known issues: maybe it’s “Clean-Up Fridays” or a full debt sprint every quarter. You’ll never eliminate debt entirely, but routine pay-down keeps it from spiraling into a crisis. Treat it like maintenance on your house. You can either patch the leak now or replace the roof later.
Automate Testing & CI Gates: The best way to prevent new tech debt? Don’t let it merge. Use automated tests, linters, and CI rules to catch bad patterns early. Every broken test or failed check is a helpful "nope" from your future self.
Document Your Shortcuts: If you take a shortcut, explain why. Use docs, inline comments, or ADRs (Architecture Decision Records) to give future devs context. "This is janky, but we did it to hit the Q2 deadline, and here’s what we’d like to change when we revisit it." Now your tech debt has a paper trail and a plan.
Have Kill-Switch Courage: Sometimes the most efficient refactor is a delete key. If a module is causing more pain than value, and no one knows why it still exists, just rip it out and rewrite it. Legacy systems, abandoned features, or duplicate services deserve a graceful exit, not eternal babysitting.

When It’s Actually Worth It

Not all tech debt is bad. Sometimes, it's the smartest move. Early in most software engineering projects (when you're testing ideas, racing toward product-market fit, or building a one-off demo), speed matters more than spotless architecture. Taking on debt intentionally can help you move fast, learn quickly, and prove value. The key is doing it with your eyes open: track it, cap it, and set a date to pay it back. Debt becomes dangerous not when you borrow, but when you forget you ever did.

References

Have you dealt with painful tech debt before? Maybe you’ve left behind a shortcut you wish you hadn’t, or inherited code that made no sense. Share your stories, your worst TODOs, or that one file everyone avoids. Let’s talk about it!

A Backend Engineer's Guide to Not Getting Hacked

Alexin — Mon, 16 Jun 2025 11:00:00 +0000

So there I was at 3AM, frantically joining an emergency Google Meet call because someone was trying to casually walk away with millions from our production environment. Not exactly how I planned to spend my night, but what choice did I have? We caught the breach in time, and by implementing some pre-determined incident response measures, we prevented what could have been a complete disaster.

Here's the thing about backend infrastructure: it's the backbone of everything we build. It's where we keep the crown jewels - user data, financial records, business logic, everything that makes our applications more than just pretty interfaces. When frontend fails, users get annoyed. When backend security fails? Companies die. Careers end. People get thrown in jail. Legal teams get that special twitch in their eyes. And yet, looking at some codebases out there, you'd think we were building toy projects instead of mission-critical infrastructure. I've seen production systems with security that wouldn't stop a determined teenager, let alone skilled attackers. I've watched companies pour millions into flashy features while treating security like an optional checkbox on their deployment checklist.

Here's everything I wish someone had drilled into my head about security before I found myself panic-googling "how to stop hackers" at 3AM. Consider this your "please don't let this be you" guide to backend security.

1. Input Validation: Trust Issues as a Service

Remember that time your mom told you to never trust strangers? Turns out she would've made a great security engineer. Every input is potentially malicious until proven otherwise. This isn't paranoia; it's just good engineering.

interface UserInput {
  id: number;
  email: string;
  metadata: Record<string, unknown>;
}

class InputValidator {
  static validateAndSanitize(input: UserInput): ValidatedUserInput {
    // Your mom was right - trust no one
    if (!this.isValidEmail(input.email)) {
      throw new ValidationError('Nice try, but no.');
    }

    return {
      id: parseInt(String(input.id), 10),
      email: this.sanitizeEmail(input.email),
      metadata: this.sanitizeMetadata(input.metadata)
    };
  }

  private static sanitizeMetadata(metadata: Record<string, unknown>): Record<string, string> {
    // Convert all values to strings and sanitize
    // Because someone will try to inject code here, I guarantee it
    const sanitized: Record<string, string> = {};
    for (const [key, value] of Object.entries(metadata)) {
      sanitized[key] = this.sanitizeString(String(value));
    }
    return sanitized;
  }
}

2. Key Management: Your Crown Jewels Aren't for GitHub

API keys are like your passwords - they don't belong on GitHub, in your DMs, in your CHatGPT debugging session or in that Slack message you swear no one will ever find. I don't care if it's a private repo that only you and your best friend has access to. No. Just no.

interface SecretConfig {
  readonly environment: 'development' | 'staging' | 'production';
  readonly region: string;
  readonly keyPrefix: string;
}

class SecretManager {
  private readonly secretsClient: AWS.SecretsManager;

  async getSecret(secretName: string): Promise<string> {
    const fullSecretName = `${this.config.keyPrefix}/${this.config.environment}/${secretName}`;

    try {
      const result = await this.secretsClient.getSecretValue({
        SecretId: fullSecretName
      }).promise();

      if (!result.SecretString) {
        throw new Error('Secret value is empty');
      }

      return result.SecretString;
    } catch (error) {
      // Log the error, but don't expose secret paths
      // Because security through obscurity is bad,
      // but security through transparency is worse
      logger.error('Failed to retrieve secret', { 
        environment: this.config.environment 
      });
      throw new Error('Failed to retrieve secret');
    }
  }

  async rotateSecret(secretName: string): Promise<void> {
    // Rotate your keys more often than you rotate your tires
    // Implementation details here
  }
}

3. Logging: Your 3AM Detective Work Helper

When things go wrong (and they will), logs are like security cameras for your application. The difference between good logging and bad logging becomes painfully clear at 3AM when you're trying to figure out why money is disappearing from user accounts. Proper logging isn't just about dumping data - it's about telling a story that your sleep-deprived future self can understand. Every log entry should answer the who, what, when, where, and how of each critical operation, because when you're in crisis mode, you won't have time to play detective with vague log messages.

interface SecurityEvent {
  eventType: 'auth' | 'data_access' | 'modification' | 'deletion';
  severity: 'low' | 'medium' | 'high' | 'critical';
  userId: string;
  action: string;
  resource: string;
  metadata: Record<string, unknown>;
  timestamp: Date;
  ipAddress: string;
}

class SecurityLogger {
  async logSecurityEvent(event: SecurityEvent): Promise<void> {
    const enrichedEvent = this.enrichEventWithContext(event);

    await this.logstashClient.log(enrichedEvent);

    if (this.requiresImmedateAlert(enrichedEvent)) {
      await this.alertingService.triggerAlert({
        severity: enrichedEvent.severity,
        message: this.formatAlertMessage(enrichedEvent),
        data: enrichedEvent
      });
    }
  }

  private requiresImmedateAlert(event: SecurityEvent): boolean {
    const criticalPatterns = [
      event.severity === 'critical',
      event.eventType === 'deletion' && event.resource.includes('database'),
      event.action.includes('escalate_privileges'),
      this.isOutsideBusinessHours() && event.action.includes('admin'),
      // Because nobody with good intentions really needs admin access at 3AM
    ];

    return criticalPatterns.some(Boolean);
  }
}

4. Rate Limiting: Because Your API Isn't an All-You-Can-Eat Buffet

If someone's hitting your API faster than you can say "distributed denial of service," maybe they shouldn't be hitting it at all. Rate limiting is your API's immune system against both malicious attacks and poorly written client code. I've seen production servers brought to their knees not by sophisticated attacks, but by an intern's script stuck in an infinite loop. Think of rate limiting as your application's bouncer - it makes sure nobody's hogging the dance floor, and it can tell the difference between enthusiastic dancing and someone trying to start a riot.

interface RateLimitConfig {
  windowMs: number;
  maxRequests: number;
  keyGenerator: (req: Request) => string;
}

class RateLimiter {
  private readonly store: RedisStore;

  async checkRateLimit(key: string): Promise<RateLimitInfo> {
    const currentWindow = Math.floor(Date.now() / this.config.windowMs);
    const windowKey = `${key}:${currentWindow}`;

    const pipeline = this.store.pipeline();
    pipeline.incr(windowKey);
    pipeline.expire(windowKey, this.config.windowMs / 1000);

    const [requests] = await pipeline.exec();

    return {
      isAllowed: requests <= this.config.maxRequests,
      remaining: Math.max(0, this.config.maxRequests - requests),
      resetTime: (currentWindow + 1) * this.config.windowMs
    };
  }
}

// Usage example:
app.use(async (req, res, next) => {
  const limit = await rateLimiter.checkRateLimit(req.ip);
  if (!limit.isAllowed) {
    // Someone's being greedy
    return res.status(429).json({
      error: 'Too many requests',
      message: 'Take a break, have a coffee ☕'
    });
  }
  next();
});

5. Authentication: Because "Admin1234" Isn't a Valid Password

Authentication is more than just checking if a password matches - it's about maintaining the sanctity of your entire system. Modern authentication should handle session management, role-based access control, brute force protection, and secure password storage. The difference between good and bad authentication often becomes apparent only after a breach, when you're trying to explain to your users why their data is being sold on the dark web.

interface Session {
  id: string;
  userId: string;
  roles: string[];
  permissions: string[];
  expiresAt: Date;
  metadata: Record<string, unknown>;
}

class AuthManager {
  async validateSession(sessionId: string): Promise<Session> {
    const session = await this.sessionStore.get(sessionId);

    if (!session) {
      throw new UnauthorizedError('Nice try, but no');
    }

    if (new Date() > session.expiresAt) {
      await this.sessionStore.delete(sessionId);
      throw new UnauthorizedError('Time to log in again, friend');
    }

    return session;
  }

  private async validatePassword(password: string): Promise<boolean> {
    // If your password is in this list, we need to talk
    const commonPasswords = [
      'password123',
      'admin1234',
      'letmein',
      'qwerty'
    ];

    if (commonPasswords.includes(password.toLowerCase())) {
      throw new ValidationError('Please choose a password that took longer than 2 seconds to think up');
    }

    return true;
  }
}

6. Encryption: Where "It's Fine in Plaintext" Goes to Die

If you're storing sensitive data in plaintext, we need to have a serious conversation about life choices. Proper encryption is your last line of defense when all other security measures fail. Think of it as your application's panic room; even if the bad guys get in, they still can't access what matters most. The key (pun intended) is doing it right: using strong algorithms, proper key management, and understanding that "security through obscurity" is not encryption.

class EncryptionService {
  private readonly algorithm = 'aes-256-gcm';

  async encrypt(data: string): Promise<EncryptedData> {
    const iv = crypto.randomBytes(12);
    const salt = crypto.randomBytes(16);
    const key = await this.deriveKey(this.masterKey, salt);

    const cipher = crypto.createCipheriv(this.algorithm, key, iv);
    const encrypted = Buffer.concat([
      cipher.update(data, 'utf8'),
      cipher.final()
    ]);

    const tag = cipher.getAuthTag();

    return {
      encrypted: encrypted.toString('base64'),
      iv: iv.toString('base64'),
      tag: tag.toString('base64'),
      salt: salt.toString('base64')
    };
  }

  // Because one day, quantum computers will make us regret weak encryption
  private async deriveKey(masterKey: string, salt: Buffer): Promise<Buffer> {
    return new Promise((resolve, reject) => {
      crypto.pbkdf2(masterKey, salt, 100000, 32, 'sha256', (err, key) => {
        if (err) reject(err);
        resolve(key);
      });
    });
  }
}

7. Proper Error Handling: Keep Your Secrets Secret

Nothing says "please hack me" quite like a stack trace in production.

class ErrorHandler {
  handleError(error: Error, req: Request, res: Response): void {
    // Log the full error for debugging
    logger.error('Internal error', {
      error: error.stack,
      requestId: req.id,
      userId: req.user?.id
    });

    // But send a sanitized version to the client
    // Because they don't need to know our life story
    res.status(500).json({
      error: 'Something went wrong',
      requestId: req.id,
      // Give them just enough to file a support ticket
      // But not enough to exploit anything
    });
  }
}

8. Monitoring: Because Nobody Wants a 3AM Surprise

Good monitoring is like having security cameras, motion sensors, and a team of guards all watching your application 24/7. It's not just about collecting metrics. It's about understanding what's normal for your system and being able to spot when something's off. The goal is to be alerted about potential issues before they become actual problems, and before your users start tweeting about how your service is down. If something moves in your system, you should know about it.

class SystemMonitor {
  async checkSystemHealth(): Promise<HealthStatus> {
    const checks = await Promise.all([
      this.checkDatabaseConnections(),
      this.checkApiLatency(),
      this.checkErrorRates(),
      this.checkMemoryUsage(),
      // The more paranoid, the better
    ]);

    return {
      status: checks.every(c => c.healthy) ? 'healthy' : 'unhealthy',
      checks,
      lastChecked: new Date(),
      message: "All systems operational (until they're not)"
    };
  }

  private async alertOnAnomaly(metric: string, value: number): Promise<void> {
    if (this.isAnomalous(metric, value)) {
      await this.notificationService.alert({
        title: 'Anomaly Detected',
        message: `Metric ${metric} is acting sus`,
        priority: 'high',
        actionRequired: true
      });
    }
  }
}

9. Dependency Management: Your Supply Chain Is Only as Strong as Its Weakest npm Package

Remember that time you npm installed half the internet to use one function? Each of those dependencies is a potential security nightmare waiting to happen. One compromised package, and suddenly your secure application is about as trustworthy as a phishing email.

class DependencyManager {  
  private readonly allowList: string[] = [  
    'trusted-package',  
    'verified-module'  
  ];  

  private readonly blockList: string[] = [  
    'definitely-not-malware',  
    'crypto-miner-utils'  
  ];  

  async auditDependencies(): Promise<AuditResult> {  
    const dependencies = await this.getAllDependencies();  
    const vulnerabilities: Vulnerability[] = [];  

    for (const dep of dependencies) {  
      // Check against known vulnerability databases  
      const npmAudit = await this.checkNpmVulnerabilities(dep);  
      const snykReport = await this.checkSnykVulnerabilities(dep);  
       
      // Check for suspicious behavior  
      const suspicious = this.checkSuspiciousPatterns(dep);  
       
      if (npmAudit.length || snykReport.length || suspicious) {  
        vulnerabilities.push({  
          package: dep,  
          issues: [...npmAudit, ...snykReport, ...suspicious],  
          severity: this.calculateSeverity(npmAudit, snykReport, suspicious)  
        });  
      }  
    }  

    return {  
      vulnerabilities,  
      summary: this.generateAuditSummary(vulnerabilities),  
      recommendations: this.generateRemediation(vulnerabilities)  
    };  
  }  

  private checkSuspiciousPatterns(dependency: Package): SuspiciousPattern[] {  
    const patterns = [  
      this.hasObfuscatedCode(dependency),  
      this.checksForDebugger(dependency),  
      this.makesUnexpectedNetworkCalls(dependency),  
      this.accessesSensitiveAPIs(dependency)  
    ];  

    return patterns.filter(Boolean);  
  }  
}

10. Incident Response: Because Hope Is Not a Strategy

Having a solid incident response plan is like having insurance - you hope you never need it, but you'll be really glad you have it when things go wrong. And in security, things will go wrong. Here's a practical example:

### The "Oh No" Plan: A Practical Guide to Not Panicking  

#### Level 1: Something's Fishy  
- Suspicious login attempts
- Weird API usage patterns  
- That gut feeling something's off  

**Action Plan:**  
1. Enhanced logging mode: ON
2. Block suspicious IPs/users  
3. Wake up the on-call engineer (sorry)  
4. Start documenting everything  

#### Level 2: We Have a Problem 
- Successful unauthorized access  
- Failed deployment flood  
- Service degradation  
- Money moving at 3AM  

**Action Plan:**  
1. Lock down admin access  
2. Freeze suspicious transactions  
3. Wake up the security team  
4. Start incident response channel  
5. Pull recent logs and backups  

#### Level 3: All Hands on Deck 🚨  
- Active financial theft  
- System compromise  
- Data breach in progress  
- Complete service outage  

**Action Plan:**  
1. Pull the emergency brake  
   - Freeze ALL transactions  
   - Revoke ALL access tokens  
   - Lock ALL admin accounts  
2. Wake up EVERYONE  
   - Security team  
   - Engineering leads  
   - CEO (yes, really)  
3. Document EVERYTHING  
   - Screenshots  
   - Log entries  
   - System states  
4. Start recovery  
   - Deploy backup systems  
   - Rotate ALL credentials  
   - Enable forensic logging  

### The Communication Playbook  

#### Internal:  
- Use secure channels only  
- No sensitive info in public workspace  
- Document decisions as they happen  
- Keep a timeline of events  

#### External:  
- Single spokesperson only  
- No tweets about the incident  
- Prepared statements only  
- Legal review required  

### Post-Incident Checklist  

1. **What Happened**  
   - Timeline of events  
   - Systems affected  
   - Data compromised  
   - Attack vector  

2. **What We Did**  
   - Actions taken  
   - Effectiveness  
   - Response time  
   - Resources used  

3. **What We Learned**  
   - Security gaps  
   - Process failures  
   - Tool inadequacies  
   - Training needs  

4. **What We're Changing**  
   - New controls  
   - Updated procedures  
   - Additional monitoring  
   - Team training

The Bottom Line: Security Is Not a Feature, It's a Mindset

Security isn't just a checkbox on your deployment checklist. It's not something you can just sprinkle on top of your application like debugging console.logs. It needs to be baked into every line of code you write, every system you design, and every process you implement.

Each of these practices serves a crucial purpose:

Input validation prevents injection attacks and data corruption
Key management protects your crown jewels from exposure
Logging gives you the breadcrumbs to track down issues
Rate limiting protects your resources from abuse
Authentication ensures only the right people have access
Encryption keeps your sensitive data secure even if other measures fail
Error handling prevents information leakage
Monitoring helps you catch issues before they become incidents
Dependency management prevents supply chain attacks
Incident response helps you handle the inevitable with grace

Because trust me, explaining to your CEO at 3AM why all the company's money is now buying someone a yacht in Hawaii is not a conversation you want to have.

Remember:

Validate everything like your paranoid aunt checking expiry dates at the grocery store
Encrypt always, because what's safely encrypted today might still be safely encrypted when quantum computers arrive
Log extensively, because future you will thank past you for the detailed logs
Monitor religiously, because the alternative is finding out about problems from your users
Manage your dependencies like you're checking ingredients for allergens
Have an incident response plan that doesn't start with "panic"
And for the love of all things holy, keep your API keys out of GitHub

Stay vigilant, folks. The hackers aren't sleeping, but that doesn't mean you have to lose sleep too.

P.S. If you're reading this because you're currently dealing with a security incident, STOP READING AND GO FIX IT! This article will still be here after you've contained the breach.

Cloud Buzzwords every Software Engineer needs to know

Alexin — Sun, 14 Jul 2024 22:23:48 +0000

In 2024, "Cloud" is a big thing. It's a fancy word. Developers everywhere are buzzing about it, feeling like it's a badge of honor to be involved with cloud technology. But what exactly is all the hype about? Why is "Cloud" so special? What even is "Cloud"? And why does everyone keep mentioning EC2 instances?

Cloud Engineering is very important in today's tech space. As more companies move their servers to cloud-based infrastructure, having a solid grasp of these concepts is critical for any software engineer looking to stay relevant and competitive in the field. In this article, we'll break down key cloud computing terms and concepts every software engineer should know. From basic cloud principles to advanced topics like containerization and infrastructure as code, this guide aims to provide a comprehensive understanding of essential cloud technologies.

What is cloud computing?

Cloud computing refers to the delivery of computing services—such as servers, storage, databases, networking, software, and more—over the internet ("the cloud"). This essentially means that companies no longer need massive data centers and on-premises servers to manage their operations. Instead, they can "rent" these services from other companies, known as cloud providers.

The cloud's fast growth is driven by its flexibility, cost efficiency, and the ability to innovate without being bogged down by infrastructure worries. Instead of making large upfront investments in infrastructure (databases, storage, software, and hardware), companies can choose to utilize their computing power over the internet—the cloud—and pay based on usage.

Companies pay cloud engineers to manage their infrastructure in the cloud, just like they paid IT administrators to manage their infrastructure on premises in traditional setups. Cloud engineers oversee the deployment, maintenance, and security of applications and services hosted on cloud platforms.

Cloud Service Models

Cloud service models categorize the types of services provided by cloud computing providers, offering different levels of control, management, and responsibility over computing resources. Here are the main cloud service models:

Infrastructure as a Service (IaaS):
IaaS provides virtualized computing resources over the internet. Users manage the operating systems, applications, and data hosted on these virtual resources, while the cloud provider maintains the physical hardware and underlying infrastructure. A well-known IaaS platform is Amazon Web Services Elastic Compute Cloud (AWS EC2).
Platform as a Service (PaaS):
PaaS offers a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the underlying infrastructure. It typically includes tools for application development, testing, deployment, and hosting. PaaS is well-suited for developers focusing on application development rather than managing hardware and software infrastructure. Commonly used examples include Heroku, Vercel and Render.
Software as a Service (SaaS):
Software as a Service (SaaS) applications are software solutions hosted and maintained by third-party providers, accessible over the internet via web browsers. Users subscribe to SaaS applications on a recurring basis, which includes updates and support. SaaS applications are highly customizable within predefined configurations and integrate seamlessly with other applications through APIs. Software engineers are often most familiar with SaaS due to its prevalence across various tools and platforms they use daily, from collaboration tools like Slack to enterprise solutions like Salesforce CRM.

Containerization, Virtualization, and Orchestration in Cloud Computing

These three terms are distinct but interrelated when it comes to cloud computing. These technologies play critical roles in optimizing resource usage, enhancing application portability and scalability, and automating complex operational tasks.

Virtualization

This is the process of creating virtual versions of computing resources such as servers, storage, and networks. Virtual Machines (VMs) are software-based simulations of physical computers. They allow multiple operating systems (OS) to run simultaneously on a single physical machine, known as the host machine. Each VM operates independently, with its own virtualized hardware resources, including CPU, memory, storage, and network interfaces. IaaS providers like Amazon EC2 utilize virtualization to provide resizable compute capacity in the cloud. AWS uses a hypervisor, a software layer that abstracts physical hardware and enables multiple VMs (instances) to run on a single physical server. The hypervisor manages and allocates hardware resources to EC2 instances, ensuring efficient use of underlying physical infrastructure.

Containerization

Containerization goes a step further than virtualization by packaging applications and their dependencies into containers. Containers encapsulate everything needed to run an application, including code, runtime, libraries, and settings. Docker, a leading container platform, allows developers to build, ship, and run applications consistently across different environments. Containers are lightweight, portable, and provide a standardized way to deploy applications, making them ideal for cloud environments where scalability and agility are crucial.

Differences Between Containers and Virtual Machines

Abstraction Level:
- Virtual Machines (VMs): VMs emulate physical hardware, including a full OS, on a host machine using a hypervisor. Each VM runs its own guest OS, which consumes more resources and takes longer to start compared to containers.
- Containers: Containers abstract at the application level, packaging applications and their dependencies into isolated units. They share the host OS kernel and resources, making them more lightweight and efficient than VMs.
Resource Utilization:
- Virtual Machines: VMs allocate dedicated resources (CPU, memory, storage) to each instance, regardless of actual usage, which can lead to underutilization of resources.
- Containers: Containers only allocate resources as needed, leading to better resource utilization and higher density of applications per host.
Portability and Deployment:
- Virtual Machines: VMs are less portable because they include a full guest OS, making them larger in size and more complex to move between environments.
- Containers: Containers are highly portable due to their lightweight nature. They encapsulate everything needed to run an application, ensuring consistency across different environments from development to production.

Orchestration

Orchestration in cloud computing, particularly with tools like Kubernetes (K8s), automates the management of containerized applications across multiple servers (nodes). It handles tasks such as deployment, scaling, and monitoring, ensuring applications run efficiently and reliably. Think of it as a system that coordinates and optimizes how your software operates in the cloud, simplifying complex processes like scaling up during traffic spikes or ensuring consistent performance across different environments.

Cloud Deployment Models

1. Public Cloud

Public clouds are operated by third-party providers and offer computing resources and services over the internet. They are accessible to anyone who wants to use or purchase them. Examples include:

Amazon Web Services (AWS): AWS provides a wide range of cloud services globally, including computing power, storage options, and databases.
Microsoft Azure: Azure offers services for computing, analytics, and networking, widely used by enterprises and developers worldwide.
Google Cloud Platform (GCP): GCP provides cloud computing services with a focus on data analytics and machine learning.

Public clouds are ideal for startups, small businesses, and large enterprises that need scalable infrastructure without upfront investment in hardware.

2. Private Cloud

Private clouds are dedicated to a single organization and are hosted either internally or by a third-party provider. Examples include:

VMware Cloud: VMware offers private cloud solutions that businesses can deploy in their own data centers or through VMware's infrastructure partners.
OpenStack: An open-source platform that enables organizations to build and manage private clouds.

Private clouds are preferred by organizations with stringent security and compliance requirements, such as financial institutions and government agencies.

3. Hybrid Cloud

Hybrid clouds integrate private and public cloud environments, allowing data and applications to be shared between them. Examples include:

AWS Outposts: AWS Outposts extend AWS infrastructure, services, APIs, and tools to virtually any datacenter, co-location space, or on-premises facility.
Azure Stack: Microsoft Azure Stack extends Azure services and capabilities to on-premises environments.

Hybrid clouds are suitable for businesses that want the flexibility to run certain workloads on-premises while leveraging the scalability of the public cloud for other applications.

4. Multi-cloud

Multi-cloud involves using services from multiple public cloud providers, avoiding dependence on a single vendor. Multi-cloud strategies are adopted by organizations seeking to avoid vendor lock-in, optimize costs, and leverage specific strengths of different cloud providers for different parts of their infrastructure.

Serverless Computing

Serverless computing is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers. In simpler terms, it allows developers to run code without having to manage the underlying infrastructure.

Why Use Serverless Computing?

Serverless computing offers several benefits:

Scalability: Applications automatically scale with demand. You don't have to worry about provisioning servers or managing scaling policies.
Cost Efficiency: You pay only for the actual compute time used, rather than paying for idle servers. This can lead to significant cost savings, especially for applications with variable workloads.
Reduced Operational Complexity: Developers can focus more on writing code and less on managing infrastructure.

Serverless Computing Tools

AWS Lambda: Allows you to run code in response to events without provisioning or managing servers. It supports a variety of programming languages and integrates seamlessly with other AWS services.
Azure Functions: Provides serverless compute to run event-triggered code without managing infrastructure. It supports multiple programming languages and integrates well with Azure services.
Google Cloud Functions: Similar to AWS Lambda and Azure Functions, it allows you to run event-driven functions in a serverless environment.

Infrastructure as Code (IaC)

Infrastructure as Code (IaC) refers to the practice of managing and provisioning computing infrastructure (such as servers, databases, networks, and storage) through machine-readable script files, rather than physical hardware configuration or interactive configuration tools. This means that instead of manually configuring servers and infrastructure components, developers and operations teams use code to automate the provisioning, configuration, and management of infrastructure resources. Here are some popular IaC tools:

Terraform: A widely adopted tool that allows you to define and provision infrastructure using a declarative configuration language. It supports multiple cloud providers and on-premises environments.
Ansible: Ansible automates configuration management, application deployment, and task automation across multiple nodes.
AWS CloudFormation: Specifically designed for AWS, CloudFormation enables you to model and set up your AWS resources as code. It supports a wide range of AWS services and integrates well with other AWS offerings.

Benefits of IaC tools include:

IaC enables automation of infrastructure management tasks, reducing human error and ensuring consistency across environments.
It facilitates the rapid deployment and scaling of infrastructure resources, allowing organizations to respond quickly to changing demands.
Version Control: Infrastructure configurations are versioned alongside application code, providing a clear audit trail and enabling rollback to previous states if needed.
Collaboration: Teams can collaborate more effectively by sharing and iterating on infrastructure code, enhancing productivity and reducing deployment bottlenecks.

Conclusion

In 2024, "Cloud" has become more than just a buzzword—it's a fundamental shift in how we build and manage technology. From understanding what "Cloud" actually means to diving into advanced topics like containerization and infrastructure as code, you've embarked on a journey to demystify these crucial concepts. Now, when someone mentions EC2 instances or Kubernetes, you'll nod knowingly rather than feeling left out of the conversation.

If you're eager to dive deeper into cloud engineering, there are plenty of resources to help you get started. Online platforms like Coursera, Udemy, and Pluralsight offer courses ranging from beginner to advanced levels. Additionally, certifications from AWS, Microsoft Azure, and Google Cloud can provide valuable credentials to showcase your expertise. Hands-on experience through personal projects or joining a cloud engineering program can also accelerate your learning journey. Thank you for reading!

Why Appwrite Is Your Ideal BaaS in 2024

Alexin — Wed, 03 Jul 2024 19:00:00 +0000

In the competitive world of Software as a Service (SaaS) products, speed to market can make or break your startup. You're racing against time to build, test, and deploy your application before your competitors do. However, building or integrating various backend services eats up valuable development hours and resources. What if there was a way to handle all your backend needs with a single, cohesive platform? This is where Appwrite comes in. Appwrite enables entrepreneurs to focus on what truly matters – building and scaling their product. In this article, you'll learn about Appwrite's history, features, and why it's the best choice for any entrepreneur building to scale in 2024.

What is Appwrite?

Appwrite is a comprehensive Backend as a Service (BaaS) platform designed to help developers build and scale applications quickly and efficiently. Whether you're a solo indie hacker or part of a growing startup, Appwrite provides the essential features you need—database management, authentication, storage, and cloud functions—all in one unified platform.

Appwrite was founded in 2019 by Eldad Fux, a software engineer and entrepreneur. The initial vision was to create an open-source platform that simplifies backend development, making it more accessible and efficient for developers of all skill levels. Eldad noticed that many developers struggled with setting up and managing backend services, often juggling multiple tools and services to meet their needs. He envisioned Appwrite as an all-in-one solution that would streamline this process, enabling developers to focus on building their applications rather than dealing with the complexities of backend development.

Key Features

Appwrite's main selling point is its comprehensive suite of backend services. Here is a list of its features:

Authentication: Think about the time and effort it takes to set up a secure and flexible authentication system for your users. Appwrite simplifies this process by providing built-in support for multiple authentication methods, including email/password, Magic URL, JWT, OAuth providers (like Google, Facebook, and GitHub), and even anonymous login. This means you can offer your users a variety of login options, enhancing their experience while ensuring security.
But Appwrite doesn't stop there. It also supports two-factor authentication (2FA) and robust session management, giving your users an extra layer of security and allowing them to maintain their login status across sessions and devices. Whether you're building a social app that needs social logins or an enterprise solution requiring strict access controls, Appwrite has you covered.
Database Management: Appwrite simplifies database management for developers by offering robust support for both SQL and NoSQL databases within a unified platform. Whether you're launching a new startup or scaling an existing SaaS application, Appwrite allows you to effortlessly create and manage databases, collections, and documents. This means you can focus more on crafting innovative features for your application and less on the complexities of backend infrastructure. With Appwrite, scaling your database to accommodate growing user bases and increasing data volumes becomes seamless, ensuring your application maintains high performance and reliability as it evolves.
File Storage: Appwrite simplifies file storage and management by seamlessly integrating with Content Delivery Networks (CDNs). Whether you're dealing with images, videos, or documents, Appwrite ensures that your multimedia content is securely stored and efficiently delivered to users worldwide. This CDN integration not only enhances the speed and reliability of content delivery but also reduces latency, improving the overall user experience. For SaaS applications that heavily rely on multimedia content, Appwrite's scalable file storage capabilities ensure efficient content management and delivery without concerns about storage limitations or performance bottlenecks.
Serverless Functions: Serverless functions are a cloud computing execution model that allows developers to run code without having to manage their own servers. These functions are typically small, stateless pieces of code that are triggered by specific events, such as HTTP requests, database changes or file uploads. Appwrite gives developers the power of serverless computing, freeing them from server management to focus on writing business logic. On Appwrite, serverless functions can be triggered by different events like database changes and HTTP requests, enabling the creation of responsive and scalable applications.

Why choose Appwrite?

Choosing the right backend-as-a-service (BaaS) platform is crucial for the success of your SaaS application. Here’s a direct comparison of Appwrite with other popular BaaS platforms like Firebase and AWS Amplify, highlighting their unique strengths and ideal use cases. By examining these comparisons, you can make an informed decision on the best BaaS solution for your project.

Feature/Platform	Appwrite	Firebase	AWS Amplify
Platform Focus	Unified platform for essential backend services: database, authentication, file storage, serverless functions	Real-time database capabilities and Google services integration	Comprehensive cloud services integration with AWS, including AI/ML and IoT support
Development Approach	Simplifies development with a cohesive approach, reducing multiple service integrations	Excels in real-time synchronization, mobile development	Suitable for enterprise-level applications needing extensive scalability and complex cloud integrations
Ideal Use Cases	Applications needing robust multimedia content management and scalable serverless architectures	Applications requiring extensive real-time synchronization and mobile development	Enterprise-level applications needing extensive scalability and complex cloud integrations

Setting Up Appwrite in Your Application

To demonstrate the power and ease of using Appwrite, this article will take you through the process of setting up Appwrite for a web application built in React.

Prerequisites

Make sure you have the following:

Node.js and npm installed on your machine.
Basic knowledge of React.js.

Step 1: Setting Up Appwrite via Browser

Access the Appwrite Console:
- Open your web browser and navigate to Appwrite Console.
- If you don't have an account, sign up for free. Otherwise, log in to your existing account.
Create a New Project:
- Once logged in, click on "Projects" in the sidebar.
- Click the "Create a New Project" button.
- Enter a name for your project (e.g., "Appwrite Demo Project") and optionally a description.
- Click "Create Project" to proceed.
Get Your Project ID and API Keys:
- After creating your project, click on its name to enter the project dashboard.
- Take note of your Project ID, which you will need to configure the Appwrite SDK in your application later.
- Navigate to the API Keys tab under Project Settings.
- Create a new API key with appropriate permissions (e.g., full access for demo purposes).
- Copy the API key value securely. You will use this in your application to authenticate API requests.

Step 2: Create a New React Project

To create a new React.js project, run this in your terminal:



$ npx create-react-app appwrite-demo
$ cd appwrite-demo

Step 3: Install Appwrite SDK

To interact with Appwrite from your React application, you need to install the Appwrite SDK. Run the following command:



$ npm install appwrite

Step 4: Initialize Appwrite in Your React App

Open your src/App.js file and initialize the Appwrite client:



import React, { useEffect } from 'react';
import { createClient } from 'appwrite';

function App() {
  useEffect(() => {
    const client = createClient({
      endpoint: '<https://appwrite.io/v1>', // Replace with your Appwrite Endpoint
      project: 'YOUR_PROJECT_ID', // Replace with your Project ID
      apiKey: 'YOUR_API_KEY', // Replace with your API Key
    });

    // Example: Create a new user
    client.account.create('user@example.com', 'password', 'username')
      .then(response => {
        console.log('User created:', response);
      })
      .catch(error => {
        console.error('Error creating user:', error);
      });
  }, []);

  return (
    <div className="App">
      <h1>Welcome to Appwrite Demo</h1>
    </div>
  );
}

export default App;

Step 5: Run Your React App

Finally, start your React application by running:



$ npm start

Open your browser and navigate to http://localhost:3000 to see your application in action. You should see the message "Welcome to Appwrite Demo" and, in your console, a response indicating the creation of a new user.

Conclusion

As we’ve explored, Appwrite stands out as an ideal backend solution for SaaS startups in 2024 due to its comprehensive platform that simplifies backend development. By offering essential services like database management, authentication, file storage, and serverless functions in one cohesive package, Appwrite eliminates the need for multiple service integrations, saving valuable development time and resources. Its open-source nature, robust security features, and scalability make it a reliable choice for both indie hackers and growing startups. With Appwrite, developers can focus on what truly matters: building and scaling their applications to meet market demands swiftly and efficiently. Thanks for reading!

Automating User and Group Management with a Bash Script in Linux

Alexin — Mon, 01 Jul 2024 14:32:16 +0000

In the fast-paced world of DevOps Engineering, automation is key to efficiency and reliability. Managing user accounts and groups manually can be a stressful, time-consuming, and error-prone task, especially in environments with numerous users. Recognizing this challenge, the HNG Internship provided a practical task that simulates a real-world scenario, where interns are required to automate user and group management on a Linux system.
The task is to create a Bash script that automates the creation of users and groups, securely manages passwords, and logs all actions performed. This exercise not only enhances scripting skills but also deepens the understanding of Linux system administration.

Task

Your company has employed many new developers. As a SysOps engineer, write a bash script called create_users.sh that reads a text file containing the employee’s usernames and group names, where each line is formatted as user;groups.
The script should create users and groups as specified, set up home directories with appropriate permissions and ownership, generate random passwords for the users, and log all actions to /var/log/user_management.log. Additionally, store the generated passwords securely in /var/secure/user_passwords.txt.
Ensure error handling for scenarios like existing users and provide clear documentation and comments within the script.

Requirements:

Each User must have a personal group with the same group name as the username, this group name will not be written in the text file.
A user can have multiple groups, each group delimited by comma ","
Usernames and user groups are separated by semicolon ";"- Ignore whitespace e.g.

   light; sudo,dev,www-data
   idimma; sudo
   mayowa; dev,www-data

For the first line, light is username and groups are sudo, dev, www-data.

My solution

To tackle this problem, I first broke down the requirements stated into clear, actionable steps:

Read Input File:
- Read the text file containing the employee’s usernames and group names.
- Each line is formatted as user;groups.
Process Each Line:
- Split each line into the username and the corresponding groups.
- Remove any whitespace for accurate processing.
Create Users and Groups:
- Ensure each user has a personal group with the same name as their username.
- Create additional groups if they do not already exist.
- Add the user to the specified groups.
Set Up Home Directories:
- Create home directories for each user.
- Set appropriate permissions and ownership for the directories.
Generate and Store Passwords:
- Generate random passwords for each user.
- Securely store the passwords in /var/secure/user_passwords.txt.
Log Actions:
- Log all actions performed (e.g., user creation, group assignment) to /var/log/user_management.log.
Error Handling:
- Implement error handling to manage scenarios like existing users or groups.

From this list of requirements, I mapped out a clear plan to solve the problem. These are the steps I followed:

Create folders for logs and secure passwords, but do nothing if they already exist.
```
mkdir -p /var/log /var/secure
```

Create files for logs and password storage.

touch /var/log/user_management.log
touch /var/secure/user_passwords.txt

Make the password file secure, giving it read and write permission for the file owner only.
```
chmod 600 /var/secure/user_passwords.txt
```

Define a function that logs actions performed by the script to the log file.

log_action() {
echo "$(date) - $1" >> "/var/log/user_management.log"
}

Create a function that handles user creation. This function does the following:

Checks if the user already exists by calling the id command and redirecting the output to /dev/null. If the user exists, it logs a message and returns.
Creates a personal group for the user using the groupadd command.
Creates the additional groups if they do not exist.
Creates the user with the useradd command, setting the home directory, shell, and primary group.
Logs a message indicating the success or failure of the useradd command.
Adds the user to the other groups using the usermod command.
Generates a random password for the user using /dev/urandom and stores the user and their respective password in /var/secure/user_passwords.txt, the secure password file.
Sets the permissions and ownership for the user's home directory.

Here is the source code:

create_user() {

# defines 3 variables passed to the function: user, groups, and password
local user="$1"
local groups="$2"
local password

# check if user already exists by logging user information with id

if id "$user" &>/dev/null; then
    log_action "User $user already exists."
    return
fi

# Create personal group for the user
groupadd "$user"

# Create additional groups if they do not exist
IFS=' ' read -ra group_array <<< "$groups"

# Log the group array
log_action "User $user will be added to groups: ${group_array[*]}"

for group in "${group_array[@]}"; do
    group=$(echo "$group" | xargs)  # Trim whitespace
    if ! getent group "$group" &>/dev/null; then
        groupadd "$group"
        log_action "Group $group created."
    fi
done

# Create user with home directory and shell, primary group set to the personal group
useradd -m -s /bin/bash -g "$user" "$user"
if [ $? -eq 0 ]; then
    log_action "User $user created with primary group: $user"
else
    log_action "Failed to create user $user."
    return
fi

# Add the user to additional groups
for group in "${group_array[@]}"; do
    usermod -aG "$group" "$user"
done
log_action "User $user added to groups: ${group_array[*]}"

# generate password and store it securely in a file
password=$(</dev/urandom tr -dc A-Za-z0-9 | head -c 12)
echo "$user:$password" | chpasswd

# store user and password securely in a file
echo "$user,$password" >> "/var/secure/user_passwords.txt"

# set permissions and ownership for user home directory
chmod 700 "/home/$user"
chown "$user:$user" "/home/$user"

log_action "Password for user $user set and stored securely."
}

In the main script, check if the list of users was provided in the script's arguments.
```
if [ $# -ne 1 ]; then
echo "Usage: $0 <user_list_file>"
exit 1
fi
```

If it was provided, check that it is a valid file:

filename="$1"
if [ ! -f "$filename" ]; then
echo "Users list file $filename not found."
exit 1
fi

Read the file line-by-line, extract the user and groups from each line, and call the create_user function passing the user and groups as an argument:
```
filename="$1"
if [ ! -f "$filename" ]; then
echo "Users list file $filename not found."
exit 1
fi
```

Here is the complete code file:

#!/bin/bash

# create folders for logs and secure passwords
mkdir -p /var/log /var/secure

# create logs file and passwords file
touch /var/log/user_management.log
touch /var/secure/user_passwords.txt

# make password file secure (read and write permissions for file owner only)

chmod 600 /var/secure/user_passwords.txt

# function to log actions to log file
log_action() {
    echo "$(date) - $1" >> "/var/log/user_management.log"
}


create_user() {

    # defines 3 variables passed to the function: user, groups, and password
    local user="$1"
    local groups="$2"
    local password

    # check if user already exists by logging user information with id

    if id "$user" &>/dev/null; then
        log_action "User $user already exists."
        return
    fi

    # Create personal group for the user
    groupadd "$user"

    # Create additional groups if they do not exist
    IFS=' ' read -ra group_array <<< "$groups"

    # Log the group array
    log_action "User $user will be added to groups: ${group_array[*]}"

    for group in "${group_array[@]}"; do
        group=$(echo "$group" | xargs)  # Trim whitespace
        if ! getent group "$group" &>/dev/null; then
            groupadd "$group"
            log_action "Group $group created."
        fi
    done

    # Create user with home directory and shell, primary group set to the personal group
    useradd -m -s /bin/bash -g "$user" "$user"
    if [ $? -eq 0 ]; then
        log_action "User $user created with primary group: $user"
    else
        log_action "Failed to create user $user."
        return
    fi

    # Add the user to additional groups
    for group in "${group_array[@]}"; do
        usermod -aG "$group" "$user"
    done
    log_action "User $user added to groups: ${group_array[*]}"

    # generate password and store it securely in a file
    password=$(</dev/urandom tr -dc A-Za-z0-9 | head -c 12)
    echo "$user:$password" | chpasswd

    # store user and password securely in a file
    echo "$user,$password" >> "/var/secure/user_passwords.txt"

    # set permissions and ownership for user home directory
    chmod 700 "/home/$user"
    chown "$user:$user" "/home/$user"

    log_action "Password for user $user set and stored securely."
}

# check if user list file is provided
if [ $# -ne 1 ]; then
    echo "Usage: $0 <user_list_file>"
    exit 1
fi

filename="$1"

if [ ! -f "$filename" ]; then
    echo "Users list file $filename not found."
    exit 1
fi

# read user list file and create users
while IFS=';' read -r user groups; do
    user=$(echo "$user" | xargs)
    groups=$(echo "$groups" | xargs | tr -d ' ')

    # Replace commas with spaces for usermod group format
    groups=$(echo "$groups" | tr ',' ' ')
    create_user "$user" "$groups"
done < "$filename"

echo "User creation process completed. Check /var/log/user_management.log for details."

The create_users.sh bash script has successfully automated user and group management on a Linux system. It reads a text file containing employee usernames and group names, creates users and groups as specified, sets up home directories with appropriate permissions and ownership, generates random passwords for the users, and logs all actions to /var/log/user_management.log. Additionally, it securely stores the generated passwords in /var/secure/user_passwords.txt. Thanks for reading!

How to Containerize Your Backend Applications Using Docker

Alexin — Mon, 01 Jul 2024 07:00:00 +0000

Imagine you have spent months meticulously building a backend application. It handles user requests flawlessly, scales beautifully, and is ready to take your product to the next level. But then comes deployment dread. Different environments, dependency conflicts, and a looming fear of something breaking - all potential roadblocks on your path to launch.

Docker solves these problems and gives you a cleaner, more efficient way to package, deploy, and scale your applications. This article will guide you through the process of containerizing your backend application and deploying it to an EC2 instance on Amazon Web Services (AWS).

What is Docker?

Assume you have a perfect pie recipe, complete with ingredients and instructions, and you bake it using an oven set to 190 degrees Celsius. When your friend tries to bake the same pie using only a microwave that goes up to 140 degrees, it doesn't turn out as expected. You can solve this problem by providing not just the ingredients and recipe, but also the exact oven, kitchen setup, and tools you used. This way, your friend can recreate the exact same pie, regardless of their own kitchen's limitations.

Similarly, Docker is a tool that helps developers package an application and all its parts—like code, libraries, and system settings—into a "container". This container can run on any computer, making sure the application works the same everywhere. Docker also lets you move these containers around easily, so you can run your app on any computer or even in the cloud without any fuss. And since containers are lightweight, you can spin up as many as you need without hogging too much space or resources. Overall, Docker makes developing and running software smoother, more consistent, and less of a headache.

How Does Docker Work?

In simple terms, Docker works by creating containers, which are like virtual machines but much lighter. These containers package up all the code and dependencies needed to run an application, including libraries, system tools, and settings. Docker then runs these containers on any computer, making sure the application runs the same everywhere. It's like having a portable box that contains everything your app needs, so you can easily move it around and run it on any computer without any extra setup.

Getting Started With Docker

This article will refer to a Node.js application built with NestJS as an example. To follow along, you'll need a few things:

A Linux Environment: Linux operating system or a virtual machine running Linux is preferred. If you primarily work with Windows, you can download the Windows Subsystem for Linux (WSL). If you use MacOS, that also works fine.
Docker installed: Download and install Docker Desktop for your operating system from the official Docker website.
Node.js and npm: Ensure you have Node.js and npm (Node Package Manager) installed on your machine. You can verify this by running node -v and npm -v in your terminal. If not installed, download them from the official Node.js website.
A basic NestJS Application: I will be working with a project called "Dorm Haven". I will assume you have a NestJS application set up. If you do not have one, you can clone A NestJS project from my GitHub account.
Having an account on Docker Hub: Sign up for a Docker Hub account at Docker Hub if you don't already have one. This will be necessary for pushing your Docker images to a remote repository.
Having an AWS Account: Sign up for an AWS account at AWS if you don't already have one. This will be necessary for deploying your application to Amazon EC2.

Now that you have Docker, Node.js, npm, and a basic NestJS application ready, let's containerize your application and deploy it to an EC2 instance on AWS.

Setting up Docker on your application

Create a file and name it Dockerfile: Note that this file should have no extension. This is a text file that contains a set of instructions to build a Docker image. Each instruction in a Dockerfile defines a step in the process of setting up the environment Docker needs to run a specific application. Add the following code to the file:
```
FROM node:20.10.0-alpine
WORKDIR /usr/src/app
COPY . .
RUN npm install
RUN npm run build
ENV NODE_ENV production
EXPOSE 3000
CMD ["npm", "start"]
```
The code above does the following:
- FROM node:20.10.0-alpine: Sets the base image for the Docker container to the official Node.js Alpine Linux image.
- WORKDIR /usr/src/app: Changes the working directory to /usr/src/app.
- COPY . .: Copies the entire contents of the local directory to the container's working directory.
- RUN npm install: Installs NPM packages.
- RUN npm run build: Builds the Node.js application inside the container.
- ENV NODE_ENV production: Sets the NODE_ENV environment variable to production.
- EXPOSE 3000: Exposes port 3000, so the application can be accessed from outside the container.
- CMD ["npm", "start"]: Defines the command to start the application.
Build Your Docker Image: In the root directory of your project, run the following command to build your Docker image. Replace dorm-haven with the name of your application:
```
$ docker build -t dorm-haven .
```
This command tells Docker to build an image (a lightweight, standalone, executable package that includes everything one needs to run a piece of software) using the instructions in your Dockerfile and tag it with the name dorm-haven.
Run Your Docker Container: After building the image, you can run it as a container. Use the following command to start the container:
```
$ docker run -p 3000:3000 dorm-haven
```
This command maps port 3000 on your local machine to port 3000 in the Docker container, allowing you to access your application at http://localhost:3000.

Pushing the Docker Image to Docker Hub:

To deploy your application to an EC2 instance on AWS, you first need to push your Docker image to a Docker registry like Docker Hub. Follow these steps:

Tag your Docker image:

$ docker tag dorm-haven alexindevs/dorm-haven

Push the image to Docker Hub:

$ docker push alexindevs/dorm-haven

Now that you have your application containerized and ready for deployment, it's time to set up the EC2 instance on AWS.

Setting up the EC2 instance

Log in to your AWS Dashboard. You should see something similar to the screen below.
Click on the Services option on the navigation bar. Click on Compute, then select EC2.
You'll be redirected to the EC2 dashboard. There, click on Launch Instance.
Enter your server name, and choose an Amazon Machine Image. For this tutorial, I will be using Ubuntu.
Next, create a key pair. This will grant you SSH access to your server.
Enter a name and choose a key pair type. It is recommended to use the RSA encrypted .pem type.
Click on Launch Instance. This will redirect you to the dashboard shown below. You have successfully created an EC2 instance on AWS!

Accessing the EC2 instance through SSH

Now your repository is stored on the Docker Hub, and you have an EC2 instance. It is time to navigate to the EC2 instance and deploy your application.

Open your instance dashboard and click on Connect to Instance. Navigate to the SSH client tab.
On your terminal, locate your private key and change its permissions as described above. Then run the command. It will grant you access to your instance.
Switch to the super user using this command.
```
$ sudo su
```

Run the following commands to install and set up Docker on the instance.

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt install docker.io
$ systemctl start docker
$ systemctl enable docker

Check that Docker is running.
```
$ docker --version
```
Login to Docker. This will grant you access to your stored repositories.
```
$ docker login
```
Pull the uploaded image from the Docker Hub, and confirm that it was downloaded successfully.
```
$ docker pull alexindevs/dorm-haven
$ docker images
```
After pulling the image, run your Docker container. Map port 80 on your EC2 instance to port 3000 in the Docker container (or any other appropriate port based on your application - make sure to configure your instance to allow public requests on that port).
```
$ docker run -d -p 80:3000 alexindevs/dorm-haven
```
The -d flag runs the container in detached mode, which means it will run in the background.
Verify that your container is running using the following command:
```
docker ps
```

Additional Tips

Check Container Logs:
If you need to check the logs for your container to troubleshoot any issues, use:
```
docker logs <container-id>
```
Replace <container-id> with the actual container ID from the docker ps output.
Manage Containers:
To stop a running container:
```
docker stop <container-id>
```
To remove a stopped container:
```
docker rm <container-id>
```

Conclusion

In this article, we walked through the process of setting up Docker, creating a Dockerfile for your Node.js application, building and running your Docker container, and finally deploying it to an AWS EC2 instance. By following these steps, you can streamline your deployment process, reduce environment-related issues, and scale your application effortlessly. Thank you for reading!

Debugging 101 - How to Fix Software Errors Efficiently

Alexin — Wed, 12 Jun 2024 20:22:48 +0000

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

You’re sitting at your desk, staring (glaring, rather) at your laptop. It’s 2 am. Your code just isn’t working and you’re not sure why. You’ve tried everything you can think of, but the bug is still there, taunting you. You feel like giving up and going to bed. You feel like throwing your laptop at the wall. You feel like crying. You start to doubt your abilities and wonder if you’ll ever be a great software engineer. In the depths of despair and frustration, you take a deep breath and decide to give it one more shot. You go through your code line by line, trying to find where you went wrong. And then, after what feels like an eternity, you see it.

A repeated function call.
A line without proper indentation.
A dang semicolon.

Bugs are the bane of every developer's existence. They come in all shapes and sizes and can be a real headache to deal with. That’s why in this article, I’ll be teaching you the classic steps to solve any kind of bug in as little time as possible.

What is a bug?

A software bug is an error, flaw, or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and correcting bugs is termed "debugging" and often uses formal techniques or tools to pinpoint bugs. Since the 1950s, some computer systems have been designed to detect or auto-correct various software errors during operations. - Wikipedia

Simply put, a bug is a software error. It’s when your code doesn’t produce the expected results. For example, when you write a function to increment the number 1 till it reaches 10, but you end up with a 10-character string of 1’s instead, that’s a bug. Debugging, on the other hand, is just what it sounds like: removing or fixing bugs.

Now, bugs typically have more disastrous consequences in everyday applications. Imagine a scenario where a bug in a banking application causes a user's balance to be incorrectly displayed or a payment to be processed twice. That could lead to serious financial problems for the user.

Different types of bugs

Different types of bugs can occur while writing software. Some of the most common types of bugs include:

Syntax errors: Typos, missing punctuation, or incorrect formatting – these basic code mistakes prevent the program from even running.

Logic errors: The code runs smoothly, but the output is wrong due to flaws in the underlying logic, like the banking app example.

Runtime errors: Unexpected situations during execution, like memory issues or accessing invalid data, cause the program to crash or behave erratically.

Misinterpreted requirements: Even with seemingly correct code, the program might not achieve its intended purpose if the developer misunderstood the requirements.

How to Debug Code

In the following paragraphs, I'll walk you through an efficient bug-solving process step-by-step, using an example to help you understand how to use it effectively.

Reproduce the error: When you first encounter a bug, you need to reproduce the error to understand its root cause. This involves identifying the specific steps or conditions that trigger the issue and then attempting to replicate them in a non-production environment.
Isolate the bug: To identify faulty code, the error message needs to be examined meticulously and then traced back to the specific line or lines of code that caused the issue. This may involve debugging tools, print statements, or code reviews.
Understand the Code: Go through every line of code in the program. Make sure you comprehend what each line is supposed to do.
Test Inputs and Outputs: Test your code with different inputs to see if the bug occurs consistently or only under certain conditions.
Fix the bug: At this point, you’ve probably identified the error in your code. Check for syntax errors, faulty logic, and issues with external dependencies. Brainstorm the solution to the bug, then refine it.
Do research: If you can’t come up with a solution on your own, it’s best to do some research online. Debug with your favorite AI tool. Look for forums like Stack Overflow where people may have experienced a similar issue and have found a solution. You can also search for tutorials or guides on how to fix the problem. If no solution is found, reach out to colleagues and senior engineers for assistance.
Test your solution: Once you have found a solution, test it. Make sure that the bug is completely fixed and that it doesn't cause any new issues or side effects. It's always a good idea to get a second opinion from a colleague or mentor before deploying the code to a production environment.

In conclusion, debugging is an essential skill for any developer. It can be a frustrating and time-consuming process, but with the right approach, it doesn't have to be. By following the steps outlined in this article, you can systematically identify and fix bugs in your code, saving yourself countless hours of hair-pulling and frustration. Remember, bugs are inevitable, but with practice and patience, you can become a proficient debugger. Thanks for reading!

Bash Scripting for Software Engineers - A Beginner's Guide

Alexin — Sun, 09 Jun 2024 15:00:00 +0000

It's your first day at your new job. You've been handed a computer running Linux, and you were told to locate all the files containing the word "key". It's a simple enough task, right? The catch is, there are thousands of files on that system, and you've never written a shell script before.

Shell scripting, the language of the command line, is your ticket to automating repetitive tasks and mastering your Linux environment. With this guide, you'll be able to navigate your way around any Bash terminal with ease, and you might learn a couple of cool tricks along the way!

What are all these terms, anyway?

Shell

A shell is a program that interprets commands and executes them on your operating system. Simply put, a shell is a command-line interpreter that acts as a bridge between you and your operating system. It is usually run in a terminal or console. The terminal provides an input interface to run textual commands, and the shell takes in those commands and executes them on your system.

Bash

It is a shell program and command language. Bash has its roots in earlier Unix shells. The Bourne shell, released in 1977, was a major step forward in allowing users to write scripts and automate tasks. Bash, short for Bourne-Again SHell, was created in 1989 by Brian Fox as part of the GNU Project. It was designed as a free and improved alternative to the Bourne shell, while still maintaining compatibility with existing scripts.

Getting started with Bash Scripting

Setting up the Development Environment

Bash shells are commonly found on Linux operating systems. In this article, we will be working primarily with Ubuntu, a Linux distribution. You can download and set up Ubuntu here: (Canonical Ubuntu)[http://ubuntu.com/download].

Alternatively, if you're working from a Windows environment, you can download the Windows Subsystem for Linux (WSL) which gives you access to a Linux operating system and a bash terminal, without the need for dual booting, or clean wiping Windows. You can get WSL here: https://learn.microsoft.com/en-us/windows/wsl/install.

Once you have your terminal open, you should see a prompt like the one below:

Now we are ready to begin.

Basic Shell commands

cd: Change directory. This command is used to navigate to a different directory within the file system.

$ cd Desktop
# This will switch to the ./Desktop directory.

ls: List directory contents. It displays the files and directories in the current directory.

$ ls
file1.txt
file2.txt
directory1/

mkdir: Make a directory. This command creates a new directory with the given name.

$ mkdir newDir
$ ls
newDir

rm: Remove. It is used to delete files or directories. Be cautious as it does not have a confirmation prompt by default.

$ rm newFile
$ ls

$ rm -rf newDir
$ ls

pwd: Print working directory. It shows the current directory path.

$ pwd
/home/alexin/newDir/

cp: Copy. This command is used to copy files or directories from one location to another.

$ cp ../file_to_copy.txt .
$ ls
file_to_copy.txt

mv: Move. It moves files or directories from one location to another. It can also be used to rename files.

$ mv ../file_to_move.txt .
$ ls
file_to_move.txt

touch: Create a new file. It creates an empty file with the specified name or updates the timestamp of an existing file.

$ touch newFile.txt
$ ls
newFile.txt

cat: Concatenate and display content. This command is used to display the content of files on the terminal. It can also be used to concatenate and display multiple files.

$ cat newFile.txt
This is the content of newFile.txt.

echo: Print text. This is used to print text or variables to the terminal or standard output.

$ echo 'I am Alexin'
I am Alexin

$ name="Alexin"
$ echo 'My name is $name'
My name is Alexin

man: Displays information about a command. 'man' stands for manual, and it is used to provide detailed information about the specified command, including its purpose, syntax, options, and examples of usage.

$ man ls
LS(1)                            User Commands                           LS(1)

NAME
       ls - list directory contents

SYNOPSIS
       ls [OPTION]... [FILE]...

DESCRIPTION
       List  information  about  the FILEs (the current directory by default).
       Sort entries alphabetically if none of -cftuvSUX nor --sort  is  speci‐
       fied.

       Mandatory  arguments  to  long  options are mandatory for short options
       too.

       -a, --all
              do not ignore entries starting with .

       -A, --almost-all
              do not list implied . and ..

       --author
 Manual page ls(1) line 1 (press h for help or q to quit)

grep: The grep command is used to search for specific patterns or regular expressions within files or streams of text. It stands for "Global Regular Expression Print".

$ grep "error" file.txt
This line contains error.
This line also contains the word "error".
This line has errors (error is in the word errors)

find: Search files and directories. This command lets you search for matching expressions or patterns in a specified file or directory. It allows you to search based on various criteria such as name, type, size, and permissions.

$ find / -

Creating Bash Scripts

A bash script is a file typically ending with the extension .sh that contains a logical series of related commands to be executed. You can create a bash script using the nano text editor by running this command in your terminal:

$ nano new_script.sh

In the editor, start your script with a shebang line. The shebang line tells the system that this file is a script and specifies the interpreter to use.

#!/bin/bash

You can add a simple command to print the text "Hello, World!" to the terminal.

#!/bin/bash

text="Hello, World!"
echo $text

Save the file then exit: CTRL X + Y + Enter.

Before you can run the file, you have to make it executable. Change the file's permissions using the following commands:

$ chmod u+x new_script.sh

Now run your bash script.

$ ./new_script.sh
Hello, World!

Congratulations! You have created your first bash script. Now, let's learn about handling control flow with conditionals and loops.

Control flow

This refers to the order in which commands are executed in a program. In Bash scripting, control flow constructs allow you to manage the execution sequence of your script, enabling you to make decisions, repeat actions, and manage complex logical conditions.

Key Control Flow Constructs in Bash

Conditional Statements: These are used to execute a block of code only if a specified condition is true.

if Statement:

 if [ condition ]; then
   # Code to execute if condition is true
 fi

if-else Statement:

 if [ condition ]; then
   # Code to execute if condition is true
 else
   # Code to execute if condition is false
 fi

if-elif-else Statement:

 if [ condition1 ]; then
   # Code to execute if condition1 is true
 elif [ condition2 ]; then
   # Code to execute if condition2 is true
 else
   # Code to execute if neither condition1 nor condition2 is true
 fi

Loops: These are used to repeat a block of code multiple times.

for Loop:

 for variable in list; do
   # Code to execute for each item in list
 done

while Loop:

 while [ condition ]; do
   # Code to execute as long as condition is true
 done

until Loop:

 until [ condition ]; do
   # Code to execute until condition is true
 done

Case Statement: This is used to execute one of several blocks of code based on the value of a variable.

   case $variable in
     pattern1)
       # Code to execute if variable matches pattern1
       ;;
     pattern2)
       # Code to execute if variable matches pattern2
       ;;
     *)
       # Code to execute if variable doesn't match any pattern
       ;;
   esac

To demonstrate these concepts, let us write a program that performs a calculation given two numbers and an operation as input:

#!/bin/bash
# Function to perform arithmetic operations
perform_operation() {
  # First we define 3 variables, to store the arguments passed into the function.
  local num1=$1
  local num2=$2
  local operation=$3

  # We then use a case statement to execute an arithmetic operation, based on the value of the $operation variable. We log the result of the operation to the terminal.
  case $operation in
    addition)
      result=$((num1 + num2))
      echo "Result of addition: $result"
      ;;
    subtraction)
      result=$((num1 - num2))
      echo "Result of subtraction: $result"
      ;;
    multiplication)
      result=$((num1 * num2))
      echo "Result of multiplication: $result"
      ;;
    division)
      if [ $num2 -eq 0 ]; then
        echo "Error: Division by zero is not allowed."
      else
        result=$((num1 / num2))
        echo "Result of division: $result"
      fi
      ;;
    *)
      echo "Invalid operation. Please use one of the following: addition, subtraction, multiplication, division."
      ;;
  esac
}

# Main script starts here
echo "Enter the first number:"
read num1

echo "Enter the second number:"
read num2

echo "Enter the operation (addition, subtraction, multiplication, division):"
read operation

# Perform the operation
perform_operation $num1 $num2 $operation

# Loop to check if user wants to perform another operation
while true; do
  echo "Do you want to perform another operation? (yes/no)"
  read choice

  case $choice in
    yes|y|Yes|YES)
      echo "Enter the first number:"
      read num1

      echo "Enter the second number:"
      read num2

      echo "Enter the operation (addition, subtraction, multiplication, division):"
      read operation
      # The read command enables a shell script to read user input from the command line.

      perform_operation $num1 $num2 $operation
      ;;
    no|n|No|NO)
      echo "Exiting the script. Goodbye!"
      break
      ;;
    *)
      echo "Invalid choice. Please enter yes or no."
      ;;
  esac
done

Handling command line arguments

n a Bash script, command-line arguments are accessed using positional parameters:

$0 is the name of the script.
$1, $2, ..., $N are the arguments passed to the script.
$# is the number of arguments passed to the script.
$@ is all the arguments passed to the script.
$* is all the arguments passed to the script as a single word.
"$@" is all the arguments passed to the script, individually quoted.
"$*" is all the arguments passed to the script, quoted as a single word.

Let's modify the previous arithmetic script to handle command-line arguments. This way, users can specify the numbers and the operation directly when they run the script.

#!/bin/bash

# Function to perform arithmetic operations
perform_operation() {
  local num1=$1
  local num2=$2
  local operation=$3

  case $operation in
    addition)
      result=$((num1 + num2))
      echo "Result of addition: $result"
      ;;
    subtraction)
      result=$((num1 - num2))
      echo "Result of subtraction: $result"
      ;;
    multiplication)
      result=$((num1 * num2))
      echo "Result of multiplication: $result"
      ;;
    division)
      if [ $num2 -eq 0 ]; then
        echo "Error: Division by zero is not allowed."
      else
        result=$((num1 / num2))
        echo "Result of division: $result"
      fi
      ;;
    *)
      echo "Invalid operation. Please use one of the following: addition, subtraction, multiplication, division."
      ;;
  esac
}

if [ $# -ne 3 ]; then
  echo "Usage: $0 <num1> <num2> <operation>"
  echo "Example: $0 5 3 addition"
  exit 1
fi

num1=$1
num2=$2
operation=$3

perform_operation $num1 $num2 $operation

Now that you know the basics of scripting in shell, try out these practice assignments:

Assignment #1: Locate Files Containing the Word "key"

Your task is to write a Bash script that searches for all files containing the word "key" within a specified directory and its subdirectories. The script should:

Accept the directory path as a command-line argument.
Use the grep command to search for files containing the word "key".
Print the paths of the files that contain the word "key".

Assignment #2: Automate Git Commits for Each Edited File

In this assignment, you will write a Bash script to automate the process of creating a separate Git commit for every file that has been edited in a Git repository. This script will be particularly useful in scenarios where you want to commit each file separately, perhaps for clearer version history or to adhere to specific project guidelines.

Ensure the script is executed within a Git repository.
Use Git commands to list files that have been edited.
Loop through the list of modified files and create a commit for each one.

Conclusion

In summary, this guide has equipped you with the foundational knowledge to navigate the world of Bash scripting. You've explored core concepts like shell commands, creating scripts, control flow structures, and handling user input. With this strong base, you can now venture into more complex scripting tasks to automate various processes and streamline your workflow on Linux systems.

Remember, practice is key to mastering any skill. Experiment with the provided assignments and explore other scripting challenges to solidify your understanding. Thank you for reading!