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
There are several problems that plague the LAMP stack. Every well-known product built on the LAMP stack suffers from these problems, in varying degrees, and it’s not necessarily the project’s fault, but the fault of the underlying stack that they chose. It may even have been the best choice available when they made it. But it isn’t anymore.
Lack of Mobility
Mobility means that it’s trivial to move your running code to another host. On most LAMP hosts, this feature doesn’t even come close to existing.
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
It is very important that you can consider your own code in isolation. Unfortunately, the vast majority of LAMP stack hosts provide shared hosting. Shared hosting is a low-cost alternative to dedicated servers, but combined with the lack of mobility that the LAMP stack presents, it is a disaster waiting to happen.
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
One of the most problematic pieces of the stack is that you don’t have control of the libraries that are available to you. When you’re using a hosting provider, you’re stuck with the libraries and the versions of those libraries that they’ve built PHP with.
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
Related to the Library Captivity is the issue of upgrades of your major tools. There are many good reasons that you may want to upgrade Apache, PHP, or MySQL, or similar counterparts. But newer versions have significant risk to others on your shared hosting, and a testing and maintenance cost to your hosting provider they may not be willing to incur. This restriction is counter to growth.
Filesystem-based Incoherence
Websites are not files. Or rather, they do not correspond to files on disk. A fundamental assumption of the LAMP stack is that websites are files, but every major product built on it provides a way to break this assumption, because it is simply a false correlation.
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
How does LAMP scale? Simply put, with great difficulty. If your site outgrows the shared hosting model, which is very likely for a critical application, migration to better hosting is a pain.
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
The LAMP stack’s greatest selling point is also it’s biggest weakness. Projects like WordPress are built on the ability of the application to modify itself. This makes it very simple to keep it up-to-date on a single host, but the stack just isn’t capable of making that simplicity happen across multiple hosts once your site has to scale. In order to scale, you can’t have the application update itself. In order for the application to update itself, it must stay on one host so that it can upgrade all the code.
Insecurity
Intimately related to mutability is the inherent insecurity of such a system. It is an attractive nuisance for code to be able to modify itself, because it leads inevitable bugs in the software to allow attackers to modify the site in unintended ways.
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
Given all these negatives, why is the LAMP stack still so prevalent? What are the benefits that keep people using it?
Extremely Simple
Sure, you can add some complexity to it to make it more capable than what we’ve talked about here, but then it’s not the same LAMP stack that I’m referring to (though it may still have many of the problems). But what made the LAMP stack so powerful is that it is easy to understand and straightforward to implement.
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
This one is harder to break. Because LAMP is so big, it remains big. Even if something hugely better comes along to replace it, it is still a behemoth incumbent, and unseating its supremacy will take more than a little luck and time.
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
The solution is now apparent: a new stack that doesn’t suffer from these flaws. While there does exist such a solution, it’s certainly not the only, best, or most complete solution. However, it is popular, simple, and well-designed.
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.
