Release It
Bad things start happening to systems via: impulse, stress, strain
Impulse(s) produces stress, stress produces strain, strain makes a system change shape (ram cpu)
The more tightly coupled the architecture, the greater the chance a coding error can propagate. Conversely the less coupled systems act as a shock absorbers, diminishing the effects of this error instead of amplifying them.
Every integration point will fail - be prepared for it
Know when to open up abstractions
Failures propagate quickly: Apply patterns to avert integration points problems
- circuit breaker, timeout, decouple middleware, handshaking
Sessions are the achilles heel of web apps. There's nothing quite as safe as the fork, run, die model of execution
As often happens, adding complexity to solve one problem creates the risk of entirely new failure modes.
The blocked threads antipattern is usually the cost of most failures and lead to chain reactions and cascading failures system-wide
Design out scale issues - unless you're Google, you can't test 'em out
Memory leaks and garbage collection usually appear as high cpu utilization
Consider failing fast for slow responses from services
Degrade gracefully and prepare for some services to die
Fast enough is usually < 250 ms for services that your system depends on
"Nevertheless, someday your little database will grow up. when it hits the teenage years - about two in human years - it will get moody, sullen, and resentful. in the worst case, it will start undermining the whole system (and it will probably complain that nobody understands it, too)"
Every system will eventually end up operating outside of spec
The test harness should leave scars on the system under test
With a system that never goes down, the users will most likely complain that it's slow.
Nothing is as permanent as a temporary fix
Mechanistic metaphors in the enterprise are trouble. They rarely behave with lifespans and predictable failure modes like machines. Biology and ecology are better metaphors.
The most useful criterion for evaluating architectures is: does it make IT better at responding to user's needs?
The cost of releasing software is almost never accounted for in budgeting
Change is the defining characteristic of software. Plan for it, accommodate it.