MEAN vs. LAMP: Choosing the Right Stack for Your Software
When we’re working with clients to create the plans and roadmaps that will guide us in converting their software visions into custom-built realities, one of the first decisions we make is which technologies will best fit the clients’ particular needs.
In early years of web applications development, a technology stack called LAMP was dominant in the field. But in recent years, evolving technologies have given rise to for dominance in the development field, businesses are asking which stack to use to reduce risks as much as possible in their systems development.
At Syberry, we love thinking through these questions with our clients, and we’re always happy to advise on the right technology stacks for your projects. But for now, let’s break down some of the key decision-making points between LAMP and MEAN in an effort to illustrate the pros and cons of each and help you start to make the decision for yourself.
First Things First: What Are MEAN and LAMP?
Conveniently enough, the stack names are acronyms that stand for the technologies used in each.
LAMP breaks down like this:
- Linux: a dominant family of operating systems used for hosting web applications
- Apache: a popular, configurable web server
- MySQL: a relational database for data storage
- PHP: a general-purpose programming language designed to create dynamic, interactive webpages
And MEAN contains its own set of technologies:
- Mongo: a non-relational (NoSQL), document-oriented database
- Express: a collection of best practices for building typical web application
- Angular: a client-side application framework for building rich, single-page applications
There is no one-to-one technology mapping between the two stacks, and both have their advantages and disadvantages depending on what a developer aims to accomplish. Let’s take a look at a few of the key distinctions.
But PHP Has its Benefits
An Argument for LAMP
In these systems, while the user experience and interface are important, the focal points are the functionality and logic of the system that supports the business. In our experience, it’s much more efficient and economically sound to build the classic way, using templates to build static HTML-based user interfaces. For these, the templating tools available in all popular PHP frameworks are sufficient, and there’s no need for Angular or other client-side-oriented frameworks that are available in LAMP.
Another budgetary benefit to this approach is that a back-end engineer may be able to create a solid user interface for a classic business system, which eliminates the need to staff a team of front-end engineers.
Especially if you’re using the MEAN stack, it’s important to hire developers who understand these concepts and who recognize that it will be more difficult to scale the team to speed development.
The Devil Is in the Database
Another key difference between the two stacks is the type of database they use. MySQL, used in the LAMP stack, is a classic example of a relational database built around the concept of relations (tables) and records.
Mongo, on the other hand, the database used in MEAN is document-oriented, which means that each unit of data is stored as its own document, and different documents in the same collection may have different — or even nested — attributes.
It is important to understand that there are no inherent pros or cons to either approach, and the proper choice is dependent on the nature of the data the system stores and how users will need to work with that data.
If your system requires strong schema and a lot of join operations over multiple data sets — such as you see in reporting — a relational database is a better choice. This is usually the case with an internal business system. But if your data has weak schema and is centered around key objects such as user profiles, the NoSQL solution found in the MEAN stack might be better. Additionally, Mongo’s scalability potential is higher than MySQL’s, so if you expect your application to grow in its data usage load, Mongo will be the better choice. (Though it should be noted that, if you’re working with a sufficiently large system, you may need to consider using a combination of both types of database.)
Ultimately, Scaling Isn’t about Stack
Though the stack you use may play a factor, if you take a bird’s-eye view to the issue of scalability, you’ll see that the key factor isn’t the specific set of technologies you choose (though you’ll likely run into trouble if you choose haphazardly). In fact, with tools like Docker that allow you to move specific components and technologies into isolated units, you’re no longer even restricted to a single stack. What matters for scalability is actually your approach to the architectural design of the system.
If you plan for the system load to grow rapidly, you must plan for that from the start by building in horizontal scalability — in other words, giving yourself the option of adjusting for the workload by adding more computational power in the form of commodity server nodes (as opposed to scaling vertically by buying a more powerful server). Building for horizontal scale means being very intentional about how you organize primary components like state, business logic, and presentation layers.
As is the case with so many strategic questions about both software and business development, there is no one right answer as to which technology stack is superior. Each company must work with its development team to make the strongest choice for the individual situation.
The most important rule of thumb we can offer is that, the smaller the application and the scale of development team, the more specific stack choice matters. The opposite end of the continuum — large-scale projects — is all about building proper architecture rather than nailing a programming language or database choice the first time out.