3 ms·

You'll be surprised. A group I work with opted for a microservices approach, a few years later they have 47 tightly coupled "microservices" that have to be dep

• ryanbrunner 6y ago
  That's unrelated to the framework used to power those things though. You can have perfectly decoupled services running some bloated Java framework or using Go with minimal libraries or whatever. You might prefer one or the other, but it has little do with how much those services fit into the definition of 'microservices'.
• scottious 6y ago
  ah, the dreaded distributed monolith. I hope this is looked at as a terrible anti-pattern someday. "But we can deploy services independently" they say, "we can scale these services independently too!", "We can finally scale our development team!" Years later: no services are scaled independently. Deployments are a mess. Most deploys end up having to be lock-stop deploys. Issues are incredibly hard to track down because of complex network interactions. For some reason 7 of them are written in Rust and only 1 guy knows Rust. Stack traces become almost worthless. You find yourself having to piece together log files across tons of services to track down issues. You have hundreds of Jenkins jobs for deploying services.