Gadgets - Because you know you want a chemistry set

Wired Science - Dangerous Science

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. By definition, this diverges from RESTfulness, but the Aloof Schipperke claims bonus points for an acronym with a canine theme.

Another Gang of Four

No doubt there's a big crowd of Double Bass fanatics out there in Architectureland.

I discovered a wonderful link at Jason's Heath's Double Bass Blog - The Bass Gang.

Here's a snippet of Birdland.

(A vestigial passion from a previous life - deal with it)

Can IT 1.0 Implement Enterprise 2.0?

In The state of Enterprise 2.0, Dion Hinchcliffe provides his take on a status report for Enterprise 2.0 as of Fall 2007.

His status report comes in the form of lessons gleaned thus far.

1. Enterprise 2.0 is going to happen in your organization with you or without you.
2. Effective Enterprise 2.0 seems to involve more than just blogs and wikis.
3. Enterprise 2.0 is more a state of mind than a product you can purchase.
4. Most businesses still need to educate their workers on the techniques and best practices of Enterprise 2.0 and social media.
5. The benefits of Enterprise 2.0 can be dramatic, but only builds steadily over time.
6. Enterprise 2.0 doesn’t seem to put older IT systems out of business.
7. Your organization will begin to change in new ways because of Enterprise 2.0. Be ready.

So far, so good. I'm a little surprised by phrases like "seems to" in #2 and #6, but these are nits.

Much of Dion's article focuses on the state of the tools. While the lessons seem to focus on the human component, his article is primarily focused on the state of tools. This caught my attention, since I've tended to focus on the people and process aspects when considering the use of 2.0 tools in the enterprise.

So I reviewed Andrew McAfee's definition of Enterprise 2.0.

Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.

And for the discerning reader,

Platforms are digital environments in which contributions and interactions are globally visible and persistent over time.

I evidently need to pay more attention to definitions.
Note to the Schipperke: Enterprise 2.0 is specifically focused on the tools.

This is truly unfortunate.

Why, you ask?

One only needs to look to SOA for the answer.

SOA started out as an architectural style, but it has morphed into something completely different. There are several underlying forces, but the primarily reason appears to be an annexation of the term by vendors. This has resulted in a dilution of many of the potential benefits of SOA, as vendor lock-in and SOA-in-a-box makes its way into the mind-share of IT.

Enterprise 2.0, from its starting definition, appears to be predestined for the same fate.

Is it unreasonable to believe that Andrew's refinement of Enterprise 2.0 didn't go far enough?

Are we setting CIOs up by intimating that deploying Enterprise 2.0 tools will create emergent collaboration?

Conversations Driving Actions

The conversation on a Pile of Lamps continues...

Bob Warfield chimed in with his view on Pile of Lamps, which includes a mapping of the style into the Roy Fielding's assessment framework. Perhaps most importantly, he reminds us that Roy Fielding's contribution is not limited to REST - Roy's dissertation provides a useful tool for thinking about web architectures in general.

Bob's remark about whether a Pile of Lamps was implemented in a grid or cluster struck my fancy. A recent, yet unrelated, conversation on conversations has also been lingering around in my brain. Like two molecules floating around, the two ideas combined.

Techniques for managing large sets of machines tend to either highly centralized or highly decentralized. Centralized solutions tend to come from system administration circles as ways to cope with large quantities of machines. Decentralized solutions tend to come from the parallel computing space where algorithms are designed to take advantage of large quantities of machines.

Neither approach tends to provide much coupling between management actions and application conditions. Neither approach seems well adapted for any form of semi-intelligent dynamic configuration of multi-layer web application. Neither of them seem well suited for non-trivial quantities of loosely coupled LAMP stacks.

I've recently been contemplating a constellated approach, where various subsets of machines engage in conversation amongst themselves.

As an example, a set of application servers might engage in a conversation concerning their general status. A failover heartbeat is a simple form, but the idea encompasses larger classes of interchange and generalizes the model. If the servers start to become overloaded, the conversation might converge on a decision to spawn a conversation between services capable of contributing to a solution. That conversation could, for instance, result in a decision to add another server to the pool.

Once an additional server is made available, the application pool would be responsible for initiating the provisioning of the new server and for integrating it into the pool. The information necessary for proper provisioning are and integration are contained within the application pool rather than some external source.

Basically, it's a pull rather than push model, with localized conversations driving actions.

A fully developed model for inter-machine decisions would most likely become unbearably complex and subject to emergent behaviors, but a basic implementation should be capable of providing an adequate framework for many situations.

I haven't completely thought through the idea, but I though I'd toss it out for comments.

I won't be wrong if you don't talk

A recent article by Tom Haskins, Outgrowing reflexive thinking, explores a barrier to reflective thinking.

This article caught my attention while considering mechanisms used as substitutes for conversations.

Perhaps a penchant for one-way communication is merely one of the defense mechanisms of our reflexive thinking.

Computer Hardware Pr0n

Guy Kawasaki tempts us with pictures from Core Memory: A Visual Survey of Vintage Computers.

Oh - gotta go - here comes the wife.