3 ms·
Yes, the micro services + Golang vanity project because you think you’re Google. I really don’t think people understand error states in distributed systems very
by andy_ppp 7y ago
Yes, the micro services + Golang vanity project because you think you’re Google. I really don’t think people understand error states in distributed systems very well, putting possible network partitions everywhere is not a great idea. I would strongly suggest trying a Golang monolith first and seeing if there are one or two heavily used services that need splitting off. Also monorepo. Always.
- StavrosK 7y agoMicroservices have always seemed dangerous to me. "Bugs thrive in the seams between libraries, so let's put more and deeper seams in!" Microservices have an immense cost, and you have to make sure they're worth it. Many teams years ago found it a nice pattern and implemented it because why not, and now we're at the "oops this isn't actually amazing" part of the cycle.
- andy_ppp 7y agoIf you work at Google where the standard is higher fine, but 99% of places people end up making very buggy stuff that interrelates in weird ways!
- asdfasgasdgasdg 7y agoThe really fascinating thing about this tendency is that Google itself never completed nor even really started the wholesale transition of programs and services to Golang/microservices. Google does have services that are micro with respect to the overall codebase. But they aren't what most people out there in the wider world would think of as micro. And Golang remains a niche language at Google, perhaps more popular than server python, but far smaller in usage than Java or C++.