3 ms·

You're saying "monoliths encourage unhealthy engineering" and then in the next sentence say "when executed correctly" for microservices. That sounds like a havi

You're saying "monoliths encourage unhealthy engineering" and then in the next sentence say "when executed correctly" for microservices. That sounds like a having/eating cake type situation.

rriepe 7y ago
To be fair, this is how I've seen tech decisions presented at most big tech companies.
- geggam 7y ago
  Quit talking about what is behind the curtain
jayd16 7y ago
Not exactly. It's hard to tell from the outside if a monolith was architecture well or is about the fall over. In a microservice architecture it's harder to pretend you're doing it right.
- StavrosK 7y ago
  I disagree, "doing it wrong" just looks different there.
  - throwaway894345 7y ago
    The argument (which I sort of buy) is that microservices provide rails that keep people from doing certain stupid things like N clients depending on the data schema (making the schema a de-facto public interface). The trick with microservices is that the ecosystem is maturing and there are still lots of ways to screw up other things that are harder to screw up with monoliths. In time 95% of those will go away (my specific prediction is that one day we will write programs that express concurrency and the compiler/toolchain will work out distributing the program across Cloud services--although "Cloud" will be an antiquated term by then--including stitching together the relevant logs, etc and possibly even a coherent distributed debugger experience).
    - StavrosK 7y ago
      You basically just described Erlang/OTP there.
- majormajor 7y ago
  > In a microservice architecture it's harder to pretend you're doing it right. After seeing a few of them, I'd say: "it's less embarrassingly obvious that you're doing it wrong." But dig into the code for a few endpoints and it usually don't take long to find the crazy spaghetti and the poorly-carved-out separation of responsibilities breaches.

You're saying "monoliths encourage unhealthy engineering" and then in the next sentence say "when executed correctly" for microservices. That sounds like a having/eating cake type situation.

rriepe 7y ago

To be fair, this is how I've seen tech decisions presented at most big tech companies.

geggam 7y ago
Quit talking about what is behind the curtain

jayd16 7y ago

Not exactly. It's hard to tell from the outside if a monolith was architecture well or is about the fall over. In a microservice architecture it's harder to pretend you're doing it right.

StavrosK 7y ago
I disagree, "doing it wrong" just looks different there.
- throwaway894345 7y ago
  The argument (which I sort of buy) is that microservices provide rails that keep people from doing certain stupid things like N clients depending on the data schema (making the schema a de-facto public interface). The trick with microservices is that the ecosystem is maturing and there are still lots of ways to screw up other things that are harder to screw up with monoliths. In time 95% of those will go away (my specific prediction is that one day we will write programs that express concurrency and the compiler/toolchain will work out distributing the program across Cloud services--although "Cloud" will be an antiquated term by then--including stitching together the relevant logs, etc and possibly even a coherent distributed debugger experience).
  - StavrosK 7y ago
    You basically just described Erlang/OTP there.
majormajor 7y ago
> In a microservice architecture it's harder to pretend you're doing it right. After seeing a few of them, I'd say: "it's less embarrassingly obvious that you're doing it wrong." But dig into the code for a few endpoints and it usually don't take long to find the crazy spaghetti and the poorly-carved-out separation of responsibilities breaches.