Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

5
  • 21
    I'm sorry, but it is way easier to mess up with microservices than you're alluding to. Micros are an order of magnitude harder to debug and test, and their development has a whole different set of pitfalls. They are a valuable tool, but not for everything and should not be used as a silver bullet. Commented Jan 18, 2021 at 11:59
  • 10
    @T.Sar: I don't think that was Telastyn's point. Rather than it's significantly harder for a developer to bypass an abstraction layer when that abstraction is its own hosted microservice, as opposed to when it is e.g. a different project in the same solution. You can quickly (and without much notice) add a project reference where you shouldn't, but that same kind of shortcut is much harder to quickly bang out when you don't even have access to both the source code or the deployed files of the abstraction (as is the case with microservices). Commented Jan 18, 2021 at 13:25
  • 5
    That's true if you're keeping the microservices in separate solutions, but that's often not the case. More often then not, they are just mangled together into a single super-solution with everything, and have just as much spaghetti as a single mono solution. Microservices don't force you to organize them properly anymore than any other architecture. They just heavily suggest you to do so, but if you'll follow that or not... that's another question entirely. Commented Jan 18, 2021 at 14:03
  • @T.Sar - yes, I was only talking about the coupling point. Microservices do add complexity and are not universally applicable. Sure, people can have them in a single repo/solution, but that is uncommon in my experience, easier to enforce programmatically, and a single decision to screw up rather than the continual correct decisions required by class level decoupling, Commented Jan 18, 2021 at 17:45
  • @T.Sar the heavy suggestion is basically always the best you can get from prgramming/architecture paradigms. In the end, as a developer you can twist all code to your perverted will. A good architecture will just make some perversions harder. At least for preventing cross-component data access microservices (if they are somewhat worth the name) indeed achieve that - it's way easier to just inject the database connection and wildly modify data of another component in a monolith; as you said, still possible with a microservice but more effort and thus perhaps discouraging enough^^ Commented Jan 19, 2021 at 5:23