4 ms·

> Otherwise, I find microservices much simpler to reason about. A counter-argument can be made on this point. You can implement the same isolation levels (modu

> Otherwise, I find microservices much simpler to reason about. A counter-argument can be made on this point. You can implement the same isolation levels (modules) but as a monolith using message passing. How is it harder to reason about it then? In other words, the hard part is how to split your program complexity in modules that are as simple and as orthogonal as possible. The worse you do this split: - In a monolithic system, the system becomes exponentially more complex and hard to maintain. You get more bugs, and developers running away from this project as fast as they can, but the thing may fulfill its goals to some degree. - In a microservice-based system, you may end up either with a handful of huge services (a monolith that uses network-based messages instead of function calls/inproc message passing), or with gross inconsistency problems if you force splits in the wrong places. Given the operational overhead and that most startups will never get to large scale, I'd say go with the monolith and try to gain traction with your startup. If/when you finally require scale you should have plenty of resources to either split the monolith (if it was well modularized) or just rewrite chunks as services until you get to a fully microservice-based architecture.

staticassertion 8y ago
Agreed that it is largely about splitting. SOA starts with that premise - but so do actors and modules, without moving out of process, and those are fine approaches too. Microservice architecture tells you more about how and where to split - introducing bounded contexts and various patterns you might use. > - In a microservice-based system, you may end up either with a handful of huge services (a monolith that uses network-based messages instead of function calls/inproc message passing), or with gross inconsistency problems if you force splits in the wrong places. Sure. You can also write really gross, convoluted monoliths. > Given the operational overhead and that most startups will never get to large scale, I'd say go with the monolith and try to gain traction with your startup. As the article states, they found that microservices allowed them to move faster on features, which is something that'll matter a lot to a startup. They do, of course, state that there were upfront costs.
- kilburn 8y ago
  > Microservice architecture tells you more about how and where to split The architecture doesn't tell you anything: it is you who decide how to split. Yes, there are guides and what not to help you make this decision, but again you could do exactly the same splits in a monolithic system. > Sure. You can also write really gross, convoluted monoliths. Totally. That's what I was implying when I said "complexity grows exponentially and developers want to run away from the project like hell". > they found that microservices allowed them to move faster on features While the article is fine, I don't agree with this affirmation at all. They rewrote the entire system (bit by bit) using better engineering principles, better internal organization, and with a lot of experience about their domain that they didn't have before. As I see it, the outcome you see here is not "microservices!", it is just "doing a better job".
  - staticassertion 8y ago
    > The architecture doesn't tell you anything: it is you who decide how to split. I don't really agree. The major difference between SOA and Microservice is the guiding principals, such as the bounded context. > As I see it, the outcome you see here is not "microservices!", it is just "doing a better job". Maybe so.

staticassertion 8y ago

Agreed that it is largely about splitting. SOA starts with that premise - but so do actors and modules, without moving out of process, and those are fine approaches too. Microservice architecture tells you more about how and where to split - introducing bounded contexts and various patterns you might use. > - In a microservice-based system, you may end up either with a handful of huge services (a monolith that uses network-based messages instead of function calls/inproc message passing), or with gross inconsistency problems if you force splits in the wrong places. Sure. You can also write really gross, convoluted monoliths. > Given the operational overhead and that most startups will never get to large scale, I'd say go with the monolith and try to gain traction with your startup. As the article states, they found that microservices allowed them to move faster on features, which is something that'll matter a lot to a startup. They do, of course, state that there were upfront costs.

kilburn 8y ago
> Microservice architecture tells you more about how and where to split The architecture doesn't tell you anything: it is you who decide how to split. Yes, there are guides and what not to help you make this decision, but again you could do exactly the same splits in a monolithic system. > Sure. You can also write really gross, convoluted monoliths. Totally. That's what I was implying when I said "complexity grows exponentially and developers want to run away from the project like hell". > they found that microservices allowed them to move faster on features While the article is fine, I don't agree with this affirmation at all. They rewrote the entire system (bit by bit) using better engineering principles, better internal organization, and with a lot of experience about their domain that they didn't have before. As I see it, the outcome you see here is not "microservices!", it is just "doing a better job".
- staticassertion 8y ago
  > The architecture doesn't tell you anything: it is you who decide how to split. I don't really agree. The major difference between SOA and Microservice is the guiding principals, such as the bounded context. > As I see it, the outcome you see here is not "microservices!", it is just "doing a better job". Maybe so.