Hacker News new | past | comments | ask | show | jobs | submit login

For my anecdotal experience, microservices is the introduction of fiefdoms in development.

And, I get it. Selfishly I would love to come onto a project and only have to worry about net-new development. It is hard to learn, and then positively contribute within another engineered system... of any complexity. When it's "my code" I tend to be much more productive, and it's easier to find my way through the forest.

Anymore, everyone is on a power-grab for "my tools" and "my way" in regards to everything they're working on with near-zero attempt to understand the base needs of the business/feature. Microservices fill this need well as devs can work with their preferred toolset and just setup I/O boundaries for everyone else to use their service. Also, this is good for resume-driven development as you can often claim creation/ownership over some "piece" which looks way better on paper vs. "contributed to a big 'ol project."

I'm not against microservices, I'm just being honest with how I've seen them socially play out - all of this is anecdotal to my experiences.




> For my anecdotal experience, microservices is the introduction of fiefdoms in development.

Fiefdoms, whether implicit or explicit, are pervasive in organizations beyond trivial size; IME, software architecture choices may impact the shape of the fiefdoms, but not their existence.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: