October 31, 2005

The Web 2.0 programmer hype

I've noticed a trend lately as part of the Web 2.0 hype. Programmers are latching on to this movement and trying to project it into their world, suggesting that the "programmer experience" should also change drastically. I thought Web 2.0 was supposedly more about user experience and collaborative agility than the substance behind how you build the stuff, but hey, people want their shot at glory I guess.

So there have been a lot of wild claims floating around lately: from claims that AJAX will kill application servers, all infrastructure will be open source infrastructure, all infrastructure will be outsourced, Ruby on Rails will kill J2EE, SOAP v. REST, RDBMS' are unnecessary to manage meaning, ESB's are bad, Portals are passe', and SOA is DOA. I can't possibly tackle these all, though I will tackle the first few. And I will post a separate entry on ESBs, a topic close to my current work.

Bottom line, these are generally ridiculous claims, on many levels -- unless (of course) you're pushing an agenda. AJAX only kills application servers if you believe that Software as a Service (SaaS) will destroy enterprise IT as we know it. This seems to be the message that both Phil Wainewright and Nick Carr like to push. Similarly, programmers sick of their existing languages and environments are also searching for new ways to do Enterprise IT, and seem to feed this line of reasoning -- they believe that SaaS will allow them to join a startup and use "language du jour" such as Lisp or Ruby on Rails to teach the Java vendors & Microsoft a lesson! This view seems to have started from Paul Graham in his various essays.

From a Service Consumer's perspective, the argument makes a fair amount of sense. From a provider's perspective, or even an "ecosystem" perspective, things start to get murky. The two-second version, from a service provider's perspective, follows -- enterprise IT still needs server side code , but a world of SaaS changes everything to a simple distinction between 'service consumers' and 'service providers', where the consumers (apparently) only need the thinest layer of HTML and JavaScript to tie together their applications. And even if you do need server side code, all you need is a bit of Lisp, PHP, or Ruby. No application server. No .NET runtime. No transaction processing or reliable messaging. Maybe an RDBMS (if you insist). Obviously I'm exaggerating the extent of this strawman somewhat, but from a high enough vantage point, this really seems to be what the pundits are arguing for.

I enjoy punditry, within reason, because it makes us think. Pundits have the odd good point, but this latest wave of SaaS and Web 2.0 stuff seem to be generating a lot more strawmen than usual. There are counter arguments that are being ignored because they don't fit into the broader agenda.

"All infrastructure will be open source infrastructure" seems to be a variant of "service contracts make implementations irrelevant", and is pushed as a way of destroying the last bit of enterprise IT that SaaS doesn't kill -- software infrastructure companies like IBM, BEA, or Oracle. But it makes no sense considering how much custom development is going on behind the scenes to make these Web 2.0 companies scale and perform. Strawmen arguments like to point to Web 2.0 companies who rely mostly on open source, but this seems like bullshit to me. Last I checked, Amazon.com used Oracle, eBay used WebSphere, and Google uses Java (in spots) -- and all rely on tonnes of custom (closed!) code. And let's not forget that Microsoft is making a huge push into this world with .NET 2.0 and Indigo. Perhaps the "long tail" of Web 2.0 services will only need the small bits of infrastructure, and only the big boys will need the "beefy" application servers. It might mean you'll need to do a rewrite if you grow beyond your expectations, it might not. The upstart SaaS infrastructure players will find some successes, certainly. But let's not get carried away. "Commercial quality OSS" is still the exception, not the rule.

Now, a service consumer certainly doesn't care if you use J2EE or PHP or .NET or Ruby under the covers, so long as you meet your service contract and/or SLA. But to claim that one cannot compete based on differentiated service features is quite disingenuous. Unless the world adopts vertical-industry vocabularies on mass, service contracts will vary , with many different kinds of features and many ways to differentiate among providers. The underlying infrastructure will have an impact on the ability to deliver these features in an agile, scalable, and performing manner. Thus there will continue to be a highly competitive market in infrastructure, probably with a mix of open source and proprietary technologies.

Ruby on Rails killing J2EE seems enthrone the "web site backed by a database" as the ultimate use case. And it was - in 2002. Enterprise IT has always been about eliminating silos and creating shared frameworks and environments. The RoR camp wants a beach head, but this will create yet another set of silos! Frankly I think IT shops are getting sick of this. Yes, the productivity is useful, but the lack of interoperability with a broader aggregation / syndication strategy is going to hold adoption. Architectural governance is getting better, and I think it will be hard to push RoR unless it fits into a broader interoperability (WSRP) and manageability framework (perhaps JRuby?)

Lots of people enjoy saying that complex technologies like SOAP and WSDL will never catch on (all evidence I've seen says they have, at least inside companies), I can point to a number of counter-arguments. "Complex" is in the eye of the beholder. Is UNIX/Linux complex? To some people yes, to others no. In the server world it is popular, but to the desktop world it is pretty complex. Does this mean it's doomed?

How about Microsoft COM / ActiveX? Tonnes of software was built on this layer. Let's just enumerate the surface of complexity here: automation vs. early binding, IDL vs. type libraries, custom marshalling, apartment threading, etc. Sure, it didn't take over the world, but it certainly took over the Microsoft world (which isn't small)!

A more universal example might be SQL and the RDBMS. Despite all the trends and hype in the Java community about ORMs and people hiding their SQL, the majority of database-using applications in the Java, PHP, .NET, Perl, Python, or even good old COBOL or C++ are still programmed with heavy reliance on SQL and stored procedures. Yet lots of people still aren't able to think in terms of sets, and DBA's are still paid a lot of money to make this stuff perform because programmers can't be bothered to understand the database. This situation isn't changing any time soon.

SOAP and WS-* are not that complex by any historical measure of comparable specifications, in my view. They're composable -- you use what you need, and don't use what you don't need. WSDL is a bit of a disappointment but is being fixed. XML Schema is probably the biggest disappointment in terms of unnecessary complexity, but it looks like we're stuck with it due to the lack of interest in alternatives like Relax NG.

I see an increase in complexity all right -- not in the individual technologies, but in the splintering of the marketplace and communities. No one wants to sit down and learn what exists, everyone wants to re-invent the world in their image, their one shot at greater glory. Not that I blame them! I'm just skeptical that the collaborative spirit of Web 2.0 will bring the talent to bear to meet what the industry needs.

Posted by stu at October 31, 2005 10:14 AM