---
title: "Misguided Mark misrepresents Micro-services: A story about paradigms"
url: https://stanko.io/misguided-mark-misrepresents-micro-services-a-story-about-paradigms-XBMbcWf6RRkz
author: Stanko Krtalic Rusendic
published: 2022-07-11
updated: 2026-02-15
tags: [meditation, story]
---

# Misguided Mark misrepresents Micro-services: A story about paradigms

Tom was brewing tea in preparation for a 5 o'clock meeting he knew little about.
The agenda was so vague it might as well have been left out - it read “Mark
introduces a new system for controlling 3rd party IoT water sprinklers”. That
was standard practice for CorpCorp - the company Tom worked for - everything was
a meeting and things were only ever presented through meetings with at least 10
attendees, even when an email would be more than enough.

But Tom wanted to attend this meeting. He was the head of the Web development
department and 3rd-party integrations were his responsibility. His team was
short-staffed to the point that they couldn’t start working on this integration
until the next quarter.

When Mark, a developer from the in-house IoT sprinkler department, offered to
develop this integration Tom immediately accepted - Mark used to work as a Web
developer before he joined CorpCorp and Tom thought that maybe he wanted to
switch departments.

5 o’clock rolls around, Tom joins the meeting from his home office and takes a
big sip of tea.

On his screen is Mark, standing in front of a nice looking slide deck that in
bold letters says “Controlling 3rd party water sprinklers: The future of
CorpCorp”.

Mark greeted everybody and started to present. He explained that he had spent
two weeks planning out this integration and came to the conclusion that it will
be built using micro-services - 13 of them - even though most of CorpCorp’s Web
services were in a monolithic Web app.

Mark explained that monoliths were a thing of the past - they didn’t scale, and
always ended up too complex to maintain. Micro-services, on the other hand,
scaled infinitely and were super easy to maintain because having everything
separate improved encapsulation and separation of concerns.

Mark stopped, looked at all the confused faces, and asked if there were any
questions. Immediately a few managers that didn’t listen to half of the
presentation asked simple questions that Mark already explained during his
presentation - this was also standard practice at CorpCorp.

Tom had a working theory that the managers get bored by the technical
jibber-jabber and doze off, but when the meeting ends they want to prove that
they actually listened and that they were a useful addition to the meeting, so
they ask a question about the last thing that they remember. Further experiments
and observations were required to prove this theory, but even knowing if that
was the case wouldn’t solve the problem - that the meeting should have been an
email.

Once the flurry of questions ended Tom started to talk. He thanked Mark for
taking the time to research this integration, and confirmed that it would be a
good solution to the problem, but that he shouldn’t move ahead with its
implementation because the system would cause too many problems down the line.
He then added that Mark couldn’t see how misguided he was about monoliths
because he clinged too hard to his paradigm to think level-headed.

The managers woke up out of a sudden - they didn’t want to miss the drama.

Tom started to address each point of Mark’s presentation. He began by asking
Mark ih he knew why CorpCorp developed a Monolith in the first place. Mark just
shrugged and guessed that it was because they were at the peak of their
popularity when the project was started. Tom refuted that and said that a
monolith was conscious decision by the department because:

### MONOLITHS ARE EASIER TO MAINTAIN FOR SMALLER TEAMS

Tom’s department counted 12 people, but those 12 people were enough to handle
most of CorpCorp’s business. Only in recent months, after one employee retired
and another quit, did Tom’s department start to struggle with meeting business
demands.

Tom’s employees built a monolith and decided upon a convention for going about
their most common tasks. This allowed them to be flexible - anyone could work on
any part of the system because they knew how everything was supposed to be
organized. And over time, as features were added or removed, and bugs fixed,
everybody became familiar with most of the system. So anybody was able to add a
feature or fix a bug anywhere in the system.

You could achieve the same by implementing a convention on top of
micro-services, but there is nothing stopping you from implementing multiple
conventions. The more people that work on your micro-services, the more opinions
there are on how they should be implemented, the likelier the chance that
convention will be broken or changed.

In fact that is a big selling point of micro-services - you can use any
technology and any convention you want for each individual service. And that is
a desirable trait for mammoth companies that suck up developers just so the
competition won't get them - they can keep them happy by letting them do what
they want in their own micro-cosmos. This sometimes works out and sometimes it
doesn’t, but for these kinds of companies that is just part of doing business.

In general, it is better for individuals and small teams, to be intentional with
what they do and how they go about it. Especially in software development -
where the question isn’t “is it doable?”, because the answer is always “yes”,
but “how much time will it take?”.

And a monolith is great at ensuring that - one vision, one codebase and
everybody is aligned.

### MONOLITHS ARE EASIER TO SCALE, BUT THEY DON’T SCALE AS WELL AS MICRO-SERVICES

Tom decided to use an analogy here so that the managers wouldn’t doze off again.
A monolith is like a hamburger, it is a meal consisting of a bun, a patty and
some salad. While micro-services are a patty, some bread and a salad as three
separate meals.

With a monolith, if you want to double the throughput you double the number of
running instances. This is the equivalent of ordering two hamburgers when you
are very hungry. The good thing is that it’s simple - you just double everything
and you are done, the bad part is that it can be wasteful.

In micro-services, if you want to double the throughput you first have to
identify what the bottleneck is, and then you double that service and some of
its upstream services. This is the equivalent of ordering two patties, a regular
salad and a bun when you are very hungry - you only pay for what you really
want.

But figuring out what the bottleneck is can be hard, both in monoliths and
micro-services.

### COMPLEXITY COMES FROM BUSINESS NOT CODE

The notion that monoliths are complex to maintain and micro-services aren’t is a
myth. In a monolith and in micro-services complexity comes from the business
domain - what the app does. If the business domain is complex or not thought
out - if there are no clear rules, if the process is dependent on many factors,
if the process has many interdependent steps, if the process is convoluted to
humans - the code will reflect that.

The code you write mirrors how you think about a problem. If you don’t think
clearly, or if the problem is inherently muddy, then you are out of luck -
architecture has little to do with that.

### MICRO-SERVICES IMPROVING ENCAPSULATION OR SEPARATION OF CONCERNS IS A MYTH

Tom had to resort to another analogy here to keep the managers listening.
Encapsulation is the act of bundling together things that belong together. It is
in a way similar to doing laundry - imagine you have two laundry baskets: one
for colored clothes and another for white & black clothes.

Separating the clothes in their baskets is encapsulation - each basket
encapsulates only its set of clothes. But where would you put dark blue
underwear?

On the one hand it is blue - a color - so it should go into the color basket.
But on the other hand it is dark blue, which is close to black - so it should go
into the white & black basket. Depending on who you ask you will get a different
answer.

But people who argue that micro-services improve encapsulation & separation of
concerns argue that, somehow, the problem will solve itself if you put the
laundry baskets really far apart.

If you are bad at separating concerns or encapsulating code, you will be equally
as bad at it in a monolith and in micro-services.

Tom stopped for a moment to look at everyone’s faces, the managers were more
alert than they have ever been while Mark was embarrassed. Tom felt bad, and
decided to give a moral to this story to lighten the mood.

He said that this was a common mistake that young developers make - they get too
attached to their paradigm and become unable to understand why someone would do
things differently. They think that the existence of a new paradigm - a new
school of thought - must invalidate the old one. Why else would then the new
school exist? Why would micro-services exist if monoliths were good?

People form an understanding of the world through paradigms. There is no one
perfect paradigm, no one ultimate school of thought, just like there is no one
perfect theory of how the world works..

Look at Newton’s and Einstein's model of gravity. Einstein’s model is superior
to Newton’s - it is better at explaining how objects will move when they are
going slow and when they are going close to the speed of light.

This precision comes at a cost - it is much harder to compute Einstein’s gravity
equations than Newton’s. But is this computational cost worth it? When the
object is moving slowly, Newton’s equations are a fraction of a percent off
compared to Einstein’s equations.

Many civil engineers say the trade off isn’t worth it. For their day to day work
they use Newton’s equations because they can iterate bridge, road, and building
designs quickly and find the best solution. But NASA engineers would beg to
differ - a precise result is much more important to them.

Each paradigm is good at something and bad at something else. It is up to you to
understand the trade off and pick what works best for you.

P.S. The style of writing in this essay was inspired by a book I recently read -
[Are your light on?](https://geraldmweinberg.com/Site/AYLO.html) by Donald C.
Gause and Gerald M. Weinberg. Its a fantastic book about problem solving and
thinking about problems.

Many thanks to Marko I. and [Hrvoje S.](https://shime.sh/) for reading drafts of
this article and providing feedback