Sun Grid looks like a traditional IT stack, exposing common interfaces to enable developers and ISV's to target different abstraction layers:

The core environment is made up of a "Resource Factory" (RF), a production plant that is optimized to produce power at appropriately consumable chunks (balancing the economics of operations/distribution against typically demanded performance units). In this model the resources are managed by a Distributed Resource Manager and similarly metered/monitored using commercial DRM's and OSS/J technologies through a Service Data Record (a superset of the traditional telco model of a CDR or Call Data Record). Over time, Sun Grid will allow for multiple/pluggable Distributed Resource Managers through the support of a super scheduler which will allow a variety of resource management models to be deployed to support the various container/containment strategies for managed workloads.

Where the RF and it's blueprints are probably interesting to Data Center operators/managers who themselves are embarking on virtualization and distributed resource control/managment projects, the developers will probably not have a lot of use for this abstraction. IMO, what developers are really looking for is a set of runtime containers that are as thick/thin, complete or pluggable as their applications demand. This means that we need a container model that allows for specific orchestration.

For example, in a traditional 3-tiered (I know, nothing is traditional anymore) architecture, the separation of concern drives us to the isolation of the MVC across multiple tiers.... this means that we need a content delivery/presentation container, and a business logic container which is suitably aligned with it's data management containers/services. How do we describe these relationships in both functional and non-functional ways? Right now this is more art, than science which is to say that there are a number of different mechanisms, each with specific value propositions, and each with their own warts. Sun has the N1 Service Provisioning System (SPS), we also have DCML (an OASIS activity), WS-Management, and even techniques from the GGF which are trying to expose enterprise services using declarative markups.

This blog is getting a bit long, so I'll follow up in a second, but let me not leave without talking about the REAL value proposition for developers (the higher layers), here are some of the services that I'm thinking about:

• a repository for open source components and libraries allowing for both forward, and regression testing that developers can use, without distribution licensing concerns (caveat emptor) to build, test, re-factor, test new version... their service / application
• a repository, a vending machine really, for commercial components that can be used in a metered/rated way (see OSS/J note above) by other developers to shorten time to deployment, improve competitive comparison, open up new opportunities and markets, and allow components to compete in an open capital market/exchange (is my component really $xx better per use than yours... if it is then I'm incented to keep developing).
• a service facade for public/private hosted services that build on the economics of the Sun Grid and the pay-as-you-use model, as well as providing improved integration through close proximity to other's services (proximity remains very important in reducing latency in distributed service based architectures).
• common services, including things like federated identity and common entitlement policies that allow these ecosystems to emerge.
• a piloting ground for commercial software... instead of shipping a disk, why not take a SaaS approach where a demonstration entitlement is granted and instantly provisioned... how much could we reduce the cost of software sale.
• and finally, but not least, produce a mechanism, like the component/service mechanisms above to allow for business processes to be patterned, shared, extended and sold to perform regulatory or other tasks. Things that haven't yet emerged in the open communities, but are certain to once suitable service oriented substrates are available.

I hope that I've been able to elucidate some of the value that a common utility could provide, and facilitate through the Java.NET community as we move forward on this journey.

Please join us in the Sun Grid Community, sign up a new project, get some free grid time, and let's move this vision forward.

Technorati Tags: Sun Grid