3 ms·

This is the first time hear the word "Monolith" What is it and how can one learn about it.

by samyar 3y ago

keybored 3y ago
It’s a kind of word which only makes sense as a negation to its antonym. Because if the antonym didn’t exist then it would just fade into the background as “normal”.
doctor_eval 3y ago
It just means that there is one big binary that does everything, instead of a bunch of microservices communicating over a fabric of some kind. As someone who thinks microservices actually simplify a lot of things, especially in complex domains, the idea that a monolith is a choice makes me cringe a bit. I mean they start out simple, but ...
- robwg 3y ago
  Them be fighting words. Tell some others orgs I've worked at that microservices are simple and they would laugh. But yes it depends on the complexity of your domain/org.
- kryptiskt 3y ago
  The idea of unnecessarily replacing nanosecond scale function calls with network communication that is five orders of magnitudes slower makes me shiver. Yeah, you can make a microservice that does one thing with a well-defined API and it's nice and clean. But you might as well make a module that does one thing with a well-defined API, and it will be so much faster because it's right there in memory with you.
  - doctor_eval 3y ago
    If you’re replacing nanosecond function calls with microservices, you’re doing it wrong. It’s a specious argument. In the domains in which I’ve worked, most services receive calls over the network, and go on to make database calls that also go over the network. So whether you do the routing inside or outside a monolith makes almost no difference to latency. And what’s more, with a front end like GraphQL, you can parallelise the work which reduces latency further. Microservices have a lot of benefits relative to monoliths, but they aren’t a panacea any more than monoliths are. They’re a useful architecture for certain workloads and a poor fit for certain others. But in my experience it’s quite a lot more difficult to maintain discipline over the long term with monolithic architectures, and that’s why I tend to prefer microservices attached to messaging architectures like NATS. YMMV, and that’s fine.
  - objektif 3y ago
    I would love to hear a valid argument against it. Why microservices as opposed to say modules or libraries.
  - vintermann 3y ago
    Speed isn't the main argument as I see it, rather complexity is. How much of each of your microservices is boilerplate code? How much is outright copy-pasted? Microservices can be an invitation to write lots of lines of code, so that management sees that you're "efficient".
- vintermann 3y ago
  It's a lot about trusting your infrastructure, your development process, your overall plan with respect to state and communication etc. If you need to make it more complicated later, can you? Probably. If you see you could have done something simpler, can you de-complicate it? Sounds harder to me in general.
  - doctor_eval 3y ago
    Probably not your point but > If you see you could have done something simpler, can you de-complicate it? this is why I think microservices are generally better - because they increase the friction to create coupling, and coupling creates complexity, and in particular makes it very difficult to de-complicate things. Put another way, microservices make coupling far more obvious, and the presence of strong coupling in a microservice architecture should be a massive red flag - one that's really easy to miss in a monolith. The unfortunate thing about participating in these exchanges, however, is that it's impossible to explain ourselves in sufficient detail, so in the monolith vs microservice debate, we all end up just speaking across each other.
    - vintermann 3y ago
      No, I see your point. It's just that in my experience, the friction didn't do much to prevent coupling, because the friction was just that you had to write a lot of boilerplate code - not hard, just boring - and they were willing to do that rather than having a design meeting with me...
pmontra 3y ago
It's a well established term. Example, this article of James Lewis and Martin Fowler from 10 years ago https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html "To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. Any changes to the system involve building and deploying a new version of the server-side application."
cpach 3y ago
Here’s one take: https://signalvnoise.com/svn3/the-majestic-monolith/ https://signalvnoise.com/svn3/the-majestic-monolith/

This is the first time hear the word "Monolith" What is it and how can one learn about it.

by samyar 3y ago

This is the first time hear the word "Monolith" What is it and how can one learn about it.

It’s a kind of word which only makes sense as a negation to its antonym. Because if the antonym didn’t exist then it would just fade into the background as “normal”.

doctor_eval 3y ago

It just means that there is one big binary that does everything, instead of a bunch of microservices communicating over a fabric of some kind. As someone who thinks microservices actually simplify a lot of things, especially in complex domains, the idea that a monolith is a choice makes me cringe a bit. I mean they start out simple, but ...

robwg 3y ago
Them be fighting words. Tell some others orgs I've worked at that microservices are simple and they would laugh. But yes it depends on the complexity of your domain/org.
kryptiskt 3y ago
The idea of unnecessarily replacing nanosecond scale function calls with network communication that is five orders of magnitudes slower makes me shiver. Yeah, you can make a microservice that does one thing with a well-defined API and it's nice and clean. But you might as well make a module that does one thing with a well-defined API, and it will be so much faster because it's right there in memory with you.
- doctor_eval 3y ago
  If you’re replacing nanosecond function calls with microservices, you’re doing it wrong. It’s a specious argument. In the domains in which I’ve worked, most services receive calls over the network, and go on to make database calls that also go over the network. So whether you do the routing inside or outside a monolith makes almost no difference to latency. And what’s more, with a front end like GraphQL, you can parallelise the work which reduces latency further. Microservices have a lot of benefits relative to monoliths, but they aren’t a panacea any more than monoliths are. They’re a useful architecture for certain workloads and a poor fit for certain others. But in my experience it’s quite a lot more difficult to maintain discipline over the long term with monolithic architectures, and that’s why I tend to prefer microservices attached to messaging architectures like NATS. YMMV, and that’s fine.
- objektif 3y ago
  I would love to hear a valid argument against it. Why microservices as opposed to say modules or libraries.
- vintermann 3y ago
  Speed isn't the main argument as I see it, rather complexity is. How much of each of your microservices is boilerplate code? How much is outright copy-pasted? Microservices can be an invitation to write lots of lines of code, so that management sees that you're "efficient".
vintermann 3y ago
It's a lot about trusting your infrastructure, your development process, your overall plan with respect to state and communication etc. If you need to make it more complicated later, can you? Probably. If you see you could have done something simpler, can you de-complicate it? Sounds harder to me in general.
- doctor_eval 3y ago
  Probably not your point but > If you see you could have done something simpler, can you de-complicate it? this is why I think microservices are generally better - because they increase the friction to create coupling, and coupling creates complexity, and in particular makes it very difficult to de-complicate things. Put another way, microservices make coupling far more obvious, and the presence of strong coupling in a microservice architecture should be a massive red flag - one that's really easy to miss in a monolith. The unfortunate thing about participating in these exchanges, however, is that it's impossible to explain ourselves in sufficient detail, so in the monolith vs microservice debate, we all end up just speaking across each other.
  - vintermann 3y ago
    No, I see your point. It's just that in my experience, the friction didn't do much to prevent coupling, because the friction was just that you had to write a lot of boilerplate code - not hard, just boring - and they were willing to do that rather than having a design meeting with me...

pmontra 3y ago

It's a well established term. Example, this article of James Lewis and Martin Fowler from 10 years ago https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html "To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. Any changes to the system involve building and deploying a new version of the server-side application."

cpach 3y ago

Here’s one take: https://signalvnoise.com/svn3/the-majestic-monolith/ https://signalvnoise.com/svn3/the-majestic-monolith/