3 ms·

It's important to realize the level of abstraction going on here. This is all philosophical discussion of how much Buddha-nature is in a particular company. If

by dsr_ 9y ago

It's important to realize the level of abstraction going on here. This is all philosophical discussion of how much Buddha-nature is in a particular company. If your application is composed of single-purpose modules, which are well documented, which have clean public interfaces, which are instrumented for monitoring, which can be scaled by using a load-balancing message router of some kind... and it works well, who cares whether you call it micro-services, Web Services, SOA, or FactoryFactory-Producer/Consumer Ecosystem?

LargeWu 9y ago
It's not about what you call it, it's about the overhead having many services entails.
- dsr_ 9y ago
  You should have exactly the number of services required. This may be hard to plan out from the beginning, but if all is basically sound, you may be able to reduce that number later. (E.g. when a module is called only by one other module, and there's no requirement for them to scale independently, maybe they should be one module.)
  - mattmanser 9y ago
    I feel like you're just saying the same thing a different way. Most development doesn't happen in a "we know exactly where we're going" way. This all sounds like some perfect, waterfall development cycle, everything's designed on paper in UML and the code is then written to spec without any changes, no requirements change, no interfaces change. That model of development simply doesn't exist in the real world. Your profile and blog say you're a sysadmin, do micro-services keep you in a job ;) It's one thing to make a bunch of micro-services as a sysadmin. It's quite another to base an ever growing and mutating production code base around them that actually has no clear path to success and an only vague understanding of future requirements.
    - dsr_ 9y ago
      Oh, no, my workplace avoids microservices like the plague. I can only think of one: PDF generation is handled by a network call that hands a webpage to a heavily firewalled (in and out) special container that hands back a PDF. There's no state in the container other than what it's processing, so we can discard and regenerate them. We keep development and operations staff tied closely together as a team, and have done since well before "devops" was coined.

by dsr_ 9y ago

LargeWu 9y ago

It's not about what you call it, it's about the overhead having many services entails.

dsr_ 9y ago
You should have exactly the number of services required. This may be hard to plan out from the beginning, but if all is basically sound, you may be able to reduce that number later. (E.g. when a module is called only by one other module, and there's no requirement for them to scale independently, maybe they should be one module.)
- mattmanser 9y ago
  I feel like you're just saying the same thing a different way. Most development doesn't happen in a "we know exactly where we're going" way. This all sounds like some perfect, waterfall development cycle, everything's designed on paper in UML and the code is then written to spec without any changes, no requirements change, no interfaces change. That model of development simply doesn't exist in the real world. Your profile and blog say you're a sysadmin, do micro-services keep you in a job ;) It's one thing to make a bunch of micro-services as a sysadmin. It's quite another to base an ever growing and mutating production code base around them that actually has no clear path to success and an only vague understanding of future requirements.
  - dsr_ 9y ago
    Oh, no, my workplace avoids microservices like the plague. I can only think of one: PDF generation is handled by a network call that hands a webpage to a heavily firewalled (in and out) special container that hands back a PDF. There's no state in the container other than what it's processing, so we can discard and regenerate them. We keep development and operations staff tied closely together as a team, and have done since well before "devops" was coined.