At the end of the day most solutions/system are just filing cabinets - sure they are huge and relational and have business-logic and stuff in there but at the end of the day a query comes from a user or web and some data comes back, or goes in - you get the picture - Its a records system - focus on that more than the technology(CPU/OS/DB/Stroage/ETC) that the filing cabent is composed of
ANYWHO I see so much downtime due to over engineering features to reduce downtime so I started trying to write basic rules on how to design simple systems and keep propeller tendencies in-check. I personally think we should try and find non IT solutions to problems some - seriously it would be cheaper to use filing cabinets and clerks sometimes that some 'enterprise ready HA CRM/ERP system etc metats perhaps? How old is the NE555 IC or BC546 transitor - they have their place
Unless otherwise absolutely unavoidable...
No NIC shall be teamed/bonded/aggregated or trunked unless there is insufficient BW - added complexity and cost does not out weigh cheap simplicity
No servers shall be HA clustered within the same site, DR should be site by site
Choose vertical redundancy over horizontal redundancy i.e. in a muliti tired application rather than having multiple layers of multiple database, app and web servers have multiple servers but design so each server has database app and web- if possible
No software or OS shall be upgraded or patched if its working fine (bird in hand rule + if it isn't broke don't fix rule)
Never adopt the latest version of any software under any circumstance just to keep current
Invest design effort in quick restores after incidents, do not waste time trying to fix
No software or OS shall be upgraded or patched if its working fine (bird in hand rule + if it isn't broke don't fix rule)
Never adopt the latest version of any software under any circumstance just to keep current
Invest design effort in quick restores after incidents, do not waste time trying to fix
In all security vs. functionally trade-offs functionality must win
In any hardware vs. skills trade-off for performance tuning go hardware as skills cost more than ram
No OS shall be customised or tweaked from default installation options for performance reasons, only for functionality
In any hardware vs. skills trade-off for performance tuning go hardware as skills cost more than ram
No OS shall be customised or tweaked from default installation options for performance reasons, only for functionality
Purchase hardware that gives the best bang for buck, not absolute performance
For any system that requires HA or failover of some type - the failover mechanism should reside as high as possible up the hard/software stack(e.g. like dns - one host down try the next , application over RAC rack, RAC over OS level cluster)
For any system that requires HA or failover of some type - the failover mechanism should reside as high as possible up the hard/software stack(e.g. like dns - one host down try the next , application over RAC rack, RAC over OS level cluster)
was thinking today: too much flexabilty leads to much of the complexity - if you can tweek and tune this or that it can make for problems
ReplyDelete