In his Electric Duncan blog, Duncan McGreggor argues that Twisted now provides a viable LAMP alternative, and asks some very pertinent "so what?"-type questions:
As such, this is a direct competitor for LAMP. Here are some questions about that: What is the value of a full stack? Why is an alternative to LAMP good or needed? What is a good alternative? [...] We need to be asking ourselves what our applications are, what the network is, what services are, and what our dev teams and engineers need.This led me to ask some questions of my own. Is this true? Is Twisted actually able to provide a full-service alternative web application solution? How adaptable is the architecture? Suppose I want to retain my Django templating instead of transitioning to Nevow: how easy would that be?
The case against LAMP starts with out-of-the-box scalability, as Sean Reifschneider (among other luminaries) has pointed out. I believe that Twisted has been proven at reasonably high levels. Whether it's processing Google-sized firehoses I don't know, but it's certainly supporting a significant part of the airline reservations structure.
As to "what is a good alternative", I suspect a lot of developers would go with "something that's orthogonal to my current code, so I don't have to rewrite anything". Perhaps that's asking a bit much, though. I know from various transitions I have made that some things just "fit my brain", and one of those was the Django templating scheme. Django users are pretty much database-agnostic, though a surprising number of them seem to use PostgreSQL. So perhaps Axiom support of Django templating?
The thing is, you can't just go around claiming to be an effective competitor to LAMP. You have to demonstrate the truth of that claim. I am sure the Twisted guys can do that if they are forced. They just don't realize the marketing necessity yet.
4 comments:
Twisted is not able to provide a full-service web application solution. It probably never will, because Twisted is about communication protocols and interaction between systems. Mechanism, not policy.
Mantissa is very much a separate layer - 3 layers up, to be precise: you've got Twisted core, Twisted web, then on top of that you've got Nevow, and somewhere over to the side you've got Axiom. On top of all of that rests Mantissa, which uses every one of those pieces to provide an aspect of the scaling solution we're talking about.
Mantissa does not, as of this moment, have a fully functional, supported scaling mechanism. I've been spending pretty much every waking moment for the last month rectifying that situation, though. All that remains, for the API, at least, is a final review pass and a release. After that there's a small additional component which will use the data supplied to that API to provide "infinite" scaling transparently to its users.
Duncan probably ought to have used the future tense on a few of the claims in that post, but it's difficult to distill what's going on here into a single blog post. There's a segmented data model - which Mantissa has had for a long time, which facilitates scaling. Then there's inter-process communication APIs (the bit I've been working on) which allow your application to have interesting interactions between its data partitions. Finally there are management and deployment tools for tying the cluster together. The first part's been around for years, the second part is just becoming ready now, and the third part is in the oven.
As far as plugging in your Django templates: it's possible, sure. I don't even think it requires any special magic to get working. The issue is documentation and support. Nobody's ever bothered to do it before, and the documentation is thin even in the really well-supported areas of Mantissa. So for the time being it's going to be a real pain figuring out how to do it.
However, when Mantissa has fully come into its own as a turn-key scaling solution, I'm sure that issues like that one will rapidly get dealt with. And at the templating level, there are no technical issues that I'm aware of which would make it particularly difficult or unpleasant. Granted, you won't be able to use Athena, but for the places that you want two-way communication you can have a sprinkling of Nevow templates.
Personally, I'd be really happy to see any effort to make alternative components that people are already familiar with work inside Mantissa. At least for the forseeable future, though, you'll probably need to stick to the provided database, though :).
One essential part of the LAMP solution is its simplicity and well documented nature.None of which even remotely apply to Twisted.
The applicability of Twisted has not been demonstrated on the same breadth of applications. Sure there may be a few important applications written with it, but that is little proof of anything.
But just about any obscure language/software library has at least one application that is typically brandished. Needs more than that.
Keep in mind also that Twisted and Apache have different performance goals: Twisted is optimized for throughput, Apache for low latency. Most HTTP apps I've seen prefer the latter.
@anonymous: You might say that Twisted has not been demonstrated to be as applicable to the *average* web application or something like that, but Twisted is used in lots of applications that don't even use the web. Hence, it has a much greater breadth than "LAMP", which is a way to write web applications. How would you write BitTorrent or MV3D with LAMP?
@fumanchu: I can see why you would think so, but that's not really an accurate statement. Twisted, honestly, isn't that optimized. If you're going to do a raw benchmark, Apache will almost always win. If you were to say it were intentionally optimized, it would be optimized for concurrency; but other multiplexing HTTP servers like LigHTTPD can do that just as well.
Talking about optimization sort of misses the point, though. The place that you'd use Twisted isn't where you need a generic HTTP server but you want different performance characteristics from Apache. You'd use it when you want a high-level, programmable HTTP implementation. For example, if you wanted to have a group of servers with an API for dynamically reconfiguring their resource hierarchies. Of course, anything is possible in this world of infinite possibilities. You can do that with Apache just fine: simply write a CGI script that rewrites httpd.conf and does a killall -HUP httpd. However, the Twisted way to do it allows you to do it all on the fly, without needing intermediary representations for the configuration file, error-checking behavior if your unparser gets it wrong, understanding of the whole file when you only want to tweak some options, etc.
Post a Comment