5 ms·

Good post in general but some caveats: 1) His user numbers are off by an order of magnitude at least, as other comments have mentioned. Even a VM/VPS should ha

Good post in general but some caveats: 1) His user numbers are off by an order of magnitude at least, as other comments have mentioned. Even a VM/VPS should handle more, and a modern bare-metal server will do way more than the quoted numbers. 2) Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud. Upside: lower prices & complexity. Downside: say goodbye to your AWS ReInvent invite. 3) Microservices. Apparently redeploying stateless appservers is a problem (despite the autoscaling part doing exactly this in response to load spikes which he's fine with), and his solution is to introduce 100x the management overhead and points of failure? The argument about scaling separate features differently doesn't make sense either - unless your code is literally so big it can't all fit in one server, there is no problem having every server be able to serve all types of requests, and as a bonus you no longer have to predict the expected load on a per-feature basis. A monolith's individual features can still talk to separate databases just fine.

withinboredom 8mo ago
And to add to this: virtually every programming language allows you to define multiple entry points. So you can have your workers in the exact same codebase as your api and even multiple api services. They can share code and data structures or whatever you need. So, if you do need this kind of complexity with multiple services, you don’t need separate repos and elaborate build systems and dependency hell.
mbb70 8mo ago
As is often stated, microservices is a solution for scaling an engineering org to 100s of developers, not for scaling a product to millions of users.
- steveBK123 8mo ago
  Unfortunately that message was way way behind the bombast of "microservices everywhere now" that preceded it for years, to the detriment of many small orgs. I've seen engineering orgs of 10-50 launch headlong into microservices to poor results. No exaggeration to say many places ended up with more repos & services than developers to manage them.
  - butvacuum 8mo ago
    do they all manage to have 4 different ways to do something like "notify user about x", all In use because they could never be bothered to complete the "upgrade"?
    - steveBK123 8mo ago
      Exactly the problem yes. Once you have more services than developers, you are probably running into infrequent releases and orphaned projects. So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying. When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
    - Nextgrid 8mo ago
      That's often the case yes. In a monolith a developer disgruntled about the situation can clean up the mess in a weekend, test it and push it through. No chance of that happening in microservices - you'd run out of weekend just opening PRs in the dozens of repos and dealing with all the nitpicking and turf wars.
      - butvacuum 8mo ago
        I've had the unfortunate experence to run into a situation where two dev's who hated eachother ended up building two systems with one passing the customer's API calls' http content directly to the front end... It was supposed to be back end and front end.
- Nextgrid 8mo ago
  You can get the separation benefits of microservices in a compiled language with modules that only communicate over well-defined interfaces, constraining each team within their own module without having to introduce a network call between each operation.
  - samrus 8mo ago
    Python dev is cheaper and faster though. People arent gonna kill velocity by making their backend in c++ so the devs can have seperation of concerns, something that can, and should, be self enforced with discipline
    - Nextgrid 8mo ago
      Java or C# is a nice middle ground. But even in python you can enforce said separation - one module can only import from itself, libraries or any other module’s “services” object, and must export its functions in its own “services” object.
- sumitkumar 8mo ago
  Microservices is bad for teams without discipline to implement "separation of concerns". They hope that physical network boundaries will force the discipline they couldn't maintain in a single codebase. While microservices force physical separation, they don't stop "Spaghetti Architecture." Instead of messy code, you end up with "Distributed Spaghetti," where the dependencies are hidden in network calls and shared databases. Microservices require more discipline in areas like: Observability: Tracking a single request across 10 services. Consistency: Dealing with distributed transactions and eventual consistency. DevOps: Managing N deployment pipelines instead of one. For most teams Modular monolith is often the better "first step." It enforces strict boundaries within a single deployment unit using language-level visibility (like private packages or modules). It gives you the "Separation of Concerns" without the "Distributed Spaghetti" network tax.
  - KellyCriterion 8mo ago
    > and shared databases. According to my understanding this is one of the reasons why microservices were invented, to prevent shared databases?
  - philipallstar 8mo ago
    > Observability: Tracking a single request across 10 services I'm not sure if this is a discipline issue in the way that domain driven design, say, is a discipline issue. If you instrument requests with a global ID and point at tool at it then you're basically done from the individual team perspective.
    - ffsm8 8mo ago
      Uh, that's not my experience at all. Sure you can say e.g "this property wasnt set in this request while being processed by this service managed by this team", but why it wasn't set will inevitably need multiple teams, each doing in-depth analysis how such as state could've been caused because they always inevitably become distributed monoliths - the former is being provided by the instrumentation, but the latter isn't (and even the former is not perfect, as not all frameworks/languages have equal support)
yomismoaqui 8mo ago
The best descripcion of microservices comes from "The Grug Brained Developer" (https://grugbrain.dev/ https://grugbrain.dev/): "grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug"
- Nextgrid 8mo ago
  Grug actually covers this in his essay: > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer Microservices definitely contribute to having a "large tribe of developer" to manage.
  - disqard 8mo ago
    Obligatory Krazam: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
techpression 8mo ago
I was reading it and got seriously confused by separate database and server for a measly 1000 users. With the two separate you can scale vertically to handle a million users if all you’re doing is basic web/rest type stuff, probably more. I feel a bit of sadness for people who had never used a bare metal server and seen how insanely capable hardware is today.
sofixa 8mo ago
> Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling. Especially today, with the costs of memory and storage. Not to mention that whenever you hit your load maximum, you have a few months of lead time to get extra capacity. And FYI, "proprietary vendor-specific APIs" sounds very scary, but if you think about it for a few seconds, those APIs end at configuring an autoscaling group which is mostly about your min/max, and scaling rules. Yeah, it's proprietary, but it's 3-4 parameters to configure based on what you need, and from then little if any adjustment is needed. And you can take the same logic and port it to any other cloud provider within ~10 mins at most.
- lelanthran 8mo ago
  > And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling. If you know when that week is, where's the problem in spinning up extra capacity just for that period, a week in advance? Retailers, whether online or not, know with a very high confidence what their expected load is going to be a week from now.
  - sofixa 8mo ago
    But you have to buy those servers, set them up, use them for that week, and then they're left idle for the whole of the year.
    - Nextgrid 8mo ago
      You don’t need to buy them, you can get them from AWS for that period only. Doesn’t mean your whole stack needs to be on AWS.

withinboredom 8mo ago

And to add to this: virtually every programming language allows you to define multiple entry points. So you can have your workers in the exact same codebase as your api and even multiple api services. They can share code and data structures or whatever you need. So, if you do need this kind of complexity with multiple services, you don’t need separate repos and elaborate build systems and dependency hell.

mbb70 8mo ago

As is often stated, microservices is a solution for scaling an engineering org to 100s of developers, not for scaling a product to millions of users.

steveBK123 8mo ago
Unfortunately that message was way way behind the bombast of "microservices everywhere now" that preceded it for years, to the detriment of many small orgs. I've seen engineering orgs of 10-50 launch headlong into microservices to poor results. No exaggeration to say many places ended up with more repos & services than developers to manage them.
- butvacuum 8mo ago
  do they all manage to have 4 different ways to do something like "notify user about x", all In use because they could never be bothered to complete the "upgrade"?
  - steveBK123 8mo ago
    Exactly the problem yes. Once you have more services than developers, you are probably running into infrequent releases and orphaned projects. So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying. When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
  - Nextgrid 8mo ago
    That's often the case yes. In a monolith a developer disgruntled about the situation can clean up the mess in a weekend, test it and push it through. No chance of that happening in microservices - you'd run out of weekend just opening PRs in the dozens of repos and dealing with all the nitpicking and turf wars.
    - butvacuum 8mo ago
      I've had the unfortunate experence to run into a situation where two dev's who hated eachother ended up building two systems with one passing the customer's API calls' http content directly to the front end... It was supposed to be back end and front end.
Nextgrid 8mo ago
You can get the separation benefits of microservices in a compiled language with modules that only communicate over well-defined interfaces, constraining each team within their own module without having to introduce a network call between each operation.
- samrus 8mo ago
  Python dev is cheaper and faster though. People arent gonna kill velocity by making their backend in c++ so the devs can have seperation of concerns, something that can, and should, be self enforced with discipline
  - Nextgrid 8mo ago
    Java or C# is a nice middle ground. But even in python you can enforce said separation - one module can only import from itself, libraries or any other module’s “services” object, and must export its functions in its own “services” object.
sumitkumar 8mo ago
Microservices is bad for teams without discipline to implement "separation of concerns". They hope that physical network boundaries will force the discipline they couldn't maintain in a single codebase. While microservices force physical separation, they don't stop "Spaghetti Architecture." Instead of messy code, you end up with "Distributed Spaghetti," where the dependencies are hidden in network calls and shared databases. Microservices require more discipline in areas like: Observability: Tracking a single request across 10 services. Consistency: Dealing with distributed transactions and eventual consistency. DevOps: Managing N deployment pipelines instead of one. For most teams Modular monolith is often the better "first step." It enforces strict boundaries within a single deployment unit using language-level visibility (like private packages or modules). It gives you the "Separation of Concerns" without the "Distributed Spaghetti" network tax.
- KellyCriterion 8mo ago
  > and shared databases. According to my understanding this is one of the reasons why microservices were invented, to prevent shared databases?
- philipallstar 8mo ago
  > Observability: Tracking a single request across 10 services I'm not sure if this is a discipline issue in the way that domain driven design, say, is a discipline issue. If you instrument requests with a global ID and point at tool at it then you're basically done from the individual team perspective.
  - ffsm8 8mo ago
    Uh, that's not my experience at all. Sure you can say e.g "this property wasnt set in this request while being processed by this service managed by this team", but why it wasn't set will inevitably need multiple teams, each doing in-depth analysis how such as state could've been caused because they always inevitably become distributed monoliths - the former is being provided by the instrumentation, but the latter isn't (and even the former is not perfect, as not all frameworks/languages have equal support)

yomismoaqui 8mo ago

The best descripcion of microservices comes from "The Grug Brained Developer" (https://grugbrain.dev/ https://grugbrain.dev/): "grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug"

Nextgrid 8mo ago
Grug actually covers this in his essay: > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer Microservices definitely contribute to having a "large tribe of developer" to manage.
- disqard 8mo ago
  Obligatory Krazam: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ

techpression 8mo ago

I was reading it and got seriously confused by separate database and server for a measly 1000 users. With the two separate you can scale vertically to handle a million users if all you’re doing is basic web/rest type stuff, probably more. I feel a bit of sadness for people who had never used a bare metal server and seen how insanely capable hardware is today.

sofixa 8mo ago

> Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling. Especially today, with the costs of memory and storage. Not to mention that whenever you hit your load maximum, you have a few months of lead time to get extra capacity. And FYI, "proprietary vendor-specific APIs" sounds very scary, but if you think about it for a few seconds, those APIs end at configuring an autoscaling group which is mostly about your min/max, and scaling rules. Yeah, it's proprietary, but it's 3-4 parameters to configure based on what you need, and from then little if any adjustment is needed. And you can take the same logic and port it to any other cloud provider within ~10 mins at most.

lelanthran 8mo ago
> And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling. If you know when that week is, where's the problem in spinning up extra capacity just for that period, a week in advance? Retailers, whether online or not, know with a very high confidence what their expected load is going to be a week from now.
- sofixa 8mo ago
  But you have to buy those servers, set them up, use them for that week, and then they're left idle for the whole of the year.
  - Nextgrid 8mo ago
    You don’t need to buy them, you can get them from AWS for that period only. Doesn’t mean your whole stack needs to be on AWS.