Mark Woodward <ma...@mohawksoft.com> observed: > My favorite example is facebook. Yes, they are a big data show case. > OMFG they have a lot of data and a lot of computational requirements. > They did not start out dreaming of big data. It started small and grew. > I believe that this inadvertent strategy helped them greatly. By > focusing on the site and what it did and *not* how to make it scale > until scalability was needed they were able to be attractive to more > users more quickly. > > Opinions?
Being the one who kicked off this thread, my original goal was to get specific technical arguments (plus a couple of business arguments like the ratio of MySQL-experienced DBAs to PostgreSQL DBAs available on the job market) to present to decision-makers who control what technology to use on new projects. So far at work I've got MyWay or the HiWay from the bosses: thou shalt use MySQL. Period. Suits me OK because I already know its quirks well, but it looks to me like more than ever the alternative of PostgreSQL (and no other FOSS product) is viable for small and large companies alike. But the thrashing of this discussion thread has given me nothing to send off to the senior tech architects at my office. Not one of the postings here has been phrased in a way that would grab such a person by the throat and persuade them to read further. Your argument above, Mark, is what I hear all the time both here and at my last employer: "We're Agile, so we can start off doing things wrong and fix them later." About $15 million and 20 months into a $6 million/9-month project (hah), at my last job we recognized that what the software team had built was a bug-ridden replacement of the previous unsupportable bug-ridden software, and most of the new software's developers quit--leaving the replacement equally unsupportable. But hey, the new one had lots of fancy stored-procs and took advantage of all of MySQL 5.1's nifty features. So if it were /my/ $15 million, I'm not so sure I'd take the position that I should focus mainly on the software features. But of course, I'm an infra guy so I'm biased: the infra goes in (2 of everying, HA from the get-go) before the first feature gets crafted. It's cheap enough to do these days, though it hasn't gotten much easier. If PostgreSQL makes it easier to set up HA, and recover from failures, than MySQL--I'd love to make that case. But going back to the Facebook startup argument--let's build this cool web page and see if people like it--then the HA argument doesn't even get considered. Another example is firewall security: if you've got this cool new web site running, and later decide to add firewalls: it'll be a lot more effort, and probably more outage-prone, trying to figure out on the fly which TCP ports and IP addresses should be opened up, and how to pull apart portions of the app to run on back-end servers with layered security. So, that's why I like to include robustness as part of Iteration Zero in the agile framework. -rich _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss