3 ms·

This. I know that quote has been overused already, but: "Almost all the successful microservice stories have started with a monolith that got too big and was b

This. I know that quote has been overused already, but: "Almost all the successful microservice stories have started with a monolith that got too big and was broken up. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble." http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html Also good: https://rclayton.silvrback.com/failing-at-microservices https://rclayton.silvrback.com/failing-at-microservices

justicezyx 11y ago
It's not a microservice success story, it's a software system success story. microservice is just the way the system evolves.
malexw 11y ago
It's a good quote, and a sentiment that I've seen echoed by CTOs and VP Engs who actually are running or are currently migrating their companies to microservices. That said, I feel the quote should be: "As of 2015, almost all successful microservice stories..." As the tooling and knowledge around microservices builds up over the next few years, I could imagine a world where starting with microservices makes sense. For a new company, the flexibility you get with microservices to try new tech and throw out failed experiments could result in much faster iterations, helping to nail the product-market fit.
- bradleybuda 11y ago
  Totally disagree. The advantage of monolith-first isn't that monoliths are easier than microservices (though they might be). The advantage is that early in a project's lifetime, you don't yet know the boundaries between services. Worse, guessing those boundaries incorrectly is more expensive than a monolith. Breaking a monolith into services is difficult, but it's much hard to "rebalance" microservices once your product grows and you realize you have gotten the interface wrong. The monolith stage is important because it helps you figure out what the hell you're building. Establishing service boundaries overly early risks getting you "stuck" in the wrong architecture.
dragonwriter 11y ago
This makes some sense, intuitively. Until a system has some degree of maturity, you probably don't have a good enough picture of it to understand where service boundaries should be and to assign responsibilities appropriately. There may be good ways of managing that (refactoring at the architectural level, essentially; microservices are in some ways like OOP on a different level), but the practices to do so probably haven't yet been developed.

justicezyx 11y ago

It's not a microservice success story, it's a software system success story. microservice is just the way the system evolves.

malexw 11y ago

It's a good quote, and a sentiment that I've seen echoed by CTOs and VP Engs who actually are running or are currently migrating their companies to microservices. That said, I feel the quote should be: "As of 2015, almost all successful microservice stories..." As the tooling and knowledge around microservices builds up over the next few years, I could imagine a world where starting with microservices makes sense. For a new company, the flexibility you get with microservices to try new tech and throw out failed experiments could result in much faster iterations, helping to nail the product-market fit.

bradleybuda 11y ago
Totally disagree. The advantage of monolith-first isn't that monoliths are easier than microservices (though they might be). The advantage is that early in a project's lifetime, you don't yet know the boundaries between services. Worse, guessing those boundaries incorrectly is more expensive than a monolith. Breaking a monolith into services is difficult, but it's much hard to "rebalance" microservices once your product grows and you realize you have gotten the interface wrong. The monolith stage is important because it helps you figure out what the hell you're building. Establishing service boundaries overly early risks getting you "stuck" in the wrong architecture.

dragonwriter 11y ago

This makes some sense, intuitively. Until a system has some degree of maturity, you probably don't have a good enough picture of it to understand where service boundaries should be and to assign responsibilities appropriately. There may be good ways of managing that (refactoring at the architectural level, essentially; microservices are in some ways like OOP on a different level), but the practices to do so probably haven't yet been developed.