4 ms·
This. The problem with decoupling services is usually there end up being a couple services that are critical but not sexy. No one wants to touch them so they s
by whatsmyusername 7y ago
This. The problem with decoupling services is usually there end up being a couple services that are critical but not sexy.
No one wants to touch them so they sit around unmaintained until an unrelated change or unpatched security issue comes around. Suddenly you've got a big problem with a mystery codebase.
- viraptor 7y agoThat sounds very familiar, but I'm not sure this is something that can be blamed on decoupling itself. An unpopular module is going to need as much attention as a micro service from code point of view. For upgrades / patching, there would be a company-wide process around it that doesn't care that much how the code is organised.
- whatsmyusername 7y ago'company wide' process is either, 'squeaky wheel gets the grease,' or, 'no one even knows this exists,' 100% of the time in my experience. This is from going from 10k+ to 150 to 5k+ to 50 people.
- viraptor 7y agoI wrote company-wide, but it's not the case everywhere. At some scale you'll want department, or even project-wide process. But the policy should be fairly common - who owns it, what's the response time, how to escalate urgent things, etc.
- whatsmyusername 7y agoI mean, I can write policy documents all day. Most of them would have had a better life as toilet paper.