Should the ‘KEG’ Stack Replace the LAMP Stack?
For years, the LAMP stack (Linux, Apache, MySQL, PHP/Python/Perl) has been an oasis for developers looking to build modern apps without getting locked into the desert of some big vendor’s ecosystem. It’s a convenient, widely used open-source framework that makes application architecture easy for developers.
However, just as a fast-changing technology landscape set the stage for the LAMP stack’s rise in the late 1990s, new shifts and trends in web development are now leading to what you might call its “sunset period.”
Today, if you are not breaking applications down into smaller components that can be independently deployed and scaled with flexibility and resilience to failure, you’re practically toast. Two major trends underscore this shift: First, every layer of the stack is now available “as a service,” enabling developers to outsource many responsibilities once deeply embedded in the stack, and to ultimately ship better products faster.
Secondly, the rise of mobile usage models in recent years has kicked this restructuring into high gear. Mobile is now the primary way users connect with applications. This means developers must build applications that are highly resilient, available around the world, and scalable enough to handle millions of clients. No matter how you cut it, the LAMP stack architecture simply cannot handle these requirements.
So what comes next? From development frameworks to programming languages and everything in between, developers today have more choices than ever before — and this toolbox is only growing larger. For this reason, developers should the components of the stack we had been calling LAMP, to continuously evolve. For now, here’s a snapshot of what a new LAMP stack might look like today if we recast it with more modern tools and frameworks:
Kubernetes Replaces Both Linux and Apache
Traditionally, applications are designed with a particular operating system in mind. For the LAMP stack, that means Linux. Today, however, the new way of thinking favors more portability than Linux can offer. This makes the Kubernetes open source container orchestration engine a good substitute platform in place of Linux. Its ability to abstract Linux away makes Kubernetes the operating system of record for many applications today.
As an added bonus, Kubernetes is also good at routing network traffic, which means it can also replace Apache. Thanks to Kubernetes, developers no longer need to deal with configuration files and static configuration when changes become necessary. Using Kubernetes constructs such as Ingress, Services, and LoadBalancer to route network requests, developers are free to adopt a more distributed and resilient approach that’s also highly dynamic and adaptive.
Etcd (Maybe) Replaces MySQL
MySQL is a still a popular tool for relational database management. However, if you want persistent data that is also resilient, then you need to store it somewhere that naturally allows for horizontal scaling and can handle node failure with transparency. In other words, you want to distribute the data layer to enable such properties, and MySQL may not be the best choice.
There are a great many services out there today which serve this need, one of the most popular being Etcd. Others include Consul (from HashiCorp), doozerd, CockroachDB, and Spanner from Google [PDF]. In the end, the right choice comes down to the nature of your application.
CockroachBD and Spanner are best for applications that require a more advanced data management system for storing larger amounts of data, meeting a traditional ACID database guarantee, and using traditional query language like SQL. For most others, Etcd, Consul, and DoozerD will do the trick.
In addition to services that provide data persistence, applications also increasingly rely on add-on data processing services such as message queues. These services also need to be highly scalable and reliable in order to meet the application’s needs.
Go Replaces Python
The Go language is eating Python’s lunch as a language of choice for developing modern applications — especially microservices.
One key advantage Go has over Python is that all dependencies are resolved at build time. This helps developers eliminate any surprises lurking around in the code, and guarantees their applications will not break unexpectedly when they’re deployed.
Most importantly, Go also allows applications to take advantage of multiple CPU cores. Basically, CPUs aren’t getting any faster these days, which means the best way to get more speed is by adding more CPU cores. Go has the advantage here as well: its elegant support for concurrency makes it easy for developers to take advantage of multiple cores. Since GO programs are statically typed and compiled to native machine code, they run much faster than interpreted or dynamically compiled languages such as Python.
Combine these observations and you might say the “KEG” stack is a good candidate for replacing the LAMP stack. But this misses the bigger point: Like it or not, the entire concept of a standard “stack” is being disaggregated.
Developers today have access to a larger, richer, and more powerful collection of tools than ever before, which means following a prescriptive approach like LAMP or even KEG is the wrong way to go. In this new world, the key is identifying the behaviors, patterns, and principles that underpin applications. Only then will the right tools for the job become clear.
