Introduction
Hello there, dear reader! Well, if you’re reading this I assume that you probably have already a basic understanding of h...
For further actions, you may consider blocking this person and/or reporting abuse
Monolith has nothing to do with MVC as well as microservice is not defined by API. Both can be developed by DDD aproach. Microservice is socio-technical solution to big problems where a single team is not capable to manage due to communication overhead among the team members. Microservices address complexity in scale, not scaling performance or space.
Hey @vaclav_prokop_02453acfbd7! Thanks for the comment! I'll do my best to disect your comment below.
So, for the first part of your comment:
I find it really hard to say that Monolith has nothing to do with MVC, since all most popular monolith frameworks like Ruby on Rails, Laravel and Django start out of the box with the MVC pattern. So, yeah, it has a lot to do with the MVC pattern and if you pick a Monolith at random, it will most probably use it.
But, I totally agree that this is not necessarily true in all cases, you can find Monoliths implementing other architectural patterns, like DDD, that's why I wrote:
The same argument is valid to the other point:
While technically true, APIs are so prevalent in microservices implementations that they are almost inseparable in practical discussions. It's hard to explain one without mentioning the other.
For the part:
True! That's an important and often overlooked historical perspective on microservices—great point!
For the last part:
I might be misunderstanding this part, so feel free to clarify. That said, I see scaling performance or space as facets of scaling complexity, which microservices often address as part of their design goals.
Lastly, I'd like to remember that this piece is focused for general beginners/intermediate level software engineers. This means that, although all those nuances exist in the software ecosystem, I intentionally simplified some aspects to make the article more approachable.
Thanks again for the comment and looking forward to seeing you around ;)
Hi Lucas, I appreciate your intention to popularize complex concepts among beginners. However, my intention was to align concepts at the same level. We have a serious problems in programming and overall architecture thoughts. That is mixing different levels of concepts toghether. I see it in code every day, and it can be seen in articles on the internet too. Just as classes in a code can represent different level of abstraction, architectural patterns serve different purposes too. What I mean is: MVC is a pattern for implementing REST services API. SOAP service can be implemented by another catchy pattern, but in principle both are implemented by some sort of decision chain design pattern. Patterns and APIs exist on a lot of different levels, such as code implementing these. It can be confusing, I know. I see that confusion among professionals making me unhappy.
Hey @vaclav_prokop_02453acfbd7, thank you for the thoughtful comment—it’s clear you’re passionate about the nuances of architecture and abstraction levels, which is something I really respect (and aim to be hahahaha).
I understand where you're coming from regarding the mix of abstraction levels in architecture discussions. It’s true that patterns like MVC or REST often get conflated with broader architectural concepts, which can muddy the waters when explaining these ideas -- to be fair, it's also hard to separate each concept in its own box since they all come together as a whole. My goal with this piece was to introduce these concepts in a way that’s approachable for beginners while staying grounded in practical realities.
Your point about different levels of abstraction—like MVC for implementing APIs versus larger architectural decisions—is well-taken. It's a challenge to balance simplification and technical precision, but I’ll make sure to take your feedback into account in future articles to try and make those distinctions sharper.
I’m also super curious to hear your thoughts on how you typically communicate these differences when mentoring or explaining to others. It’s always great to learn from someone who has clearly spent a lot of time thinking about these challenges.
Thanks again for your input—I really appreciate it!
Microservices are only useful to large companies. The rest of the world can very well do with a monolith. A monolith can still be designed in a modular way so that most of the disadvantages are addressed. Microservices requires a lot of orchestration which is difficult and tedious. That is something that is not often mentioned in articles and if done wrong lead to a very expensive solution.
Hey @retakenroots! Thanks for the comment and I agree with a lot that you said! So much so that this article was largely inspired by this video of DHH.
As I mentioned, if you're in doubt, there's a great chance you're going to be better suited with a monolith!
Thanks and see you around ;)
I'd like to understand this more. I am working to develop microservices specifically because I don't want to orchestrate development by other groups, nor do their programming. I want to build the platform, offer services and when they build content, leverage it for my group. Is this a bad idea? Are there better architectures I should use?
I have no problem that you promote the capabilities of your company.
The post contains a lot of information, But it is not balanced. It leans to microservices.
As an example:
With pay more server power you reference vertical scaling. But you never address horizontal scaling, where different servers run the same application.
You wrote it in the context of having a pressure point in your application. How are microservices going to handle that? By horizontal scaling perhaps?
What irks me the most is that post feels like a choose a side and stick with it scenario. Like all things in life there are a lot of grays between white and black.
I understand you can't address all the things. And you did address some of them. But because of those sharp lines the post feels more like an ad than a genuine expression of information.
Hey @xwero! Super thanks for the feedback!
And, to be fair, that was a really unexpected feedback, because, my general idea I was going for was totally the opposite (lean towards Monoliths, even more in the case you are not sure, -- since Microservices can be really hard, complex and a total overkill in some scenarios).
I'll try to reference some examples below of me leaning to monoliths:
Or, in the comparison table, I specifically put the term really large to emphasize that microservices can be a overkill for most apps:
So yeah, if you got the sense that the article leans heavily towards microservices, I'll look into editing it a little bit to make it even more explicit that the opposite is true hahahah.
Regarding your point about horizontal scaling: You’re absolutely right that horizontal scaling—where different servers run the same application—is a valid strategy for monoliths. I agree that I could provide more context on this alongside the discussion of vertical scaling to give a more balanced view of scaling approaches in monolithic architectures.That said, scaling a monolith with tightly coupled components often introduces challenges that are different from scaling individual microservices -- which was the vibe I was going for. I'll definitely explore that further in a revision.
Regarding this part of your comment:
As with the leaning to the microservices, the opposite is what I was trying to go for. I even mention that you can convert one into the other and a few ways on converting, e.g.:
But, on the revision, I'll try to emphasize more this gray area! Thanks for noticing!
And with the last part, that this feels more like an ad instead of a genuine piece, I’m sorry if the article felt more like an ad—that wasn’t my intention. My primary goal is to provide valuable and practical insights, and I work hard to strike a balance between highlighting the brand and delivering genuine, helpful content. I’ll make sure future pieces keep this balance even sharper.
Thanks again for your valuable input—I’ll be reviewing the article with your points in mind. If you have any specific examples of where you think the balance could improve, I’d love to hear them!
I think multiple posts of the Brownfield replacement process would be better than this one monolith versus microservices post.
It will allow you to provide more information about the path to go from a single server to a full microservice solution.
The pressure point is not always with the code. The title says it is 101, which means people are maybe not aware of having the application and the database on the same server can become a problem.
You provided a lot of information, but some of the things will be overlooked because you added as what can be considered as a side-note like modular monolith and DDD. It is easy to discard a single sentence as something that is not that important.
I'm all over the place, but i think you can pick up some of the things.
Great Article 👏
Thanks a lot @petermwambi!
Hi Lucas,
Very nice and helpful !
Thanks for sharing.
Hey @jangelodev!
Thanks a lot! Glad that I could help another 🇧🇷
See ya!
Thanks a lot 👍
Is it true that in a Microservice architecture, each service is a monolith itself?
Hey @ali_mirzaei_3baf003de70dc! Really great comment! This is a super common analogy and it can be in parts true (but it also can be in parts false).
Here's my take on that:
If you think that a microservice usually is deployed with everything it needs to work, it can look similar to multiple monoliths, since, you're deploying multiple things, that contains databases and all the other things they need to run -- specially if the microservice is BIG (which generally is a bad practice, since they usually should be used within the same domain).
But as I mentioned, that analogy is not 100% correct. Although you could say each microservice has a "monolithic structure" in terms of its independence and internal organization, it's the distribution and decoupling of services that make a microservice architecture different from a traditional monolith.
Thanks a lot and feel free to leave any more questions!
Thank you for this,I want to migrate my backend monolith app to microservices. How do I do it. Stack is AWS offerings,fatapi, postgreSQL,google vision and redis
Hey! Thanks for the comment @adesoji1!
Migrating things is certainly a challenge! Although it's impossible for me to help in terms of precisely how to solve it, feel free to use the guides and ideas mentioned on this article as a path towards your goal (Strangler Fig might be the one you're looking for the most ;))
Thank you for the blog post. I heard good things of Hono.js and want to look at it today.