The Problem with the LAMP Stack

The web has a parasite inhibiting its growth. The LAMP Stack won the market for one reason: it’s simple. But that’s not enough to make it good. The web needs something better.

Let’s start by defining the venerable LAMP stack. It’s four main components are Linux, Apache, MySQL, and PHP.

For each of these components, they can easily be switched out for comparable pieces, with comparable results. Linux could easily be switched for OS X, FreeBSD, or even Windows, and have comparable results. Likewise, any of the other pieces could be replaced for a platform-appropriate alternative web server, database, or programming language, and you’d still end up with a LAMP stack by another name.

The big problems with the LAMP stack aren’t with any of these pieces, but rather how they are assembled, usually in a way that is brittle, error prone, and insecure. You’re sure to find the common thread connecting these problems: shared hosting. Indeed, most of these problems are created or compounded by how the shared hosting was designed.

The Problems

Lack of Mobility

Sure, the code is mostly mobile. You just copy your code to the new host, and it’s there. But what about your data? Since most shared hosting providers have the database on the same server as your code, you’ll have to make a database dump and restore it on the new host. And you’ll need to have your site down during the process, or else you may lose user activity in the process.

Can’t afford to lose user activity or up time? Good luck. This architecture isn’t designed to allow you to do both. Sure, it can be done, but it will be extremely painful. Coordinating copying the database to a new server, copying the code to the new server, and changing all the pointers without any downtime is something that this system just hasn’t though about.

Lack of Separation

A very common scenario is for another, unrelated site from your own, to get overloaded with requests. This causes the server they are running on to be completely overwhelmed, and every other site that is hosted on that shared site, including your own, is inaccessible.

Especially when your small business relies on your website being up, that’s an unacceptable compromise, but the cost of moving to dedicated hosting may also not be a reasonable solution.

Library Captivity

Combined that with the overwhelmingly common shared hosting, and you have a recipe for disaster. It’s very likely that an upgrade will cause somebody problems, and until they’re willing to break their site, you can’t get a newer version of libraries.

If you’re a developer, you cannot afford to be constrained by the needs of people completely unrelated to anything you’re writing.

Platform Stagnance

Filesystem-based Incoherence

It is your application that must decide what a URL means, not the filesystem. Putting that into Apache configuration files is not the way to solve this problem; it must be a decision made in your application’s code.

Unscalable Infrastructure

Scaling requires significant up-front effort, which most projects simply aren’t big enough for. Until, of course, they are. Then you’re stuck with all of the pain of migration.

When scaling to multiple servers, you’re left to your own devices to figure out how to get the database shared between the servers, and to make sure that the connections are secure.

Additionally, you gain the most undesirable task of figuring out how to make sure that all the servers are running the same software. If you don’t, then you will get users that end up with different pages, and Heisenbugs that you can’t confirm, but are a constant source of user frustration.

Mutability

Insecurity

Have you ever heard of a WordPress site being hacked? Of course you have. It’s a fundamental flaw in the architecture. If every program in the stack were flawlessly written, sure, it wouldn’t have to cause any problems. But that’s just not reasonable. I make terrible, horrible programming errors on an alarmingly regular basis, and so do you, if you’re honest.

The Reasons

Extremely Simple

The problem is that the only baseline that the LAMP stack provides to projects that need to write on it is the insecure, unstable, unscalable mess that we’ve been talking about.

Inertia

In order for something to win, it’s got to solve all these problems, keep most of the benefits that the LAMP stack has, and simultaneously revolutionize the way we ship software.

The Solution

I’m referring to the 12-factor app. It’s most notable implementation can be found in Heroku’s Buildpacks, of which there are many. They have managed to solve most of the issues with the LAMP stack. Sure, it’s still not easy to do some things, like having the code update itself, but it is leaps and bounds above the normal LAMP stack. And perhaps we will even see the rest of these problems resolved in sane way.

Now the challenge is to spread the word! Let’s make the world a better place, and rid ourselves of the LAMP stack.

Written by

Christian, Husband, Father, Programmer.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store