Goodbye Microservices: From 100s of problem children to 1 superstar
This is a classic case of not understanding micro services and trying to fit a problem around a tool.<p>At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco&#x2F; , all Java services go under jumanji&#x2F; , all go services go under goat&#x2F; , all JS services go under js&#x2F;. This means, everytime you touch something under a repo, it affects everyone. You are forced to use existing code or improve it, or you risk breaking code for everyone else. What does this solve? This solves the fundamental problem a lot of leetcode&#x2F;hackerrank monkeys miss, programming is a Social activity it is not a go into a cave and come out with a perfect solution in a month activity. More interaction among developers means Engineers are forced to account for trade offs. Software Engineering in its entirety is all about trade offs, unlike theoretical Comp Science.<p>Anyway, this helps because as Engineers we must respect and account for other Engineers decisions. This methods helps tremendously to do this. No one complains, everyone who wants 1000 more microservices usually turns out to be a code monkey entangled in new fad, or who doesn&#x27;t want to work with other Engineers.<p>You want to use rust? There is a repo named fe2O3&#x2F;, go on. Accountability and responsibility is on your shoulders now.<p>If you think about it, an Engineer is tied to his tools, why not segregate repos at language level instead of some arbitrary boundary no one knows about in a dynamic ecosystem?