Tuesday, October 30, 2007

I See Spots

As Mark Masterson mentions in Blinded by the Lamps.., Rails on AIX using DB2 would still quality as LAMP in many circles. The real value of LAMP is not the specific packages, it's the simple pattern it provides for building web applications.

For the record, I am still not convince Pile of Lamps is a viable platform for massively scalable web applications. I do, however, claim that the topic is probably worth investigating, as there is a very real chance we'll end up with some variation of the idea.

With that out of the way, let's review LAMP - it might trigger an idea somewhere - you never know.

Here's the original form:

  • Linux
  • Apache
  • MySQL
  • P{HP,erl,ython}
This has been a stunningly effective solution stack for a variety of web applications. Obviously there are variations - bazillions. Here's a simple conversion to avoid references to specific products:
  • Scripting Language
  • HTTP
  • Operating System
  • Database
I've taken the liberty of rearranging the list for my own amusement.

Note that this version encompasses nearly all of the variations listed in the Wikipedia article on LAMP. There are a few pathological exceptions, but no matter - this is the heart of LAMP.

Note that this self-contained web application stack is reasonably well partitioned for both single-machine and multi-tier environments. Mild amounts of rework might be required, but careful thought up front can avoid most obvious gaffes. Also, each of the elements can be treated as bolt-on components within the LAMP architecture. It's completely reasonable to imagine a LAMP stack with no storage - as a proxy, for example.

Also note there is nothing inherently unRESTful about LAMP. In fact, it can be (is) used to implement all of the core components in REST (origin server, gateway, proxy, and user agent) with minimal grief.

If we constrain the Pile of Lamps style to require REST, the existing LAMP stack provides all of the building blocks, minus any management pieces we might want to add for sanity as it scales out. At the same time, we could also view any additional pieces as simply being features implemented as part of the application we're coding.

Since I've committed other non-Web indiscretions in a previous life, I decided to take another conversion pass at the list. Here's a slightly more abstracted form:
  • Storage
  • Programming Language
  • Operating System
  • Transfer Protocol
This loosens the constraint that the stack provide an HTTP service. Once in this form, it's possible to model all manner of existing Internet applications.1

1. By definition, this diverges from RESTfulness, but the Aloof Schipperke claims bonus points for an acronym with a canine theme.


Mark Masterson said...

Well, sure, OK. Agreed and conceded.

But isn't this kind of like playing the "your programming language is no better than mine because we're both Turing complete" game? Isomorphisms. Once you abstract things past a certain point, you stop talking about something useful -- this is what I understood Bob's concern to be wrt. to loosening up the definition of "lamp" at all.

One of the interesting things that Fielding argues in the REST paper is that it's the application of constraints that make things useful. So, to me, the trick seems like it must be: refine it to the useful point, *but no further*.

So I find SPOT a bit too unconstrained to be useful. I definitely miss statelessness here (although I concede I haven't really explained why I want it). And I would be very hesitant to let go of HTTP, to be honest. But I don't know if I could justify that reluctance before a jury of my peers, at the moment...


Mark Masterson said...

... and that looks like a cool book. :-)

Bob Warfield said...

Aloof and Mark, there is more potential here than meets the eye, if we connect the dots from the spots and a few other places:


Aloof Schipperke said...

wrt SPOT, I mention it primarily to illustrate the boundary. Well sort of... Just as REST acknowledges the need to interface with other protocols, SPOT illustrates that LAMP can extended beyond web if/when necessary.

wrt HTTP, I agree - it's a useful constraint. I see little reason to avoid it, modulo the point made in the previous paragraph.