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"
