Live data from Hacker News

Is there any place for monoliths in 2021? (2020)

fjrevoredo.me

31–40 of 67 posts

Re: Is there any place for monoliths in 2021? (2020)

#31
Hearing a lot about monolith vs. microservices, can someone shed some light how "pluggable/plug-in driven monoliths" fit in? To Quote Martin Fowler on monoliths:

> Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed.

But this is not true. I worked at some C# "monolith" ~2010ish, and we used MEF framework to build pluggable .dll files that you could just "drop" into the deployment folder. As long as you stuck to the same interfaces (through a shared interfaces project) you could build and ship individual parts of the application in separate teams. Even exceptions could not harm the full system (when they were properly caught in the host) - and segfaults shouldn't happen in a managed system (but yes, they did, mostly through P/Invokes).

I always liked the good old "Winamp model" where you would just drop some dlls and got new visualization plugins enabled - each more different than the other.

Re: Is there any place for monoliths in 2021? (2020)

#32
post #20

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

Monoliths have high coupling by default — coupling components together is the "easy" and "obvious" way to get things done in a monolithic codebase, and so it's what junior devs will inevitably do when pressed for time. A monolithic system's architect would have to make an explicit choice at some point, to reject/restrict coupling (by e.g. building the monolith on an actor-model language/framework, where components th…

I’m very intrigued by this comment. It probably captures the thing that has held me back from microservices. Can you explain how one can break up a monolith without keeping the interdepencies?

Re: Is there any place for monoliths in 2021? (2020)

#33

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

If you compare making a call to a web service vs calling a function to achieve a similar outcome, it is definitely true that you can easily have business logic coupled between these two services. You also have the additional cost of having to handle network errors in the calling function.

However, scaling a monolith (as someone who does this for their day-job) is significantly harder than scaling independent services. This is mainly because performance issues in one function can hog resources that other functions share. This is particularly the case when you have a single, central database where one poorly optimized query can cause performance for all users to degrade severely.

Re: Is there any place for monoliths in 2021? (2020)

#34

> Is there any place for monoliths in 2020? > Is there any place for monoliths in 2021? maybe one year we'll get our answer!

It's the polar opposite of the perennial "Is it the year of Linux on the desktop?"

IMO the year of the Linux desktop was 2015, when Microsoft made their operating system available gratis.

Re: Is there any place for monoliths in 2021? (2020)

#35
post #7

Decent write-up. I agree that most things should start as a monolith and only move to microservices if no other solution will solve the problem. You can scale a monolith quite effectively with a little planning.

Agreed, but I have seen numerous times (I contract and see a lot of shops inhouse) that employees suggest microservices as architecture from the start for new projects. I have a strong feeling this is CV driven development, a.k.a "its trendy and I need skills in this field to stay relevant on the job market".

I joined a shop where that was the case. We invested time in reintegrating services back into the monolith. A number of them could be replaced with ~100 lines of ruby.

Re: Is there any place for monoliths in 2021? (2020)

#36
post #17

microservices: let's take the hardest problem in software construction, factoring the system properly, and introduce network connections and deployment complexity into it. yeah, there's a place for monoliths, and developers who are willing to ignore the industries ludicrous fads and faang-chasing have the advantage.

Don't forget things like routing, authentication, certificates, logging, deployments, error-tracking, monitoring, error-handling and service-meshing. Sure, it probably gets easier when you're booting your third or fourth microservice, but there's a lot of overhead.

For some, the overhead is the point.

Re: Is there any place for monoliths in 2021? (2020)

#37
Every project should be started as a monolith. Period.

Then as it grows and it makes sense to decouple at the edges then it makes sense.

And these micro services only make sense when there is a team responsible for each one.

Otherwise the whole thing is like a game of chess - you will forget to make a move at some point.

Re: Is there any place for monoliths in 2021? (2020)

#38

> If we analyze most of the successful migrations into microservices, they were driven almost exclusively from necessity rather than preference. This is basically how everything should work. There's no need to rush things if you don't need it now, especially that some that do convert are disappointed at the results (it's not the microservices themselves, it's the specific migration planning, design, and maintenance.)…

> This is basically how everything should work. There's no need to rush things if you don't need it [right] now.

I'm really not sure why this is so difficult to grasp for so many people in IT.

I think it stems from a desire to not have to think too hard about how to solve a problem since "someone else has already solved this."

... or maybe an inability to do so.

Re: Is there any place for monoliths in 2021? (2020)

#39

In my experience, the architecture is not relevant at all for the success of a business. It's alignment with the company structure is. The same way Conway's law tells us that company structure and the communications should be in sync, the architecture should match the teams. As a rule of thumb... the good architecture is the one that minimize the communication within the different teams.

I've worked for a very successful very high margin $200M+ revenue company with very good salaries on a (some years back) CORBA Java system.

Some would argue that if you are using corba you probably have a pretty good idea of what you are doing and you are not doing fashion/hype driven development.
Post reply on HN