Unless I am very much mistaken bloglines has finally nailed the performance issues plaguing the service. Performance was bad enough that Stephen, for example, has been trialing an alternative (Bye For Now Bloglines). Others are too, if the co…

You can sign up for the webinar there.

(note to self: must remember to preview before posting!)

As far as a briefing, I’m giving a 30-minute webinar on Tuesday. It has some high level description, but then I actually get in and write some code (grid-enabling a .NET app as you watch). If you’d like to take 30 minutes, this is a good opportunity.

Or, if you’d like a more personal, directed briefing, e-mail me at dan (at) digipede (dot) net and we can set something up.

One other point to make: scalability is very expensive, it’s true. But planning for scalability isn’t necessarily expensive–you have to make smart decisions when designing your solution. On the other hand, if you don’t make smart decisions at design time, then you can end up having to re-write your software–and that can be a very expensive process.

Not planning to scale is like planning not to succeed. You have to plan to succeed.

Jeremy: totally agreed. the way that i was talking about it w/ Alex last night, it should be some sort of union type situation. pool together for collective purchasing power, etc.

Jim: you actually scooped me there – well done. i was thinking about a scenario in which some of the bigger providers – folks such as Google, Microsoft and Yahoo – that presumably know how to scale, would become providers of a sort as well. more on that later.

Dan: interesting. would love to talk to you more about that. one question: do you support Mono apps as well?

James: not sure if that’s exactly the pushback the lesscode folks had against sabbah. danny didn’t ask questions, unfortunately, he said it couldn’t scale – and the lesscoder’s acted as they probably should.

http://naeblis.cx/rtomayko/2005/05/28/ibm-poop-heads

same in the Java world. a “J2EE” app that doesnt index data but constantly hits a database is not going to scale, regardless of how many servers you throw at it.

in terms of your resource question, lets just look at google analytics- which, it did *not* design, but acquired. google doesnt lack the resources to “host” these services it acquired. so what *is* happening. why can’t google do it? i would argue that the initial google architecture design was scalable in a way some of these new services might not be.

the whole notion of scale is problematical too. there is a lot of expectation management in this space. when Danny Sabbah asks questions of PHP lesscoders call him an asshat. When Stephen O’Grady asks about web 2.0 scale he is applauded.

now i fully understand that web 2.0 and PHP are not interchangeable. but the point i am trying to make is about expectations.

there is also an interesting similarity with Microsoft’s growing up. in that didnt microsoft focus initially on user experience, with no real scalability of design. the question in my mind is can web 2.0 players really deliver scalability as a service (rather than the lumpy improvements and forklifts we saw with windows). ie happening at the back end without the user noticing. we’ve seen some moves in that regard-typepad for example (we noticed the degradation but not the upgrade). which i guess brings us back to your question.

i think a definition of scale would be useful. subsecond response times across many users? or what? that is one reason i like your google example.

that is there is no latency in a google search. compare and contrast with my supposed rich client, where i spend many minutes a day wondering what in the hell the machine is doing.

that is another advantage of services 2.0 – that is, it makes a lot of sense to just focus on scaling one service, rather than trying to scale *any* service. back to google…

just a few thoughts.

I a certain sense, that is what Akamai did for Web 1.0 companies–at the Dean campaign we would pay extra for bandwidth at peaks, to Akamai, and though it was expensive it was better than the alternative. To send out the “Judy Dean interview” video online we spent $70k in a day or so.

Another better solution, certainly for a Web 1.0 site, would be some sort of bittorrent-based cooperative arraingment. Had bittorent been fartr along during the campaign, we could have gotten 30k or so users or more to host torrents on their computers, and driven our cost for video dowloads to zero. That would have let us use a lot more video, which would have been fun and perhaps effective.

It strikes me that in the Web 2.0 world scalability is not as simple as in Web 1.0. The server and processing issues are more central, because at heart the services are more computationally intensive. Bandwidth alone is not a solution.

Technorati is a perfect example, with complex combinatorial searches as its core offering, but very light bandwidth requirements. No way is it going to be able to keep up with Google’s server and processing and computational capacity, methinks.

It would be interesting if Microsoft or another big company found a way to do the core backend work for Web 2.0 companies, in trade for some sort of revenue shares or traffic building. This could lead to a federated organizational structure competing with Google’s and Yahoo’s more centralized organization and technology infrastructure.

That might be an interesting development in the ecosystem..