4 ms·

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

• dsr_ 8y 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 8y 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_ 8y 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.