Much of the foundation of the software as a service (SaaS) segment of the tech industry is built upon the Linux kernel, the Apache web server, the MySQL database, and either Perl, PHP, or Python. In practice, the ‘P’ in LAMP could stand for Programming language. Over time, some of the other letters in the acronym changed with people’s technical biases (my own included). Some people replaced Linux with FreeBSD. Other people preferred Nginx’s speed and easier configuration over Apache. And many people felt that PostgreSQL prioritized correctness and protection of data more than MySQL.
No matter the change in components, the fundamentals of the LAMP stack architecture have stood the test of time pretty well. The past few decades, though, have seen a marked increase in complexity. On the frontend alone, the task of building a Web application today seems insurmountable for some given the wide range of tools that are promoted as required for a modern application. Backend services and infrastructure seem to have converged on Kubernetes by default, whether or not the true cost of adoption is fully understood.
This is not to say that the progress we’ve made in tooling and infrastructure is bad. These advances came in response to specific problems people encountered in building and operating their applications. There is much to be learned from those experiences and the resulting solutions. What is increasingly concerning is the pattern of people adopting solutions to problems they would like to have as opposed to the ones they do have. It appears that we have lost a strong baseline over time.
A sensible default
The LAMP stack, for all its flaws, addressed the needs of a majority of developers who needed to build Web applications. Everyone needed to access a database, perform some logic, and present data to customers. LAMP provided all the foundational tools needed to do exactly that. While there was a learning curve, once you mastered the basics you could pretty much build any Web application you needed. Are our applications much different today? Granted, our interfaces provide richer interactions especially with the shift to mobile. Data science and machine learning are enabling more powerful capabilities for the everyday person. Still, today’s application architecture requires retrieving data from multiple sources, processing it, and presenting information to multiple devices and optionally via an API. While one can build modern applications using the LAMP stack today, integrating the necessary supporting technologies introduces a significant amount of complexity.
Knowing what we know now and taking advantage of technological advances, how can we establish a new baseline that maintains the strengths of the LAMP stack but provides a better baseline to build the next generation of applications? The primary complexity of LAMP is rooted in the installation, configuration, and integration of multiple pieces of open source server applications. Each of these server applications have their own installation complexities, configuration formats, languages, and extension points. Connecting them to each other creates operational complexity – especially where upgrades are concerned. Environments quickly become the next problem. With so many developers working on macOS, or even Windows, there is always the possibility of something not working when the application is deployed to Linux. Developing on Linux can help mitigate this issue but it’s not a desirable solution for a lot of people.
Return of the LAMP
Managed services is the solution that offers acceptable tradeoffs. By acknowledging that developers want to spend more of their time on the specifics of their application, managed services provide the benefit of offloading a good amount of operational burden. More and more open source applications are offered via a managed service where either the vendor or a cloud provider handles the operational aspects of installation, upgrading, patching, etc., and provides APIs and SDKs for developers to consume. AWS, Azure, and Google Cloud all have managed services for MySQL and PostgreSQL, as well as several other data persistence options. They also provide functions as a service (FaaS) capabilities allowing developers to have logic executed in response to various events that may occur. These same FaaS capabilities can also be used to serve content similar to the server-side rendering (SSR) model employed by frameworks such as Ruby on Rails, Django, and Express.
An alternate model for serving content has emerged recently: JAMstack. JAM stands for JavaScript, APIs, and Markup. The main idea is that a Web application frontend can be rendered statically and served from a content delivery network (CDN) backed by object storage. For example, one could store the web application content in AWS S3 and use AWS Cloudfront or Fastly to replicate and serve that content globally. The content could be generated from markup tools and stored in version control where it can then be pushed to object storage and then served. A JAMstack application then uses JavaScript to consume APIs provided by managed services and/or the developer’s own code executed via FaaS.
With JAMstack and FaaS, developers have the tools to provide applications and APIs that leverage advanced capabilities provided by cloud vendors. There is definitely a tradeoff with respect to loss of operational control. However, this is an acceptable tradeoff for a majority of developers, despite the perceived need to master every aspect of your chosen programming language, Linux, and a plethora of server applications. Instead, with a solid grasp of Git and GitHub (although GitLab or Bitbucket are options), and a programming language (with which you will consume APIs and write your own business logic), developers have a new baseline from which to build applications.
Git. APIs. Programming language. Is this the GAPstack? No. These components combined with managed services that can scale down to zero is serverless. And serverless is the new LAMP stack.