4 ms·

A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each

A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. A startup should be using a monolith until it becomes a victim of its own success and then should migrate thoughtfully to microservices only when it has to. It also requires a very heavy investment in devops and tools since microservices will fail in production in every which way possible. It also requires a huge investment in metrics and alerts and logging otherwise you will have no idea what is wrong with your now too-complicated production system.

danielovichdk 7y ago
Do you know the domain of the business? Otherwose it sounds like you should reconsider the advice you give out.
- jennyyang 7y ago
  My statement applies across the board. It doesn't matter what the domain of the business is. Microservices cost more and have a higher impact on productivity and is only worth it if your engineering team needs the flexibility, at the cost of increase devops investment and more down time.
  - danielovichdk 7y ago
    No.
    - jennyyang 7y ago
      Ok. Once you have real world experience, then you should continue commenting.
speedplane 7y ago
> A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. While I generally agree with you in the vast majority of practical cases, it can make sense in some circumstances, namely, if there is a very clear logical abstraction between one service and another. A microservice is just another layer of abstraction, similar to functions, classes, files, libraries, and programs, but even higher up the food-chain, and it comes with its own characteristics and peculiarities. If you have high confidence that one component is (1) logically extremely different from all of the other components, (2) has no side effects, (3) is not I/O bound as it's going over a network, and critically, (4) is on a separate development timeline, then you have a solid candidate for a microservice.

danielovichdk 7y ago

Do you know the domain of the business? Otherwose it sounds like you should reconsider the advice you give out.

jennyyang 7y ago
My statement applies across the board. It doesn't matter what the domain of the business is. Microservices cost more and have a higher impact on productivity and is only worth it if your engineering team needs the flexibility, at the cost of increase devops investment and more down time.
- danielovichdk 7y ago
  No.
  - jennyyang 7y ago
    Ok. Once you have real world experience, then you should continue commenting.

speedplane 7y ago

> A startup has no business running microservices. Microservices are only when the engineering team can't scale properly because they keep stepping on top of each other. While I generally agree with you in the vast majority of practical cases, it can make sense in some circumstances, namely, if there is a very clear logical abstraction between one service and another. A microservice is just another layer of abstraction, similar to functions, classes, files, libraries, and programs, but even higher up the food-chain, and it comes with its own characteristics and peculiarities. If you have high confidence that one component is (1) logically extremely different from all of the other components, (2) has no side effects, (3) is not I/O bound as it's going over a network, and critically, (4) is on a separate development timeline, then you have a solid candidate for a microservice.