4 ms·

why does everything have to be microservice oriented and what's wrong with a simple monlithic application that runs the whole thing? also, when are those ice c

by b20000 4y ago

why does everything have to be microservice oriented and what's wrong with a simple monlithic application that runs the whole thing? also, when are those ice cream machines going to get fixed?

toomuchtodo 4y ago
To your point, Shopify's monolith was handling 1.27M requests/sec on Black Friday: https://twitter.com/ShopifyEng/status/1597983918900510720 https://twitter.com/ShopifyEng/status/1597983918900510720 Thread: https://threadreaderapp.com/thread/1597983918900510720.html https://threadreaderapp.com/thread/1597983918900510720.html
- gscho 4y ago
  But ruby is too slow!
  - pxue 4y ago
    Lots of their code is in Go
    - ecshafer 4y ago
      Way way way more of our code in Ruby. Go (and now Rust) is really only used for very low level services with a high SLA (Like Infrastructure). Almost all business logic is Ruby + Rails.
      - vips7L 4y ago
        True but you’re still putting significant investment into ruby to speed it up. Ruby is slow. I don’t think any other company could do that.
- tiffanyh 4y ago
  > averaging 3 Terabytes per minute of egress traffic across our infrastructure. That’s 4.3 Petabytes per day! I’d hate to get that AWS bandwidth bill.
  - ip26 4y ago
    On the other hand, 4.3 Petabytes of VISA/MasterCard traffic is a bill you'd probably be happy to pay. (It's Shopify after all, not Flickr)
- aeyes 4y ago
  Is running a separate instance of the monolith with a separate database for every store really "a monolith" withstanding 1.27M rps? It's a bit like saying Magento served 1M rps on Black Friday leaving out the small but important detail that each individual store has separate infrastructure and manageable load. Divide and conquer works, congrats to the Shopify team that their design decisions worked out for their use case. And obviously some parts of the system are still shared but my guess is that they are not part of the monolith.
- spoils19 4y ago
  Exactly. I've written and maintained monoliths that handle close to ~20M requests per second, and it only went down once (when somebody tripped over the power cable!)
kemiller2002 4y ago
Well, I mean really most of the micro service architectures are just monoliths with network calls between the components.
- b20000 4y ago
  yeah, so what about locking? it must be a nightmare to make sure that the components all work together as intended...
  - Kamq 4y ago
    > yeah, so what about locking? POST /lock This is only a slight exaggeration over some of the stuff I've seen people try to pull.
  - xwolfi 4y ago
    So, normally, you do not need to lock. If all your services are single threaded, and you have a good transactional model, you only need to duplicate services to create parallel routes. You need to lock when you write a shared area from multiple sources with no opinion on write ordering. But say your pipeline is client-> decorator -> processor -> observer with client publication -> external partner, each input will go into a set of instances different from the previous and next one, and rejoin at the output who will queue and order them. You have parallel heavy work and sequential light result publication. Your simple output must be as fast as the sum of your parallel routes to minimize queueing. Ofc it s more complex, and I prefer 0 network hop myself, but I work on a large investment bank micro service system and we do not lock, and the component are both simple and complex enough that when one disappear, everything else waits or rebalances, and when it reappears it can catch up automatically, and go on. It consumes large amount of memory to keep a duplicated state in each component and persistence is not guaranteed to be on time (in fact, our persistence layer was 30 minutes behind by mid day, for years, until we dug into the 30yo sql)
    - b20000 4y ago
      so why do you need this to be distributed and why can you not use a monolithic server application, perhaps with background threads?
nathanaldensr 4y ago
This is a very informative YouTube video on that very subject (ice cream machines): https://www.youtube.com/watch?v=SrDEtSlqJC4 https://www.youtube.com/watch?v=SrDEtSlqJC4
ramenmeal 4y ago
In your monolith if you offload a request to a queue and have a background process processing the queue messages, what do you call that module processing messages? Is it a component of your monolith? I think a lot of teams would call it a microservice, I could see some people considering it a component of a service. Unless you're confounding microservices w/ async architectures and saying to drop asynchronous patterns like this all together.
- b20000 4y ago
  I don't need another process. I can use a thread. If the teams you are talking about never heard of threads and only know about microservices, then there is something seriously wrong with their CS education. Maybe they all were hired via leetcode. That could explain it. I'm not confounding anything. Distributed programming has its applications and uses, but if you don't have a good reason to use it, then don't, and use a thread in a single process for background processing.
  - oflor 4y ago
    And how does it recover incomplete tasks in case of sudden power outage? Microservices use persistent message brokers for that, which are not there in threads. Or are these monoliths all treated as pets with redundant power supply and network lines?
    - sebazzz 4y ago
      Thread does not imply no queue or no persistent storage. In fact, if you use something like Hangfire you already have that.
  - strokirk 4y ago
    My CS education (Stockholm, KTH) didn’t include anything about web service architecture, and information about threads was about how they are implemented in the OS at a low level, not how to use them effectively. I think this stuff is normally picked up after working in the industry.
- 4y ago
nijave 4y ago
>with globally distributed teams of developers with diverse skill levels The last place I worked with a monolith (~100 developers) put quite a bit of work into making sure everyone didn't step on everyone else's toes. This mostly propagated as optimizing CI and improving test quality (since a single flakey test could derail everyone's build) As to why "microservices" versus a few "normal" sized services I'm not sure why it's always "monolith" or "microservices"
- thiht 4y ago
  At my previous job we used "microservices" for lack of a better term, but really they were "business services". We tried calling them "business services", "macroservices" or just "services", but it was confusing so in the end we just stuck with "microservices".
  - nijave 4y ago
    I think we (as an industry) are basically just revisiting SOA https://en.m.wikipedia.org/wiki/Service-oriented_architecture https://en.m.wikipedia.org/wiki/Service-oriented_architectur... (but maybe with a little less Java this time)
deleted 4y ago
[deleted]
dboreham 4y ago
Because Conway.

by b20000 4y ago

why does everything have to be microservice oriented and what's wrong with a simple monlithic application that runs the whole thing? also, when are those ice cream machines going to get fixed?

toomuchtodo 4y ago

To your point, Shopify's monolith was handling 1.27M requests/sec on Black Friday: https://twitter.com/ShopifyEng/status/1597983918900510720 https://twitter.com/ShopifyEng/status/1597983918900510720 Thread: https://threadreaderapp.com/thread/1597983918900510720.html https://threadreaderapp.com/thread/1597983918900510720.html

gscho 4y ago
But ruby is too slow!
- pxue 4y ago
  Lots of their code is in Go
  - ecshafer 4y ago
    Way way way more of our code in Ruby. Go (and now Rust) is really only used for very low level services with a high SLA (Like Infrastructure). Almost all business logic is Ruby + Rails.
    - vips7L 4y ago
      True but you’re still putting significant investment into ruby to speed it up. Ruby is slow. I don’t think any other company could do that.
tiffanyh 4y ago
> averaging 3 Terabytes per minute of egress traffic across our infrastructure. That’s 4.3 Petabytes per day! I’d hate to get that AWS bandwidth bill.
- ip26 4y ago
  On the other hand, 4.3 Petabytes of VISA/MasterCard traffic is a bill you'd probably be happy to pay. (It's Shopify after all, not Flickr)
aeyes 4y ago
Is running a separate instance of the monolith with a separate database for every store really "a monolith" withstanding 1.27M rps? It's a bit like saying Magento served 1M rps on Black Friday leaving out the small but important detail that each individual store has separate infrastructure and manageable load. Divide and conquer works, congrats to the Shopify team that their design decisions worked out for their use case. And obviously some parts of the system are still shared but my guess is that they are not part of the monolith.
spoils19 4y ago
Exactly. I've written and maintained monoliths that handle close to ~20M requests per second, and it only went down once (when somebody tripped over the power cable!)

kemiller2002 4y ago

Well, I mean really most of the micro service architectures are just monoliths with network calls between the components.

b20000 4y ago
yeah, so what about locking? it must be a nightmare to make sure that the components all work together as intended...
- Kamq 4y ago
  > yeah, so what about locking? POST /lock This is only a slight exaggeration over some of the stuff I've seen people try to pull.
- xwolfi 4y ago
  So, normally, you do not need to lock. If all your services are single threaded, and you have a good transactional model, you only need to duplicate services to create parallel routes. You need to lock when you write a shared area from multiple sources with no opinion on write ordering. But say your pipeline is client-> decorator -> processor -> observer with client publication -> external partner, each input will go into a set of instances different from the previous and next one, and rejoin at the output who will queue and order them. You have parallel heavy work and sequential light result publication. Your simple output must be as fast as the sum of your parallel routes to minimize queueing. Ofc it s more complex, and I prefer 0 network hop myself, but I work on a large investment bank micro service system and we do not lock, and the component are both simple and complex enough that when one disappear, everything else waits or rebalances, and when it reappears it can catch up automatically, and go on. It consumes large amount of memory to keep a duplicated state in each component and persistence is not guaranteed to be on time (in fact, our persistence layer was 30 minutes behind by mid day, for years, until we dug into the 30yo sql)
  - b20000 4y ago
    so why do you need this to be distributed and why can you not use a monolithic server application, perhaps with background threads?

nathanaldensr 4y ago

This is a very informative YouTube video on that very subject (ice cream machines): https://www.youtube.com/watch?v=SrDEtSlqJC4 https://www.youtube.com/watch?v=SrDEtSlqJC4

ramenmeal 4y ago

In your monolith if you offload a request to a queue and have a background process processing the queue messages, what do you call that module processing messages? Is it a component of your monolith? I think a lot of teams would call it a microservice, I could see some people considering it a component of a service. Unless you're confounding microservices w/ async architectures and saying to drop asynchronous patterns like this all together.

b20000 4y ago
I don't need another process. I can use a thread. If the teams you are talking about never heard of threads and only know about microservices, then there is something seriously wrong with their CS education. Maybe they all were hired via leetcode. That could explain it. I'm not confounding anything. Distributed programming has its applications and uses, but if you don't have a good reason to use it, then don't, and use a thread in a single process for background processing.
- oflor 4y ago
  And how does it recover incomplete tasks in case of sudden power outage? Microservices use persistent message brokers for that, which are not there in threads. Or are these monoliths all treated as pets with redundant power supply and network lines?
  - sebazzz 4y ago
    Thread does not imply no queue or no persistent storage. In fact, if you use something like Hangfire you already have that.
- strokirk 4y ago
  My CS education (Stockholm, KTH) didn’t include anything about web service architecture, and information about threads was about how they are implemented in the OS at a low level, not how to use them effectively. I think this stuff is normally picked up after working in the industry.
4y ago

nijave 4y ago

>with globally distributed teams of developers with diverse skill levels The last place I worked with a monolith (~100 developers) put quite a bit of work into making sure everyone didn't step on everyone else's toes. This mostly propagated as optimizing CI and improving test quality (since a single flakey test could derail everyone's build) As to why "microservices" versus a few "normal" sized services I'm not sure why it's always "monolith" or "microservices"

thiht 4y ago
At my previous job we used "microservices" for lack of a better term, but really they were "business services". We tried calling them "business services", "macroservices" or just "services", but it was confusing so in the end we just stuck with "microservices".
- nijave 4y ago
  I think we (as an industry) are basically just revisiting SOA https://en.m.wikipedia.org/wiki/Service-oriented_architecture https://en.m.wikipedia.org/wiki/Service-oriented_architectur... (but maybe with a little less Java this time)

deleted 4y ago

[deleted]

dboreham 4y ago

Because Conway.