8 ms·

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

38 points by clubdorothe 5y ago

BiteCode_dev 5y ago
Most softwares are monoliths in 2021. The exceptions are over hyped, because the day to day lives of administration and corporate devs are boringly standard.
halfmatthalfcat 5y ago
It really depends on the framework being used. Some frameworks are essentially micro-in-monolith (Akka) and some encourage the microservice framework (Federated Apollo GraphQL) due to their use case. I think it ultimately it depends on the tools being used and the team building them because there's tradeoffs to going each way.
glutamate 5y ago
Microservices 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.
- shikoba 5y ago
  I think the idea is that if you only need for an external tool one service you don't need the whole thing.
- auspex 5y ago
  If you have an “authentication” micro service. I can just reuse/deploy the service for my new app. No coding (maybe some configuration)
  - scottious 5y ago
    I find a lot of people create micro-services when a simple library would suffice. An "authentication" micro-service might make sense in some contexts, but in almost every real-world situation I've been in, this would be better as a library.
- chomp 5y ago
  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.
fortytw2 5y ago
Many of the points in this article are entirely a matter of implementation, not inherent to or ingrained in any particular architectural choice. You can just as easily build a highly modular and decoupled monolith as you can a tightly coupled and fragile microservice. The same point holds true for many of the other pro/cons the author brought up.
silvestrov 5y ago
> 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 components to the system (or even if it adds any benefit at all).
- zinekeller 5y ago
  > I've had managers that wants a CDN I'm hoping that the purported CDN is not for an internal, company-only application.
- wcarss 5y ago
  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.
cwitty88 5y ago
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.
- littlecranky67 5y ago
  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".
  - jacobkg 5y ago
    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.
recursivedoubts 5y ago
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.
- kawsper 5y ago
  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.
  - Veuxdo 5y ago
    For some, the overhead is the point.
- fourseventy 5y ago
  exactly, thank you
- UglyToad 5y ago
  I feel like the hype made a lot of people (not you) forget there's a middle ground, like you can't just have "services". I therefore propose a new hype cycle "mesoservices", i.e. only split out a service from the monolith when needed and it just does as much as is necessary.
zinekeller 5y ago
> 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.) > So maybe there’s no point in keep discussing microservices vs monoliths. Wikimedia has monoliths for text-based systems and microservices for (some) media-based systems, and it make sense: transcoding is unpredictable workload (for them, I imagine this is more common for YouTube) while database operations (at Wikipedia's scale) is very predictable and doesn't warrant the additional complexity. Even in their planning for multi-datacenter operations (https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Active-active_MediaWiki https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Ac...), they are more concerned with disaster recovery and slowness to logged-in users, not quick scalability.
- mmazing 5y ago
  > 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.
  - xnx 5y ago
    Many IT people are tech-fetishists and only solve genuine problems incidentally.
tester756 5y ago
Monoliths pros: Way easier to debug
madeofpalk 5y ago
> Is there any place for monoliths in 2020? > Is there any place for monoliths in 2021? maybe one year we'll get our answer!
- thrower123 5y ago
  It's the polar opposite of the perennial "Is it the year of Linux on the desktop?"
  - smichel17 5y ago
    IMO the year of the Linux desktop was 2015, when Microsoft made their operating system available gratis.
rollulus 5y ago
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 missing something?
- derefr 5y ago
  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.
  - jacobkg 5y ago
    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?
    - Voloskaya 5y ago
      Say you have some unit of work A within a monolith, and it is used by service B, C, D also in the monolith. You can carve out A as a microservice with a clean general interface, and write an adapter layer to translate calls from your old messy interface to your new one, and B, C, D call that. Then start refactoring B, C, D one by one depending on your priorities. That way new service X that needs to use A, can directly start using the clean general API even if B, C, D are not refactored yet.
cientifico 5y ago
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.
- KingOfCoders 5y ago
  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.
  - barbarbar 5y ago
    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.
    - js8 5y ago
      It might also mean that they had the project created when CORBA was in fashion, and it survived to this day, because it was an actually useful system, and despite the architecture being - whatever it was.
      - KingOfCoders 5y ago
        "CORBA was in fashion" Exactly this.
KingOfCoders 5y ago
Yes.
littlecranky67 5y ago
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.
eric4smith 5y ago
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.
- bwship 5y ago
  This seems to be a little over-simplistic. There are many good cases for microservices, and there are times when going into the project, you know it is what is needed. I think there are also a number of ways to make microservices, and it doesn't have to always be difficult. For instance, the last 4 projects I have built have been done with microsoervices, where the API Gateway endpoints such as /user or /machines each talk to their own lambda microservice.
mat0 5y ago
Yes
dasil003 5y ago
I feel all these black and white comparisons of monolith vs microservices tend towards being overly reductive and miss the crux of the matter. First, "microservice" is a terrible name (we should have just stuck with SOA), it leads to all kinds of agile consultant snake-oil salesmen claiming some ideal size for a service. That's bullshit. Services should be defined by their interfaces, full stop. If you can't come up with a stable interface between two services such that the interface changes orders of magnitude than the code within each service, or if you find yourselves always having to deploy the services in pairs due to leaky abstraction on the interface, then they probably shouldn't be two services. Second, SOA is primarily a tool for scaling teams. Yes there are some tangential benefits in terms of code base size, CI build time, etc, but those are false economies if you have a small team that has to deal with the overhead of many services. Modern web-scale architectures are really about factoring things to leverage specialists to scale very large tech platforms. Third, and perhaps most importantly. In any rapidly growing business you need to evolve quickly. You should not expect to design a perfect architecture day one, you should plan to evolve the architecture continuously, so that every two orders of magnitude growth you look up and realize you've replaced most of what you've previously written one way or another. Small startups that focus on "microservices" before they are anywhere near 100 engineers tend to die before traction.
loourr 5y ago
After much debate my company recently switched back to a monolithic architecture and it may be the greatest decision we've ever made. It dramatically simplifies so many aspects of development, which means you can have developers working on more impactful features and you don't have to worry about create a meta structure for keeping things consistent across all your micro services which is one of the biggest benefits I didn't see mentioned in this article. And in many systems with interdependent logic (which ours is), not duplicating data and not having micro services calling other micro services in loops become incredibly difficult things to avoid. I highly recommend the monolith for anyone who is not trying to cope with epic scaling issues. All hail the monolith!
lobo_tuerto 5y ago
I think tou can reap the benefits of both: monolith + microservices (nanoservices?) with something like Elixir / Erlang.

38 points by clubdorothe 5y ago

Most softwares are monoliths in 2021. The exceptions are over hyped, because the day to day lives of administration and corporate devs are boringly standard.

halfmatthalfcat 5y ago

It really depends on the framework being used. Some frameworks are essentially micro-in-monolith (Akka) and some encourage the microservice framework (Federated Apollo GraphQL) due to their use case. I think it ultimately it depends on the tools being used and the team building them because there's tradeoffs to going each way.

glutamate 5y ago

Microservices 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.

shikoba 5y ago
I think the idea is that if you only need for an external tool one service you don't need the whole thing.
auspex 5y ago
If you have an “authentication” micro service. I can just reuse/deploy the service for my new app. No coding (maybe some configuration)
- scottious 5y ago
  I find a lot of people create micro-services when a simple library would suffice. An "authentication" micro-service might make sense in some contexts, but in almost every real-world situation I've been in, this would be better as a library.
chomp 5y ago
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.

fortytw2 5y ago

Many of the points in this article are entirely a matter of implementation, not inherent to or ingrained in any particular architectural choice. You can just as easily build a highly modular and decoupled monolith as you can a tightly coupled and fragile microservice. The same point holds true for many of the other pro/cons the author brought up.

silvestrov 5y ago

> 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 components to the system (or even if it adds any benefit at all).

zinekeller 5y ago
> I've had managers that wants a CDN I'm hoping that the purported CDN is not for an internal, company-only application.
wcarss 5y ago
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.

cwitty88 5y ago

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.

littlecranky67 5y ago
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".
- jacobkg 5y ago
  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.

recursivedoubts 5y ago

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.

kawsper 5y ago
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.
- Veuxdo 5y ago
  For some, the overhead is the point.
fourseventy 5y ago
exactly, thank you
UglyToad 5y ago
I feel like the hype made a lot of people (not you) forget there's a middle ground, like you can't just have "services". I therefore propose a new hype cycle "mesoservices", i.e. only split out a service from the monolith when needed and it just does as much as is necessary.

zinekeller 5y ago

> 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.) > So maybe there’s no point in keep discussing microservices vs monoliths. Wikimedia has monoliths for text-based systems and microservices for (some) media-based systems, and it make sense: transcoding is unpredictable workload (for them, I imagine this is more common for YouTube) while database operations (at Wikipedia's scale) is very predictable and doesn't warrant the additional complexity. Even in their planning for multi-datacenter operations (https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Active-active_MediaWiki https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Ac...), they are more concerned with disaster recovery and slowness to logged-in users, not quick scalability.

mmazing 5y ago
> 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.
- xnx 5y ago
  Many IT people are tech-fetishists and only solve genuine problems incidentally.

tester756 5y ago

Monoliths pros: Way easier to debug

madeofpalk 5y ago

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

thrower123 5y ago
It's the polar opposite of the perennial "Is it the year of Linux on the desktop?"
- smichel17 5y ago
  IMO the year of the Linux desktop was 2015, when Microsoft made their operating system available gratis.

rollulus 5y ago

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 missing something?

derefr 5y ago
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.
- jacobkg 5y ago
  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?
  - Voloskaya 5y ago
    Say you have some unit of work A within a monolith, and it is used by service B, C, D also in the monolith. You can carve out A as a microservice with a clean general interface, and write an adapter layer to translate calls from your old messy interface to your new one, and B, C, D call that. Then start refactoring B, C, D one by one depending on your priorities. That way new service X that needs to use A, can directly start using the clean general API even if B, C, D are not refactored yet.

cientifico 5y ago

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.

KingOfCoders 5y ago
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.
- barbarbar 5y ago
  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.
  - js8 5y ago
    It might also mean that they had the project created when CORBA was in fashion, and it survived to this day, because it was an actually useful system, and despite the architecture being - whatever it was.
    - KingOfCoders 5y ago
      "CORBA was in fashion" Exactly this.

KingOfCoders 5y ago

Yes.

littlecranky67 5y ago

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.

eric4smith 5y ago

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.

bwship 5y ago
This seems to be a little over-simplistic. There are many good cases for microservices, and there are times when going into the project, you know it is what is needed. I think there are also a number of ways to make microservices, and it doesn't have to always be difficult. For instance, the last 4 projects I have built have been done with microsoervices, where the API Gateway endpoints such as /user or /machines each talk to their own lambda microservice.

mat0 5y ago

Yes

dasil003 5y ago

I feel all these black and white comparisons of monolith vs microservices tend towards being overly reductive and miss the crux of the matter. First, "microservice" is a terrible name (we should have just stuck with SOA), it leads to all kinds of agile consultant snake-oil salesmen claiming some ideal size for a service. That's bullshit. Services should be defined by their interfaces, full stop. If you can't come up with a stable interface between two services such that the interface changes orders of magnitude than the code within each service, or if you find yourselves always having to deploy the services in pairs due to leaky abstraction on the interface, then they probably shouldn't be two services. Second, SOA is primarily a tool for scaling teams. Yes there are some tangential benefits in terms of code base size, CI build time, etc, but those are false economies if you have a small team that has to deal with the overhead of many services. Modern web-scale architectures are really about factoring things to leverage specialists to scale very large tech platforms. Third, and perhaps most importantly. In any rapidly growing business you need to evolve quickly. You should not expect to design a perfect architecture day one, you should plan to evolve the architecture continuously, so that every two orders of magnitude growth you look up and realize you've replaced most of what you've previously written one way or another. Small startups that focus on "microservices" before they are anywhere near 100 engineers tend to die before traction.

loourr 5y ago

After much debate my company recently switched back to a monolithic architecture and it may be the greatest decision we've ever made. It dramatically simplifies so many aspects of development, which means you can have developers working on more impactful features and you don't have to worry about create a meta structure for keeping things consistent across all your micro services which is one of the biggest benefits I didn't see mentioned in this article. And in many systems with interdependent logic (which ours is), not duplicating data and not having micro services calling other micro services in loops become incredibly difficult things to avoid. I highly recommend the monolith for anyone who is not trying to cope with epic scaling issues. All hail the monolith!

lobo_tuerto 5y ago

I think tou can reap the benefits of both: monolith + microservices (nanoservices?) with something like Elixir / Erlang.