LAMP is Dead. Long Live Linux / Python!
by Mike Levin SEO & Datamaster, 01/31/2011
Hey, pssst! Wanna see my new “short stack” dev platform? Download Levinux, and you can have a little Linux server running on your Mac, Windows or Linux desktop in a matter of minutes. In a few more minutes, you can have the full Python, vim & git dev stack installed and ready to play with, weighing in at only about 50MB.
[syg_gallery id=2] My transition from Windows onto Linux, Python, Mercurial and vim is going well, as I get deeper into the implementation of my latest system. My platform actually isn’t LAMP, as only Linux and Python have become an integral part of my day-to-day programming. SQL and the web-server, not so much. This article explores that a little bit. Only a few years ago I lived and died by SQL Server, but today I find myself rebelling against it (and MySQL)—not because it’s bad, but because it’s overkill on most of the types of things I do these days. If I need SQL but have light requirements, there’s Python’s sqllite3, file-compatible with the ubiquitous sqllite. If you need a simple object persistence database, but not relational database features, there’s the Simple database built into Python that uses Unix’s hash database, (n)dbm. Your platform doesn’t need a vendor-encumbered “enterprise-level” databases as a pre-defined part anymore. So, no enterprise SQL, huh? I remember when I couldn’t imagine giving up SQL Server, and it’s related Microsoft tools, particularly VBScript, IIS. They were the source of power, and my deep familiarity with them let me work magic. They were optimized to work together in a tightly coupled triumvirate. On the same multi-core 64-Bit machine you could extract performance out of then that could only be matched with load-balanced Apache and clustered MySQL. I termed these Microsoft super-servers “Islands”, and they gave a huge, albeit counter-intuitive competitive advantage, on which I built the HitTail service.
I haven’t tried to reproduce these hyper-optimized server Islands on my new platform yet, but I suspect if I did, I’d be choosing something called PyTables over some SQL variation, for the Appache log-like write-once, read many applications in which I simulate indexed sequential access mode, thereby actually defeating the whole purpose of using using set-theory SQL. Even so, my development work has recently turned away from high-performance tracking systems, towards latency-tolerant API mashup programming with very low (local) database requirements—so all the more reason to not focus on SQL.
So much for the “M” in LAMP, but how about the “A”? Even though I do use Apache, I don’t consider it fundamental to my platform. It’s a necessary evil, because my mash-up work needs somewhere from which to listen to http requests. But Apache is similarly (to SQL) too heavyweight for my requirements. I just need somewhere to optimally run Python with http listening capabilities. I’m attracted to node.js, Twisted and other lightweight tcp/ip push-friendly servers, so I’m trying to keep my code as lightly coupled to Apache as possible. I consider the text editor and revision control system a larger part of MY platform (not necessarily the code execution platform) than either the database or webserver.
Huh? vim (text editor) and Mercurial (revision control) more fundamental to a platform than MySQL or Apache—both of which are actually part of the code execution environment? YES, because I’m talking about MY platform for writing code, and not the execution environment for running that code. It’s an important distinction, because execution environments are moving targets, changing over the years, due to changes in hardwaer, software, optimizations, and trends. The only thing that will let YOU program better over the years is getting better and better at tools that aren’t themselves moving targets.
There’s nowhere you spend more time than in the text editor, and it’s also one of the main culprits for disruption and change over the years. But I’ve already done plenty of writing about why your text editor deserves a place in your mind as primary part of your platform, along with a revision control system. Suffice to say, these are the non-moving targets (or at least, minimally moving) where the you can start to enjoy the benefits of spontaneous mastery, playing your code like a musical instrument, zipping forward and back through your revision control code histories as if video scrub-controls.
So for my platform, I have an “L” for Linux, a “P” for Python. I could steal the “M” from Mercurial, and work on reproducing the LAMP acronym, but with different meaning. But who cares? The important thing is that I have a nice solid understanding of what constitutes MY platform and why. I breath life into just about any hardware that passes under my nose with Linux and give it personality with Python. I do this with perfect undo/redo lifetime memory through Mercurial, and with ever-increasing speed, free from vendor-imposed disruptions thanks to vim.