2 ms·
That's certainly a valid argument, but the most compelling use-case for a microservice architecture is when your organizational structure (and the specific tech
by acobster 9y ago
That's certainly a valid argument, but the most compelling use-case for a microservice architecture is when your organizational structure (and the specific technical strengths that come with that) mirrors the application structure. There may be a really good reason to write one backend API in Go and the other backend APIs in Java, or whatever. This architecture simply takes that constraint as a premise. Solutions that prescribe diverse polyglot architectures without this constraint are, as you seem to intuit, missing the point.
- shawnb576 9y agoIt's a compelling idea, for sure, but it tends to delay a bunch of bigger costs. It _feels_ super productive to use "the right tool for the job", but at scale this ends up being really expensive. You end up with an organization that grows using different toolsets, libraries, build/CI systems, training/onboarding, test harnesses, developer mobility, etc. As things grow, inconsistency and inability to share become extremely difficult problems.