Monoliths pros:
Way easier to debug
Is there any place for monoliths in 2021? (2020)
11–20 of 67 posts
Re: Is there any place for monoliths in 2021? (2020)
#12> Is there any place for monoliths in 2020?
> Is there any place for monoliths in 2021?
maybe one year we'll get our answer!
Re: Is there any place for monoliths in 2021? (2020)
#13Microservices Pros: Code reusability? Please ELI5 how I get better code reuseability in microservices than in my monolith with separated concerns into libraries and helper modules.
If you have an “authentication” micro service. I can just reuse/deploy the service for my new app. No coding (maybe some configuration)
Re: Is there any place for monoliths in 2021? (2020)
#14> Developers always want to try the new flashy things [...] On the other hand, management mostly sees risks .. mostly wants new fancy features I have the inverse experience: management wants to brag about tech and therefore force ill-suited tech onto the developers. I've had managers that wants a CDN because that's what all professionals do and they don't take a moment to think about added risk by adding more compone…
> I've had managers that wants a CDN
I'm hoping that the purported CDN is not for an internal, company-only application.
Re: Is there any place for monoliths in 2021? (2020)
#15In 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 missing something?
Re: Is there any place for monoliths in 2021? (2020)
#16> Developers always want to try the new flashy things [...] On the other hand, management mostly sees risks .. mostly wants new fancy features I have the inverse experience: management wants to brag about tech and therefore force ill-suited tech onto the developers. I've had managers that wants a CDN because that's what all professionals do and they don't take a moment to think about added risk by adding more compone…
CDNs are a great example where, if you don't have the problem they solve yet, using them correctly might not be worth your time.
You may now have separate asset domains, interactions of cache expiry headers across different servers, custom header forwarding through your front-ends, new separate asset packaging and deployment steps during shipping, and a slew of other "new stuff" to think about during every deploy, that can all break, and that you ought to have multiple people on the team really understand to use properly, or to debug if it's not working.
If you have <100 users, growing to ~500 by the year's end, you maybe don't need to spend time on any of that stuff yet.
Re: Is there any place for monoliths in 2021? (2020)
#17microservices: 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.
Re: Is there any place for monoliths in 2021? (2020)
#18Microservices Pros: Code reusability? Please ELI5 how I get better code reuseability in microservices than in my monolith with separated concerns into libraries and helper modules.
Yeah I think it's better rephrased as "service reusability". A proper microservice should be able to be redeployed anywhere for anything.
If you have an authenticate() function in an auth helper library, you can move that around to new web apps to help users authenticate with different parts of your site(s).
Your authenticate() function for a microservice is probably going to be part of a broader "microservice api library" that gets reused, but I can't imagine reusing the microservice code itself - you're supposed to just spin up a new one.
Re: Is there any place for monoliths in 2021? (2020)
#19In 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.
Re: Is there any place for monoliths in 2021? (2020)
#20In 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 then become "location neutral" between being in-process vs. out-of-process, making the "monolithicness" of the system just a deployment choice — choosing to deploy all the components as one runtime process — rather than a development paradigm.)
Service-oriented code, on the other hand, has low coupling by default, until coupling is introduced via explicit choices like making synchronous RPC calls between components.
Sadly, people refactoring a monolith into SOA code will often introduce such coupling, as it's seemingly the cleanest 1:1 "mapping" of the monolith's code into SOA land. But the point of refactoring into SOA isn't to do a 1:1 semantic recreation of your monolith, including its inter-component dependencies; by doing so, you just produce a "distributed monolith emulator." A proper SOA refactoring should carry over the semantics of the individual components, but not the semantics of their interdependencies.