Tiago Pascoal's WebLog

Hello Good Evening and welcome to nothing much.

Is Yukon the end of the middle-tier II?

This isn't a real followup of my original post. But since the original post generated some responses i would like to address them here.

I will skip the first one: Kaneboy nothing personal but the post is written in some asian language, i fed it through babelfish by trial and experience and seems to be chinese. :-)

Anyway, it's a small post but it seems (if we trust babelfish and assuming i chose the right language :-)) to somehow agree that the middle tier is obsolete.

The second one argued that yukon will be a platform. No doubts there, If it was for microsoft wishes even Solitaire would be a platform :-). [Ray Ozzie once wrote the best description of a platform i once read online.]

Ok, i'm exagerating, but i think it's truth at a certain point, for MS the more the platforms the better, and the more platforms that leverage and extend the Windows (and office) franchise. If you have read Breaking Windows you can see how any (even internal) threat to the windows franchise is handled.

A platform is also great for Microsoft (at least for now) because it allows the sharecroppers to benefit from it (not to mention how well it sells windows platform thus increasing network externalities for MS products).

Although i think for a while now a MS culture change has started, and it's morphing into a different company (more open) it's not enough yet, i was excited with Infopath as a platform until i understood that you had to had office installed to use it. It such an impediment i don't see Infopath franchise flourishing as well as it could.

Saying that, i don't understand articles like this ones, angry coder is well angry at Microsoft for releasing SQL Server Reporting Services with a SQL server dependency when technically there are no reasons for such a dependency.

[Beware take my view with a grain of salt, obviously i'm not qualified to emit any opinions on strategy & economic matters, but since that never stopped me in the past i will emit them anyway. :-)]

" So why is it that Reporting Services only works with SQL Server? As far as I can tell, the database that stores the report formats is merely used as a data repository, and it can't be an OS and/or platform requirement because Oracle, MySQL and other database platforms can run on Windows. Did the Reporting Services team at Microsoft just not want to have to write PL/SQL stored procs for Oracle , or not want to bother figuring out how to port their SQL Server database to another DBMS? I wish I could find the answers to these questions. I'm curious."

You are right there are no technicall reasons but there are business reasons and microsoft seems to be in the business off licensing (renting? :-)) things (the more the better). Here microsoft is crossing that line between the user of the product and the ISV that build upon that platform (they have a history of that). A free product benefits it's users and goes against it's partners (crystal reports is the first one i can remember in this particular case, but i'm sure there are a lot more), but let's assume for a moment that with this step MS isn't stepping on ISV toes. Microsoft is using Reporting Services as a complementor to sell Sql Server because for MS that all there is (regarding db systems that is :-)), it wouldn't make any (business) sense to gain a few bucks selling a reporting product, if that meant not gaining much more for a Sql Server license or heaven forbids someone using reporting services for increasing (or preserving) a market share of a competitor. (i bet Larry would have a blast presenting annually results, stating how many new sales have been generated by Reporting Services :-)). Another reason is probably MySQL which is clearly a disprutive technology that is upscaling and is becoming a contender for MS SQL Server. [Update: Why MySQL grew so fast]

[BTW a new book on Reporting services is being written and the first 2 chapters can be download for reviewing here (via Jon Box)]

[the same reasoning can be applied to ObjectSpaces question]

Anyway this was just to ilustrate that indeed i also think Yukon will be a platform. At least for the people in the second group of my original post. For the first ones, they don't care for the platform, only for it's speed and stability. :-)

The second post is from Harry Pierson and with this post i have some disagreements.

[Update: Ingo Rammer has add it's 2 cents]

[Update: Harry has a followup]

Harry states, that the middle tier will move into the database because Moore Law is on our side. Ah speed, yes we like that the more the better. But unfortunately speed is all very nice, but when the comes to scalability speed probably isn't the main factor (I/O bandwith, CPU cache coherence (to a lesser degree), memory speed).

The main problem that affects scalability is contention, resource contention and as i stated here the data seems to be the major contention point.

Adding a faster CPU means other tasks will wait a little less, but you will have to have contention somewhere if you wish to preserve your data integrity.

Surely for some systems a single system would be more than enough, but for those that aren't i would love to see yukon supporting transparent data partitioning (i'm not talking about spliting data files among different spindles or filegroups) either in the same database or several distributed databases (transparently).

Harry says to a point "It even makes sense to build a both an application and a messaging infrastructure directly into the database engine." i wonder where does this leave Indigo?

Harry also says

"We also need better management. And not incrementally better, orders of magnitudes better. If you're going to replace a single BIG app with hundreds of independent services, incremental manageability improvements are not going to cut it. "

Agreed, and google groked this a long time ago and i really hope DSI will improve things on these matters. 

 

Similar thoughts, also generated by Harry Pierson post:

From Ted Neward and Ed Draper. (but more thorough and eloquent than me)

 

 

Comments

No Comments