Architecture on Easy Mode

Hey everyone! The architecture of information systems won't leave me alone, and here's why. I keep seeing systems analysts who, across the board, don't understand the classic design patterns — and it shows in their specs. A bad spec drags along extra development time, implementation headaches, and inconsistent data on the way in. And it's the analyst who's supposed to be the person who lays out ideas clearly for developers and testers. In practice, though, what comes out of those "wise" heads are ideas that aren't remotely technical))

Why is that?

My take is simple: no base, no foundation — and that's the pain of the current layer of analysts. Not all of them, sure — gurus do exist — but the general mass is exactly like this.

So I took it upon myself to run a crash course — for analysts and for anyone else curious about development and design.

Today's topic is a simple one. Earlier I broke down what a monolith and microservices are — in plain terms, easy to digest. Now I want to think through when you should reach for a monolith and when for microservices. While reading through various articles, I ran into a curious chart.

Here's the gist of it: at a certain stage, the cost of a line of code in a monolith starts to climb, and there's a point where building the monolith simply stops paying off.

How does the cost of a line of code change the rules of the game?

When people pick an architecture — monolith or microservices (and no, those aren't all the patterns, there are far more, but that's for another time) — the conversation usually slides into boring words like "scalability" and "fault tolerance." Let's dig deeper instead and ask: how much does each line of code cost? That's right — every line is like a tiny IT worker who demands a salary, upkeep, and attention. Let's figure out how the price of a small change affects the architecture choice.

Monolith, when every line of code is cheap labor

Picture this: a startup, three developers, and a big dream. Time passes, features come out of the oven like hot pastries. Here the monolith is the most economical choice. Every line is as cheap as a pack of instant noodles. Everything's in one place: one project, one deploy, one great big test. You don't burn energy shuttling data between services, you don't agonize over "wait, why does this microservice even exist?", and you live happily, never once thinking about inter-service communication.

But you know where free cheese lives. The app grows like a cat on steroids, and every new release turns into a nightmare. A bug in one module takes down the whole payment processing, a sleep-deprived team lead philosophizes about the meaning of life in meetings, and the developers sharpen their spears to work out who's to blame for the sleepless nights. That's when the cost of maintaining each line shoots up. Not sky-high, of course, but enough to make you stop and think.

Microservices, every piece of code is an investment in the future

Now a different scenario: the startup took off, there are thirty-three developers now, and features multiply faster than mushrooms after the rain. Welcome to the world of microservices! Here every piece of code is no longer just a line but a strategic investment. Each service lives its own life, like cats in separate rooms: one wants Scala, another Java, a third wants a rain dance around Kubernetes. The initial setup costs more, but each individual "code cat" isn't all that ravenous.

Picture a developer named Vasya adding a new feature. Instead of waking up the whole codebase (and, along with it, Petya, peacefully asleep at that moment), Vasya updates only his own piece. The tests are fast, the deploy is independent. And if Vasya suddenly decides his heart lies with Rust rather than Java — his microservice is more likely to benefit, and without the pain that would come with a monolith.

So when should you move to microservices?

The question isn't when you're ready to make the move, but whether you're ready to invest in the future right now. A monolith is like catching a cab: you get there fast and cheap. Microservices are a pricier purchase: it hurts up front, you have to put money into analysis, into automated tests, into pipelines — but over the long haul it pays off far more. Just getting started, budget on a knife's edge — the cheapest move is to jump into a monolith. But if every new developer brings along a batch of bugs, and the cost of a line of code climbs to an unbearable level — it's time to get yourself some microservices!

Bottom line: if your project is a light monolithic slice of toast for breakfast, let it stay that way. But the moment that toast turns into a multi-layered sandwich, think about microservices — so that each line of code doesn't cost as much as a trip to space.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP