6 ms·

Am I the only one that loves the monolith? Apart from the scaling mentioned in the article, this feels like accidental complexity. And, let's face it, 95% of ap

by BenoitP 11y ago

Am I the only one that loves the monolith? Apart from the scaling mentioned in the article, this feels like accidental complexity. And, let's face it, 95% of apps are about serializing complex business problems into code. Also, I don't agree with: > Since these components are doing different things, there is little chance that there would be a performance benefit Complementary workloads should not be a problem. It would actually make thrifty usage of the hardware. The only reason I see for breaking the app this way would be to enforce low coupling.

regularfry 11y ago
The app in the article is an interesting case. If you've got an app split like that, working backwards from Conway's Law tells us there are likely two separate teams working on it. Cutting the deployment in half may well allow each team to become more independent. That might be the real win.
- fatherlinnux 11y ago
  I actually regretted not mentioning the organizational advantage. Basically, scaling and organizational split are really the major two business drivers for splitting an application up!
dayjah 11y ago
Monoliths have their role in the world, certainly! I've heard Facebook have a mantra of sorts about their monolith, if anyone here could corroborate that would be great. It goes something like: - build v1 in the monolith - do users like v1? - if so, does v1 use too much of the monolith? - improve the implementation within the monolith - does it still use too much of the monolith? Break it out into its own stack I believe there are only two stacks: - ad serving, where literally lower latency is more money and thus benefits from optimizations not realistic within the monolith, - and "everything else".
- ghaff 11y ago
  Martin Fowler has argued for something similar. [1] I suspect that the "right" answer is complicated and based on things like where you're coming from, the size of team(s), and the degree to which there are well-defined shared services. DHH of Basecamp also argued recently [2] that Monoliths can make sense although I noted at the time that, with a team size of about 12 engineers, that isn't much larger than the two-pizza team sizes you see promoted for microservices functions. [1] http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html [2] https://m.signalvnoise.com/the-majestic-monolith-29166d022228#.3npyzyfsr https://m.signalvnoise.com/the-majestic-monolith-29166d02222...
- Touche 11y ago
  Also known as "we'll fix it later".
thraxil 11y ago
>> Since these components are doing different things, there is little chance that there would be a performance benefit > Complementary workloads should not be a problem. It would actually make thrifty usage of the hardware. The argument continued "there is little chance that there would be a performance benefit from being in the same JVM". Splitting the two components out into separate containers doesn't preclude running them on the same hardware. But it does give you the option of running them on separate hardware, which may allow for even more efficient overall hardware usage.
- jburwell 11y ago
  The only performance reason I could imagine would be if both pieces had required large heaps and had difference garbage collection profiles. Putting them in separate containers (and by extension JVMs) would split the size of the heap for garbage collection and provide more deterministic garbage collection cycle times. However, to receive such a benefit, the heaps would need to be fairly large (e.g. greater than 4GB each).
  - pyre 11y ago
    > (e.g. greater than 4GB each). That's an awful lot of RAM to be using. I doubt many people even have servers with that amount of RAM in them let alone enough for 2.
    - justincormack 11y ago
      Have you seen a modern server? People have 1TB Ram in some of them.
      - pyre 11y ago
        I thought that I didn't need to explicitly tag that as sarcasm. Apparently I was wrong...
      - majewsky 11y ago
        I've seen 2TB already.
brightball 11y ago
In many cases, I consider microservices an optimization. It's usually just a case of time to market to getting enough paying customers to afford to spend time on the optimizations. Monoliths are great for time to market. Here's a piece I wrote for Codeship breaking down the problem and how Heroku can seriously insulate you from the complexity of microservices. https://blog.codeship.com/exploring-microservices-architecture-on-heroku/ https://blog.codeship.com/exploring-microservices-architectu...
eternalban 11y ago
> Am I the only one that loves the monolith? Discussions on this topic are typically mired by a lack of conceptual clarity†. Are we describing a monolith in terms of the process model, or the deployment model? In context of scale-up/scale-out concerns, we would be considering the deployment model. In context of loose-coupling and extensibility, we would be considering the process model. Postgres is a classic example. [1] [edit: note above are not mutually exclusive.] Naturally, an increase in the number of moving parts places additional orthogonal demands in terms of operational integrity. As with any upward clicks of complexity, the decisions should be informed by valid‡ requirements and facts. Ok, done with my mini rant /g. As to your query, in certain cases a monolith is indeed worthy of love. [1]: http://raghavt.blogspot.com/2011/04/postgresql-90-architecture.html http://raghavt.blogspot.com/2011/04/postgresql-90-architectu... † Not a surprise in a field celebrating its unique brand of "senior engineers with 3 years of experience"... ‡ No, hype cycles are not valid architectural and/or business requirements.
- mwcampbell 11y ago
  For further clarity, I suggest these blog posts by Uncle Bob Martin: http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroService... http://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArchitecture.html http://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicrose...
- toomuchtodo 11y ago
  > ‡ No, hype cycles are not valid architectural and/or business requirements. I'm stealing this. Fantastic way to highlight motivation for certain techs.
  - jtuente 11y ago
    It also sounds way more polite than calling it something like a circlejerk.
carlosnunez 11y ago
I don't have a lot of skin in the microservices architecture game, but my gut intuition tells me that in most cases, it's better to build your business on a monolith for simplicity (it's easier to conceptualize your entire application when it's one thing) and then break it down when it's "proven."
awinder 11y ago
Do people tend to love "THE" monolith, or do they tend to love "THEIR" monolith? By that I mean, do people like some of the simplicity & efficiencies of the monolith pattern as a general pattern, or only when they're able to strictly control the evolution of the architecture in there?
antihero 11y ago
What about the deployment benefit? Surely if you want to scale out your API you don't necessarily want to scale out your webservers - that's ludicrous! Surely the applications should be already decoupled enough that there's pretty much zero reason to run the backend on and serve the frontend from the same box? And it's not like an SPA really needs any power - if you're just serving up bundled JavaScript and some HTML, anyway.
- joshmanders 11y ago
  This is exactly what I do. My product consists of 4 base docker containers. 1 is a nginx reverse proxy to 2 of the 3 remaining containers. 1 is a database container. The 2 other containers hold the API which is "monolithic" app. The other container is just bundled html/css/javascript. This allows me to scale the API to handle load independent of the app itself, since that's just static assets, it doesn't need it as much.
  - antihero 11y ago
    I have basically a docker image that basically is just an nginx reverse proxy that forwards to a local socket. Then I can use it with whatever app I want, (usually node) and it provides a slightly "harder" (request buffering etc) http interface to the outside world.
- fatherlinnux 11y ago
  This was exactly why I chose the workload I did. I think independent scaling and possibly enforcing decoupled behavior in the development teams are the only real reason TO decouple.... The rest are all descriptions of things that "might" make decoupling valid :-)
olalonde 11y ago
> The only reason I see for breaking the app this way would be to enforce low coupling. Which is a big deal... Microservices enable easier code re-use and division of labor across teams, especially when persistent data is involved. It is a technical solution to a people/economic problem and not the other way around. At a high level, I think of all the popular APIs powering the web (Stripe, Google Analytics, Twilio, Intercom, etc.) and how they enable developers to do their work more efficiently. "Buy vs build" was mentioned as a promising attack on accidental complexity in "No Silver Bullet". If you design your microservices in a way that they're usable in different contexts and don't build at all when a paid or open source solution is available, you will boost your productivity.
- fatherlinnux 11y ago
  This is again, getting to the right answer for the wrong reason. You could keep these code bases separate whether they run in the same JVM in one container or in separate JVMs in different containers. As long as you enforce communication over something like REST, you will never have a problem. In fact, the application was already written this way and it was never enforced. This makes no sense to enforce if it wasn't already broken.
fatherlinnux 11y ago
Fair point, but it's an existing application. I sort of assume it has low coupling already. But, if it already has low coupling, one might fairly ask, why do I need to enforce it? For some future optimization?
- cpitman 11y ago
  Because applications that don't structurally enforce low-coupling are touched by many hands over time. All it takes is the occasional blurring of the line to end up with extreme-coupling down the road.
fatherlinnux 11y ago
My argument is, if two different processes are doing completely different things in the same JVM, I am skeptical that they will share memory pages well, etc. I simply don't know without testing, but I don't have any reason to believe they would. On the other had, if I was running multiple threads that all cached data from the same data store, it is quite likely that scaling up threads in the same JVM would have a massive advantage over splitting them into multiple JVMs. Also, in the comments I admit that over 10K applications on 1K machines, it's probably better 99% of the time not to use 10K JVMs. There would be a huge CPU/Memory overhead....

by BenoitP 11y ago

regularfry 11y ago

The app in the article is an interesting case. If you've got an app split like that, working backwards from Conway's Law tells us there are likely two separate teams working on it. Cutting the deployment in half may well allow each team to become more independent. That might be the real win.

fatherlinnux 11y ago
I actually regretted not mentioning the organizational advantage. Basically, scaling and organizational split are really the major two business drivers for splitting an application up!

dayjah 11y ago

Monoliths have their role in the world, certainly! I've heard Facebook have a mantra of sorts about their monolith, if anyone here could corroborate that would be great. It goes something like: - build v1 in the monolith - do users like v1? - if so, does v1 use too much of the monolith? - improve the implementation within the monolith - does it still use too much of the monolith? Break it out into its own stack I believe there are only two stacks: - ad serving, where literally lower latency is more money and thus benefits from optimizations not realistic within the monolith, - and "everything else".

ghaff 11y ago
Martin Fowler has argued for something similar. [1] I suspect that the "right" answer is complicated and based on things like where you're coming from, the size of team(s), and the degree to which there are well-defined shared services. DHH of Basecamp also argued recently [2] that Monoliths can make sense although I noted at the time that, with a team size of about 12 engineers, that isn't much larger than the two-pizza team sizes you see promoted for microservices functions. [1] http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html [2] https://m.signalvnoise.com/the-majestic-monolith-29166d022228#.3npyzyfsr https://m.signalvnoise.com/the-majestic-monolith-29166d02222...
Touche 11y ago
Also known as "we'll fix it later".

thraxil 11y ago

>> Since these components are doing different things, there is little chance that there would be a performance benefit > Complementary workloads should not be a problem. It would actually make thrifty usage of the hardware. The argument continued "there is little chance that there would be a performance benefit from being in the same JVM". Splitting the two components out into separate containers doesn't preclude running them on the same hardware. But it does give you the option of running them on separate hardware, which may allow for even more efficient overall hardware usage.

jburwell 11y ago
The only performance reason I could imagine would be if both pieces had required large heaps and had difference garbage collection profiles. Putting them in separate containers (and by extension JVMs) would split the size of the heap for garbage collection and provide more deterministic garbage collection cycle times. However, to receive such a benefit, the heaps would need to be fairly large (e.g. greater than 4GB each).
- pyre 11y ago
  > (e.g. greater than 4GB each). That's an awful lot of RAM to be using. I doubt many people even have servers with that amount of RAM in them let alone enough for 2.
  - justincormack 11y ago
    Have you seen a modern server? People have 1TB Ram in some of them.
    - pyre 11y ago
      I thought that I didn't need to explicitly tag that as sarcasm. Apparently I was wrong...
    - majewsky 11y ago
      I've seen 2TB already.

brightball 11y ago

In many cases, I consider microservices an optimization. It's usually just a case of time to market to getting enough paying customers to afford to spend time on the optimizations. Monoliths are great for time to market. Here's a piece I wrote for Codeship breaking down the problem and how Heroku can seriously insulate you from the complexity of microservices. https://blog.codeship.com/exploring-microservices-architecture-on-heroku/ https://blog.codeship.com/exploring-microservices-architectu...

eternalban 11y ago

> Am I the only one that loves the monolith? Discussions on this topic are typically mired by a lack of conceptual clarity†. Are we describing a monolith in terms of the process model, or the deployment model? In context of scale-up/scale-out concerns, we would be considering the deployment model. In context of loose-coupling and extensibility, we would be considering the process model. Postgres is a classic example. [1] [edit: note above are not mutually exclusive.] Naturally, an increase in the number of moving parts places additional orthogonal demands in terms of operational integrity. As with any upward clicks of complexity, the decisions should be informed by valid‡ requirements and facts. Ok, done with my mini rant /g. As to your query, in certain cases a monolith is indeed worthy of love. [1]: http://raghavt.blogspot.com/2011/04/postgresql-90-architecture.html http://raghavt.blogspot.com/2011/04/postgresql-90-architectu... † Not a surprise in a field celebrating its unique brand of "senior engineers with 3 years of experience"... ‡ No, hype cycles are not valid architectural and/or business requirements.

mwcampbell 11y ago
For further clarity, I suggest these blog posts by Uncle Bob Martin: http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroService... http://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArchitecture.html http://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicrose...
toomuchtodo 11y ago
> ‡ No, hype cycles are not valid architectural and/or business requirements. I'm stealing this. Fantastic way to highlight motivation for certain techs.
- jtuente 11y ago
  It also sounds way more polite than calling it something like a circlejerk.

carlosnunez 11y ago

I don't have a lot of skin in the microservices architecture game, but my gut intuition tells me that in most cases, it's better to build your business on a monolith for simplicity (it's easier to conceptualize your entire application when it's one thing) and then break it down when it's "proven."

awinder 11y ago

Do people tend to love "THE" monolith, or do they tend to love "THEIR" monolith? By that I mean, do people like some of the simplicity & efficiencies of the monolith pattern as a general pattern, or only when they're able to strictly control the evolution of the architecture in there?

antihero 11y ago

What about the deployment benefit? Surely if you want to scale out your API you don't necessarily want to scale out your webservers - that's ludicrous! Surely the applications should be already decoupled enough that there's pretty much zero reason to run the backend on and serve the frontend from the same box? And it's not like an SPA really needs any power - if you're just serving up bundled JavaScript and some HTML, anyway.

joshmanders 11y ago
This is exactly what I do. My product consists of 4 base docker containers. 1 is a nginx reverse proxy to 2 of the 3 remaining containers. 1 is a database container. The 2 other containers hold the API which is "monolithic" app. The other container is just bundled html/css/javascript. This allows me to scale the API to handle load independent of the app itself, since that's just static assets, it doesn't need it as much.
- antihero 11y ago
  I have basically a docker image that basically is just an nginx reverse proxy that forwards to a local socket. Then I can use it with whatever app I want, (usually node) and it provides a slightly "harder" (request buffering etc) http interface to the outside world.
fatherlinnux 11y ago
This was exactly why I chose the workload I did. I think independent scaling and possibly enforcing decoupled behavior in the development teams are the only real reason TO decouple.... The rest are all descriptions of things that "might" make decoupling valid :-)

olalonde 11y ago

> The only reason I see for breaking the app this way would be to enforce low coupling. Which is a big deal... Microservices enable easier code re-use and division of labor across teams, especially when persistent data is involved. It is a technical solution to a people/economic problem and not the other way around. At a high level, I think of all the popular APIs powering the web (Stripe, Google Analytics, Twilio, Intercom, etc.) and how they enable developers to do their work more efficiently. "Buy vs build" was mentioned as a promising attack on accidental complexity in "No Silver Bullet". If you design your microservices in a way that they're usable in different contexts and don't build at all when a paid or open source solution is available, you will boost your productivity.

fatherlinnux 11y ago
This is again, getting to the right answer for the wrong reason. You could keep these code bases separate whether they run in the same JVM in one container or in separate JVMs in different containers. As long as you enforce communication over something like REST, you will never have a problem. In fact, the application was already written this way and it was never enforced. This makes no sense to enforce if it wasn't already broken.

fatherlinnux 11y ago

Fair point, but it's an existing application. I sort of assume it has low coupling already. But, if it already has low coupling, one might fairly ask, why do I need to enforce it? For some future optimization?

cpitman 11y ago
Because applications that don't structurally enforce low-coupling are touched by many hands over time. All it takes is the occasional blurring of the line to end up with extreme-coupling down the road.

fatherlinnux 11y ago

My argument is, if two different processes are doing completely different things in the same JVM, I am skeptical that they will share memory pages well, etc. I simply don't know without testing, but I don't have any reason to believe they would. On the other had, if I was running multiple threads that all cached data from the same data store, it is quite likely that scaling up threads in the same JVM would have a massive advantage over splitting them into multiple JVMs. Also, in the comments I admit that over 10K applications on 1K machines, it's probably better 99% of the time not to use 10K JVMs. There would be a huge CPU/Memory overhead....