DEV Community: Micheal Angelo

From Home Networking to Enterprise Networking: What Changes Behind the Scenes?

Micheal Angelo — Sat, 20 Jun 2026 07:26:15 +0000

From Home Networking to Enterprise Networking: What Changes Behind the Scenes?

For a long time, networking felt relatively straightforward.

A device connects to a router, the router connects to the Internet, and traffic eventually reaches its destination.

A simplified view looks like:

Laptop
   ↓
Router
   ↓
ISP
   ↓
Internet
   ↓
Website

While studying networking, I became curious about how enterprise environments work.

Corporate devices often have additional security software installed, VPN clients are common, and traffic sometimes appears to follow entirely different paths than it does on a home network.

This raised an interesting question:

What actually changes when networking moves from a home environment to an enterprise environment?

The Problem Organizations Are Trying To Solve

Home networks are usually optimized for convenience.

Enterprise networks have a different set of priorities.

Organizations need to:

Protect sensitive information
Restrict access to certain websites
Monitor traffic for security threats
Enforce compliance requirements
Control how applications communicate
Route traffic through approved paths

Simply allowing devices to communicate directly with the Internet is often insufficient.

Additional security layers are introduced to enforce these requirements.

What Is A Secure Web Gateway?

One common component in enterprise environments is a Secure Web Gateway (SWG).

Instead of traffic flowing directly to the Internet:

Browser
   ↓
Internet

traffic may follow a path like:

Browser
   ↓
Security Client
   ↓
Secure Web Gateway
   ↓
Internet

The gateway acts as an intermediary.

Before traffic reaches its destination, the gateway can:

Apply security policies
Filter websites
Inspect requests
Generate logs
Enforce compliance requirements

The user still experiences a normal browsing session, but additional checks occur behind the scenes.

Identity Matters More Than MAC Addresses

One misconception many beginners have is that organizations identify users primarily through:

MAC addresses
Local IP addresses

In reality, enterprise environments usually rely on richer forms of identity.

Examples include:

User authentication
Device certificates
Security agents
Corporate identity providers
Session information

This allows an organization to distinguish between:

An approved corporate device
A personal device

even when both devices are connected to the same home Wi-Fi network.

The decision is often based on identity and trust rather than simply an IP address.

Understanding Traffic Steering

One of the more interesting concepts in enterprise networking is traffic steering.

The basic idea is simple:

Different types of traffic may follow different paths.

For example:

Web Browsing
        ↓
Gateway A

Internal Applications
        ↓
Gateway B

Client Systems
        ↓
Gateway C

The path can be chosen based on:

User identity
Application type
Destination
Security policies

A useful analogy is an airport.

Passengers may enter through the same building, but different groups are routed through different checkpoints depending on where they are going.

Enterprise networks often work in a similar way.

Why Network Behavior Can Change Over Time

One observation that initially confused me was that network behavior sometimes changes without any visible action from the user.

A website that was inaccessible one day may suddenly become accessible later.

This often happens because enterprise security platforms periodically receive updated policies.

Those policies may modify:

Access permissions
Routing behavior
Security controls
Gateway selection

As a result, the path traffic follows today may not be identical to the path it follows next month.

Where VPNs Fit Into The Picture

Before learning more about networking, I assumed traffic always followed a simple path:

Laptop
   ↓
Router
   ↓
Internet
   ↓
Server

VPNs introduce an additional layer.

Conceptually:

Laptop
   ↓
Encrypted Tunnel
   ↓
VPN Gateway
   ↓
Destination

The VPN gateway becomes a trusted entry point into an organization's network.

Instead of communicating directly with internal resources, traffic first reaches the VPN infrastructure.

From there it is forwarded according to organizational policies.

One Device, Multiple IP Addresses

Another important concept is that a device may be associated with multiple IP addresses simultaneously.

Local IP Address

Assigned by the home router.

Examples:

192.168.x.x
10.x.x.x

Used only inside the local network.

Public IP Address

Assigned by the Internet Service Provider.

This is typically what external websites see.

VPN Address

Assigned by the VPN infrastructure.

When connected to organizational resources, this address may be used instead of the public ISP address.

Understanding these different layers helps explain why network traffic can appear differently depending on where it is observed.

DNS Still Plays A Critical Role

Regardless of whether traffic is flowing through a home network or an enterprise network, DNS remains fundamental.

Humans prefer names:

example.com

Computers require IP addresses.

DNS performs the translation:

example.com
        ↓
IP Address

One useful command is:

nslookup example.com

This allows you to observe how names are resolved into addresses.

Building On Earlier Networking Concepts

While learning networking, I spent a lot of time understanding:

ARP
DHCP
DNS
ICMP
IP
MAC Addresses

These protocols solve lower-level networking problems.

For example:

ARP asks:

I know the IP address. What is the MAC address?

DHCP asks:

What IP address should I use?

DNS asks:

What IP address corresponds to this domain name?

Enterprise networking introduces a different set of questions:

Who is the user?

Is this device trusted?

Which policy applies?

Which gateway should handle this traffic?

The focus shifts from simple connectivity to identity, security, and policy enforcement.

Final Thoughts

One thing that became clear while learning networking is that enterprise networking is not a completely different world.

The same fundamentals still exist:

IP addresses
DNS
Routing
TCP/IP

What changes is the addition of security, identity, and policy layers on top of those fundamentals.

The more I studied packet flows and network paths, the easier these concepts became to understand.

Rather than memorizing protocols individually, it became much more useful to ask:

Where is this packet going, and why is it taking that path?

That simple question often reveals how the entire system works.

One Public IP, Many Devices: How Your Router Knows Where Replies Belong

Micheal Angelo — Sat, 13 Jun 2026 17:26:18 +0000

After learning about DHCP, ARP, DNS, TCP, and NAT, I ran into a question that completely changed how I thought about home networking.

I already understood the basics of NAT.

My laptop might have:

192.168.1.100

while my router has a public address such as:

49.43.12.10

The router replaces the private address with its public address before sending packets to the Internet.

That part made sense.

But then a new question appeared.

The Problem

Imagine a home network with three devices.

Laptop
192.168.1.100

Phone
192.168.1.101

Tablet
192.168.1.102

All three devices are browsing websites simultaneously.

After NAT, every packet appears to originate from:

49.43.12.10

To the Internet, all three devices look identical.

Which raises an obvious question:

When replies come back, how does the router know which device should receive them?

This is where ports become extremely important.

Think of NAT Like an Apartment Building

Imagine a large apartment building.

The building has a single address:

49.43.12.10

Inside the building are:

Apartment 101
Apartment 102
Apartment 103

The public IP address is the building.

The ports are the apartment numbers.

Without apartment numbers, a package arriving at the building could not be delivered to the correct resident.

[Insert Figure 1: Apartment Building Analogy Here]

A Real Example

Suppose we have:

Laptop:
192.168.1.100

Phone:
192.168.1.101

Router:
49.43.12.10

The laptop performs a DNS lookup.

Its operating system chooses a temporary source port:

The packet looks like:

Source IP:
192.168.1.100

Source Port:
53001

Destination IP:
8.8.8.8

Destination Port:
53

The Phone Does the Same Thing

Now the phone also performs a DNS lookup.

It chooses:

as well.

The packet becomes:

Source IP:
192.168.1.101

Source Port:
53001

Destination IP:
8.8.8.8

Destination Port:
53

At first glance this looks problematic.

Both devices chose the same source port.

Surprisingly, this is completely valid.

Why?

Because their source IP addresses are different.

Inside the LAN they are still unique connections.

The Router Receives the First Packet

The router sees:

192.168.1.100:53001

and creates a translation entry:

192.168.1.100:53001
        ↓
49.43.12.10:40001

Notice something interesting.

The router did not keep:

It selected:

instead.

This becomes the public-facing connection.

The outgoing packet now looks like:

Source IP:
49.43.12.10

Source Port:
40001

Destination IP:
8.8.8.8

Destination Port:
53

The Router Receives the Second Packet

Now the phone's packet arrives.

The router creates another entry:

192.168.1.101:53001
        ↓
49.43.12.10:40002

Notice what changed.

The public IP stayed the same.

The public port changed.

The translation table now contains:

192.168.1.100:53001
        ↓
49.43.12.10:40001

192.168.1.101:53001
        ↓
49.43.12.10:40002

This table is the real magic behind modern home networking.

[Insert Figure 2: PAT Translation Table Here]

The Replies Return

Google sends a reply to:

49.43.12.10:40001

The router checks its translation table.

It finds:

40001
        ↓
192.168.1.100:53001

The packet is rewritten and delivered to the laptop.

A second reply arrives:

49.43.12.10:40002

The router checks the table again.

It finds:

40002
        ↓
192.168.1.101:53001

The packet is forwarded to the phone.

Both devices receive the correct response even though they share the same public IP address.

[Insert Figure 3: Reply Mapping Diagram Here]

This Is Actually PAT

Most people casually refer to this process as:

NAT

More specifically, what is happening here is:

PAT

which stands for:

Port Address Translation

Another common name is:

NAT Overload

because many devices are sharing a single public IP address.

Why PAT Is So Powerful

A port number can range from:

This provides roughly:

65,000+

possible ports.

That means thousands of simultaneous connections can share the same public IP address.

Without PAT, home networking as we know it would be much more difficult.

What Does the Router Actually Store?

The router does not simply remember IP addresses.

It maintains a connection table.

A simplified entry might look like:

Inside IP:
192.168.1.100

Inside Port:
53001

Outside IP:
49.43.12.10

Outside Port:
40001

Destination IP:
8.8.8.8

Destination Port:
53

Real routers store additional information such as:

Protocol
TCP state
Timeouts
Flags
Session metadata

This is what allows thousands of connections to coexist simultaneously.

What Happens When the Connection Ends?

Suppose the browser tab is closed.

Eventually the TCP session terminates.

The router notices.

The translation entry is removed.

For example:

49.43.12.10:40001

becomes available for reuse.

This process happens continuously behind the scenes.

Why Random Incoming Traffic Gets Dropped

Imagine a random server sends a packet to:

49.43.12.10:45000

The router checks its translation table.

No matching entry exists.

The router effectively says:

I don't know who requested this connection.

The packet is dropped.

This behavior is one reason home routers provide a basic level of protection against unsolicited traffic.

The Insight That Changed My Mental Model

Initially I thought NAT was simply:

Private IP
        ↓
Public IP

That is only part of the story.

The real magic is the translation table.

The router continuously maintains mappings between:

(Private IP, Private Port)
                ↔
(Public IP, Public Port)

for every active connection.

That is how one public IP address can support dozens of devices and thousands of simultaneous network conversations.

And once this idea clicked, ports stopped feeling like random numbers and started feeling like apartment numbers in a giant building.

Following a Packet: What Really Happens Between Opening Your Laptop

Micheal Angelo — Sat, 13 Jun 2026 10:30:24 +0000

For a long time, networking felt like a collection of unrelated acronyms.

DHCP.

ARP.

DNS.

TCP.

IP.

NAT.

VPN.

I could explain each one individually.

But if someone had asked:

"What actually happens when you open a website?"

I would have struggled to answer.

The turning point came when I stopped learning protocols individually and started following a single packet through the network.

This article follows that packet from the moment a laptop connects to Wi-Fi until a webpage finally appears in the browser.

Before We Begin: Data, Segments, Packets, and Frames

One of the biggest beginner misconceptions is that everything is called a packet.

Technically, that is not true.

As data moves through the networking stack, its name changes.

Application Layer

The browser creates:

GET /

At this stage it is simply:

Data

Transport Layer

TCP adds a header containing information such as:

Source Port
Destination Port
Sequence Number
Acknowledgement Number
Flags

Now we have:

TCP Header + Data

This is called a:

Segment

Network Layer

IP adds another header containing:

Source IP Address
Destination IP Address
TTL
Protocol

Now we have:

IP Header + Segment

This becomes a:

Packet

Data Link Layer

Ethernet or Wi-Fi adds:

Source MAC Address
Destination MAC Address

Now we have:

Ethernet Header + Packet

This becomes a:

Frame

The final structure looks like:

Frame
└── Packet
    └── Segment
        └── Data

This process is known as:

Encapsulation

Every packet on the Internet begins this way.

Our Example Network

To keep things simple, imagine the following setup.

Laptop

MAC = BB:BB:BB:BB:BB:BB

Router

LAN IP  = 192.168.1.1
LAN MAC = AA:AA:AA:AA:AA:AA
Public IP = 49.43.12.10

DNS Server

8.8.8.8

Website

example.com
104.26.10.50

Now let's follow the packet.

Step 1: Laptop Boots

Immediately after startup, the laptop knows surprisingly little.

It knows:

My MAC Address

But it does not yet know:

IP Address
Default Gateway
DNS Server

Those must be discovered.

Step 2: Connecting to Wi-Fi

The laptop successfully joins the wireless network.

At this point many people assume networking is ready.

It is not.

The laptop still lacks an IP address.

Without one, meaningful communication cannot occur.

Step 3: DHCP Gives the Laptop an Identity

The laptop broadcasts:

DHCP Discover

Meaning:

Is there a DHCP server available?

The router responds:

DHCP Offer

containing:

IP Address = 192.168.1.100
Gateway    = 192.168.1.1
DNS Server = 8.8.8.8

The laptop accepts.

Now it finally knows:

Who am I?
Where should I send traffic?
Which DNS server should I use?

DHCP has completed its job.

Step 4: The User Opens a Website

Suppose the user enters:

https://example.com

The browser immediately faces a problem.

It knows:

example.com

but websites are reached using IP addresses.

The browser asks:

What IP address belongs to example.com?

Step 5: Before DNS, ARP Happens

To contact the DNS server, the laptop must send traffic through the router.

It knows the router's IP address:

192.168.1.1

But it does not know:

Router MAC Address

So it broadcasts:

Who has 192.168.1.1?

This is an ARP request.

The router replies:

192.168.1.1 is AA:AA:AA:AA:AA:AA

The laptop stores this information in its ARP cache.

Problem solved.

Step 6: The DNS Query Leaves the Laptop

The laptop creates an IP packet.

Source IP      = 192.168.1.100
Destination IP = 8.8.8.8

Then it creates a frame.

Source MAC      = BB:BB:BB:BB:BB:BB
Destination MAC = AA:AA:AA:AA:AA:AA

This reveals an important networking principle:

Destination IP  = Final Destination

Destination MAC = Next Hop

For many beginners, this is the first surprising realization.

Step 7: NAT Changes the Source Address

The router receives the packet.

The router notices:

192.168.1.100

is a private IP address.

Private addresses cannot travel across the public Internet.

The router performs:

NAT

Network Address Translation.

The source address changes from:

192.168.1.100

to:

49.43.12.10

which is the router's public IP.

The router also records this translation in its NAT table.

This is how replies find their way back later.

Step 8: Routers Forward the Packet

The packet begins traveling across the Internet.

An important detail often goes unnoticed.

At every hop:

Old Ethernet Frame
      ↓
Discarded

New Ethernet Frame
      ↓
Created

This means:

MAC Addresses
Change at every hop

while:

IP Addresses
Remain largely unchanged

This is why networking engineers often say:

MAC = Hop-to-Hop

IP = End-to-End

Step 9: The DNS Server Responds

Eventually the packet reaches:

8.8.8.8

Google DNS receives:

Source IP = 49.43.12.10
Destination IP = 8.8.8.8

Notice something important.

Google never sees:

192.168.1.100

It only sees the public address created by NAT.

Google replies:

example.com = 104.26.10.50

Step 10: The Reply Finds Its Way Home

The DNS reply eventually returns to the home router.

The router consults its NAT table:

49.43.12.10:53001
        ↓
192.168.1.100:53001

The router now knows exactly which device requested the information.

The reply is forwarded back to the laptop.

Step 11: TCP Establishes a Connection

Now the browser finally knows:

example.com = 104.26.10.50

Before sending data, TCP establishes a connection.

The famous three-way handshake occurs:

SYN
 ↓
SYN-ACK
 ↓
ACK

The connection is now established.

Step 12: TLS Creates Encryption

Because the website uses HTTPS, encryption must be negotiated.

The browser and server exchange:

Certificates
Cryptographic parameters
Session keys

An encrypted channel is created.

Only after this step can secure communication begin.

Step 13: The Actual Website Loads

Finally, the browser sends:

GET /

The server responds with:

HTML
CSS
JavaScript
Images

The browser renders everything.

The webpage appears.

What Changes When a VPN Is Enabled?

Without a VPN:

Laptop
 ↓
Router
 ↓
ISP
 ↓
Website

With a VPN:

Laptop
 ↓
Router
 ↓
ISP
 ↓
VPN Server
 ↓
Website

The router does not disappear.

ARP still happens.

DHCP still happens.

Frames still exist.

The difference is that traffic is encrypted and sent to the VPN server first.

To the ISP:

VPN Server

appears to be the destination.

The actual website remains hidden inside the encrypted tunnel.

The Mental Model That Finally Helped

Networking became easier once I stopped imagining the Internet as a single connection.

Instead, I started viewing it as many small conversations.

Laptop ↔ Router

Router ↔ ISP Router

ISP Router ↔ ISP Router

ISP Router ↔ Destination

Each conversation uses different MAC addresses.

The IP packet survives the journey.

Once that idea clicked, concepts such as:

DHCP
ARP
DNS
NAT
VPNs
Routing
Wireshark captures

started feeling like pieces of the same puzzle instead of isolated protocols.

Final Thoughts

For a long time, networking felt overwhelming because every protocol seemed independent.

The breakthrough came when I followed a single packet from start to finish.

Rather than memorizing definitions, I began asking:

What problem is this protocol solving right now?

Viewed through that lens:

DHCP provides identity.
ARP finds local devices.
DNS finds destinations.
NAT enables Internet access.
TCP creates reliable communication.
TLS secures it.

And together, they make something as ordinary as loading a webpage possible.

A URL Worked on My Work Laptop but Not My Personal Laptop — Here's What That Taught Me About VPNs, ARP, and Networking

Micheal Angelo — Sat, 13 Jun 2026 02:41:14 +0000

One of the most effective ways to learn networking is to stop memorizing protocols and start investigating real problems.

Recently, I encountered a situation that seemed simple at first.

A newly deployed internal service was accessible from my work laptop but not from my personal laptop.

A month later, the exact same URL became accessible from both devices.

At first glance this looked like a permissions issue.

But the more I investigated, the more networking concepts started connecting together.

What began as a simple question eventually led me through:

Cloud networking
VPNs
Public vs private IP addresses
MAC addresses
ARP
Ethernet frames
Packet captures in Wireshark

This article summarizes the mental models that finally helped these concepts click.

The Original Question

The observation was simple:

Work Laptop
     ↓
URL works

Personal Laptop
     ↓
URL does not work

Later:

Work Laptop
     ↓
URL works

Personal Laptop
     ↓
URL also works

The obvious question was:

How does a server know the difference between two laptops?

Both devices were connected to the same home network.

Both were using the same internet connection.

So what was different?

My First Hypothesis: Cloud Networking Rules

My first assumption was that the answer lived inside the cloud platform.

Regardless of whether a service runs on:

AWS
Azure
GCP

all cloud providers offer mechanisms for controlling network access.

Examples include:

AWS

Security Groups
Network ACLs

Azure

Network Security Groups (NSGs)

GCP

Firewall Rules

The names differ.

The underlying goal is the same:

Allow traffic
Block traffic
Control who can reach a service

This led me to a hypothesis:

Perhaps the service was initially restricted and later opened to a broader audience.

That explanation seemed plausible.

But there was another possibility.

The VPN Realization

My work laptop regularly connects through a VPN.

Specifically:

GlobalProtect VPN

This changed how I thought about the problem.

Without a VPN, traffic follows a path similar to:

Laptop
   ↓
Home Router
   ↓
ISP
   ↓
Internet
   ↓
Destination Server

With a VPN:

Laptop
   ↓
Home Router
   ↓
ISP
   ↓
VPN Gateway
   ↓
Company Network
   ↓
Destination Server

This raised a new possibility.

The server might not care about:

Work Laptop
vs
Personal Laptop

Instead, it might care about:

Company Network
vs
Public Internet

That distinction made much more sense.

Understanding IP Addresses

This investigation also exposed a misunderstanding I had about IP addresses.

There isn't just one IP address involved.

There are several.

Local IP Address

Assigned by your router through DHCP.

Example:

192.168.1.10

This address exists only inside your home network.

Internet servers never see it directly.

Public IP Address

Assigned by your ISP.

Example:

103.x.x.x

This is the address most internet services see.

VPN Address

Assigned by the VPN infrastructure.

Example:

10.50.x.x

When connected to a VPN, company systems may see this address instead of your ISP-assigned address.

This was an important realization.

A server often identifies where a request is coming from based on IP addresses—not based on the physical laptop itself.

The MAC Address Misconception

Another misconception I had involved MAC addresses.

Initially I assumed that remote services might somehow see the MAC address of my network card.

That is not how networking works.

What Actually Happens

Imagine traffic moving toward GitHub:

Laptop
   ↓
Router
   ↓
ISP Router
   ↓
More Routers
   ↓
Datacenter Router
   ↓
GitHub

At every hop:

MAC Address
Changes

IP Address
Remains the same

This means:

GitHub never sees the MAC address of my Wi-Fi card.

GitHub sees my public IP address.

That single insight corrected a large part of my networking mental model.

Where ARP Fits In

This naturally led to another question:

If devices communicate using MAC addresses locally, how does a device discover a MAC address?

The answer is:

ARP

Address Resolution Protocol.

The Problem ARP Solves

Suppose a device knows:

192.168.1.10

but does not know:

2c:9c:58:8b:2d:7b

ARP exists to bridge that gap.

Its purpose is simple:

IP Address
      ↓
Find MAC Address

An ARP Request in Plain English

A typical ARP request looks like:

Who has 192.168.1.10?
Tell 192.168.1.1

Translated into normal language:

I am 192.168.1.1

I am looking for
192.168.1.10

Who owns that address?

ARP requests are broadcast to the entire local network.

The ARP Reply

The device that owns the address responds:

192.168.1.10 is at
2c:9c:58:8b:2d:7b

Meaning:

I own that IP address.

Here is my MAC address.

The router can now send Ethernet frames directly to the correct device.

A Discovery from Wireshark

While inspecting packets in Wireshark, I noticed something surprising.

The packet structure looked like:

Frame
   ↓
Ethernet II
   ↓
ARP

Notice what is missing.

There is no:

IP

layer between Ethernet and ARP.

This was unexpected.

I initially assumed ARP worked inside IP.

It does not.

ARP operates alongside IP.

Why ARP Has No TTL

Another misconception involved TTL.

I assumed every networking protocol contained fields such as:

TTL
Routing information
IP headers

That assumption was wrong.

TTL exists because IP packets travel through routers.

Example:

Laptop
   ↓
Router
   ↓
ISP
   ↓
Internet
   ↓
Destination

Each router decreases the TTL value.

ARP packets never leave the local network.

They are not routed across the internet.

Because of that:

No Routing
      ↓
No TTL Needed

Once I understood this, ARP's design suddenly made much more sense.

The Mental Models That Finally Clicked

After all of this investigation, several concepts became much easier to remember.

Cloud Networking

Different names.

Same networking fundamentals.

VPN

Changes the route packets take.

IP Address

Identifies a device across networks.

MAC Address

Identifies a network interface on a local network.

ARP

Answers:

"I know the IP address. What is the MAC address?"

DHCP

Answers:

"I just joined the network. Which IP address should I use?"

DNS

Answers:

"I know the website name. Which IP address does it map to?"

Final Thoughts

What started as a simple access issue turned into a useful networking lesson.

The biggest takeaway wasn't a specific protocol.

It was a different way of learning.

Instead of memorizing definitions, I found it far more effective to observe actual packet exchanges and then ask:

Why did that happen?

Wireshark made invisible networking behavior visible.

And once the packets became visible, many concepts that previously felt disconnected finally started fitting together.

Learning DevOps from First Principles: What an EC2 Instance Actually Is

Micheal Angelo — Mon, 08 Jun 2026 03:16:19 +0000

One of the first cloud concepts many people encounter while learning AWS is EC2.

The name sounds technical.

The documentation is extensive.

And the number of configuration options can make it feel like something fundamentally different from a regular computer.

But while trying to understand cloud computing, I found myself repeatedly coming back to a simple thought:

At the end of the day, an EC2 instance is just another computer.

That realization helped me understand cloud infrastructure much more clearly.

The Intimidation Factor

When people first open the AWS console, they encounter terms such as:

EC2
VPC
Security Groups
Elastic IPs
Auto Scaling

It is easy to feel that cloud computing is an entirely different world.

But before diving into those concepts, it helps to ask a simpler question:

What is an EC2 instance actually providing?

Starting with the Name

EC2 stands for:

Elastic Compute Cloud

The important word here is:

Compute

AWS is essentially renting computing resources.

When you launch an EC2 instance, AWS allocates:

CPU
Memory (RAM)
Storage
Networking

to a virtual machine that you can access.

In other words:

You are renting a computer that lives inside AWS's infrastructure.

Comparing It to a Personal Computer

Consider a typical laptop.

It contains:

A processor
RAM
Storage
An operating system
Network connectivity

Now consider an EC2 instance.

It also contains:

Virtual CPUs
RAM
Storage
An operating system
Network connectivity

The location is different.

The concepts are the same.

The Main Difference: Ownership

The biggest difference is not technical.

It is operational.

With a personal computer:

You own the hardware.
The machine sits near you.
You maintain it.

With EC2:

AWS owns the hardware.
The machine runs in a data center.
AWS manages the physical infrastructure.

You only manage the virtual machine running on top of it.

Why Linux Knowledge Transfers

This was one of the most interesting observations during my learning.

If an EC2 instance runs Linux, many of the same concepts apply:

File permissions
Processes
Services
Logs
Package management
Networking

For example, if you already know how to:

ssh user@server

check running processes:

ps aux

or inspect network interfaces:

ip addr show

those skills remain useful inside a cloud environment.

The cloud does not replace Linux.

It builds upon it.

Why Networking Suddenly Matters

A local computer often works without much thought about networking.

Cloud systems are different.

To access an EC2 instance, you must think about:

IP addresses
Ports
Firewalls
Security Groups
Routing

Questions such as:

Which traffic should be allowed in?

and

Which traffic should be allowed out?

become important very quickly.

This is one reason networking appears so frequently in DevOps discussions.

The "Elastic" Part

One aspect that does make EC2 different from a personal machine is elasticity.

A laptop has fixed hardware.

An EC2 instance can be changed relatively easily.

Need more RAM?

Choose a larger instance type.

Need more CPU?

Launch a different instance.

Need multiple servers?

Create several instances.

The computer remains conceptually the same.

The flexibility changes.

A Useful Mental Model

The way I currently think about it is:

```text id="l6t4uy"
Personal Computer
↓
Virtual Machine
↓
Cloud Virtual Machine (EC2)




The further you move down this chain, the more infrastructure management is abstracted away.

But the underlying concepts remain familiar.

---

## Why This Perspective Helped Me

Initially, cloud services felt like hundreds of disconnected products.

But viewing EC2 as "just another computer" made many concepts easier to understand.

Instead of asking:

> "How does AWS work?"

I could start by asking:

> "How would I do this on a Linux machine?"

Often, the cloud version turns out to be an abstraction of something that already exists.

---

## Final Thoughts

Cloud computing introduces many new terms.

Some of them are genuinely new concepts.

Others are familiar ideas presented at a larger scale.

For me, EC2 became much easier to understand once I stopped thinking of it as a cloud product and started thinking of it as a computer.

A computer with CPU, RAM, storage, networking, and an operating system.

Just running somewhere else.

And sometimes, understanding a complex system begins by realizing that it may be simpler than it first appears.

Same Hardware, Different Experience: Why Linux Feels Faster

Micheal Angelo — Mon, 08 Jun 2026 03:16:05 +0000

A few weeks after switching from Windows to Linux, I noticed something interesting.

The hardware had not changed.

The processor was the same.

The RAM was the same.

The SSD was the same.

And yet, the laptop felt noticeably faster.

Not necessarily because applications were completing tasks dramatically quicker, but because the entire system felt more responsive.

Keyboard input felt immediate.

Windows opened faster.

Terminal commands appeared instantly.

The desktop experience felt smoother.

This raised a question:

How can the same hardware feel different simply because the operating system changed?

While I'm still learning, this is the mental model I've built so far.

The Hardware Didn't Change

Consider a laptop with:

AMD Ryzen processor
16 GB DDR5 RAM
NVMe SSD
Modern integrated graphics

When switching operating systems, none of these components change.

The CPU does not suddenly become faster.

The RAM does not magically increase.

The SSD remains identical.

From a hardware perspective:

```text id="u3m9xd"
Before → Same Hardware
After → Same Hardware




So the difference must come from somewhere else.

---

## An Operating System Is Not Just a User Interface

Many people think of an operating system primarily as the desktop they see.

But an operating system does far more than display windows and icons.

It manages:

* Memory
* CPU scheduling
* Processes
* Storage
* Networking
* Device drivers
* Background services

In other words:

> The operating system decides how hardware resources are used.

Two operating systems can therefore create very different experiences using the same hardware.

---

## Perceived Performance vs Raw Performance

One thing I have learned is that performance is not always about benchmarks.

A system can have excellent benchmark scores and still feel sluggish.

Why?

Because users experience responsiveness, not benchmark numbers.

Examples include:

* How quickly a window opens
* How fast a menu appears
* How responsive typing feels
* How quickly applications launch

These small interactions shape our perception of speed.

---

## Background Services Matter

Modern operating systems often run numerous services in the background.

Examples include:

* Update services
* Search indexing
* Telemetry collection
* Synchronization services
* Device management services

Many of these provide useful functionality.

However, they also consume resources.

Even when no application is actively running, background processes may still be:

* Using memory
* Accessing storage
* Performing network activity
* Scheduling CPU work

This creates a baseline level of system activity.

---

## Resource Utilization Is a Shared Budget

A useful way to think about system resources is as a shared budget.

Your laptop has finite:

* CPU cycles
* Memory
* Storage bandwidth

Every running service consumes part of that budget.

The more resources allocated to background tasks, the fewer remain available for user-facing work.

This does not necessarily mean one operating system is "better" than another.

Different operating systems make different trade-offs.

---

## Different Priorities, Different Results

One realization that helped me understand the situation is this:

Operating systems are optimized for different goals.

Some prioritize:

* Broad hardware compatibility
* Enterprise features
* Legacy application support

Others prioritize:

* Simplicity
* Minimalism
* Resource efficiency

Neither approach is inherently right or wrong.

They simply optimize for different audiences.

---

## Why Linux Often Feels Lightweight

Many Linux distributions allow users to choose exactly what they install.

Examples include:

* Desktop environments
* Services
* Background applications
* System utilities

This flexibility often results in systems that run fewer background components by default.

Consequently:

* Memory usage may be lower
* Idle CPU usage may be lower
* Disk activity may be reduced

The hardware itself has not changed.

The workload placed on it has.

---

## The Importance of Responsiveness

One thing I did not fully appreciate before switching is how much responsiveness affects the user experience.

Consider typing.

If every keypress appears immediately, the system feels fast.

If there is even a slight delay, users notice it.

The same applies to:

* Opening terminals
* Launching applications
* Switching windows

The actual difference may only be milliseconds.

Yet those milliseconds accumulate into a perception of smoothness.

---

## Why This Matters for DevOps Learning

This observation also connects back to learning DevOps.

Many cloud servers run Linux.

Understanding Linux is not only about commands and configuration files.

It is also about understanding how operating systems manage resources.

Concepts such as:

* Memory usage
* Running processes
* Service management
* System monitoring

appear repeatedly in real-world infrastructure.

The desktop experience simply provides a visible example of those concepts.

---

## A Simple Mental Model

The way I currently think about it is:



```text id="r2n6wk"
Hardware
    +
Operating System
    +
Running Workloads
    =
User Experience

The hardware is only one part of the equation.

The operating system and workload distribution matter just as much.

Final Thoughts

After switching operating systems, the hardware remained exactly the same.

Yet the overall experience changed noticeably.

That experience made me realize something important:

Performance is not only about how powerful a machine is.

It is also about how efficiently its resources are used.

The fastest-feeling system is not always the one with the most powerful hardware.

Sometimes, it is simply the one asking the hardware to do less.

And that has been one of the most interesting lessons from exploring Linux so far.

Learning DevOps from First Principles: MAC Addresses vs IP Addresses — The Difference Finally Clicked

Micheal Angelo — Mon, 08 Jun 2026 03:15:52 +0000

One of the first networking concepts that confused me was this:

Why does a computer need both a MAC address and an IP address?

At first glance, they seem to solve the same problem.

Both appear to identify a device.

Both show up in networking tools.

Both appear in packet captures.

So why do we need two different addresses?

While exploring Linux networking tools and Wireshark, the distinction finally started making sense.

This article summarizes the mental model that helped me understand the difference.

Looking Inside the Machine

Before discussing addresses, it helps to understand where they come from.

If you open a typical laptop, you will usually find components such as:

Battery
RAM
Storage
Processor
Cooling system
Network interfaces

One of those network interfaces is typically:

A Wi-Fi card
An Ethernet controller

These components are responsible for network communication.

They are the parts of the machine that actually send and receive data across a network.

Every Network Interface Has an Identity

A network interface needs a way to identify itself.

This is where the MAC address comes in.

A MAC address is associated with a network interface card (NIC).

Example:

```text id="q3d9nm"
2C:9C:58:8B:2D:7B




Think of it as the identity of the network interface itself.

Not the operating system.

Not the browser.

Not the application.

The network hardware.

---

## What Is a MAC Address?

MAC stands for:

**Media Access Control**

A MAC address operates at the **Data Link Layer** of the OSI model.

Its primary purpose is to help devices communicate within a local network.

Examples include:

* Laptop to router
* Router to switch
* Switch to printer

In other words:

> MAC addresses help devices find each other on the same local network.

---

## What Is an IP Address?

An IP address serves a different purpose.

Example:



```text id="g8x4tc"
192.168.1.20

```text id="v6u7mz"
2405:201:8000::1




IP addresses operate at the **Network Layer**.

Their job is to identify where a device exists within a larger network.

This allows communication beyond a single local network.

For example:

* Home network → Internet
* Office network → Cloud server
* Laptop → GitHub

---

## The Question That Helped Me

The mental model that helped me most was:

**MAC Address answers:**

> Which physical device on this local network should receive this data?

**IP Address answers:**

> Which device anywhere in the world should receive this data?

They solve related but different problems.

---

## Hardware Identity vs Logical Identity

This is where things finally clicked for me.

A MAC address is tied to a network interface.

An IP address is assigned by the network.

Think of it this way:

### MAC Address



```text id="w2l7fa"
Identity of the network hardware

IP Address

```text id="h5r3ek"
Identity assigned within a network




One identifies the hardware.

The other identifies the location.

---

## Why Not Use Only MAC Addresses?

Initially, I wondered:

> Why not simply use MAC addresses everywhere?

The problem is scale.

Imagine trying to communicate with a server on another continent.

Routers across the internet cannot practically route traffic based on MAC addresses alone.

Instead:

* IP addresses handle routing across networks.
* MAC addresses handle delivery within local networks.

This division of responsibility makes networking scalable.

---

## Seeing It in Linux

One of the easiest ways to observe this is:



```bash id="j8r4np"
ip addr show

Typical output includes interfaces such as:

```text id="f2q7xs"
lo
eth0
wlp2s0




You may also see:

### MAC Address



```text id="c9m5vn"
link/ether 2c:9c:58:8b:2d:7b

IPv4 Address

```text id="u4x6la"
inet 192.168.1.20




### IPv6 Address



```text id="b7p8dw"
inet6 2405:201:8000::1

Seeing both together helped reinforce that they serve different purposes.

Where Wireshark Made It Click

While experimenting with Wireshark, I noticed that packets often contained both:

Source MAC Address
Destination MAC Address

and

Source IP Address
Destination IP Address

At first this felt redundant.

But it eventually became clear:

The packet needs:

IP information to determine where it should go globally.
MAC information to determine which device should receive it locally.

Both are necessary.

A Simple Analogy

Imagine sending a letter.

The city and street address represent the IP address.

They help the postal system route the letter across large distances.

The person's name on the mailbox resembles the MAC address.

Once the letter arrives at the correct location, it still needs to reach the correct recipient.

The analogy is not perfect, but it helped me visualize the distinction.

A Useful Mental Model

The way I currently think about it is:

```text id="n8y3vk"
IP Address
↓
Find the correct network

MAC Address
↓
Find the correct device




Together they allow communication to scale from local networks to the global internet.

---

## Why This Matters for DevOps

At first glance, MAC addresses and IP addresses seem like purely networking topics.

But they appear everywhere:

* Cloud servers
* Containers
* Virtual machines
* Kubernetes networking
* Load balancers
* VPNs

Understanding the distinction makes many higher-level networking concepts easier to grasp.

---

## Final Thoughts

For a long time, MAC addresses and IP addresses felt like two different labels describing the same thing.

They are not.

A MAC address identifies a network interface on a local network.

An IP address identifies a device's location within a larger network.

One focuses on hardware-level delivery.

The other focuses on network-level routing.

And once that distinction clicked, many networking concepts suddenly became much easier to understand.

Learning DevOps from First Principles: I Ran ping github.com and Opened Wireshark — Here's What I Learned

Micheal Angelo — Mon, 08 Jun 2026 03:15:37 +0000

One of the most interesting things about learning networking is that many concepts seem abstract until you see them happening in real time.

For example, I had heard terms such as:

ICMP
Packets
Requests
Replies
Network traffic

But they remained theoretical concepts until I opened Wireshark and watched them appear on my screen.

What started as a simple command:

ping github.com

turned into a useful lesson about how computers communicate across networks.

The Experiment

The setup was intentionally simple.

Open Wireshark
Select the active network interface
Apply the filter:

icmp

Open a terminal
Run:

ping github.com

My goal was simple:

Observe what actually happens on the network when a ping command is executed.

Before Running Ping

Before running the command, Wireshark showed no ICMP traffic.

📸 Before Capture

Figure 1: Wireshark filtered by ICMP before running ping github.com.

This initially confused me.

I had applied the filter correctly, but nothing appeared.

Then I realized something important:

Wireshark only shows packets that actually exist.

Since no ICMP traffic was being generated, there was nothing to display.

Running the Command

The command used was:

ping github.com

Immediately, the terminal began showing responses similar to:

64 bytes from 20.xx.xx.xx:
icmp_seq=1 ttl=119 time=61 ms

At the same time, Wireshark started filling with packets.

After Running Ping

The moment the ping command started running, ICMP packets appeared in Wireshark.

📸 After Capture

Figure 2: ICMP Echo Requests and Echo Replies captured after running ping github.com.

This was the first time I could visually observe what the ping command was doing behind the scenes.

What Does `ping` Actually Do?

Many beginners—including myself—treat ping as a connectivity test.

We run:

ping github.com

and if responses appear, we assume everything is working.

While that is true, there is more happening underneath.

The ping utility uses a protocol called:

ICMP

which stands for:

Internet Control Message Protocol

ICMP is part of the TCP/IP networking stack and is primarily used for diagnostics and troubleshooting.

The Two Messages That Matter

When ping runs, two ICMP messages become important.

ICMP Echo Request

Sent from your computer.

It is essentially asking:

"Are you there?"

ICMP Echo Reply

Sent back by the destination host.

It is essentially saying:

"Yes, I'm here."

Together, these create the familiar request–response pattern.

What Wireshark Was Showing

Looking at the capture, I could see entries similar to:

Echo (ping) request
Echo (ping) reply
Echo (ping) request
Echo (ping) reply

Each request was followed by a corresponding reply.

This was not just theory anymore.

It was a live conversation occurring between my machine and GitHub's servers.

A Simple Conversation

The interaction can be visualized as:

My Laptop
    ↓
"Are you there?"
    ↓
github.com

github.com
    ↓
"Yes, I'm here."
    ↓
My Laptop

This exchange repeats continuously while the ping command runs.

Something Interesting I Noticed

In the capture, I could clearly see two IP addresses.

For example:

Source:
192.168.1.x

Destination:
20.x.x.x

and then immediately afterwards:

Source:
20.x.x.x

Destination:
192.168.1.x

The addresses had reversed.

That was the reply packet making its way back.

Seeing this happen visually helped me understand networking far better than simply reading definitions.

Looking Inside a Packet

Expanding a packet in Wireshark revealed multiple layers.

For example:

Ethernet Frame
        ↓
IPv4 Packet
        ↓
ICMP Message

This was an interesting moment because several concepts I had been studying separately suddenly appeared together.

Inside a single packet I could see:

Source MAC Address
Destination MAC Address
Source IP Address
Destination IP Address
ICMP data

The OSI model was no longer just a diagram.

I was seeing it in action.

Why Both MAC and IP Addresses Appear

One question that had been bothering me earlier was:

Why do packets contain both MAC addresses and IP addresses?

Observing Wireshark helped answer that.

The packet needs:

IP Address

To determine where it should travel across networks.

MAC Address

To determine which device should receive it on the local network.

Both are required.

They simply operate at different layers.

Measuring Latency

One of the most useful outputs from ping is:

time=61 ms

This represents the round-trip time.

The measurement includes:

Request sent
        ↓
Destination receives it
        ↓
Reply generated
        ↓
Reply received

The reported time covers the entire journey.

This is why ping is often used to estimate network latency.

Why This Matters for DevOps

At first glance, ping appears to be a very simple command.

However, many real-world infrastructure problems eventually become questions such as:

Is the server reachable?
Is DNS resolving correctly?
Is the network path functioning?
Are packets being dropped?

Understanding what ping actually does provides a foundation for answering those questions.

Tools such as Wireshark simply make the invisible visible.

A Useful Mental Model

The way I currently think about it is:

ping command
      ↓
ICMP Echo Request
      ↓
Network
      ↓
Destination Host
      ↓
ICMP Echo Reply
      ↓
Back to Sender

Every successful ping is simply a completed request–reply conversation.

Final Thoughts

Before opening Wireshark, ping felt like a black box.

You ran the command.

A response appeared.

And that was the end of the story.

After watching the packets move across the network, the process became much easier to understand.

A simple command turned into a visible exchange of requests and replies.

And for the first time, concepts such as:

ICMP
Packet captures
MAC addresses
IP addresses

started feeling less like networking terminology and more like parts of a real conversation between machines.

Sometimes the best way to learn networking is not by reading about packets.

It is by watching them travel.

If AI Gets Better at Coding, What Becomes the Bottleneck?

Micheal Angelo — Sun, 07 Jun 2026 11:20:02 +0000

One thought has been occupying my mind recently.

As AI systems continue to improve, where does the bottleneck move?

Historically, writing software involved two distinct challenges:

Understanding the problem
Translating the solution into code

For a long time, both were difficult.

Today, however, the second challenge is becoming significantly easier.

Modern AI systems can already generate substantial amounts of code from natural language instructions. Open-source models are improving rapidly, and frontier models continue to push capabilities forward.

This raises an interesting question:

If generating code becomes increasingly automated, what remains uniquely valuable?

I do not claim to know the answer.

But I have a hypothesis.

A Historical Parallel

Consider what happens when a program is compiled.

Developers rarely write machine code directly.

Instead:

Human Logic
      ↓
Programming Language
      ↓
Compiler
      ↓
Machine Code

In a sense, compilers already generate the final executable instructions.

Yet software engineers did not become irrelevant.

The bottleneck simply shifted.

Humans focused on:

Problem solving
Architecture
Design decisions
Trade-offs

while compilers handled translation.

AI May Shift the Bottleneck Again

Something similar may be happening today.

The amount of code directly written by humans may decrease.

The amount of guidance provided to AI systems may increase.

The bottleneck may move from:

Writing Code

toward:

Defining Problems

and

Communicating Intent

Articulacy May Become a Competitive Advantage

One skill that increasingly feels important is articulacy.

By articulacy, I mean:

The ability to translate thoughts into clear, precise language.

This sounds simple.

In practice, it is surprisingly difficult.

Many people know what they want.

Far fewer can describe it precisely.

The difference matters.

Vague Requests Produce Vague Results

Consider the difference between:

Build me a web application.

and

Build a React application using Redux for state management,
with authentication, role-based access control,
server-side pagination, and optimistic UI updates.

Both are requests.

Only one provides meaningful constraints.

The second request communicates intent more effectively.

As AI systems become more capable, the quality of instructions may become increasingly important.

Asking Better Questions

Another skill that feels increasingly valuable is asking the right questions.

Good questions often emerge from understanding how systems work.

For example:

What are the trade-offs?
What assumptions are being made?
What constraints exist?
What information is missing?

These questions frequently matter more than syntax.

The better the question, the more useful the answer tends to be.

Why Domain Knowledge Still Matters

A common misconception is:

If AI can write code, technical knowledge becomes unnecessary.

I am not convinced that this is true.

To guide an AI system effectively, one still needs to understand:

Architecture
Design patterns
Framework choices
Performance constraints
Security considerations
Operational requirements

In many cases, knowing what to ask requires understanding the domain first.

Open Source Models Will Continue Improving

Another observation is that open-source models appear to be improving at a remarkable pace.

Today's frontier models may remain ahead.

But history suggests that capabilities often diffuse over time.

What seems exclusive today may become widely accessible tomorrow.

This raises another question:

If capable models become available locally, what limits adoption?

Hardware May Become the Next Constraint

One possible answer is hardware.

A model can be open source and still be inaccessible.

Why?

Because running it may require expensive hardware.

Most people I know use laptops with configurations such as:

16 GB RAM
Consumer CPUs
Integrated graphics

If a model requires:

High-end GPUs
Large memory pools
Expensive infrastructure

its practical adoption remains limited.

In that case, the bottleneck shifts again:

Model Availability
         ↓
Hardware Availability

The model may exist.

The ability to run it becomes the challenge.

A Possible Future

This makes me wonder whether future software development may increasingly look like:

Human
    ↓
Idea
    ↓
Clear Instructions
    ↓
AI System
    ↓
Implementation

In that world, human value may not disappear.

It may simply move higher up the stack.

Towards:

Problem definition
Architecture
Communication
Judgment
Context

A Thought, Not a Prediction

I could be completely wrong.

Technology has a habit of surprising people.

But if current trends continue, I suspect the most valuable skill may not be typing code faster.

It may be:

Thinking clearly
Communicating precisely
Understanding systems deeply
Asking better questions

Because even if machines become exceptional at implementation, someone still needs to decide what should be built in the first place.

And that decision begins with a thought that can be articulated clearly enough for others—human or machine—to understand.

Learning DevOps from First Principles: Why Linux and Networking Might Be the Best Place to Start

Micheal Angelo — Sun, 07 Jun 2026 10:32:10 +0000

One question has been occupying my mind recently:

If someone wants to learn DevOps, where should they actually begin?

The internet offers thousands of answers.

Some recommend starting with Docker.
Others suggest Kubernetes.
Many point directly to AWS, Azure, or GCP.

As someone currently learning DevOps, I've been trying to understand the subject from a more fundamental perspective.

And the conclusion I've reached—at least for now—is this:

Linux and networking seem to be the foundation upon which many DevOps concepts are built.

I may be wrong, and I'm still learning, but this line of reasoning has helped me make sense of what initially felt like an overwhelming field.

The Problem with Starting from Services

Cloud providers offer an enormous number of services.

AWS alone provides hundreds of them.

For a beginner, this can create a feeling that DevOps is simply about memorizing services:

EC2
S3
VPC
IAM
Route 53
CloudWatch

And many more.

The challenge is that learning services without understanding the underlying concepts can sometimes feel like memorizing buttons in a user interface.

The service names may change.

The concepts usually don't.

Looking Beneath the Cloud

When I started looking past the service names, I noticed something interesting.

Many cloud services ultimately provide access to concepts that already exist outside the cloud.

For example, consider a virtual machine.

In AWS, that service is called EC2.

But what is an EC2 instance really?

At a high level, it is a computer running somewhere else.

It has:

An operating system
Storage
Memory
Networking
Processes

The same concepts exist on a personal Linux machine.

The environment changes.

The fundamentals do not.

Why Linux Feels Important

A significant amount of modern infrastructure runs on Linux.

Servers.
Containers.
Cloud workloads.

Many of them are Linux-based.

This means concepts such as:

File systems
Permissions
Processes
Services
Package managers
Logs

appear repeatedly across different technologies.

Learning Linux does not teach a specific cloud provider.

Instead, it teaches the environment where many cloud workloads live.

Why Networking Appears Everywhere

The second concept that keeps showing up is networking.

Every modern application communicates with something.

Examples include:

A browser talking to a server
A server talking to a database
Containers communicating with each other
Services communicating across networks

Without networking, these systems become isolated.

Concepts such as:

IP addresses
DNS
Ports
Protocols
Routing

appear constantly throughout DevOps workflows.

Even many cloud services are ultimately abstractions built on networking concepts.

A Simple Mental Model

The way I currently think about it is:

Linux → Understand the machine

Networking → Understand communication between machines

Cloud → Understand how those machines and networks are managed at scale

Whether this model is perfectly accurate, I'm still not sure.

But it has helped me organize my learning.

Why This Approach Appeals to Me

One reason I find this approach attractive is that the knowledge feels transferable.

If a cloud provider introduces a new service tomorrow, understanding Linux and networking still remains valuable.

The terminology may change.

The foundations usually remain.

Learning fundamentals first seems to reduce the feeling of constantly chasing new tools.

What I'm Learning Next

As part of this journey, I'm currently exploring:

Linux internals
Network interfaces
MAC addresses
IP addresses
Packet analysis using Wireshark
DNS and routing

My goal is not to become an expert overnight.

It is simply to understand the systems beneath the abstractions a little better.

Final Thoughts

I don't yet know whether Linux and networking are the best place to start learning DevOps.

But they increasingly feel like a reasonable place to begin.

The more I explore cloud technologies, the more I find myself returning to these fundamentals.

Perhaps the fastest way to understand complex systems is not to start with the most advanced tools.

Perhaps it is to understand the layers beneath them first.

And right now, Linux and networking seem like two of those layers.

Keep Your AI Conversations Local: Open WebUI + Ollama Setup

Micheal Angelo — Sun, 05 Apr 2026 02:21:55 +0000

Want Your AI to Stay Private? Run a Fully Local LLM with Open WebUI + Ollama

As LLMs become part of daily workflows, one question comes up more often:

Where does the data go?

Most cloud-based AI tools send prompts and responses to remote servers for processing.

For many use cases, that’s perfectly fine.

But in some situations:

Sensitive code
Personal notes
Internal documentation
Experimental ideas

You may prefer not to send that data outside your machine.

This is where local LLM setups become useful.

🧠 What This Setup Provides

This setup creates a fully local ChatGPT-like experience:

Runs entirely on your machine
No external API calls
No data leaving your system
Modern chat interface
Model switching support

⚙️ Architecture Overview

Browser (Open WebUI)
        ↓
Docker Container (Open WebUI)
        ↓
Ollama API (localhost:11434)
        ↓
Local LLM Model (e.g., mistral)

Everything runs locally.

🧩 Components

1. Ollama

Runs LLM models locally and exposes an API.

2. Open WebUI

Provides a ChatGPT-like interface with:

Chat history
Model selection
Clean UI

🔗 https://openwebui.com/

3. Docker

Runs Open WebUI in an isolated container.

🚀 Installation & Setup

1. Install Ollama

curl -fsSL https://ollama.com/install.sh | sh

2. Start Ollama

ollama serve

If you see:

address already in use

It simply means Ollama is already running.

3. Pull a Model

ollama pull mistral

Check available models:

ollama list

4. Run Open WebUI

sudo docker run -d \
  --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui \
  --restart unless-stopped \
  ghcr.io/open-webui/open-webui:main

🌐 Access the Interface

Open your browser:

http://localhost:8080

You now have a local ChatGPT-style interface.

🔗 Important Fix (Docker Networking)

If Open WebUI cannot detect Ollama:

Use:

--network=host

This allows the container to directly access:

http://127.0.0.1:11434

Without this, Docker may isolate the container from the local API.

▶️ Daily Usage

Start WebUI

sudo docker start open-webui

Stop WebUI

sudo docker stop open-webui

Check Models

ollama list

Run Model in Terminal

ollama run mistral

🔁 Troubleshooting

Port already in use (11434)

Ollama is already running — no action required.

Model not visible in UI

sudo docker restart open-webui

Connection issue

Check:

curl http://127.0.0.1:11434

🔒 Why This Matters

This setup ensures:

Prompts stay local
Files remain on your machine
No external logging or tracking
Full control over your environment

It is especially useful for:

Developers working with sensitive code
Offline workflows
Learning and experimentation
Privacy-conscious users

⚠️ Trade-offs

Local models are not identical to large cloud models.

Expect:

Slightly lower reasoning capability
Slower responses (CPU-based inference)
Limited context window (depending on model)

But for many use cases, they are more than sufficient.

⚡ Final Result

You now have:

A local LLM (e.g., Mistral)
A ChatGPT-like interface
A fully private AI environment
No dependency on external APIs

🧾 Quick Cheat Sheet

# Start WebUI
sudo docker start open-webui

# Open UI
http://localhost:8080

# Check models
ollama list

# Run model
ollama run mistral

# Stop WebUI
sudo docker stop open-webui

🏁 Final Thought

Cloud AI is powerful and convenient.

Local AI is controlled and private.

Both have their place.

This setup simply gives you the option.

What Happens Behind the Scenes When You Publish a Website

Micheal Angelo — Sat, 07 Mar 2026 13:12:04 +0000

Publishing a website may look simple from the outside.

You buy a domain, deploy your code, and the site appears on the internet.

But under the hood, several systems work together to make that happen.

This article explains the backend journey of a website — from domain registration to a live, accessible website.

1. Domain Registration

A domain name is the human-readable address used to access a website.

Examples include:

example.dev
example.com
example.org

When a domain is purchased through a domain registrar (such as Namecheap, GoDaddy, or Google Domains), the registrar records the ownership in the global domain registry for that specific top-level domain (TLD).

This process performs three key tasks:

The domain ownership is recorded in the global registry.
The domain is associated with authoritative DNS servers.
A DNS zone is created to store configuration records.

At this stage, the domain exists — but it does not yet point to any website.

2. DNS: The Internet's Phonebook

The Domain Name System (DNS) translates human-readable domain names into machine-readable IP addresses.

Computers communicate using numbers such as:

192.0.2.1

Humans prefer domain names like:

example.dev

DNS performs the translation:

domain name → IP address

When someone enters a domain in a browser, the browser performs a DNS lookup to determine which server hosts the website.

Common DNS Records

The DNS zone contains several types of records.

A Record

Maps a domain directly to an IP address.

Example:

example.dev → 192.0.2.1

This tells browsers exactly which server hosts the site.

CNAME Record

Creates an alias from one domain to another hostname.

Example:

www.example.dev → hosting-provider-domain.com

This is commonly used when hosting platforms manage the underlying infrastructure.

3. Website Hosting

A website must be stored on a server connected to the internet.

Hosting providers manage these servers and respond to requests from visitors.

For static websites, the server stores files such as:

index.html
styles.css
script.js

These files are delivered directly to the user’s browser.

For dynamic websites, the server may also run backend logic and interact with databases.

Examples include:

Node.js applications
Python backends
PHP systems
Database queries

4. Deployment

Deployment is the process of transferring application code from a development environment to a production server where users can access it.

A typical deployment workflow looks like this:

Developer machine
       ↓
Source code repository
       ↓
Build / deployment system
       ↓
Hosting server
       ↓
Public website

Whenever code is updated and pushed to the repository, the deployment system rebuilds and updates the live website.

This process is often automated through CI/CD pipelines.

5. Connecting the Domain to the Website

Once the website is deployed to a hosting server, the domain must be connected to that server through DNS configuration.

This is done by adding DNS records that point the domain to the hosting infrastructure.

The process looks like this:

User enters domain
        ↓
DNS lookup occurs
        ↓
DNS returns server IP
        ↓
Browser connects to server
        ↓
Server returns website files

Once the DNS records are correctly configured, the domain becomes the public entry point to the website.

6. DNS Propagation

DNS updates are not instant.

When DNS records change, the new information must propagate through DNS caches and resolvers across the internet.

Propagation typically takes:

a few minutes to several hours

During this time, some users may reach the new server while others still see the old configuration.

This temporary inconsistency is normal.

7. Secure Access with HTTPS

Modern websites use HTTPS to encrypt communication between users and servers.

HTTPS requires an SSL/TLS certificate for the domain.

Once installed, the website becomes accessible securely:

https://example.dev

Encryption ensures that data transmitted between the browser and the server cannot be intercepted or modified.

Final Architecture Overview

The entire process can be summarized as:

Domain registration
        ↓
DNS configuration
        ↓
Website deployment to hosting server
        ↓
DNS routes domain traffic to the server
        ↓
Users access the website via the domain

This chain of systems — domain registries, DNS servers, hosting infrastructure, and browsers — forms the core infrastructure that makes the modern web possible.

Final Thoughts

Launching a website involves more than uploading files to a server.

Behind every domain is an ecosystem of systems working together:

Domain registrars
DNS infrastructure
Hosting platforms
Deployment pipelines
Security layers

Understanding this flow provides a clearer mental model of how the internet serves websites to millions of users every day.