5 ms·

The Great Microservices vs. Monolithic Apps Twitter Melee

42 points by Garbage 12y ago

FooBarWidget 12y ago
Why is it "microservices" vs "monolithic"? It's not black and white, it's a continuum. Why would 300 microservices make more sense than, say, 6 medium-sized SOA apps? According to the article, the point of microservices is scaling development, not scaling as in req/sec. But development scaling can already be done without microservices. You can already split source code in multiple files. You can already refactor classes into multiple smaller classes. So then why are microservices "awesome"? Why does it make more sense to have 300 microservices, each 500 lines, compared to 6 medium-size SOA apps, each consisting of 25.000 lines spread over 50 files/classes? Now, if you have 200 developers then I understand why splitting your app into 50+ independent microservices makes sense. But I get the feeling that lots of developers, even those in 3-man teams, are jumping on the several-hundred-microservices bandwagon.
- lkrubner 12y ago
  We had this debate at my company. You might want to read this: http://www.smashcompany.com/technology/an-architecture-of-small-apps http://www.smashcompany.com/technology/an-architecture-of-sm... It's important to realize that you are wrong when you use the word "continuum". In a true continuum you can move in both directions with equal ease, whereas there is an important asymmetry in the tension between micro-services and monolithic apps. Read this part: "There is an important asymmetry between an architecture of small apps and an architecture of The Monolithic CMS. If you have small apps, and decide you want to move to a monolithic CMS, then you must do The Big Rewrite: the exhausting effort of reproducing all of your funtionality so that it is handled by your one, all-consuming CMS. But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Instead you take some small part of your CMS, rewrite it as an independent app, set the app on its own port, use your webserver to proxy the app-on-a-port to whatever URL the CMS was previously using for that functionality, and thus you’ve taken a step towards a new architecture without having to rewrite anything but the functionality covered by your new, small app." I did not hear the phrase "micro-services" until Martin Fowler wrote his essay in March 2014, but clearly, what I talked about in that essay, 14 months ago, is what we would now call micro-services.
  - krschultz 12y ago
    That's the first time I've ever read it was hard to move from a collection of small services to a monolith, and easy to move from a monolith to small services.
    - SerpentJoe 12y ago
      Agreed, that seems totally backward from my experience. I notice no justification is given either, apart from describing both refactors (small->large and large->small).
  - joshuacc 12y ago
    I found this to be a much better article than the OP since it is very focused on the practicalities.
    - lkrubner 12y ago
      The user "slyall" just submitted it: https://news.ycombinator.com/item?id=8204826 https://news.ycombinator.com/item?id=8204826
  - d23 12y ago
    > But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Uh, what? Maybe if your app is written The Right Way, but in cases where encapsulation and cohesion are poor, where do you begin splitting? Services, on the other hand, force encapsulation from the get-go. Why wouldn't it be easier to connect them -- it's what they designed to do.
    - derefr 12y ago
      You don't need to do a big rewrite. Instead, you 1. turn your current monolith into one service (e.g. "cms-legacy"); 2. fork the monolith codebase and remove everything not needed for that one particular component; 3. rewrite your integration tests for that component to use gateways, such that they either can be talking to the componentized service or the legacy service implementation without caring; 4. refactor the component into your favored beautiful new SOA design; 3. ensure the integration tests continue to pass; 4. remove the equivalent component implementation from the legacy codebase, and reimplement the shell of its consumer-facing API with calls to the componentized service (think LibreSSL here); 5. ensure the integration tests continue to pass; 6. repeat. Basically, this is the Big Ball Of Mud (http://www.laputan.org/mud/ http://www.laputan.org/mud/) strategy, applied to cohesion between services rather than cohesion between modules.
coldcode 12y ago
Anyone else tired of people arguing complex concepts in tweets? So hard to read. People don't usually talk in single sentences.
- FooBarWidget 12y ago
  Yes, extremely. I receive questions from time to time for which the answer is complicated (and if I simplify the answer, the important nuance will be lost). I usually write my response in a gist and tweet a link to it. But the thing is: Twitter is extremely easy to use and the barrier to tweeting is extremely low, more so than email. People are more inclined to tweet than to send an email, even for complex subjects. As much as I dislike it, this is how things are, so better accept it and use it to your advantage than trying to fight it or complain about it.
  - johnchristopher 12y ago
    But why hasn't a twitter clone/alternative that would allow more than 140 characters taken off yet then ?
    - ryandvm 12y ago
      This seems like the premise of an Onion article...
    - bunderbunder 12y ago
      There's an interesting startup that I think does that. It's called Facebook.
      - aikah 12y ago
        Then why are people using Twitter then ? You cant say Facebook is like Twitter with more characters in the messages,it simply doesnt work.
        FooBarWidget 12y ago
emo_tards_on_hn 12y ago
But, I have more services! But, each of my fewer services do more! And this folks, is why IT is still a joke in most quarters.
deleted 12y ago
[deleted]
mbseid 12y ago
I also think a lot has to do with language and deployment. Etsy uses PHP for their entire codebase. PHP can be easily hot swapped without any overhead. It's all scaffolded and thrown out every pageview. This provides a much simpler deploy process and has much less impact. Java on the other hand takes time to warm up. It just isn't practical to redeploy the whole app when you are just updated one aspect.
fminor 12y ago
The thing that strikes me is that John Allspaw provides literally zero examples of how the constraints of a monolith provide any benefit. He asserts they do and walks away. It's some weak tea.

42 points by Garbage 12y ago

Why is it "microservices" vs "monolithic"? It's not black and white, it's a continuum. Why would 300 microservices make more sense than, say, 6 medium-sized SOA apps? According to the article, the point of microservices is scaling development, not scaling as in req/sec. But development scaling can already be done without microservices. You can already split source code in multiple files. You can already refactor classes into multiple smaller classes. So then why are microservices "awesome"? Why does it make more sense to have 300 microservices, each 500 lines, compared to 6 medium-size SOA apps, each consisting of 25.000 lines spread over 50 files/classes? Now, if you have 200 developers then I understand why splitting your app into 50+ independent microservices makes sense. But I get the feeling that lots of developers, even those in 3-man teams, are jumping on the several-hundred-microservices bandwagon.

lkrubner 12y ago
We had this debate at my company. You might want to read this: http://www.smashcompany.com/technology/an-architecture-of-small-apps http://www.smashcompany.com/technology/an-architecture-of-sm... It's important to realize that you are wrong when you use the word "continuum". In a true continuum you can move in both directions with equal ease, whereas there is an important asymmetry in the tension between micro-services and monolithic apps. Read this part: "There is an important asymmetry between an architecture of small apps and an architecture of The Monolithic CMS. If you have small apps, and decide you want to move to a monolithic CMS, then you must do The Big Rewrite: the exhausting effort of reproducing all of your funtionality so that it is handled by your one, all-consuming CMS. But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Instead you take some small part of your CMS, rewrite it as an independent app, set the app on its own port, use your webserver to proxy the app-on-a-port to whatever URL the CMS was previously using for that functionality, and thus you’ve taken a step towards a new architecture without having to rewrite anything but the functionality covered by your new, small app." I did not hear the phrase "micro-services" until Martin Fowler wrote his essay in March 2014, but clearly, what I talked about in that essay, 14 months ago, is what we would now call micro-services.
- krschultz 12y ago
  That's the first time I've ever read it was hard to move from a collection of small services to a monolith, and easy to move from a monolith to small services.
  - SerpentJoe 12y ago
    Agreed, that seems totally backward from my experience. I notice no justification is given either, apart from describing both refactors (small->large and large->small).
- joshuacc 12y ago
  I found this to be a much better article than the OP since it is very focused on the practicalities.
  - lkrubner 12y ago
    The user "slyall" just submitted it: https://news.ycombinator.com/item?id=8204826 https://news.ycombinator.com/item?id=8204826
- d23 12y ago
  > But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Uh, what? Maybe if your app is written The Right Way, but in cases where encapsulation and cohesion are poor, where do you begin splitting? Services, on the other hand, force encapsulation from the get-go. Why wouldn't it be easier to connect them -- it's what they designed to do.
  - derefr 12y ago
    You don't need to do a big rewrite. Instead, you 1. turn your current monolith into one service (e.g. "cms-legacy"); 2. fork the monolith codebase and remove everything not needed for that one particular component; 3. rewrite your integration tests for that component to use gateways, such that they either can be talking to the componentized service or the legacy service implementation without caring; 4. refactor the component into your favored beautiful new SOA design; 3. ensure the integration tests continue to pass; 4. remove the equivalent component implementation from the legacy codebase, and reimplement the shell of its consumer-facing API with calls to the componentized service (think LibreSSL here); 5. ensure the integration tests continue to pass; 6. repeat. Basically, this is the Big Ball Of Mud (http://www.laputan.org/mud/ http://www.laputan.org/mud/) strategy, applied to cohesion between services rather than cohesion between modules.

coldcode 12y ago

Anyone else tired of people arguing complex concepts in tweets? So hard to read. People don't usually talk in single sentences.

FooBarWidget 12y ago
Yes, extremely. I receive questions from time to time for which the answer is complicated (and if I simplify the answer, the important nuance will be lost). I usually write my response in a gist and tweet a link to it. But the thing is: Twitter is extremely easy to use and the barrier to tweeting is extremely low, more so than email. People are more inclined to tweet than to send an email, even for complex subjects. As much as I dislike it, this is how things are, so better accept it and use it to your advantage than trying to fight it or complain about it.
- johnchristopher 12y ago
  But why hasn't a twitter clone/alternative that would allow more than 140 characters taken off yet then ?
  - ryandvm 12y ago
    This seems like the premise of an Onion article...
  - bunderbunder 12y ago
    There's an interesting startup that I think does that. It's called Facebook.
    - aikah 12y ago
      Then why are people using Twitter then ? You cant say Facebook is like Twitter with more characters in the messages,it simply doesnt work.
      - FooBarWidget 12y ago

emo_tards_on_hn 12y ago

But, I have more services! But, each of my fewer services do more! And this folks, is why IT is still a joke in most quarters.

deleted 12y ago

[deleted]

mbseid 12y ago

I also think a lot has to do with language and deployment. Etsy uses PHP for their entire codebase. PHP can be easily hot swapped without any overhead. It's all scaffolded and thrown out every pageview. This provides a much simpler deploy process and has much less impact. Java on the other hand takes time to warm up. It just isn't practical to redeploy the whole app when you are just updated one aspect.

fminor 12y ago

The thing that strikes me is that John Allspaw provides literally zero examples of how the constraints of a monolith provide any benefit. He asserts they do and walks away. It's some weak tea.