Uno dei modi più comuni di rendere disponibili le applicazioni web è attraverso lo stack LAMP. LAMP è un acronimo che sta per Linux, Apache, MySQL e PHP; in questo ambiente, Linux è il sistema operativo, Apache il server web, MySQL il server di database e PHP il linguaggio di programmazione.  Questa architettura può essere utilizzata per servire applicazioni open source o anche app personalizzate. Siti web famosissimi come Facebook, Wikipedia e Yahoo usano questo ambiente per servire le loro applicazioni a milioni di utenti in tutto il mondo, e anche moltissime applicazioni open source, quali WordPress, Drupal, Joomla! MediaWiki e SugarCRM, si appoggiano allo stack LAMP.

Che stiate implementando o facendo da piattaforma ad un'applicazione personalizzata, o che stiate usando una soluzione open source, dovreste usare un'architettura che massimizzi il tempo di uptime dell'applicazione, elimini i single point of failure, permetta di scalare senza tempo di fermo, e sia relativamente semplice da implementare e supportare. È meglio prendersi il tempo all'inizio per tenere in considerazione i requisiti e gli obiettivi a lungo termine del servizio che state implementando, invece di prendere decisioni sull'architettura durante un momento di emergenza come può essere un potenziale aumento del traffico o un'interruzione dell'elettricità. Fare queste cose durante un'emergenza non è il modo migliore di gestirle.

Ogni progetto può avere requisiti diversi, ma in genere ci sono solo alcuni punti importanti da considerare di sicuro: la ridondanza, la scalabilità, le prestazioni e la gestione. La ridondanza è come si riesca a reagire ad eventuali guasti, la scalabilità è la possibilità di gestire una base di utenti più grande o più piccola, le prestazioni implicano assicurarsi che l'esperienza di ciascun utente sia ad un livello almeno accettabile. Avere un servizio ridondante, scalabile e ad alte prestazioni non serve a niente se non si riesce a gestirlo, quindi anche questa è una considerazione chiave da fare. Chi implementerà il progetto? Chi ne gestirà la manutenzione? È fattibile farlo scalare nel modo che è stato previsto nel progetto? A volte, soluzioni più complesse possono essere escluse per la mancanza di risorse, ad esempio per un budget limitato o la mancanza di personale qualificato. Inoltre, a volte le soluzioni complesse progettate per minimizzare il tempo di fermo possono in realtà aumentarlo perché è necessario perché ci vuole più a risolvere i problemi quando accade qualcosa di inaspettato.

Questo libro presenta un paio di progetti che affrontano tutti i punti sopra elencati. I progetti proposti eliminano i single point of failure (punti di vulnerabilità singoli) e possono essere fatti scalare per arrivare a servire un numero sempre maggiore di utenti, mantenendo delle prestazioni accettabili. Verranno presentati progetti basati su hardware fisico, su server virtuali e sulla cloud. Sono progetti relativamente semplici, che soddisfano tutti questi requisiti, e sono facili da implementare, gestire e manutenere.