2 ms·
> enough pieces so that; 1. your engineers … are not afraid of doing changes. I don’t really understand that argument, and I don’t really feel safer making a c
by ch_sm 4y ago
> enough pieces so that; 1. your engineers … are not afraid of doing changes.
I don’t really understand that argument, and I don’t really feel safer making a change to a microservice inside a large system, as opposed to making a change to a monolith — the consequences of a mistake are equal in both cases (although harder to observe/debug in a microservice architecture) — am I missing something?
- tanseydavid 4y agoIf you read Kent Beck's book Test-Driven-Development By Example you will find that a major theme is this idea of developer fear or reticence. From the Amazon book description: Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism.
- rudnevr 4y agoThinking through the inter-service interface is costlier and more transparent than calling the function in the same monolyth. That said, interfaces between services are inherently better than function calls. Also, making mistake in microservice is more easily isolated, fixed and redeployed. Other than that, microservices are business entities, rather than just tech entities. They can be scoped, evaluated and managed on business level. After all, you can ask another team rewrite the specific microservice. You can't do that with monolyth. And the problem wouldn't be just buried in tech details and opinions.