4 ms·

> By which I mean focus on Domain Driven Development, focus strongly on modularity even when, and this is the key part, it's not required because it's in a mono

> By which I mean focus on Domain Driven Development, focus strongly on modularity even when, and this is the key part, it's not required because it's in a monolith Here, here! If I had a dollar for every team I’ve seen adopt micro services as a solution to code modularization I’d have several dollars. “Hey our code could be cleaner and our git repo seems to be getting big” “Sweet let’s inject the network in between everything”

mathgladiator 4y ago
Having lived between packaged based repos (Amazon) and mono repo (FB), I've come to greatly appreciate the mono repo life. All my dependencies match up, and I can build everything in one command. Furthermore, I can run all 4007 tests in 13 minutes.
- jamesfinlayson 4y ago
  Agreed! I worked at a job where most of the company worked on a monolith, with the frontend in its own repo, then another 25 microservices hanging off the monolith. Everything was different in every repo, including how to deploy and run tests etc. The project I was working on was everything in one repo with a nice deploy.sh and test.sh and no chasing people to find out how to deploy that one microservice that was last touched months ago.
systemvoltage 4y ago
Cloud provider's best trick was to convince everyone that network calls are better than function calls.
- neongreen 4y ago
  I think they are, though. Off the top of my head: * Network calls are traceable by default — logging all incoming queries is easy, logging all function calls is harder. * Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc. The downsides are a) decreased performance b) you have to handle failures c) dev ergonomics, but eh. I would still choose network calls over function calls for a big backend, probably.
  - brundolf 4y ago
    > logging all function calls is harder It's really not though. Many (most?) languages have some way to annotate function calls with logging logic > function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language Not really sure what you're referring to here
  - duped 4y ago
    > Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc. Define "easy" because curl is not "easy" compared to a function call and involves building a few large datastructures to work at all.
  - rco8786 4y ago
    Oof. Everything in my 12-13 years of engineering has led me to the exact opposite conclusion of literally every point you made here. Are you genuinely suggesting that making a network call is easier than calling a function in the same code base running in the same process?
  - xwolfi 4y ago
    Completely disagree if you work on low latency systems, or a high volumes of requests: functions are traceable if you need to in a crisis: plug a profiler, run like prod, see the hot paths. Dev ergonomics explode the cost of everything and you spend your time trying to figure out what the hell is going on where rather than just... plugging the profiler and sending the input, then observe the internals moving around. If the system can work without micro services, it should.
- systemvoltage 4y ago
  I think this is a blanket statement on my part, so to counter it; networked databases are definitely important. Some micro services maybe necessary for things outside of your control (HIPAA, Finance audits) and geo-proximity processing needs. And sometimes good ol micro services became popular because it was easy business in a giant org chart (Amazon, every team has an API). Real world is messy.
  - rco8786 4y ago
    I’m not anti micro services. I’m anti micro services as a code organization strategy. There are very real reasons to need process isolation in larger systems. Code modularity is not one of them.
- arinlen 4y ago
  > Cloud provider's best trick was to convince everyone that network calls are better than function calls. Not really. Cloud providers did convince everyone that if you hit a resource limit in one of your boxes then your best strategy is being able to add more boxes, and not move everything and the kitchen sink to a larger box. Also, not everything sits in the hot path of anything. Sometimes all you want is a long-running job to run somewhere.

mathgladiator 4y ago

Having lived between packaged based repos (Amazon) and mono repo (FB), I've come to greatly appreciate the mono repo life. All my dependencies match up, and I can build everything in one command. Furthermore, I can run all 4007 tests in 13 minutes.

jamesfinlayson 4y ago
Agreed! I worked at a job where most of the company worked on a monolith, with the frontend in its own repo, then another 25 microservices hanging off the monolith. Everything was different in every repo, including how to deploy and run tests etc. The project I was working on was everything in one repo with a nice deploy.sh and test.sh and no chasing people to find out how to deploy that one microservice that was last touched months ago.

systemvoltage 4y ago

Cloud provider's best trick was to convince everyone that network calls are better than function calls.

neongreen 4y ago
I think they are, though. Off the top of my head: * Network calls are traceable by default — logging all incoming queries is easy, logging all function calls is harder. * Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc. The downsides are a) decreased performance b) you have to handle failures c) dev ergonomics, but eh. I would still choose network calls over function calls for a big backend, probably.
- brundolf 4y ago
  > logging all function calls is harder It's really not though. Many (most?) languages have some way to annotate function calls with logging logic > function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language Not really sure what you're referring to here
- duped 4y ago
  > Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc. Define "easy" because curl is not "easy" compared to a function call and involves building a few large datastructures to work at all.
- rco8786 4y ago
  Oof. Everything in my 12-13 years of engineering has led me to the exact opposite conclusion of literally every point you made here. Are you genuinely suggesting that making a network call is easier than calling a function in the same code base running in the same process?
- xwolfi 4y ago
  Completely disagree if you work on low latency systems, or a high volumes of requests: functions are traceable if you need to in a crisis: plug a profiler, run like prod, see the hot paths. Dev ergonomics explode the cost of everything and you spend your time trying to figure out what the hell is going on where rather than just... plugging the profiler and sending the input, then observe the internals moving around. If the system can work without micro services, it should.
systemvoltage 4y ago
I think this is a blanket statement on my part, so to counter it; networked databases are definitely important. Some micro services maybe necessary for things outside of your control (HIPAA, Finance audits) and geo-proximity processing needs. And sometimes good ol micro services became popular because it was easy business in a giant org chart (Amazon, every team has an API). Real world is messy.
- rco8786 4y ago
  I’m not anti micro services. I’m anti micro services as a code organization strategy. There are very real reasons to need process isolation in larger systems. Code modularity is not one of them.
arinlen 4y ago
> Cloud provider's best trick was to convince everyone that network calls are better than function calls. Not really. Cloud providers did convince everyone that if you hit a resource limit in one of your boxes then your best strategy is being able to add more boxes, and not move everything and the kitchen sink to a larger box. Also, not everything sits in the hot path of anything. Sometimes all you want is a long-running job to run somewhere.