smashing.org

I was reading Scott's (scrottie) journal, and came across his commentary on Ask's
Real World Scalability talk. I have some comments of my own, and in the end I think that Ask's presentation, when taken outside of the context of a Perlmongers group meeting, simply suffers from a bad title.

First, I applaud Ask for bringing to light a lot of the relatively unknown open source scalability and high availability solutions. It's important that people know that there are free and open source solutions out there. However, I also applaud Scott for exposing Ask's extreme prejudice toward FOSS solutions. I've been a system administrator for 12 years now, in academia, ISPs, and the corporate world, with a whole bunch of consulting on the side. If I know anything, it's that a good sysadmin will look at all of the available options, free or not, open source or not.

So let's nitpick. Ask's presentation seems to discount any solution whose cost is greater than zero, thereby eliminating the entire world of commercial solutions. And while there are plenty of good FOSS solutions out there, guess what? The commercial ones work too. Often better. And you get support. Not a mailing list, but someone to call to fix things when they break. Yes, all of this costs money. But in the real world, companies are willing to pay for this. And if they're not willing to pay, or the cost breaks the budget, or the open source solution is simply better than the commercial one, then that's where FOSS makes sense.

Let's move on to databases. Why the aversion to Oracle? I'm no fan of Oracle (I loathe their costly licensing scheme), but I've used it (along with MySQL and Postgres) since version 7, and it does the job and more. A properly tuned Oracle database will perform just as well as MySQL or Postgres, so don't tell me not to use something without showing me numbers. I let budget, in-house expertise, and feature/functionality dictate whether or not I use Oracle.

Also regarding databases:

Stored Procedures Dangerous...work in the database server bad

Wow. This couldn't be more wrong. Databases exist to work with data. If I can encapsulate complex data manipulation in an internal stored procedure, what is wrong with that? It divorces SQL from my application layer, where I don't want to see 30 lines of some complex multiple join. Now, Ask does have a point. There is a lot you can do in a stored procedure that does not belong in the database, such as HTML template processing (yes, I've seen this). But don't discount stored procedures as a whole. They are extremely valuable. And if your database's performance is suffering, get a DBA who knows what he's doing to diagnose the problem!

In the "High Availability Shared Storage" slide, Ask says this about shared storage, including Netapp filers, which provide both NAS and SAN interfaces:

all expensive and smells like "the one big server"

Expensive? Without question. "Smells like the one big server?" Yikes. Have you actually used a clustered Netapp filer like the FAS720? If one side goes down due to a hardware failure or maintenance, the other side takes over without missing a beat. And everything is redundant, down to dual loops through each disk controller to guard against FC-AL loop failure. How exactly is that bad? Where is the single point of failure that is "the one big server?"

Finally, we come to disaster recovery. This is a HUGE topic, and I hate seeing it covered so succinctly in any presentation. But at the same time you would be doing your audience a disservice by not mentioning it. So I won't really harp on this, but do I see one glaring thing missing in Ask's presentation -- testing. He never mentions testing your disaster recovery plan. This is the single most difficult and overlooked part of any DR plan, and it is absolutely critical to making sure your recovery procedures actually work in the real world, and for keeping your plan up to date when things change. And things always change.

Now, back to my original assertion that Ask's presentation suffers from a bad title. I think if it were titled, "Open source scalability solutions" or "Inexpensive scalability solutions", there wouldn't be a problem, since he most certainly focuses on FOSS and the price of commercial hardware and software. But the "real world" is a big place, and gives us a much wider range of appropriate solutions than you'd be led to believe from this presentation.