Turning off the LAMP

Some thoughts on migrating away from WordPress and onto a server-less stack

Pulling the Line Cord on the Proverbial LAMP

Update: what I describe below has lead me here, to medium.com (see stack.) Medium is cool, and you should use it.

Overview

My website runs on WordPress, atop a Linux-Apache-MySQL-PHP stack. Which, in 2017, as a professional back-end engineer, is kind of an embarrassing and humbling statement to make.

This article documents the first steps I have made in thinking about “turning off the LAMP.” It proposes a few alternatives. None have been prototyped as of yet (stay tuned.)

What’s Wrong With WordPress

WordPress stack has some pros:

• It is known entity. Everyone and their mom runs one and writes tech articles about doing so. (See MomsForWordpress.org (not a real thing.))
• It takes like, an afternoon to setup start to finish.

However:

1. Out of box, WordPress is slow. You’ll eventually have to on-board a caching solution, perhaps W3 Total Cache, or a separate, front end caching server like Varnish or nginx FastCGI. (W3 Total Cache uses memcached.)
2. It is fairly straight-forward to migrate your WordPress to EC2 and RDS, and on-board S3 and CloudFront for asset delivery (See Deploy WordPress on AWS.) But managing server instances and data storage is still a bummer, even after you’re “in the cloud”, paying Amazon to do some of it for you.
3. The WordPress code offers little to no abstraction of separation of concerns, and as such, getting it running on different web servers or databases is pretty much a non-option. (See “DynamoDB for WordPress Install?” and WordPress roadmap for Using Alternative Databases.)

shifter.io has moved WordPress to serverless infrastructure, and it looks to be architecturally pretty sweet. But it’s closed source and they want to sell you stuff. And kind of takes the fun out of this project.

So: No LAMP. No WordPress.

So OMG, What Now?

Modern websites look like this.

Given the above, maybe it’s time to rethink some basic principles. Today’s web is pretty different than it was circa 2000. Social Media happened. Mobile happened. Cloud Computing happened. JavaScript took over the world. Holy Shit, it’s 2017.

My website is mostly static content on simple white pages with interlaced code snippets. Occasionally a picture if I’m really cutting loose.

But I don’t know, it’s not fun to author content in. That’s why I’m here, I guess, instead of posting a link to something over there.

Just Use a Different CMS?

Nah. They mostly address a different set of use cases and are all pretty bloated. And WordPress is kind of the only one that isn’t gross. Plus a lot of them run on LAMP still, and we’re turning off the LAMP. So, ya know.

Simple, Static, Hosted

So at the one extreme, you could go minimalist, hosted static content. Think basically “Markdown to HTML”. You write markdown, it renders, and then you serve it up (with nginx if nothing else.) Fast, fun. Hip.

Oh But I have Use Cases foo; bar.

Don’t we all, pal. Alright, so maybe we need something fancier. Let’s attack the problem instead by looking at what is out there today, and how we could assemble it together to build a stack.

Increasingly, I’d like to be able to host web-based software development tools. Imagine what would happen if txti.es and c9.io had babies. What if you could expose tools like JSON formatter, ideone.com and base64encode.org via a development tools REST API, then use the utilities all over the place?

I need a stack that is going to allow me to explore ideas like this and do quick turn-key of development versions into a low-cost, flipping-fast, production web endpoint.

With this, I extend the idea of “Simple, Static, Hosted” to be more general-purpose.

The Serverless (TM) AWS Way

The title is a little unfair, because I think there will end up being some “Serverless” AWS in pretty much all of the designs I consider. I don’t want to provision EC2 hosts, and I certainly don’t want to try to envision which RDS instance type I need. Around this part of the article is where I begin sounding like stackshare.io, which itself, reads like an AWS Marketing Campaign document.

So how about a stack like:

• A web front end based on HTML5 BoilerPlate, using CSS3 and ReactJS.
• CloudFront as a CDN;
• Elastic Load Balancer and Web Application Firewall at the endpoint (don’t need these at my scale, but whatevs, something to toy around with.)
• ElastiCache front-end cache;
• API Gateway and Lambda to support document CRUDs and other APIs for the types of SOA utilities I describe above.
• S3 and DynamoDB for storing stuff.

The first four APIs I’d write, I guess, would support CRUD of MarkDown documents:

The “Serverless” Way on… Your Server

You could run your own server and then treat it like a utility. This approach still uses a couple of AWS utilities, but overall it would be way cheaper if you already have a server of your own.

• Same client stack
• CloudFront for CDN still — AFAIK, there’s no community-supported p2p CDN network, so you still have to buy this stuff. (Startup idea: community-driven CDN using a block-chain “throughput” currency.)
• Don’t use a load balancer or a firewall, because I want to save money and doing this in software is too slow and operationally costly.
• Run an KVM stack on some box I have lying around and put WebVirtMgr management front end on it. (Note: I already do this.) (See also: list of KVM management tools.)
• Spin up an nginx FastCGI front end caching server, on the above. Of course, it will run Debian because what else would any reasonable person possibly use.
• Spin up a host for Docker.
• Implement the APIs in Containers, using the Go Programming Language. Because Go is hip and #YOLO.
• Still use S3 and Dyanmo, because again, provisioning storage sucks wicked bad.

Parenthetical: How I Originally Started Using WordPress

Back in the nineties, I took an interest in making websites. Using one of the first releases of Macromedia Dreamweaver, I’d make little hobby websites for my interests. I ran them from a UserDir on a Mindspring HTTP server. This way, I began learning to write HTML 4 and CSS 1.0.

Fast forward to high school, I was bored one summer so decided to try and put Mandrake 7.1 on my PC. Around that time, I was running Apache from a gutted Windows XP image. If anyone has figured out how to install Mandrake 7.1 yet, let me know.

Around 2003 it was pointed out to me by our local tech guru that I should probably run Red Hat. That’s around when I started running a LAMP, to host WordPress. This 2006 post to the WordPress forums shows the great technical maturity I had harnessed by this time: “ import myspace blogs?”

Conclusion

So what do you think? How should I rewrite my website?

Originally published at https://www.linkedin.com on March 12, 2017.