Eric - MSFT developed technologies to solve integration and transaction management at several very different levels, and the mechanisms and administration models are quite a bit different. This makes the holy grail of "single system image" for aggregated resources difficult to achieve. Let me compare the current state of the MSFT architecture to a mature proprietary cluster architecture like the Tandem Himalaya.
First, it is obvious that Tandem has a big advantage - they can constrain application models to what they think fits their model, and they have no requirement to accommodate a broad range of potential applications - or in fact any applications that don't meet their strict requirements. MSFT has the opportunity to do similar constraint with datacenter, but they may instead turn it into an essentially feature-enhanced version of advanced server.
Second, Tandem also makes the hardware - so they can make underlying complexity in the architecture invisible to the application and transaction management layers. MSFT must allow current and future support for a variety of server architectures over which they have minimal control.
If we look at the design, capability and management model of MSFT's base level clustering, we see a synchronized failover model which does not allow load sharing, does not provide single system image, except in the sense that a failed system can be replaced by the backup at a meta-layer in terms of cluster IP address and other high level identification. The independent resources in the cluster must still be managed separately. Looking in detail at the material below microsoft.com
shows the incompatibilities of the different clustering mechanisms.
At the next level up, we see app center providing load sharing and "scale out" capacity management, and the most complete framework for the use of COM+ components. But even here there are a number of somewhat independent technologies, and going down one path can preclude a user from the capabilities available in other paths. You can get the flavor from
microsoft.com
At an even more abstract level, we have the BizTalk components, which provides some workflow management and translation between metadata to allow more integrated management of business interactions. There is a pretty decent white paper at
microsoft.com
I could also discuss the new SQL Server - they also add a lot of capability, but not yet in a fully integrated way. This bunch of technology offers solutions for a lot of common problems, but these capabilities would be exponentially more powerful if the programming models were more integrated, if each layer built on the layers below in a way which makes the underlying services transparent, and if the administration model allowed aggregated resources to be managed as entities, rather than forcing both administration of underlying components and separate administration of the meta-layers. |
