:) A good one! Nice writing, Nick.
My favorite: > 'course, most people are not thinking about the long-term health of the > company, but the short-term "what can I stuff on my resume on my way out > the door before this blows up" //mxb On 23 dec 2012, at 04:43, Nick Holland <n...@holland-consulting.net> wrote: > On 12/22/12 07:54, Friedrich Locke wrote: > ... >> But for other services i don't have now what i could use. A example: i need >> a file system that must expand by adding more machine in the network in a >> simple way. > > in plain English: "I'm not thinking out the design carefully, so I'm > going to rely on fancy shit to haul my ass out of the fire when the > predictable (and not so predictable) happens. > > You don't need that for your problem, you need that for the solution you > came up with for your problem. Your solution is wrong. > > You know your needs will change in the future, so build the whole system > around the idea of modular storage and other scalability design features > -- not "unlimited expandable storage". > > Chunk your data from the very beginning. In the case of a mail server, > part of the user's LDAP record indicates the storage unit where it is > stored. > > Yes, this is a better design. > > I've seen many designs where the answer was "toss it all in one pool, > let some 'advanced technology' keep my ass out of the fire." They have > all been total shit. Usual result: the "advanced technology" gathers > the kindling, splits the logs, lights the fire, and tosses your ass on > the pyre before you ever get around to the first "expansion". If you > wish to argue that your "problem" is special, and requires One Big Pool > of Storage, feel free to tell me about it (off list), maybe someone's > got one. More likely, you will be telling me about your SOLUTION which > requires one big pool, not the root problem. (I'm not above learning > new stuff, but I'm done with assuming most people know something I don't > -- that's something that is really annoying to be wrong about, I'm finding). > > Your design should incorporate (among other things): > * initial load handling. > * future load handling improvements. > * future storage upgrade. > * future storage REPLACEMENTS (you want to remove your three year old > storage module in favor of a new one ten times the size, but your six > month old one is still quite good) > * future complete solution replacements. (*) > the simplest possible solutions that will accomplish the above within > acceptable business frameworks (i.e., not "we'll have our entire IT > staff working a major multi-day holiday because that's the only way we > can accomplish this") > > Nick. > > > (*) if you ever wish to keep a closed source solution OUT of your > operations, this is your magic weapon to use with responsible, thinking > people. Every closed source solution is built around the idea of > keeping you a captive customer. But the fact is, if your business is > run well, in 50 years, it can still be around. You will almost > certainly have to replace entire systems with competing products "some > day" -- your company's success should not be dependent upon a third > party remaining in business. So, an exit strategy has to be part of any > good system design (even though it almost never is). How are you going > to scrape your legacy data off your old system and install it into its > replacement? When the APIs are proprietary, you won't... Ask your > prospective vendor "If you go bankrupt or otherwise leave the business > next year, how will we move >OUR< data stored in your system to another > product?" They will start with "We aren't going anywhere", which you > know they would say if they weren't sure about getting their paychecks > next week. > > 'course, most people are not thinking about the long-term health of the > company, but the short-term "what can I stuff on my resume on my way out > the door before this blows up"
