DEV Community: Himanshu Bhatt

HTML-101 #6. Paths, Anchor Tag, Mail & Phone Links

Himanshu Bhatt — Wed, 21 Jan 2026 03:39:56 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning HTML and decided to learn in public by documenting my journey.

This blog is part of my HTML-101 series, where I’m learning HTML step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

Quick recap — what paths are (short)
Anchor tag basics (<a>) and anatomy
Types of href values (absolute, relative, fragment, mailto, tel)
Important attributes: target, rel, download, title
Link states, styling, accessibility & keyboard behavior
Mailto links: formats and extra parameters (subject, body)
Tel links: formatting and best practices
When to use links vs buttons
Common mistakes and tips

📂 GitHub Repository

All my notes, examples, and practice code live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/html-101

This repo is updated as I continue learning.

📚 Learning Notes

1. Quick recap — What a path is (1 line)

A path tells the browser where to find a file (image, page, script, stylesheet).

Examples:

<img src="images/logo.png">
<a href="pages/about.html">About</a>
<link rel="stylesheet" href="css/style.css">

Difference between src, href and rel

Attribute	What it means	Loads file?	Used for
`src`	Source of content	✅ Yes	Images, JS, media
`href`	Link/reference	⚠️ Sometimes	Pages, CSS
`rel`	Relationship	❌ No	Explains purpose

2. Anchor tag basics — what is `<a>`?

<a> (anchor) creates clickable links.

Basic example:

<a href="https://example.com">Visit Example</a>

href = destination (required for a real link)
Link text = what users see and click

If href is missing, <a> is not treated as a link by browsers and assistive tech.

3. Types of `href` values

3.1 Absolute URL (external)

Full web address with protocol:

<a href="https://youtube.com">YouTube</a>

Use when linking to another website or CDN.

3.2 Root-relative path

Starts from the site root (/):

<a href="/about">About</a>
<img src="/assets/images/logo.png">

Works reliably when the site is hosted at domain root.

3.3 Relative path

Relative to the current file’s folder:

<!-- current file: /project/index.html -->
<a href="pages/about.html">About</a>
<img src="images/logo.png">

Use for files inside the same project.

3.4 Fragment / Anchor (jump within page)

Jump to an element with a matching id:

<h2 id="projects">Projects</h2>
<a href="#projects">Go to Projects</a>

3.5 `mailto:` (email) and `tel:` (phone)

Special schemes that launch apps:

<a href="mailto:someone@example.com">Email me</a>
<a href="tel:+911234567890">Call me</a>

4. Anchor tag anatomy (basic + attributes)

<a href="URL" target="_blank" rel="noopener noreferrer" title="Tooltip">
  Link Text
</a>

href — destination (URL, path, mailto, tel, or fragment)
target — where to open (_self, _blank, _parent, _top)
rel — relationship / security (important with _blank)
- noopener prevents the new page from getting window.opener
- noreferrer prevents sending the referrer URL
download — suggests downloading the resource instead of navigating
title — tooltip (use sparingly; not always helpful for accessibility)

Attribute	Value(s)	What it does (plain English)	When it comes into play	When to use it	Example
`target`	`_self`	Opens link in same tab	When link is clicked	Default behavior	`<a href="page.html" target="_self">`
`target`	`_blank`	Opens link in new tab	When link is clicked	External sites	`<a href="https://google.com" target="_blank">`
`target`	`_parent`	Opens link in parent frame	Inside iframe	When using iframes	`<a href="x.html" target="_parent">`
`target`	`_top`	Opens link in full window	Inside nested iframes	Break out of frames	`<a href="x.html" target="_top">`
`rel`	`noopener`	Blocks access to `window.opener`	With `target="_blank"`	Security	`<a target="_blank" rel="noopener">`
`rel`	`noreferrer`	Hides referrer info	With external links	Privacy	`<a rel="noreferrer">`
`download`	filename (optional)	Forces file download	On click	Download files	`<a download>`
`title`	text	Shows tooltip on hover	On mouse hover	Extra hint text	`<a title="Info">`

Safe new-tab pattern (always do this):

<a href="https://example.com" target="_blank" rel="noopener noreferrer">
  External site
</a>

5. Link states & basic styling

Browsers provide pseudo-classes for link states:

a:link — unvisited link
a:visited — visited link
a:hover — mouse over
a:active — pressed/clicking
a:focus — focused via keyboard (Tab)

Order in CSS: :link, :visited, :hover, :active, :focus (LVHAF).

Basic styling example:

a {
  color: #1e90ff;
  text-decoration: none; /* remove underline */
}
a:hover {
  text-decoration: underline;
}
a:focus {
  outline: 3px solid #f59e0b;
  outline-offset: 2px;
}

Usability tip: If you remove underline, show a clear hover or focus indicator so users know it’s a link.

6. Accessibility & keyboard behavior

Links are keyboard-focusable by default and activate with Enter.
Never remove focus outline without replacing it with a visible focus style.
Link text should be descriptive (avoid “click here”).

Good vs bad:

<!-- Bad -->
<a href="mailto:someone@example.com">Click here</a>

<!-- Good -->
<a href="mailto:someone@example.com">Email Support</a>

7. Anchor vs Button — When to use what?

Use <a> for navigation (go to a new page, external link, fragment).
Use <button> for actions on the current page (open modal, submit form, toggle UI).

Bad pattern:

<a href="#" onclick="submitForm()">Submit</a> <!-- ❌ -->

Better:

<button type="button" onclick="submitForm()">Submit</button> <!-- ✅ -->

8. `download` attribute (force download suggestion)

<a href="/files/resume.pdf" download>Download Resume</a>
<a href="/files/resume.pdf" download="Himanshu-Bhatt-Resume.pdf">Download</a>

Browser may still open the file depending on type & user settings, but download suggests saving.

9. Mailto links — more details & extras

Basic mailto:

<a href="mailto:someone@example.com">Email me</a>

Multiple recipients:

<a href="mailto:person1@example.com,person2@example.com">Email both</a>

Add subject and body (URL-encoded):

<a href="mailto:someone@example.com?subject=Hello%20from%20site&body=Hi%20there%2C%0A%0AI%20found%20your%20site.">
  Email with subject
</a>

Spaces → %20
New lines → %0A or %0D%0A
Use ? for first param, & for others

Note: mailto opens the user’s email client. Not all desktop users have a configured client.

10. Tel links — formatting & best practice

Basic:

<a href="tel:+911234567890">+91 12345 67890</a>

Use international format (+ + country code) in href.
Display can show spaces or local formatting for readability.
tel: opens dialer on mobile; desktop behavior varies.

Good examples:

<!-- Display friendly, href machine-friendly -->
<a href="tel:+14155552671">+1 (415) 555-2671</a>
<a href="tel:+911234567890">+91 12345 67890</a>

11. Usability & accessibility tips for mail/tel links

Make link text descriptive: Email Support or Call Support.
For phone numbers, consider adding aria-label for clarity:

<a href="tel:+911234567890" aria-label="Call support at +91 12345 67890">
  +91 12345 67890
</a>

Don’t rely on mailto: for forms that require structured data — prefer actual contact forms for reliability and spam protection.

12. Common mistakes (summary)

Forgetting to add rel="noopener noreferrer" with target="_blank".
Using links for actions that should be buttons (accessibility & semantics).
Using href="#" — this is an anti-pattern (it changes the URL or scrolls).
Poor link text like “click here” — not descriptive for screen reader users.
Not testing mailto: / tel: behavior on mobile vs desktop.

⚠️ Challenges / Mistakes I Faced

When I started, I used links for things that should be buttons and I often forgot rel="noopener noreferrer" for target="_blank".

I also learned that mailto: and tel: work great on mobile but may behave differently on desktop.

If you faced any issues or have questions, feel free to let me know in the comments 🙂

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

something incorrect,
a better explanation,
or have suggestions to improve my understanding,

please comment below. I’m happy to learn and correct mistakes.

⭐ Support the Learning Journey

If you find these notes useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 Internal Page Navigation

I’ll also continue updating the GitHub repo as I progress.

🙌 Final Thoughts

Thanks for reading!

If you’re also learning HTML, feel free to:

follow along,
share your experience,
or drop questions in the comments 👋

📘 Learning in public

📂 Repo: https://github.com/dmz-v-x/html-101
🐦 Twitter/X: https://x.com/_himanshubhatt1
💬 Feedback welcome — please comment if anything feels off
⭐ Star the repo if you find it useful

Networking 101 #6. Subnets, CIDR & NAT

Himanshu Bhatt — Thu, 15 Jan 2026 10:33:04 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

What are subnets
Public subnet vs Private subnet
What is CIDR
What is NAT
Issues with Subnets

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. First: why do subnets even exist?

Let’s start with a simple question.

Why don’t we just put all computers on one big network?

Because:

It would be insecure
It would be chaotic
It would not scale

So networks are divided into smaller networks.

These smaller networks are called subnets.

2. What is a subnet?

A subnet is:

A group of IP addresses that belong to the same internal network.

That’s it.

Example:

10.0.0.0 – 10.0.0.255

All machines in this range:

Can talk to each other directly
Are part of the same private network

3. Why cloud providers force you to use subnets

In cloud platforms (AWS, GCP, Azure):

You don’t get a “flat” network
You must create:
- VPC (virtual private network)
- Subnets inside it

Why?

Security isolation
Routing control
Scalability

This is why you always see subnet selection during VM creation.

4. What is CIDR (the scary `/24` thing)?

CIDR looks scary but is simple.

Example:

10.0.0.0/24

CIDR means:

“How many IPs belong to this network”

4.1 CIDR without math (promise)

Here’s the only thing you need to remember:

CIDR	Approx IPs
/24	~256 IPs
/16	~65,000 IPs
/8	~16 million IPs

Smaller number after / → bigger network

Bigger number after / → smaller network

That’s enough for DevOps.

4.2 What `/24` actually means

10.0.0.0/24

Means:

Network starts at 10.0.0.0
Ends at 10.0.0.255
Total ≈ 256 IPs

Cloud providers reserve some IPs internally.

5. Why CIDR matters in real DevOps work

CIDR decides:

How many servers you can run
How isolated your network is
Whether services can talk to each other

Common mistake:

Choosing a subnet too small → running out of IPs

6. Public vs Private subnets

6.1 Public Subnet

Has a route to the internet
Used for:
- Load balancers
- Bastion hosts
- Public-facing services

6.1 Private Subnet

No direct internet access
Used for:
- App servers
- Databases
- Internal services

Best practice:

Only expose what must be public.

7. How do private subnets access the internet?

This is where NAT comes in.

7.1 What is NAT (Network Address Translation)?

NAT allows:

Private IPs → Internet

Without exposing:

Internet → Private IPs

NAT is one-way by default.

7.2 NAT explained simply

Private server:

10.0.1.5

Wants to access:

google.com

Flow:

10.0.1.5 → NAT Gateway → Internet

Internet sees:

Public IP → Internet

Replies come back through NAT.

8. Why NAT is critical for security

Without NAT:

Every private server needs a public IP
Everything is exposed

With NAT:

Servers stay private
Only outbound traffic allowed

This is why databases are almost always in private subnets.

9. Common DevOps architecture

Internet
   ↓
Load Balancer (Public Subnet)
   ↓
App Servers (Private Subnet)
   ↓
Database (Private Subnet)

NAT allows:

App → Internet (updates, APIs)
Database → No internet access

10. How subnet issues show up in real life

Problem	Likely Cause
Can’t reach DB	Wrong subnet
App can’t access internet	Missing NAT
Server unreachable	Public IP missing
Only some services talk	Routing issue

Most “network issues” are subnet or NAT misconfigurations.

11. Mini hands-on mental exercise

Ask yourself:

Is this service public or private?
Does it need inbound access?
Does it need outbound internet?

Those answers decide:

Subnet
NAT
Security rules

12. Mental model upgrade

Your networking stack now looks like:

Internet
  ↓
Public Subnet
  ↓
Private Subnet
  ↓
Service

Subnets decide who can talk to whom.

✅ Key takeaways

Subnets group IPs
CIDR controls subnet size
Public subnets face the internet
Private subnets stay hidden
NAT allows safe outbound access
Most cloud networking issues are subnet-related

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 Firewalls, Security Groups & Why “Connection Refused” Happens

I’ll also continue updating the GitHub repo as I progress.

📘 Learning in public

📂 Repo: https://github.com/dmz-v-x/networking-for-devops-101
🐦 Twitter/X: https://x.com/_himanshubhatt1
💬 Feedback welcome — please comment if anything feels off
⭐ Star the repo if you find it useful

Networking 101 #5. DNS Explained

Himanshu Bhatt — Thu, 15 Jan 2026 04:03:03 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

What is DNS?
DNS Resolution flow
DNS Caching
TTL in DNS caching
Common DNS Record types

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. Quick recap (from earlier blogs)

From Part 1:

Computers do NOT understand domain names.

They only understand IP addresses.

DNS exists to translate:

myapp.com → 13.234.56.78

DNS happens before:

TCP connection
HTTPS
Any application logic

If DNS fails, nothing else matters.

2. What actually happens during DNS resolution

When your browser wants to reach:

https://myapp.com

It asks:

“What IP address belongs to myapp.com?”

But who does it ask?

3. DNS resolution flow (simplified)

Browser
  ↓
OS DNS Cache
  ↓
Local Resolver (ISP / 8.8.8.8 / 1.1.1.1)
  ↓
Authoritative DNS Server
  ↓
IP Address returned

DNS is distributed, not centralized.

This design makes DNS:

Fast
Scalable
Cache-heavy (important!)

4. What is DNS caching?

To avoid repeating DNS lookups:

Browsers cache results
OS caches results
DNS resolvers cache results

Each cached record has a TTL.

5. TTL — Time To Live

TTL tells DNS:

“How long can I remember this answer?”

Example:

TTL = 300 seconds (5 minutes)

Meaning:

DNS answer can be reused for 5 minutes
No fresh lookup needed during this time

6. Real DevOps DNS failure example

Scenario:

You update your server IP
You update DNS record
Some users still hit the old server

Why?

Old IP is cached
TTL hasn’t expired yet

DNS is eventually consistent, not instant.

7. Common DNS record types (DevOps must-know)

You do NOT need to know all DNS records.

These are enough.

7.1 A Record

Maps a domain to an IP address.

myapp.com → 13.234.56.78

7.2 CNAME Record

Maps one domain to another domain.

www.myapp.com → myapp.com

Used for:

Aliases
Load balancers
Cloud services

7.3 TXT Record

Stores arbitrary text.

Used for:

Domain verification
SSL certificates
Email security

Used often when working with cloud providers.

8. Why CNAMEs matter in DevOps

CNAMEs allow:

Changing infrastructure without changing domains
Blue/green deployments
Easier migrations

Example:

app.mycompany.com → alb-123.aws.com

You update the load balancer — DNS stays same.

9. Common DNS debugging commands

9.1 Check DNS resolution

dig myapp.com

9.2 Use a specific DNS server

dig myapp.com @8.8.8.8

9.3 See only the IP

dig myapp.com +short

9.4 Using nslookup

nslookup myapp.com

10. Why DNS works for some users and not others

Because:

Different users use different DNS resolvers
Different caches expire at different times
ISPs cache aggressively

This is normal DNS behavior, not a bug.

11. DNS vs TCP vs HTTP (clear separation)

Layer	Failure Example
DNS	Domain not resolving
TCP	Connection refused
TLS	Certificate error
HTTP	500 error
App	Logic bug

Always identify which layer is failing.

12. Classic DevOps mistake

Mistake:

“DNS change didn’t work — let’s restart the server.”

Wrong.

DNS:

Lives outside your server
Is cached everywhere
Needs time to propagate

Restarting apps won’t fix DNS.

13. Mini hands-on exercise

Run:

dig google.com

Look at:

ANSWER section
TTL value

Run it again:

Notice TTL decreases

That’s caching in action.

14. Mental model upgrade

Your updated flow:

Browser
  ↓
DNS (cached or fresh)
  ↓
IP + Port
  ↓
TCP / UDP
  ↓
Application

DNS is always first.

✅ Key takeaways

DNS converts names → IPs
DNS is cached everywhere
TTL controls how long results live
DNS issues look random but are predictable
Debug DNS before touching servers

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 Subnets, CIDR & NAT

I’ll also continue updating the GitHub repo as I progress.

📘 Learning in public

Networking 101 #4. TCP vs UDP

Himanshu Bhatt — Thu, 15 Jan 2026 03:42:30 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

What is TCP
Advantages of TCP
What is UDP
Advantages of UDP
When to use TCP vs UDP
Basic commands related to TCP & UDP

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. First, the big question

When one computer sends data to another, how do we make sure:

The data arrives?
The data arrives in the correct order?
Missing data is re-sent?

There are two different answers to this problem.

They are called:

TCP
UDP

2.Before we start: where TCP & UDP sit

From earlier blogs, our stack looks like this:

Application (HTTP, SSH, DB)
        ↓
Transport Layer (TCP or UDP)
        ↓
IP (IP Address)
        ↓
Network

TCP and UDP live in the transport layer.

They decide how data moves, not where it goes.

3. TCP — Transmission Control Protocol

TCP is the most important protocol for DevOps engineers.

3.1 What TCP guarantees

TCP guarantees:

Data arrives
Data arrives in order
Lost data is re-sent
Duplicate data is removed

This makes TCP reliable.

4. What “connection-based” actually means

Before sending data, TCP does something crucial.

It creates a connection.

Conceptually:

Client: “Can we talk?”
Server: “Yes”
Client: “Great”

This is called the TCP handshake.

If this handshake fails, nothing else happens.

5. Common DevOps errors caused by TCP failure

If TCP connection fails, you’ll see errors like:

Connection refused
Connection timed out
No route to host

These errors mean:

The app may be running
But TCP cannot establish a connection

Usually due to:

Firewall rules
Closed ports
App not listening
Wrong IP or port

6. What uses TCP? (Very important list)

Almost everything you use daily:

Protocol	Uses TCP?
HTTP	✅
HTTPS	✅
SSH	✅
FTP	✅
Databases	✅

If reliability matters → TCP is used.

7. UDP — User Datagram Protocol

UDP solves a different problem.

7.1 What UDP does (and doesn’t do)

UDP:

Sends data
Does not guarantee delivery
Does not guarantee order
Does not create a connection

UDP is fast, but unreliable.

8. UDP analogy (simple)

TCP is like:

Making a phone call and talking step by step.

UDP is like:

Shouting messages across a room and hoping they’re heard.

9. Why does UDP even exist?

Because sometimes:

Speed matters more than perfection
Losing some data is okay

Examples:

DNS queries
Video streaming
Online gaming
Metrics & monitoring systems

Retrying TCP connections would be too slow here.

10. What uses UDP? (DevOps-relevant)

Use Case	Protocol
DNS (mostly)	UDP
Metrics	UDP
Service discovery	UDP
Streaming	UDP

DNS often uses UDP first, and TCP only if needed.

11. Side-by-side comparison (important)

Feature	TCP	UDP
Connection	Yes	No
Reliable	Yes	No
Ordered	Yes	No
Speed	Slower	Faster
DevOps usage	Very High	Medium

12. How this affects DevOps debugging

When something breaks, ask:

Is this TCP-based or UDP-based?
Does it expect reliability?

Examples:

HTTP API failing → TCP issue
DNS sometimes failing → UDP + network issue
Metrics missing → UDP packet loss

Understanding this changes how you debug.

13. Commands mapped to TCP & UDP

13.1 TCP testing

Checks if TCP port 443 is open and reachable

nc -vz example.com 443

13.2 UDP testing

Sends a UDP packet to port 53 to see if it’s reachable (best-effort check)

nc -vu example.com 53

Notice:

TCP checks for connection
UDP just sends data

14. Real DevOps scenario

Problem:

Your app can resolve DNS, but sometimes fails to connect.

Why this happens:

DNS uses UDP
UDP packets can be dropped
Retry logic may be missing

This is why DNS caching and retries matter (next blogs!).

✅ Key takeaways

TCP = reliable, connection-based
UDP = fast, connectionless
Most DevOps tools rely on TCP
DNS and metrics often use UDP
Error messages tell you which layer is failing

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 DNS Explained

I’ll also continue updating the GitHub repo as I progress.

📘 Learning in public

[Boost]

Himanshu Bhatt — Wed, 14 Jan 2026 09:17:54 +0000

Networking 101 #3. IP Addresses & Ports

Himanshu Bhatt ・ Jan 14

Networking 101 #3. IP Addresses & Ports

Himanshu Bhatt — Wed, 14 Jan 2026 09:17:45 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

IP Address, Local IP vs Internet IP
Public IP vs Private IP
Brief overview of NAT
Ports
localhost vs 127.0.0.1
Few Basic commands

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. What is an IP address (really)?

An IP address identifies a machine on a network.

That’s it.

Just remember this:

IP address = identity of a machine on a network

Examples:

192.168.1.10
10.0.0.5
13.234.56.78

Every machine that communicates on a network must have an IP.

2. Local IP vs Internet IP (very first distinction)

Your laptop has:

One IP inside your local network
Possibly another IP visible to the internet

Why? Because networks are layered.

Example:

Laptop → WiFi Router → Internet

Your laptop is not directly exposed to the internet.

3. Public IP Address (Internet-facing)

A public IP:

Is unique on the internet
Can be accessed from anywhere
Is assigned by ISPs or cloud providers

Example:

13.234.56.78

Cloud servers usually have:

A public IP (optional)
A private IP (always)

4. Private IP Address (Internal-only)

A private IP:

Works only inside a private network
Cannot be reached directly from the internet

Common private IP ranges:

10.0.0.0    – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

Your home WiFi, office network, and cloud VPCs all use private IPs.

5. Why private IPs exist

The internet does not have enough IPs for every device.

So:

Private IPs are reused everywhere
Public IPs act as gateways

This design allows:

Security (not everything exposed)
Scalability
Cost efficiency

This leads us to a very important idea (we’ll learn this concept later):
👉 NAT (Network Address Translation)

6. Tiny preview: What NAT does

NAT allows:

Many private IPs → One public IP

Your laptop sends traffic:

192.168.1.10 → Internet

The router translates it to:

Public IP → Internet

7. What is a port?

If an IP identifies a machine, a port identifies a program on that machine.

One machine can run many applications:

Web server
Database
SSH
Cache

Ports make this possible.

8. Port analogy (simple but powerful)

Think of:

IP address → apartment building
Port → apartment number

13.234.56.78:22   → SSH
13.234.56.78:80   → HTTP
13.234.56.78:443  → HTTPS

Same building, different doors.

9. Common ports every DevOps engineer must know

Port	Purpose
22	SSH
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis

10. How IP + Port work together

A network connection always needs:

IP address + Port

Examples:

ssh user@13.234.56.78     → port 22
https://example.com       → port 443
localhost:3000            → port 3000

Without a port, the OS doesn’t know which app should receive the data.

11. `localhost` vs `127.0.0.1`

When we run an application on our laptop, that's when localhost and 127.0.0.1 comes into picture.

11.1 What is 127.0.0.1?

127.0.0.1 is an IP address, specially it is called loopback IP which means if any network request sent to this IP it comes back to the same machine.

The request never leaves our machine, no router, no internet and no external network is involved.

11.2 What is `localhost`?

localhost is a hostname, it's not an ip. When we type localhost our operating system translates this name into an IP address that is 127.0.0.1

localhost → 127.0.0.1

This translation happens via

/etc/hosts file (Linux/macOS)
C:\Windows\System32\drivers\etc\hosts (Windows)

11.3 How does `localhost` actuallly works?

When we type: http://localhost:3000, internally our operating system follow these steps:

OS sees localhost
It looks up the hosts file
Resolve it to an IP (usually 127.0.0.1)
Send the request to that IP

So the flow becomes:

localhost → 127.0.0.1 → your own machine

11.4 Are `localhost` and `127.0.0.1` same?

Short Answer: No

127.0.0.1 is hard-coded as a loopback IP
localhost is configurable

Our system can map localhost to something else

In many modern systems:

localhost → ::1

::1 is the IPv6 loopback address.

11.4 Which one should we use?

Use localhost when:

Developing locally
You don't care about IPv4 vs IPv6

Use 127.0.0.1 when:

Debugging networking issues
Want guaranteed IPv4
Dealing with Docker, databases, or binding issues

11.5 A DevOps Example:

If our server logs say:

Listening on 127.0.0.1

That means:

Only this machine can access it.
Not accessible from other devices.

If it listens on:

0.0.0.0

That means:

Accept connections from any network interface.

11.6 Complete flow

We type in browser:
   `localhost`
       ↓
 OS resolves name
       ↓
   `127.0.0.1` or ::1
       ↓
 Request comes back to
   your own machine

12. Classic DevOps failure example

Problem:

App works on your laptop but not on the cloud server.

What’s happening:

App is listening on localhost
Cloud traffic comes to public IP
App never sees it

Fix:

Bind app to 0.0.0.0
Open the correct port
Allow traffic in firewall/security group

We’ll fully break this down later.

13. Hands-on commands

13.1 Check your IPs

ip addr        # Linux
ifconfig       # macOS

13.2 See listening ports

ss -tuln

netstat -tuln

13.3 Test remote port

nc -vz 13.234.56.78 443

✅ Key takeaways

IP address identifies a machine
Port identifies an application
Public IP → internet-facing
Private IP → internal-only
localhost vs 127.0.0.1
Most DevOps bugs = wrong IP, wrong port, or wrong binding

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 TCP vs UDP (Connections, Reliability, and Why It Matters)

I’ll also continue updating the GitHub repo as I progress.

📘 Learning in public

Networking 101 #2. How the Internet actually works

Himanshu Bhatt — Tue, 13 Jan 2026 15:09:50 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

How DNS works
TCP Connection & TCP Handshake
TLS Brief Overview
Complete Request Response Flow

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. Consider this scenario:

Let's say i want to visit a website:

https://myapp.com

and then i press Enter.

Let’s follow this request from start to finish.

Step 0: What does your browser actually need?

Your browser cannot talk to:

Domain names
Applications
Containers
Kubernetes

Your browser only knows how to talk to:

IP addresses
Ports
Using TCP

So the browser’s first question is:

“What IP address should I connect to?”

That’s where DNS comes in.

Step 1: DNS — Converting Domain name → IP

From Part 1:

DNS is the phonebook of the internet.

Your browser asks the operating system:

“Do you know the IP for myapp.com?”

Possible outcomes:

Case 1: DNS cache hit

If your system already knows the IP (cached):

No network request needed
Faster response

Case 2: DNS cache miss

Your system asks:

DNS resolver
Which asks other DNS servers
Until it gets an IP address

Eventually, you get something like:

myapp.com → 13.234.56.78

If DNS fails → everything stops here

Step 2: Choosing the port (HTTP vs HTTPS)

You typed:

https://myapp.com

That https matters.

It tells the browser:

Use port 443
Use encrypted communication

If it were:

http:// → port 80
https:// → port 443

So now the browser knows:

IP:   13.234.56.78
Port: 443

Step 3: TCP connection (very important)

Before any data is sent, TCP does something crucial.

TCP Handshake (conceptual)

Client: “Can I connect?”
Server: “Yes”
Client: “Okay, let’s talk”

This is why TCP is called connection-based.

If this step fails, you’ll see errors like:

Connection refused
Connection timed out

This usually means:

Firewall blocked it
Port not open
Service not running

Step 4: TLS (HTTPS security layer)

Because this is HTTPS, another step happens.

The browser and server:

Agree on encryption
Exchange certificates
Set up a secure channel

If TLS fails, you’ll see:

“Your connection is not private”
Certificate errors

DevOps engineers see this often when:

Certs expire
Domains don’t match
Load balancers misconfigured

Step 5: HTTP request is finally sent

Only now does the browser send the request:

GET / HTTP/1.1
Host: myapp.com

Important:

HTTP is inside TCP
TCP is inside IP
IP is inside the network

Think of it like nested boxes.

Step 6: The request reaches the server

On the server side:

The OS receives the packet
TCP hands data to the application
Web server (Nginx, Node, etc.) processes it
Application logic runs
A response is created

Example response:

HTTP/1.1 200 OK

Step 7: The response travels back

The response:

Goes back through TCP
Over the network
To your browser

Your browser:

Parses HTML
Loads CSS/JS
Makes more requests (repeat steps!)

One page load = many network requests

Full flow (one glance view)

Browser
  ↓
DNS (name → IP)
  ↓
TCP connection
  ↓
TLS handshake (HTTPS)
  ↓
HTTP request
  ↓
Server processing
  ↓
HTTP response
  ↓
Browser renders page

This is the core internet flow.

Everything else in DevOps builds on this.

Where things usually break (DevOps view)

Step	Common Failure
DNS	Wrong record, cache issues
TCP	Port closed, firewall
TLS	Expired certificate
HTTP	500 errors
Server	App crash, timeout

📌 Debug top to bottom, never randomly.

Commands mapped to each step

Step	Command
DNS	`dig`, `nslookup`
Reachability	`ping`
TCP	`nc`, `telnet`
HTTP	`curl`
TLS	`curl -v`, browser errors

You now know why these commands exist.

✅ Key takeaways

Browsers don’t talk to apps — they talk to IPs & ports
DNS happens before any network connection
TCP connection must succeed before HTTP
HTTPS adds a security layer on top
Every failure maps to a specific step

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 IP Addresses & Ports

I’ll also continue updating the GitHub repo as I progress.

📘 Learning in public

[Boost]

Himanshu Bhatt — Tue, 13 Jan 2026 09:32:11 +0000

Networking 101 #1. Networking Introduction

Himanshu Bhatt ・ Jan 13

#networking #devops #cloud #beginners

Networking 101 #1. Networking Introduction

Himanshu Bhatt — Tue, 13 Jan 2026 07:21:25 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

Why DevOps engineers should care about networking
The core networking mental model
DNS, IP addresses, and ports
TCP vs UDP
ICMP vs TCP vs HTTP
A practical debugging flow
Hands-on commands to make networking real

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. Why should DevOps engineers even care about networking?

Let’s start from basics.

Most DevOps failures are not code bugs.

They look like this:

❌ “The app works locally but not in production”
❌ “The service is running but not reachable”
❌ “502 Bad Gateway”
❌ “Connection refused”
❌ “Request timed out”

All of these comes down to one problem that is networking problems.

If you don’t understand networking:

You won’t know where the problem is
You’ll randomly try fixes
You’ll depend on someone else to debug

This blog series exists to change that — from zero.

2. Goal of this series

By the end of this series, you should be able to:

Understand how traffic flows from browser → cloud → server
Debug basic production networking issues
Understand Docker & Kubernetes networking at a high level
Read cloud architecture diagrams without fear
And hopefully, you and I both can confidently answer networking interview questions

3. The ONE mental model we must remember

Everything in networking can be explained using three boxes:

Client (Browser / App)
        ↓
     Network
(DNS, Internet, Load Balancer)
        ↓
Server (VM / Container / App)

Rule:

When something breaks, the problem is always in one of these boxes or the connection between them.

We’ll keep coming back to this model in every blog.

4. DNS — turning names into addresses

When you type any url into our browser:

For Example:

https://google.com

Your computer does not understand google.com.

Computers only understand numbers (IP addresses).

👉 DNS exists to solve this problem.

DNS = Name → IP address
Means resolving Name(address/url) to IP Address.

Example:

google.com → 93.184.216.34

Think of DNS like a phone book:

You search by name
You get a number

If DNS breaks, nothing works — even if your server is perfectly fine.

5. IP addresses & Ports — where and what to connect to

5.1 IP Address

An IP address identifies a machine on a network.

Examples:

192.168.1.10 (private IP)
13.234.56.78 (public IP)

Public IP → reachable from the internet

Private IP → only reachable inside a private network (like cloud VPCs - Virtual Private Cloud)

5.2 Port - Which application?

A port identifies which application on that machine we want to talk to.

Okay, so when we connect to an application, we are actually connecting to an IP address where that application is running.

However, this does not mean that only one application can run on a single IP address. In reality, mulitple application can run on the same IP address, and they are distinguished from each other using different port numbers.

Example: Let say we have a server that has an IP:

192.168.1.10

Now on this same IP, we might have:

Web app running on port 80
Backend API running on port 3000
Database running on port 5432

So:

192.168.1.10:80 → Web application
192.168.1.10:3000 → Backend service
192.168.1.10:5432 → Database

Common Ports:

22 → SSH
80 → HTTP
443 → HTTPS
5432 → PostgreSQL

IP = which computer

Port = which app on that computer

6. TCP vs UDP — how data is sent

This is about rules of communication.

6.1 TCP (most important for DevOps)

Reliable
Ordered
Connection-based

Used by:

HTTP / HTTPS
SSH
Databases

Think of TCP like a phone call:

You connect
You talk
You hang up

6.2 UDP (less common, but important)

Fast
No guarantee of delivery
No connection

Used by:

DNS (often)
Streaming
Some internal systems

Think of UDP like shouting messages — fast, but no confirmation.

7. DNS Resolution — What’s Really Happening?

Computers cannot understand domain names.

Computers only understand IP addresses like:

93.184.216.34

So when we type a domain like google.com, it must be converted into an IP address first.

👉 Finding the IP address of a domain name is called DNS resolution.

If DNS fails → nothing else matters.

8. What Happens Before ping?

Before anything else, we always ask:

What is the IP address of google.com?

Internally, this happens:

google.com → DNS → 93.184.216.34

So if DNS fails, everything fails.

9. What ping Actually Does

Once the IP is known, we use ping.

Ping sends a special network message called an ICMP Echo Request.

It’s like asking the server:

“Hey server, are you alive?”

If the server is reachable and allows ping, it replies with an ICMP Echo Reply.

Your terminal prints something like:

64 bytes from 93.184.216.34: time=12ms

This means:

The server is reachable
The network path works
The round-trip time is 12 milliseconds

By default, ping keeps sending packets every second:

ping → reply
ping → reply
ping → reply

Until you stop it with:

Ctrl + C

10. What ping Verifies vs What It Does NOT

What ping verifies:

The IP is reachable over the network
Basic connectivity exists

What ping does NOT verify:

Application is running
Website is working
Port is open
Server is healthy

A server can reply to ping and still have a down website.

11. Why ping Sometimes Fails but Website Works

Sometimes this happens:

ping google.com → ❌ fails
curl https://google.com → ✅ works

This does not mean the site is down.

Many servers block ICMP (ping) for security reasons.

12. Does ping Do DNS Resolution?

Yes, ping does DNS resolution — but only when we give it a domain name.

Example:

ping google.com

Internally:

ping sees the domain
It asks DNS to resolve it
DNS responds with:

  google.com → 93.184.216.34

ping sends ICMP packets to that IP

📌 Point to remember:

Ping does DNS only as a prerequisite, not as its main job.

If you provide an IP directly, DNS is skipped completely.

13. Why We Still Need dig & nslookup

Question:

If ping does DNS resolution, why do we need dig and nslookup?

Answer:

Ping does DNS just enough to proceed.

dig and nslookup exist to inspect and debug DNS itself.

14 ping vs dig / nslookup

Aspect	`ping`	`dig / nslookup`
Primary question answered	After resolving the name, can I reach the IP?	Is DNS working correctly?
Main purpose	Network reachability	DNS resolution & configuration
Uses DNS?	Yes (minimal)	Yes (main focus)
Shows DNS server	❌ No	✅ Yes
Shows DNS response time	❌ No	✅ Yes
Shows record types	❌ No	✅ Yes
Shows multiple IPs	❌ No	✅ Yes
Shows TTL	❌ No	✅ Yes
Affected if ICMP is blocked	❌ Yes	✅ No

15. ping Domain vs ping IP

CASE A: `ping google.com`

Domain name is provided
DNS lookup happens:

  google.com → 93.184.216.34

Ping sends packets to the IP
DNS involved only once

CASE B: `ping 93.184.216.34`

IP address is provided
DNS is skipped completely
Ping sends packets directly

One-line difference:

Command	DNS involved?	What is pinged
`ping domain`	✅ Yes	Application server IP
`ping IP`	❌ No	Application server IP

16. Why Cloud Servers Block ping

Ping uses ICMP, which is a low-level network check.

Security reasons:

Attackers can find live servers
Infrastructure mapping becomes easy
Can lead to DDoS scanning

Users don’t use ICMP.

Users use HTTP, HTTPS, APIs, TCP connections.

So blocking ping does not affect real users.

Common real-world situation:

ping myserver.com  → fails
curl https://myserver.com → works

This means:

Server is running
Application is working
ICMP is intentionally blocked

17. ICMP vs TCP vs HTTP

ICMP

Internet Control Message Protocol
Used only to check reachability
Answers: Can I reach this server at all?

TCP

Transmission Control Protocol
Opens reliable connections
Talks to applications on ports

HTTP / HTTPS

Application-level protocols
Built on top of TCP
Used by real users

Comparison

Thing	ICMP (Ping)	TCP / HTTP
Purpose	Reachability	Real communication
Uses ports?	❌ No	✅ Yes
Talks to app?	❌ No	✅ Yes
Blocked often?	✅ Yes	❌ Rarely
Used by users?	❌ No	✅ Yes

18. Check DNS Resolution

dig google.com +short

We ask the dig tool: “Hey DNS, what is the IP address of google.com?”
DNS replies with an IP like: 74.125.68.101
+short means: show only the final IP

Alternative: nslookup

nslookup google.com

nslookup (Name Server Lookup) does the same job as dig but also shows:

The DNS server used
The response details

Example output:

Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name:    google.com
Address: 93.184.216.34

19. Check Basic Connectivity

ping google.com

OR

ping 93.184.216.34

If ping fails:

Network issue
Firewall issue
Host down

20. Check If a Port Is Open (nc)

nc -vz google.com 443

What is nc (Netcat)?

Networking testing tool
Opens TCP connections
Tests if a port is reachable

Flags:

-v → verbose
-z → zero-I/O (no data sent)

Internal steps:

DNS resolution
TCP 3-way handshake
Result printed

If you see:

connection refused → service or firewall issue
timeout → routing or security group issue

21. Test HTTP Directly (curl)

curl -I https://google.com

curl = Client URL
-I = HEAD request (headers only)

Internal flow:

DNS resolution
TCP handshake
HTTP request
Response received

22. Real DevOps Debugging Order

1. DNS        → dig
2. Reachable  → ping
3. Port open  → nc
4. App works  → curl

Example:

dig google.com
ping google.com
nc -vz google.com 443
curl https://google.com

✅ Key Takeaways

DevOps problems are often network problems
Understand DNS before anything else
Ping checks reachability, not applications
Use the right tool at the right step
Debug step by step, never by guessing

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 How the Internet Actually Works

I’ll also continue updating the GitHub repo as I progress.

Final Thoughts

Networking for DevOps isn’t about memorizing protocols or becoming a networking expert overnight.

It’s about:

understanding how traffic actually flows
knowing where to look when something breaks
debugging step by step instead of guessing
building a strong mental model (Client → Network → Server)

Most production issues don’t fail because of code —

they fail because something in the network path breaks.

📘 Learning in public

📂 Repo: https://github.com/dmz-v-x/networking-for-devops-101
🐦 Twitter/X: https://x.com/_himanshubhatt1
💬 Feedback welcome — please comment if anything feels off
⭐ Star the repo if you find it useful

Introduction to DevOps #5. DevOps Tooling Landscape

Himanshu Bhatt — Mon, 12 Jan 2026 04:30:29 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning DevOps and decided to learn in public by documenting my journey.

This blog is the last part of my DevOps 101 series, where I’m learning DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

What DevOps tools are (and aren’t)
Why tooling matters in DevOps
Major DevOps tool categories
How tools fit into the DevOps lifecycle
Common misconceptions about DevOps tools
How beginners should think about learning tools

This blog gives a high-level overview, not tutorials.

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/introduction-to-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. DevOps Tools Are Enablers, Not DevOps Itself

A very important reminder:

Tools do not equal DevOps.

DevOps tools exist to:

reduce manual work
enforce consistency
automate processes

Without the right mindset:

tools become complex
automation breaks
teams struggle

Culture comes first, tools come second.

2. Why Tooling Matters in DevOps

Modern systems are:

complex
distributed
always changing

Tools help teams:

move fast safely
avoid human errors
observe system behavior
recover quickly from failures

DevOps without tools doesn’t scale.

3. Version Control (Collaboration Foundation)

Purpose:

manage code changes
collaborate safely
track history

Examples:

Git
GitHub
GitLab
Bitbucket

Why it matters:

enables team collaboration
supports automation
acts as the source of truth

4. CI/CD Tools (Automation Backbone)

Purpose:

automate build, test, and deploy
reduce manual steps
speed up releases

Examples:

Jenkins
GitHub Actions
GitLab CI
CircleCI

CI/CD helps make deployments:

repeatable
predictable
boring

5. Containerization Tools (Consistency)

Purpose:

package applications with dependencies
ensure consistent environments

Examples:

Docker
Podman

Why this matters:

eliminates “works on my machine”
simplifies deployments
improves portability

6. Orchestration Tools (Running at Scale)

Purpose:

manage many containers
handle scaling and failures

Examples:

Kubernetes
Docker Swarm

Orchestration helps with:

auto-scaling
self-healing
service discovery

7. Cloud Platforms (Infrastructure on Demand)

Purpose:

provide scalable infrastructure
reduce upfront costs

Examples:

AWS
Google Cloud
Azure

Cloud enables:

rapid experimentation
automation
global reach

8. Infrastructure as Code (Automation for Infra)

Purpose:

manage infrastructure using code
version control infrastructure changes

Examples:

Terraform
CloudFormation

Benefits:

repeatability
auditability
consistency

9. Monitoring & Observability Tools (Feedback Loop)

Purpose:

observe system health
detect issues early
support debugging

Examples:

Prometheus
Grafana
Datadog

Monitoring closes the DevOps feedback loop.

10. Logging & Alerting Tools (Visibility)

Purpose:

understand system behavior
respond to incidents

Examples:

ELK Stack
Loki
Splunk

Visibility helps teams learn from failures.

11. Common Tooling Misconceptions

Common mistakes:

learning tools before concepts
chasing every new tool
assuming one tool solves everything

Better approach:

understand the problem first
then choose the right tool

12. How Beginners Should Approach DevOps Tools

Suggested approach:

Understand DevOps concepts
Learn one tool per category
Focus on why, not just how
Build small projects
Improve gradually

DevOps mastery is a journey.

✅ Key Learnings & Takeaways

DevOps tools enable DevOps practices
Tools exist to automate and standardize
Each tool category solves a specific problem
Learning concepts before tools matters
Tooling should support culture, not replace it

DevOps works best when tools and mindset align.

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

missing tool categories,
incorrect assumptions,
or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this DevOps 101 series useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔚 Wrapping Up DevOps 101

This marks the end of the DevOps 101 series.

We covered:

What DevOps is
Why DevOps was needed
How DevOps came into existence
What problems DevOps solves
The DevOps tooling landscape

This foundation makes it much easier to:

dive into tools
build real projects
understand real-world systems

🙌 Final Thoughts

DevOps isn’t about becoming a tool expert overnight.

It’s about:

thinking in systems
improving continuously
collaborating better

Thanks for following along on this learning journey 🙌

📘 Learning in public

📂 Repo: https://github.com/dmz-v-x/introduction-to-devops-101
🐦 Twitter/X: https://x.com/_himanshubhatt1
💬 Feedback welcome — please comment if anything feels off
⭐ Star the repo if you find it useful

[Boost]

Himanshu Bhatt — Mon, 12 Jan 2026 04:26:18 +0000

Introduction to DevOps #4. What Problems DevOps Solves

Himanshu Bhatt ・ Jan 12

#devops #cloud #beginners #discuss

Introduction to DevOps #4. What Problems DevOps Solves

Himanshu Bhatt — Mon, 12 Jan 2026 04:18:26 +0000

👋 Short Intro (Why I’m Writing This)

I’m currently learning DevOps and decided to learn in public by documenting my journey.

This blog is part of my DevOps 101 series, where I’m learning DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

what I understand,
what confuses me,
and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

The core problems DevOps is designed to solve
How DevOps improves software delivery
The impact of DevOps on teams and systems
Before vs After comparisons
Why DevOps matters in the real world
How DevOps changes everyday engineering work

This blog focuses on practical outcomes, not tools.

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/introduction-to-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. Problem: Slow Software Delivery

Before DevOps:

releases were rare
deployments were stressful
shipping features took weeks or months

With DevOps:

small changes are shipped frequently
deployments are automated
feedback is faster

DevOps helps teams move fast without breaking things.

2. Problem: Risky and Unreliable Deployments

Earlier:

manual deployments
human errors
late-night rollbacks

With DevOps:

automated pipelines
repeatable processes
safer releases

Failures become:

smaller
easier to fix
less scary

3. Problem: Poor Collaboration Between Teams

Earlier:

Dev and Ops worked in silos
handoffs caused delays
blame culture existed

With DevOps:

shared responsibility
cross-functional teams
better communication

Teams stop blaming and start solving problems together.

4. Problem: Environment Inconsistency

Earlier:

different setups everywhere
“works on my machine” issues
unpredictable behavior

With DevOps:

consistent environments
automation ensures repeatability
fewer surprises

Consistency builds confidence.

5. Problem: Slow Feedback Loops

Earlier:

bugs discovered late
users reported issues first
debugging was hard

With DevOps:

monitoring and logging
fast alerts
quick feedback

Teams learn faster and improve continuously.

6. Problem: Systems That Don’t Scale Well

Earlier:

manual scaling
guesswork
downtime during traffic spikes

With DevOps:

automated scaling
infrastructure as code
predictable behavior under load

Systems grow without chaos.

7. Problem: Burnout and Stress

Earlier:

long release nights
constant firefighting
high stress

With DevOps:

boring deployments
clear processes
shared on-call responsibility

DevOps improves developer experience, not just systems.

8. Before vs After (Quick Comparison)

Before DevOps:

slow releases
manual deployments
silos
blame culture
unstable systems

After DevOps:

frequent releases
automation
collaboration
ownership
reliability

The difference is huge.

9. Why Businesses Care About DevOps

DevOps enables:

faster time to market
better customer experience
reduced downtime
lower operational costs

It aligns engineering with business goals.

10. DevOps Solves System-Level Problems

DevOps doesn’t fix:

bad code
poor requirements

But it does fix:

broken processes
slow feedback
operational bottlenecks

It optimizes the entire system, not just one part.

✅ Key Learnings & Takeaways

DevOps solves real, painful problems
Automation reduces risk and stress
Collaboration improves outcomes
Faster feedback leads to better systems
DevOps benefits both engineers and businesses

DevOps is valuable because it actually works.

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

something missing,
a real-world example to add,
or a better explanation,

please comment below. I’m here to learn and improve.

⭐ Support the Learning Journey

If you find these notes useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 DevOps Tooling Landscape (High-Level Overview)

I’ll also continue updating the GitHub repo as I progress.

🙌 Final Thoughts

DevOps is valuable because it solves problems
teams face every single day.

Understanding these benefits makes the tooling
much easier to learn later.

DEV Community: Himanshu Bhatt

HTML-101 #6. Paths, Anchor Tag, Mail & Phone Links

👋 Short Intro (Why I’m Writing This)

📌 What This Blog Covers

📂 GitHub Repository

📚 Learning Notes

1. Quick recap — What a path is (1 line)

2. Anchor tag basics — what is <a>?

3. Types of href values

3.1 Absolute URL (external)

3.2 Root-relative path

3.3 Relative path

3.4 Fragment / Anchor (jump within page)

3.5 mailto: (email) and tel: (phone)

4. Anchor tag anatomy (basic + attributes)

5. Link states & basic styling

6. Accessibility & keyboard behavior

7. Anchor vs Button — When to use what?

8. download attribute (force download suggestion)

9. Mailto links — more details & extras

10. Tel links — formatting & best practice

11. Usability & accessibility tips for mail/tel links

12. Common mistakes (summary)

⚠️ Challenges / Mistakes I Faced

💬 Feedback & Discussion

⭐ Support the Learning Journey

🐦 Stay Updated (Twitter / X)

🔜 What’s Next

🙌 Final Thoughts

Networking 101 #6. Subnets, CIDR & NAT

👋 Short Intro (Why I’m Writing This)

📌 What This Blog Covers

📂 GitHub Repository

📚 Learning Notes

1. First: why do subnets even exist?

2. What is a subnet?

3. Why cloud providers force you to use subnets

4. What is CIDR (the scary /24 thing)?

4.1 CIDR without math (promise)

4.2 What /24 actually means

5. Why CIDR matters in real DevOps work

6. Public vs Private subnets

6.1 Public Subnet

6.1 Private Subnet

7. How do private subnets access the internet?

7.1 What is NAT (Network Address Translation)?

7.2 NAT explained simply

8. Why NAT is critical for security

9. Common DevOps architecture

10. How subnet issues show up in real life

11. Mini hands-on mental exercise

12. Mental model upgrade

✅ Key takeaways

💬 Feedback & Discussion

⭐ Support the Learning Journey

🐦 Stay Updated (Twitter / X)

🔜 What’s Next

📘 Learning in public

Networking 101 #5. DNS Explained

👋 Short Intro (Why I’m Writing This)

📌 What This Blog Covers

📂 GitHub Repository

📚 Learning Notes

1. Quick recap (from earlier blogs)

2. What actually happens during DNS resolution

3. DNS resolution flow (simplified)

4. What is DNS caching?

5. TTL — Time To Live

6. Real DevOps DNS failure example

7. Common DNS record types (DevOps must-know)

7.1 A Record

7.2 CNAME Record

7.3 TXT Record

8. Why CNAMEs matter in DevOps

9. Common DNS debugging commands

9.1 Check DNS resolution

9.2 Use a specific DNS server

9.3 See only the IP

9.4 Using nslookup

10. Why DNS works for some users and not others

2. Anchor tag basics — what is `<a>`?

3. Types of `href` values

3.5 `mailto:` (email) and `tel:` (phone)

8. `download` attribute (force download suggestion)

4. What is CIDR (the scary `/24` thing)?

4.2 What `/24` actually means

11. `localhost` vs `127.0.0.1`

11.2 What is `localhost`?

11.3 How does `localhost` actuallly works?

11.4 Are `localhost` and `127.0.0.1` same?