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? 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. for reading drafts of this article and providing feedback
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? 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. for reading drafts of this article and providing feedback