A Developer’s Identity Crisis
Microservices vs Monolith
By Nigel Dsouza
Once, we were the keepers of monoliths — towering codebases that held everything in one place.
They were messy, sure.
But they were whole. Understandable.
Then the industry told us to break them.
Split the monolith. Decouple everything.
The age of microservices arrived.
And suddenly, being a developer wasn’t about understanding the system —
It was about understanding your part in it.
🧩 The Birth of the Fragmented Engineer
In the monolith world, you were a builder of cities.
Now, in microservices, you’re a plumber for a single street.
You own service-accounts-api-v2 — not the domain, not the flow, just the pipe.
And while that’s scalable, it’s also disorienting.
We went from architects to tenants.
From creators to maintainers.
And many of us — whether we admit it or not —
miss the clarity of the monolith.
🧪 The Myth of Autonomy
Microservices promised autonomy.
Teams could own their services end to end.
But in practice?
We’ve traded cross-functional ownership for cross-team dependencies.
Want to change how onboarding works?
- You need five approvals
- Three PR merges
- And a Slack thread with someone named
DevOpsDragon420who hasn’t replied in days
Autonomy, it turns out, is a UX problem.
🧠 Monolith as Memory
A monolith is a system with a story.
You can scroll through a file and see the shape of decisions made over time.
You can feel the evolution — the good, the bad, and the hacks that shipped Friday night.
Microservices?
They’re amnesiacs. Stateless. Isolated.
Designed to forget everything except their job.
They scale beautifully.
But they don’t remember why.
🧭 The Developer’s Dilemma
As engineers, we crave:
- Clarity
- Narrative
- Control
But our tools are increasingly:
- Modular
- Distributed
- AI-assisted
We’re being asked to write symphonies —
while only composing trumpet parts.
So we cling to architecture diagrams like they’re treasure maps.
We over-document.
We invent endless tooling just to reconstruct a view of the system we once held in our heads.
🛠️ Reclaiming Identity in a Distributed World
It’s time to stop pretending this isn’t hard.
It’s time to design systems that are not just decomposed — but discoverable.
That tell their story.
That welcome new developers like tour guides, not gatekeepers.
That let engineers feel whole again.
Because whether we write monoliths or microservices —
We are still storytellers.
Still problem-solvers.
Still creators.
And we deserve systems that don’t just scale —
But make us feel like developers again.
👤 About the Author
Nigel Dsouza is a Principal Software Engineer at Fidelity Investments.
He’s built monoliths, broken them, and stitched them into clouds.
He writes not just for the machines,
but for the developers trying to remember why they started.
Top comments (13)
This lovely piece of article by Nigel explains how today Developers are at crossroads in todays highly modern automated world and resultant identity crises. It bares the truth that earlier in the monolith era, developers had a holistic understanding and were builders of entire applications. However, with microservices today, that clarity is lost and Developers now only maintain fragmented, isolated services, often disconnected from the broader system. Earlier, Monoliths preserved the history and maintained rationale behind decisions. Today, microservices leads to increased complexity and dependencies and lack narrative. It becomes more of a dull drag world
Nigel urges developers to reclaim their identity — not just as code custodians, but as storytellers, creators, and engineers with a vision.
Nigel, how then can we keep sight of the big picture? Being an expert in a niche is fine, but who or what will oversee the various niches working seamlessly together? Or will the weakest link in the chain snap and sink the ship?
While microservices offer advantages in scalability and flexibility, Nigelt highlights the need to address the human element of software development. By designing systems with developer clarity, narrative, and control in mind, organizations can empower their engineers and make working with microservices a more fulfilling experience. Well expressed!
Really enjoyed reading this. You have put into words something a lot of developers quietly wrestle with. That uncertainty around identity—am I technical enough, creative enough, or in the right space—is so relatable. The way you described your experience at the IBM bootcamp felt very real, especially how asking design questions made you think differently.
It is refreshing to see someone embrace that overlap between design and development without trying to box themselves in. The piece flows nicely and feels honest, not overthought. Just a solid reminder that it is okay to grow in unexpected directions.
Great topic! General rule of thumb in my opinion:
Microservice for performance reasons. For example, if you have something like an image resizer, it might require significant resources, and therefore it doesn't make sense to buy more compute for your main app. You could save on infrastructure costs by building an on-demand service in Cloudflare or other serverless providers.
Microservice for security reasons. You may have a transactions microservice that requires extra layers of security, a separate DB, and that kind of thing.
You have an API that will be used by various frontends like mobile, web, and even admin panels. While not exactly a microservice, this should be decoupled from the UI.
Microservice for newer tech when you have a legacy codebase. You may have an older codebase that's 3-4 versions behind and too expensive to upgrade, but you need features available in newer versions. Should be last resort though.
Microservice if you are using vastly different technologies. For example, you may have a webapp in Laravel, but need to implement some machine learning feature that requires a custom-trained model. Naturally, Python is the go-to language here because PHP is not designed for machine learning. Thus, it makes sense to have a separate service just to handle all the machine learning aspects.
Microservice for big teams. If you have large teams of 30+ developers. Sometimes, for practicality, it makes sense to have niche microservices managed by specific teams. This requires careful consideration, though, and shouldn't be done just for the sake of doing so.
Monolith for everything else.
Imagine the result if 30 Sculptors were allotted different sections of the marble block to create Michaelangelo's David!!
Look forward to engineers reclaiming their lost identity....
Thanks for sharing! Would love to connect as I have a few issues that could require your perspective.
Nice one!
Great article Nigel. Very relevant to today's scenario
Insightful