What this phrase "Try to make you architecture more horizontal rather than vertical" means?

Question

Hello,

I've just listened to http://www.zend.com/webinar/PHP/70170000000bAuS-webinar-php-performance-principles-and-tools-20100218.flv (Zend webinar about PHP performance).

I can't understand what this phrase means "Try to make you architecture more horizontal rather than vertical" (see screenshot)

Thank you.

Answer 1

Horizontal scalability represents the ease you have to add more servers to your architecture.

Vertical scalability represents adding more ressources to a single server (as in more CPU, RAM ...).

Answer 2

A simple example of horizontal scaling VS. vertical scaling just with Database's

Given an example application like so: Application has many clients, each client has multiple users.

update: No client needs to know about another client, each user belongs exclusively to one client

Vertical scaling:

Client data is stored in a normalized SQL based database. user credentials for all users is stored in client_users table.

Benefits

1. Shortest path of resistance for development
2. relatively easy to maintain integrity with
3. Easy to backup

Problem:

Because all client credentials are stored in this one table along with related data, to maintain or increase performance would require beefing up your database tier with more resources or investing in more slaves to this one master.

Horizontal scaling:

Each client exists on a prefixed table schema. client_users becomes client01_users

Benefits

Someone with intermediate level skills in DB administration could write a simple script to copy client#_* tables to a new DB server in about 5 minutes ( then another hour to sanity check/test/verify). In this way you can push your low traffic clients onto a overbooked server and profit from the infrastructure savings while charging your higher traffic clients for requiring dedicated hardware.

Problems

1. Maintenance/development time can extend into oblivion and paralyse development entirely if shared nothing techniques don't include automation and schema change management systems.
2. A simple task like adding/dropping a column will take much longer to peform as you have to do it on multiple tables/machines in lockstep to software changes.
3. Backup's get pretty interesting sometimes

Summary

If in the beginning I can see an opportunity for shared nothing, I will fight tooth and nail to get that implemented. For new client's with scaling issues, after contracted my initial proposal will include refactoring to incorporate sharding or shared nothing principals. In my mind, the extra complexity can be managed if approached/handled correctly.