DEV Community: joietej

The Old Guard vs. The New Way: Traditional Infrastructure Management vs. Modern DevOps

joietej — Sun, 01 Mar 2026 16:05:45 +0000

How we went from "don't touch the server" to "let's destroy it and rebuild it in 30 seconds"

If you've been in software long enough, you remember it. The sacred server room. The deployment checklist that was 47 steps long. The one person in the team who actually knew how the production server was configured — and everyone praying they never went on vacation.

That was the world of traditional infrastructure management. And while it worked (mostly), it also held teams back in ways we didn't fully appreciate until the DevOps revolution changed everything.

Let's walk through what's changed, why it matters, and what the shift really looks like on the ground.

The Traditional Way: Servers Are Pets

In the traditional model, servers were pets — lovingly named, carefully maintained, and irreplaceable. Think PROD-SVR-01, hand-configured by a sysadmin over a weekend, with configuration details living in someone's head (or if you were lucky, a Word document from 2014).

How deployments worked

The typical deployment in a traditional setup looked something like this:

A developer writes code and "throws it over the wall" to the operations team.
Ops receives a deployment package — a ZIP file, an MSI, a WAR file — along with a set of instructions.
Someone remotes into the production server (often via RDP or SSH).
They manually stop services, back up files, copy over new binaries, update config files, restart services.
They test by opening the browser and clicking around.
If something breaks, they roll back by restoring the backup. Hopefully it works.

This process was slow, error-prone, and terrifying. Friday deployments were avoided like the plague. "Change Freeze" periods lasted weeks. And every release felt like defusing a bomb.

Infrastructure provisioning

Need a new server? Here's what that looked like:

Raise a ticket with the infrastructure team.
Wait 2–6 weeks for hardware procurement and rack-and-stack.
Sysadmin manually installs the OS, patches it, configures networking, installs dependencies.
Another ticket to the security team for firewall rules.
Another ticket to the DBA for database access.
Hope that the staging environment is "close enough" to production. (Spoiler: it never was.)

The pain points

Snowflake servers: Every environment was unique. "Works on my machine" was a daily reality.
Manual, undocumented processes: Tribal knowledge ruled. If the person who set it up left, you were in trouble.
Slow feedback loops: Developers wouldn't know their code broke production until days or weeks later.
Fear of change: Because deployments were risky, teams deployed less often — which paradoxically made each deployment riskier because it packed in more changes.
Blame culture: Dev blamed Ops. Ops blamed Dev. Nobody owned the full pipeline.

The Modern DevOps Way: Servers Are Cattle

In the DevOps world, servers are cattle — identical, numbered, and replaceable. If one gets sick, you don't nurse it back to health. You terminate it and spin up a new one. The entire infrastructure is defined in code, versioned, reviewed, and automated.

How deployments work now

A modern CI/CD pipeline looks radically different:

Developer pushes code to a Git branch.
A pull request triggers automated builds, linting, unit tests, integration tests, and security scans.
On merge to main, the CI/CD pipeline (Azure DevOps, GitHub Actions, GitLab CI — pick your flavor) automatically builds a container image or deployment artifact.
The pipeline deploys to a staging environment that is identical to production (because both are defined by the same Infrastructure as Code templates).
Automated smoke tests and health checks run.
If everything passes, the pipeline promotes to production — often using blue-green deployments or canary releases to minimize risk.
Monitoring and alerting kick in immediately. If error rates spike, an automatic rollback is triggered.

The whole process? Minutes. Not days. And no human had to SSH into anything.

Infrastructure provisioning

Need a new server — or an entire environment?

terraform apply

That's a slight simplification, but not by much. With Infrastructure as Code (IaC) tools like Terraform, Bicep, Pulumi, or AWS CloudFormation, your entire infrastructure is defined in version-controlled configuration files. Need a new environment? Run the pipeline. Need to tear it down? Run the pipeline again. Need to know exactly what's running in production? Read the code.

What makes this work

Infrastructure as Code (IaC): Every server, database, network rule, and load balancer is defined in code. Reviewed in PRs. Tested before deployment.
Containers & orchestration: Docker packages your app with all its dependencies. Kubernetes (or Azure Container Apps, ECS, etc.) manages scaling, health, and networking.
CI/CD pipelines: Automated pipelines ensure every code change goes through the same rigorous process — build, test, scan, deploy.
Immutable infrastructure: Instead of patching servers in place, you build a new image and replace the old one. No configuration drift. No "what version is running on that box?"
Observability: Centralized logging (ELK, Azure Monitor, Datadog), distributed tracing, and metrics dashboards mean you know what's happening in production right now.
Shift-left security: Security scanning happens in the pipeline, not as an afterthought before go-live.
GitOps: The Git repository is the single source of truth. What's in main is what's in production. Period.

A Side-by-Side Comparison

Aspect	Traditional	Modern DevOps
Server identity	Named pets (hand-configured)	Numbered cattle (auto-provisioned)
Deployment frequency	Monthly or quarterly	Multiple times per day
Deployment method	Manual (RDP/SSH, file copy)	Automated CI/CD pipelines
Rollback strategy	Restore backup and pray	Automated rollback, blue-green, canary
Infrastructure setup	Weeks (tickets, manual config)	Minutes (IaC + pipelines)
Environment consistency	"Close enough"	Identical (same IaC templates)
Documentation	Word docs, wikis, tribal knowledge	The code is the documentation
Monitoring	Check logs manually, wait for user complaints	Real-time dashboards, alerts, auto-healing
Team structure	Dev and Ops are separate silos	Cross-functional teams own the full lifecycle
Change management	Heavyweight CAB approvals	Lightweight, automated guardrails
Failure recovery	Hours to days	Seconds to minutes

The Cultural Shift Matters Most

Here's the thing people often miss: DevOps isn't just about tools. You can adopt Kubernetes, Terraform, and GitHub Actions, and still operate like a traditional shop if the culture doesn't change.

The real transformation is in ownership and collaboration:

Developers own their code in production. "I wrote it, I deploy it, I monitor it."
Ops engineers write code and build platforms, not manually configure servers.
Failures are treated as learning opportunities (blameless postmortems), not occasions to find someone to blame.
Small, frequent changes replace big-bang releases. Each change is lower risk, easier to understand, and simpler to roll back.

Does This Mean Traditional Is Dead?

Not entirely. There are still environments — legacy systems, regulated industries, air-gapped networks — where traditional approaches persist, sometimes for valid reasons. Not every organization can (or should) move to containers and Kubernetes overnight.

But the direction is clear. Even organizations in heavily regulated sectors (banking, healthcare, government) are adopting DevOps practices — automated pipelines, IaC, immutable deployments — because the reliability and speed benefits are too significant to ignore.

The question isn't whether to adopt modern DevOps practices. It's how fast you can get there — and what's holding you back.

Final Thought

If you're still deploying by remoting into a server and copying files, you're not just slow — you're accumulating risk with every release. The modern DevOps toolchain exists precisely because the old way didn't scale, wasn't reliable, and burned people out.

The best part? You don't have to adopt everything at once. Start with CI/CD. Add IaC. Containerize one service. Build from there.

The servers don't care if they're pets or cattle. But your team — and your customers — certainly will.

What does your deployment process look like today? Still somewhere in between? I'd love to hear about your journey — the good, the bad, and the "we don't talk about that deploy."

I Used 22 Prompts to Plan an Entire MuleSoft-to-.NET Migration. Here's the Playbook.

joietej — Sat, 28 Feb 2026 16:15:42 +0000

Last week I sat down to migrate a MuleSoft integration project to .NET 10 Minimal APIs. Instead of spending days writing migration specs, architecture docs, and agent team definitions manually, I paired with Claude to do it in a single conversation.

22 prompts. That's all it took to go from "where do I start?" to a fully structured, audited, ready-to-execute migration toolkit -- complete with scanner agents, phased prompts, integration patterns, and project scaffolding.

Here's exactly how I did it, broken into a repeatable playbook any dev team can follow.

Phase 1 -- Explore & Ground the AI in Your Codebase

Most developers start an AI conversation with a wall of text explaining everything upfront. Don't.

Start broad. Let the AI propose an approach first, then steer it.

My opening prompt was simple:

"What is the best approach to convert MuleSoft to C# Minimal API?"

Claude came back with a solid general strategy -- Strangler Fig pattern, connector mapping tables, a phased approach. Good foundation, but generic. It didn't know my stack.

So I pointed it at my actual code:

"Check my project on GitHub for the target architecture"

It pulled the wrong repo at first. I corrected it:

"That's not the right repo -- try this URL instead"

This is the key insight: the AI produces dramatically better output when it's grounded in your real project, not a hypothetical one. Once it read my solution structure, EF Core setup, Polly config, and Azure AD auth -- everything it generated afterward was contextually accurate.

Takeaway: Don't explain your architecture in prose. Point the AI at your code and let it read.

Phase 2 -- Request Deliverables That Match Your Tooling

Once the AI understands your codebase, ask for output in the format you'll actually use. Not a blog post. Not a summary. The actual artifact.

"Can you create detailed agent team definitions I can use with Claude Code CLI?"

Claude generated a full set of agent team roles, prompts, and coordination rules -- tailored specifically for Claude Code's agent teams feature. But when I reviewed the output, I spotted a gap:

"We're missing a step -- we need to scan and inventory the source project before migrating anything"

This is where it gets interesting. The AI didn't think of a Phase 0 scanner because I hadn't mentioned one. But the moment I flagged the gap, it built a comprehensive 5-agent scanner team that parses MuleSoft XML flows, catalogs DataWeave transforms, maps connectors to NuGet packages, and generates a phased migration plan.

Then I fed it domain knowledge it couldn't possibly discover on its own:

"I already know the integrations we use -- Azure AD auth, Key Vault for secrets, Graph API for user management, Box for documents, and SQL Server stored procedures"

With this, it pre-seeded the scanner with ready-to-use C# implementation patterns for each integration -- complete with typed clients, DI registration, and config examples. No hallucinated APIs. No outdated SDK calls.

Takeaway: The AI can't read your production systems. Feed it what you know, and it'll build on top of that knowledge rather than guessing.

Phase 3 -- Challenge Architecture Decisions

Here's where most people go wrong with AI: they accept the first answer. Don't. Debate it.

I initially suggested:

"I think we should copy the source code into a docs folder inside the project"

Then immediately challenged my own idea:

"Actually no -- the source should stay external and never be modified. Ask the user for the path at runtime instead"

This back-and-forth -- which took maybe 30 seconds -- resulted in a fundamentally better design. The MuleSoft project stays read-only in its original location. The scanner asks for the path. No file duplication. No accidental modifications. Clean separation.

The AI adapted instantly. It rewrote the Phase 0 init prompt to ask for the path, updated all agent team definitions to reference MULE_SOURCE_PATH, and added validation for the directory structure.

Takeaway: The best architecture emerges from debate, not from prompting. Push back on the AI. Push back on yourself. The AI is fast enough to restructure everything in seconds.

Phase 4 -- Evolve the Design as Context Changes

Real projects don't stand still while you plan. Midway through my session, the project structure changed.

I was building the template in a parallel Claude session and realized:

"This is a reusable template, not the actual project -- we need a scaffolding step that renames everything"

Claude immediately generated init scripts for both Bash and PowerShell. But then my other session handled it differently using dotnet new template engine with sourceName:

"Another session is handling the template config already, so we don't need the init script anymore -- drop it"

Most developers would forget to tell the AI about this. They'd end up with duplicate work, conflicting approaches, and docs that reference deleted files. Instead, one prompt -- "drop it" -- and Claude removed the scripts, updated all cross-references, and simplified the workflow.

Takeaway: When something else handles a concern, tell the AI to remove work -- not just add more. AI-generated docs with stale references are worse than no docs.

Phase 5 -- Quality Gate Before Shipping

AI makes consistency errors. Across 6 interconnected files, there will be naming leaks, broken cross-references, and stale paths. Always audit before shipping.

I caught the first issue:

"The generated config still has hardcoded project name references -- it needs to use generic placeholders"

Then the repo structure changed:

"These files belong in a separate toolkit repo -- here's the folder structure, reorganize everything to fit"

And finally, the most important prompt of the entire session:

"Do a deep review of every file -- check cross-references, path consistency, typos, and logical errors"

Claude ran a 12-point audit across all files. It found and fixed: inconsistent placeholder names ({Name} vs {ProjectName}), wrong MuleSoft directory paths in quick-reference prompts, a typo in a JSON config (EnterprisId), stale "copied to" language that should have said "accessible at", and old file names in cross-references.

Without that final audit, I would have shipped docs that pointed to non-existent files and used incorrect MuleSoft paths. The audit took 2 minutes. It would have cost hours of debugging later.

Takeaway: Never ship AI-generated output without a final audit pass. Ask the AI to check its own work -- it's surprisingly good at catching its own mistakes when you explicitly ask.

The Playbook

Here's the pattern, distilled:

Start broad -- let the AI propose, don't over-specify upfront
Ground it in real code -- point at your actual repo, not a hypothetical one
Request usable artifacts -- ask for the format your tooling actually consumes
Feed domain knowledge -- tell it what you know about your integrations, constraints, and systems
Identify gaps -- review output and flag what's missing
Debate architecture -- push back on assumptions, including your own
Evolve the plan -- when context changes, update the AI and remove stale work
Audit everything -- demand a thorough cross-file review before shipping

22 prompts. One conversation. A complete migration toolkit with scanner agents, phased migration prompts, integration patterns, setup guides, and project scaffolding -- all verified, cross-referenced, and ready to use.

The AI didn't replace my judgment. It amplified it. Every architectural decision was mine. The AI just made it possible to execute on those decisions in hours instead of days.

AI Won't Save You If You Don't Know What Good Code Looks Like

joietej — Thu, 12 Feb 2026 11:48:29 +0000

Every other post on your feed is telling you AI tools are going to "revolutionize" your coding workflow. And they're not wrong — these tools are powerful. But here's what nobody's saying loud enough: the developer using the tool still matters more than the tool itself.

I've been using AI coding tools daily for a while now. Terminal agents, chat-based assistants, autocomplete — the whole stack. And the single biggest lesson? You need discipline. The AI is your assistant, not your brain.

You Still Need to Know What Bad Code Looks Like

Whether you're two years into your career or twenty, the basics don't become optional just because AI can generate code for you. I've watched developers prompt an AI, get back 150 lines, paste it into their project, and move on. No review. No understanding. Just vibes. Then something breaks and they're stuck, because they never understood what that code was doing.

Here's the uncomfortable truth: AI tools don't close the gap between strong and weak developers. They widen it. If you understand what's happening under the hood — how requests flow, how queries execute, how auth actually works — you'll catch the AI's mistakes before they hit production. If you don't, you'll ship them.

AI Will Over-Complicate Things. Every. Single. Time.

This is the pattern I see most consistently. Ask AI to solve a problem and it'll hand you the over-engineered version by default. You need a simple config change? Here's an abstraction layer. You need to parse a string? Here's a utility class with eight methods and an interface.

I've lost count of how many times I've looked at AI output and thought "this could be five lines." And it could. But the AI doesn't optimize for simplicity — it optimizes for covering every possible edge case, even the ones that don't apply to your situation.

Your job is to look at the output and ask: is this the simplest thing that works? That judgment — knowing when 50 lines should be 5 — doesn't come from AI. It comes from years of writing, reading, and debugging real code. There's no shortcut.

The Debugger Is Still Your Best Friend

Here's what the "AI-first" crowd conveniently skips: interactive debugging is still the most powerful skill you have.

Set a breakpoint. Step through. Watch the variables. Understand the flow. When AI-generated code doesn't work — and it won't, regularly — your ability to fire up the debugger and trace the problem line by line is what separates you from someone who just pastes the error message back into the chat and hopes for the best.

I'll admit, I've been that person. Early on with these tools I caught myself in a loop — AI generates code, doesn't work, I feed the error back, AI generates a "fix" that introduces a new problem, I feed that back, and three rounds later I've got a mess that's worse than where I started. The moment I stopped and opened the debugger, I found the issue in two minutes. It was a one-line fix.

That try-and-error loop — write, run, break, fix — has always been the heartbeat of development. AI doesn't replace it. It just changes who's typing. But you still need to be the one who knows whether the fix actually makes sense.

The Smart Way to Automate

Now here's the real unlock. Tools like agentic coding assistants can actually run your code, see the error, fix it, and iterate — all without you typing. That's powerful. But it only works if you've defined what "correct" looks like. Good tests. Clear acceptance criteria. Known expected behavior.

Without that, the AI will happily iterate itself into a solution that passes but is unmaintainable nonsense. I've seen an agent loop five times and produce something I could've written by hand in two minutes — except mine would've been half the lines and actually readable.

And the ecosystem is only getting deeper. Claude Code now has plugins like Ralph for autonomous coding loops, Context7 for live API docs, and Playwright for browser testing — all running inside your terminal. On the non-dev side, Cowork plugins and connectors are letting teams wire up Asana, Linear, Notion, and more into AI-driven workflows. The entire try-and-error loop — from ticket to code to test to deploy — is becoming automatable. But "automatable" doesn't mean "unattended." Someone still needs to define the guardrails, review the output, and know when the machine is confidently wrong.

Automation is brilliant for boilerplate, for repetitive scaffolding, for the stuff where you know exactly what you want but typing it out is tedious. It's dangerous the moment you use it as a substitute for understanding.

The One Thing That Actually Matters

Junior or senior, it doesn't matter. The developers who get the best output from AI are the ones who could've written the code themselves — maybe slower, but correctly. They use AI to move faster, not to think less.

If you can't tell good output from bad, AI won't fix that. If you can, AI becomes the best productivity tool you've ever had.

That's the discipline. And no AI is going to learn it for you.

Full transparency: This article was written with the help of AI. The core ideas, opinions, and experiences are entirely mine — but I used AI to help structure, critique, and refine the writing. Felt only right to practice what I preach.

Flex

joietej — Wed, 11 Dec 2019 20:00:10 +0000

Wow ! I am on my second story !

In this story, I want to briefly talk about my fev layout container !

I am not a fan of bootstrap style layout system so I was thrilled when I read about flexbox and css grid.

Flexbox reminds me of WPF StackPanel which is also one dimensional .

I would highly recommend this amazing article to understand how flexbox works it’s magic.

Here is a quick recipe to create
flex container :

1.Set display:flex
2.Set flex-direction to 'row' or 'column'
3.Set ‘justify-content ‘ to align items across MAIN axis.
4.Set ‘align-items ‘ to align items across CROSS axis.

Even after reading a couple of in-depth articles ,I was still confused about 'justify-content' and 'align-items' ☢️.

Finally I decided to create simple component to clear the confusion .
Here it is ‘Stack’ component inspired by StackPanel 💡.

Singularity

joietej — Wed, 11 Dec 2019 11:03:59 +0000

I am lazy as ×××× ( fill in whatever that suits u 😉) so I have never considered writing about anything ...It too much for me but hay u have to start somewhere, hence I have decided to break the dragon eggs and let my inner dragon out ...

This is part 1 of a series of articles or it could be the first and last one who knows !

Prologue:

Apart for being lazy I have never contributed to open source projects as I was spending most of my free time doing photography and watching TV. I don't have to tell you that it hurts when u do interviews so I decided to create showcase project with all fancy techno stuff that I want to learn and/or want to use.
After 6-8 weeks, I managed to create decent prod ready application ( client and server less backend ) and that's what I am going to write about.

My initial plan was to create cross platform responsive app with serverless architecture preferably with CQRS/Event Sourcing (yeah baby) and functional language like F#.

I currently work in the hospitality industry so it's as natural for me to pick the same domain for the sake of familiarity.

Here is my initial tech stack :

FE :
React & some fancy component library to force design language i.e. Ionic /Material UI etc.
BE:
Everything Azure

For BE I could send 130 euro per month as it comes with MSDN subscription .

For FE : I choose React as it's my personal choice than anything else. I love it for its simplicity .

Component libraries : This was really a difficult choice to make. I tried a couple of libraries like MatrtialUI, React Bootstrap , Ant Design etc. My basic requirement was to have one library that has decent scheduler component , data driven components and built for desktop web app. After couple of days of painful evaluation, I came to the conclusion that none of these libraries provide what I wanted .
But I have to start with something so I picked react-uwp due to its native win 10 fluent design. It provides nice themes and sidebar for electron desktop app and decent basic controls. I was happy about my choice and I made good progress in one week.

I would write tomorrow (hopefully ☺️) about what I had learnt in that first week..

Ciao !