3 ms·
If you find yourself routinely pushing a bad binary that has (1) passed your test suite; and (2) passed whatever manual QA process you have on sandbox/staging d
by whakim 6y ago
If you find yourself routinely pushing a bad binary that has (1) passed your test suite; and (2) passed whatever manual QA process you have on sandbox/staging deployments, then I would again suggest the problem is the process and not the architecture. Not to mention that if the service is indeed critical, you're not rolling out a deployment to every production server at once (or you're low enough scale that it doesn't matter). Either way, easy enough to roll back a bad deploy before things get hairy regardless of architecture.
Also, I'm not sure what kind of internal CRUD tools you're writing, but "malicious input" doesn't really seem likely to come from your coworkers.
- dodobirdlord 6y agoInput doesn’t have to be malicious to cause problems, just unexpected. Separating memory-unsafe code into the finest granularity memory spaces possible is just good practice regardless of whether it’s microservices or just process isolation in a monolith.
- bedobi 6y agoWhen you're dealing with a giant piece of software that has existed since the 90s, with hundreds of developers working on it at any given moment, what you're describing doesn't work. You can read about a famous example here https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941
- whakim 6y agoWell, you began by saying that "monoliths are universally bad in every imaginable way." You're now saying that a select few poorly-maintained, 25-year old monoliths are bad, which is an entirely different claim. That doesn't really prove that microservices are any better (are 25-year old poorly maintained clusters of services really going to be an improvement?). Let alone "better in every imaginable way."