DEV Community: tusharsharma099

Don’t Learn DevOps Before Understanding Web Development

tusharsharma099 — Sat, 24 Jan 2026 10:40:02 +0000

When people ask me how to start learning DevOps or Cloud, I always say the same thing:

“First, build a simple three-tier web app — even if it’s just a Hello World.”

And they usually look confused.
_“Why? I want to be a DevOps engineer, not a web developer.”
_
I get it — I said the same thing once.

How I Started

I began my career as a backend-focused web developer.
I spent my days writing APIs, debugging weird server errors, and figuring out why that one endpoint suddenly returned 500 after deploying.

Eventually, I moved into DevOps and Cloud Engineering — and that’s when I realized how much my development background saved me.

Because here’s the truth:
You can become a DevOps engineer without learning web development — but you’ll never be an impactful one until you understand why things are built the way they are.

The “Why” Behind the Tools

A lot of new DevOps learners jump straight into Kubernetes, Docker, Terraform, or AWS.
They follow the roadmaps, memorize commands, spin up clusters — and then hit a wall.

Because when something breaks, they have no clue whether it’s an app problem, a config issue, or an architectural flaw.
They know how to deploy, but not what they’re actually deploying.

That’s what I call the** “tooler trap”** — knowing tools, but not the system.

A Simple 3-Tier App Can Teach You Everything

You don’t need to build a full SaaS to understand the ecosystem.
Just develop a 3-tier Hello World app:

Frontend: even a static page with a button
Backend: a small API that returns “Hello, world”
Database: maybe a single table or record
Then deploy it.
Host the backend somewhere, connect it to the DB, expose an endpoint, and open it in a browser.

That process alone will teach you how data flows, where bottlenecks form, **and **why infrastructure matters.
Once you see that flow end-to-end, every DevOps concept — CI/CD, load balancing, monitoring, scaling — starts making sense, not just noise.

Real DevOps Is About Solving Problems, Not Running Pipelines

A “tooler” can build a Jenkins pipeline or deploy to AWS.
A real DevOps engineer can look at a system and ask,

“Why is this deployment taking 8 minutes?”
“Why is our API timing out?”
“Why does our architecture break under load?”

Those questions can’t be answered without understanding the application layer.
If you’ve never built or debugged a web app, you’ll miss the reasoning behind every DevOps decision.

DevOps is not about using tools — it’s about solving the pain developers face every day.
And you can’t fix pain you’ve never felt.

My Advice
If you’re new and aiming for DevOps or Cloud:

Yes, learn the tools. But first, build something that uses them.
Yes, you can skip web dev — but then you’ll miss the “why” that makes DevOps meaningful.
Start small. A simple 3-tier Hello World will teach you more than any crash course on Terraform or Kubernetes ever could.
Because once you understand why developers struggle, every automation you create will have** purpose **— not just pipelines.

Final Thoughts

DevOps isn’t just a stack of tools; it’s a mindset built on understanding how software works, from code to customer.
You don’t have to become a full-stack developer — but you should at least experience the stack once.

Otherwise, you’ll always stay a tooler, not an engineer — busy setting up systems that solve no real problems.

And that’s not DevOps. That’s just decoration.

📬 Contact
If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

LinkedIn: www.linkedin.com/in/tushar-sharma-77063225b

From 1.2GB to 54MB: My Docker Image Went on a Diet

tusharsharma099 — Tue, 02 Dec 2025 10:36:20 +0000

When I first containerized a Node.js app, I felt pretty good about myself. I had a Dockerfile, I built it, and it worked.

Then I checked the size.

1.2GB. For a single Node.js service.

That’s when reality hit me. My image wasn’t lean—it was obese. It slowed down builds, bloated my CI/CD pipeline, took forever to push to the registry, and ate storage like there was no tomorrow.

So, I put my Docker image on a strict diet. After a few rounds of optimizations, it went from 1.2GB → 250MB → 54MB.

Here’s the story of how I cut the fat—and how you can too.

Step 1: The Heavyweight Start
Here’s what my original Dockerfile looked like:

node:16 is Debian-based and heavy (~350MB).
npm install installed everything-dev and production dependencies.
No .dockerignore, so logs, git history, and node_modules sneaked into the image

The result? A 1.2GB monster that slowed everything down.

Step 2: Choosing a Leaner Base
The first fix was swapping node:16 for node:16-alpine.

That one-line change cut my image down to ~250MB.

Lesson: Your base image choice can make or break your build.

⚠️ Caveat: Alpine uses musl instead of glibc. If your app has native modules (sharp, bcrypt, canvas), you may need extra packages.

Step 3: Multi-Stage Builds
My app uses TypeScript, so I had build tools sitting inside the final image. Big mistake. They added hundreds of MBs I didn’t need in production.

Enter multi-stage builds:

Now, the final image contains only:

Compiled JavaScript (dist/)
Production dependencies No dev dependencies. No build cache. No clutter.

This dropped my image to ~120MB.

Step 4: Prune and Ignore Junk
Another culprit: files that had no business being in production.

I added a .dockerignore:

And I cleaned up caches in the Dockerfile:

End result: no accidental junk, no wasted MBs.

Step 5: Minimize Layers
At first, I had a Dockerfile with multiple RUN statements:

Each RUN adds a layer. I combined them into one:

This small tweak shaved off ~15MB. Not huge, but every MB counts when you’re pulling images in production.

Step 6: Measuring and Iterating
The key to trimming images is measuring:

With docker history, I saw exactly which layer was eating space and optimized from there.

Final Weight Check
Original: 1.2GB
After switching to Alpine : ~250MB
After multi-stage + pruning: 120MB
After .dockerignore + cleanup: 54MB 🎉
That’s a ~95% reduction. Pulls went from minutes to seconds, and CI/CD pipelines stopped crawling.

Lessons Learned
Pick the right base image – Defaults are rarely optimal.
Multi-stage builds are gold – Keep dev tools out of production.
Use .dockerignore religiously– Don’t ship junk.
Prune aggressively – Caches, logs, temp files… delete them.
Measure constantly– Know what’s eating space before fixing it.

Conclusion
Cutting Docker image size isn’t just about bragging rights—it’s about faster deploys, lower registry costs, and fewer headaches.

My Node.js image went on a diet and lost 1.1GB, and I’ll never go back to lazy Dockerfiles again.

If your containers are bloated, trust me: a few tweaks can make them featherweight.

So… is your Docker image on a healthy diet?

📬 Contact
If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

GitHub: https://github.com/tusharsharma099
LinkedIn: www.linkedin.com/in/tushar-sharma-77063225b