This post originated from an RSS feed registered with Web Buzz
by Mark Masterson.
Original Post: Blinded by the lamps..
Feed Title: Process Perfection
Feed URL: http://www.jroller.com/MasterMark/feed/entries/rss
Feed Description: Life, the Universe, workflow, BPM, Java, Ruby, functional/generative/meta programming, pi calculus, patterns, the Grid, agents, software architecture and the kitchen sink. :)
Bob and Kevin go back on forth on the Pile O' Lamps meme. Too fast for me, really, but since it's partly my idea, I kind of feel a kind of parental responsibility for it. As has been the case since Kevin and I began talking about it on his Aloof Architecture blog, I have the feeling that he and I are (more or less) on the same wavelength. I agree with some of the things that Bob's saying, and certainly everything he says is extremely interesting. But I'm not 100% convinced that we're on the same wavelength. Whatever the business model of Smoothspan is, it seems to have something to do with SaaS. And I get the feeling, reading some of the things that Bob's written, that he's got a hammer in his hand, and is seeing nails. Observation: that doesn't mean that they're not nails. Bob may be absolutely correct. For my part, I'm not ready to say yet.
Anyway, I feel compelled to respond to some of these things, but I can't claim to have thought through it all yet. Some of what follows may therefore be a bit half-baked. So be it. Release early, release often.
Some of the things that Bob has suggested gave me pause. For example:
Is the machine the object? Whether or not it is, our software layers must take account of machines as objects because that’s how we pay for them.
Whoof. Hold on there, Bob. The places I work have huge investments in existing mainframe hardware - entire data centers. Those data centers are aware of the threat that SaaS poses to them, and they're not going to simply die without a fight. Certain white hot discussions currently happening between closed doors about chargeback models are all about this (ahh, MIPs. Almost as silly as function point voodoo), for example. Anyway, the point is: machines are not the (only) de facto unit of computing cost in this environment. Even if whatever horse Bob is betting on wins, and SaaS changes that, it will take awhile. Do we just get to build Piles O' Lamps for the cool kids that purchase SaaS? That would mean no fun for me, so I dislike that scenario. As I've said in the past, I was on the front lines of the last War Against The Data Center. We were sure we had it down for the count, last time round, but it wasn't. So I have learned to respect the data center, and to be skeptical of rumors of its demise.
Bob explains:
LAMP refers to Linux as the OS, Apache as the web server, mySQL as the database, and a “P” language (usually PHP or Python) as the langauge used to implement the application. It has become almost ubiquitious as a superfast way to bring up a new web application. There are some shortcomings, but by and large, it remains one of the simplest ways to get the job done and still have the thing continue to work if you move into the big time. A Pile of Lamps architecture would presumably simplify scaling by building it in at the outset rather than trying to tack it on later.
... and that's absolutely accurate, but as one of the parents of the idea, I feel compelled to point out that a strict interpretation of the "lamp" term as acronym is much more constricted than what I was thinking of. Rails on AIX using DB2 could still be a "lamp" in my book. The deciding factor isn't the programming language, the database vendor or the operating system -- it's the architecture of a lamp that counts (which may mean that we need to define that more clearly;)).
In his first post, Bob applies Roy Fielding's analytical framework to the Pile O' Lamps style, and gets close to what I think it is, but he stops short of adding statelessness to the mix, which I think it needs.
In his later post, Bob poses three questions we need to answer to attack the problem of how to manage the radically distributed systems landscape that Kevin thinks about in his latest post. Bob's second question:
How do we allocate activity to our scalability units? Examples include load balancing and database partitioning. Abstractly, we need some hashing function that selects the scalability unit to allocate work (data, compute crunching, web page serving, etc.) to.
I see this as being a kind of a tuplespace, Bob. A distributed tuplespace. Does that make sense? Toss a unit of work into it, and whatever agent is best suited to attacking it (where that is a function that takes load, fitness for purpose, locality of reference (thinking of Connie Smith, SPE here), and so on, into account), does so.
Bob's third question:
What is the mechanism to rebalance? When a scalability unit reaches saturation by some measure, we must rebalance the system.
Whoof again. In a Twitter exchange with Kevin, I pointed out that really good system management functionality being baked into the stack of a lamp is a key enabler for the overall idea -- without it, no piles of lamps, really. But what Bob's getting at here goes way beyond that, into the realm of feedback loops and self-adjusting systems. Cool stuff, but those are applications that we still need to write, by and large, in my experience. They (still) don't exist in most enterprises, despite the fact that we've a) known how to do this and b) had the basic tools to do it for about 20 years now. Kevin's idea of systems that re-provision themselves is going to be hard to implement too, and is utterly dependent on getting the system management building blocks and feedback loops right.
Finally, Bob poses a fourth question, and it's a cracker:
How do the scaling units communicate when the resources needed to finish some work are not all present within the scaling unit?
How indeed. The world is full of answers, of course, just -- which one do we choose? Bob suggests, for example, that it would be cool if we could hide the complexity of this problem from the app developers. Whoof yet again. Dunno, Bob. I've grown skeptical of paradigms that "hide complexity" from app developers. The trick here will be to solve this without introducing a solution that's worse than the problem (cue CORBA, J2EE, WS-*).
This is all deeply cool stuff, but there's still a lot of details to hammer out, and that's where the Devil always lurks.
Previous Topic
